Timing Simulation Problem

B

b01010101

Guest
Mitt design er implementert på MAX7256AE.
Jeg bruker QuartusII å systhesis og passer på design.The Classic Timing Analythesis rapporterer at fmax av CLK kan få 84.03MHz, og ingen feil eller advarsler
rapportert.
Jeg tar timing simulering i Modelsim-SE6.2b og møte med denne feilen:

/ / Feilmelding / /
# ** Error: D: / Modeltech_6.2b/win32/../altera/verilog/src/max_atoms.v (2070): $ oppsett (datain: 379100 ps, posedge clk & & & reset: 381200 ps, 2900 ps);
# Time: 381200 ps gjennomkøyring: 0 Instance: / testcase / inst_harness / u_FCT / \ r_addr [4] \ / preg
# ** Error: D: / Modeltech_6.2b/win32/../altera/verilog/src/max_atoms.v (2070): $ oppsett (datain: 379100 ps, posedge clk & & & reset: 381200 ps, 2900 ps);
# Time: 381200 ps gjennomkøyring: 0 Instance: / testcase / inst_harness / u_FCT / \ r_addr [5] \ / preg
.
.
Alle feilene oppstår i 381200 ps, det kurveformen er koblet nedenfor (ft_lck er klokken):<img src="http://images.elektroda.net/80_1240991013_thumb.jpg" border="0" alt="Timing Simulation Problem" title="Timing Simulation Problem"/> Q1: Jeg forstår ikke hvorfor denne feilen oppstår.Det er bare en enkel asynkron tilbakestilles når 'pc_rst_n' er lav.Hvorfor den ikke kan møte det setup tid?
Jeg synes at denne feilen ikke vil skje hvis jeg flytter pc_rst_n noen ns tidligere eller senere.Men hvorfor feilen skjer i noen situasjon?
Hvorfor Classic Timing Analysis ikke rapportere dette problemet?

Koden er bare så vanlig.Deler av kildekoden er vist nedenfor:
/ / Source Code / /
alltid @ (negedge ft_lck eller negedge pc_rst_n) begin
if (~ pc_rst_n) begin
......
r_addr <= 19'h0;
......
slutt
else begin
......
r_addr <=......;
......
slutt
slutt

Forresten, jeg har 2 flere spørsmål:
Q2: Hva gjør "~ dataout" og "~ pexpout" betyr i bølgeform henholdsvis?
Q3: Hvorfor "sram_addr ~ 743_dataout" er før "sram_addr", men "ft_lck ~ dataout" er etter "ft_lck"?

 
b01010101 skrev:

/.../ Jeg ta timing simulering i Modelsim-SE6.2b og møte med denne feilen /.../
 
when close to the active slope of the clock?

Så, det samme problemet eksisterer også når asynkron reset aktiveres
når nær den aktive skråningen av klokken?

Derfor er det ikke min design problem.Er det noe jeg kan gjøre for å unngå det som skjer?

Betyr dette problemet saker?Betyr det betyr ethvert design med asynkron reset er upålitelig?Når du tilbakestiller, kan utformingen komme inn i en ukjent tilstand.

Thank you so much!

 
b01010101 skrev:

Så, det samme problemet eksisterer også / ... / aktivert

når nær den aktive skråningen av klokken?
 
Quote:

Så, det samme problemet eksisterer også / ... / aktivert

når nær den aktive skråningen av klokken?nei, i så fall bare noen FF's er reseted litt raskere

enn andre;
 
b01010101 skrev:

Men i simulatoren, oppstår ved 381200ps (nær rst_n 1 -> 0 )/.../
 

Welcome to EDABoard.com

Sponsor

Back
Top