verilog simulatie vraag

[floatgrass]

Als ik posedge klok Triger altijd verklaring, maar A Sigal is posedge veranderen, simulator denk dat het zo laag niveau, maar dat is voor de synthese ok?

indien Pix_Mux_s1 [7] veranderen 0-1, op hetzelfde moment memtemp_v1 veranderen Frome een waarde naar een andere waarde, hoe toewijzen?Het is na of voor de verandering?
bedankt!
altijd @ (Mem_Pointer_s1 of pixel_s1 of Pix_Mux_s1)
beginnen
if (Pix_Mux_s1 [7])
beginnen
zaak (Mem_Pointer_s1)
3'b001: begin
pixelcol_v1 [23:16] = pixel_s1;
pixelcol_v1 [15:8] = memtemp_v1 [15:8];
pixelcol_v1 [7:0] = memtemp_v1 [7:0];
eindigen

3'b010: begin
pixelcol_v1 [23:16] = memtemp_v1 [23:16];
pixelcol_v1 [15:8] = pixel_s1;
pixelcol_v1 [7:0] = memtemp_v1 [7:0];
eindigen

3'b100: begin
pixelcol_v1 [23:16] = memtemp_v1 [23:16];
pixelcol_v1 [15:8] = memtemp_v1 [15:8];
pixelcol_v1 [7:0] = pixel_s1;
eindigen

default: pixelcol_v1 = memtemp_v1; / / niets nieuws geschreven
endcase
eindigen
eindigen

 

[z81203]

Hoi,

Ik denk dat de reden is dat je "altijd" conditie.

"always @ (Mem_Pointer_s1 of pixel_s1 of Pix_Mux_s1)"
heb je drie bundel, moet u ze beschrijven detail hier.

synthese tool desn't zorg hen, maar simulatietool zorg hen.

gewoon proberen.

BR
z81203

 

[stevepre]

z81203, wat heb je het over?Dit is verilog, niet VHDL.floatgrass 's bijvoorbeeld heeft geen behoefte aan meer uitleg.

Nu hier zijn de problemen van bijvoorbeeld floatgrass's:
1.It's gonna afgeleid een grendel, omdat de if-statement is niet compleet.(Je hebt als (Pix_Mux_s1 [7]), maar geen "anders".

2.gevoeligheid van memtemp_v1 ontbreekt.

OK, nu je vraag is of Pix_Mux_s1 [7] veranderingen op hetzelfde tijdstip als memtemp_v1, wat zal gebeuren.

Je moet niet vergeten een ding, er is niet zoiets als "op hetzelfde moment" in een simulator.Er is altijd een bestelling.Hoewel de simulator "schema" op hetzelfde moment, er is altijd een bestelling.De volgorde is meestal de volgorde van uw code, maar niet noodzakelijk, het hangt af van de simulator.

Laten we 2 gevallen, en draagt zorg voor uw simulator schema evenement volgens de volgorde van uw code.
En nemen "B" veranderingen precies dezelfde tijd als Pix_Mux_s1.

case 1:
altijd @ (B)
memtemp_v1 = B;
altijd @ (Mem_Pointer_s1 of pixel_s1 of Pix_Mux_s1)
.... dit is je grote altijd blokkeren

case 2:
altijd @ (Mem_Pointer_s1 of pixel_s1 of Pix_Mux_s1)
.... dit is je grote altijd blokkeren
altijd @ (B)
memtemp_v1 = B;Laten we een kijkje nemen op uw vraag:
in geval 1: pixelcol_v1 krijgen "NEW" memtemp_v1 waarde omdat memtemp_v1 berekenen was eerder dan je altijd blokkeren.

in geval 2: pixelcol_v1 krijgt "oude" memtemp_v1 waarde.*** Het grootste probleem is dat je gemist memtemp_v1 gevoeligheid in de lijst.

Stel dat u toevoegt aan uw memtemp_v1 gevoeligheid lijst, zowel in geval 1 & 2
pixelcol_v1 krijgen "NEW" memtemp_v1 waarde

WAAROM?
Neem een kijkje in geval 2:
op tijdstip T, de simulator schema:
1.evalueren pixelcol_v1 omdat Pix_Mux_s1 wijzigingen
2.evalueren memtemp_v1 omdat B veranderingen
3.evalueren pixelcol_v1 AGAIN omdat memtemp_v1 veranderingen als gevolg van veranderingen B

Als u niet memtemp_v1 in uw gevoeligheid lijst, in principe de simulator zal overslaan "3", dat is waarom het zal verknallen.

Genieten.

 

[floatgrass]

dank voor uw zorgvuldig antwoord.
i toe te voegen aan sensitylist, vinden uitkomst is intant waarde, maar vóór de uitkomst is voor veranderingswaarde

 

[andromeda]

Over uw eerste vraag:
u kunt proberen om het oplossen van delta-cyclus afhankelijkheid probleem (die er alleen voor functionele simulatie en bestaan niet in het post-synthese netlist met vertragingen) in followig manier:
gebracht klein deel van de klok cyclus (laten we zeggen 10%) als een vertraging in sequentiële processen (in next_state -> current_state en, indien reset is synchroon, in reset_state-> current_state), geen vertraging in de combinatorische processen zetten
deze vertragingen worden genegeerd door synthese tools (zal sommige Waarschuwing messeges, maar dat is onbelangrijk), maar het zal oplossen delta-cyclus afhankelijkheden probleem
andere (maar ingewikkelder Mogelijkheid) is het aantal processen evenwicht in elke klok weg - het is moeilijk te bereiken en je moet experimenteren met dat om zeker te zijn over de resultaten