er det en fejl af Design Compiler?

[jinruan]

der er sådan en kode i mit design, men når jeg syntetisere koden, finder jeg resultatet er forkert. Hvad er problemet? er det problemet med min kode, eller er det en fejl i DC? målet biblioteket er slow/CSM25. koden: (! rst_n) altid @ (posedge CLK eller negedge rst_n), hvis dout

 

[news]

W ramach programu Project Zero firma Google automatycznie udostępniła raport, z którego dowiedzieć możemy się o luce w systemie Windows 8.1. Oznacza to, że Microsoft wiedział o niej 90 dni.

Read more...

 

[leeenghan]

Hej Jinruan, Be tålmodighed og spore gennem logik. Begge er de samme. Overvej resultatet fra Synopsys, og overveje de tilfælde, hvor larmen == 0 og DIN == 1, og du vil se, hvor smart Synospsy er! Af den måde, bruger værktøjet scanne FF at gennemføre logik. Dette kan ikke være en god idé, hvis du vil indsætte scanne senere, eller engang tidspunktet fra SI sti kan give overraskelse (fx meget lang setup tid). Regards, Eng Han

 

[jinruan]

men når "larmen" nå cellen langsommere end "da", eller når DIN er "x" tilstand nogle gange, den dynamiske simulering viser, at dout vil altid være i "x" tilstand.

 

[leeenghan]

Hej Jinruan,>> men når "Din" nå cellen langsommere end "da" Hvis dette er tilfældet dit design kører alt for langsomt for clock-hastighed. Der er en grund til, at DC skabe den logik, som denne. Sandsynligvis kredsløb er mindre / hurtigere sammenlignet med den, du forventede.>> når DIN er "x" tilstand nogle gange Hvis du har dette problem, er du nødt til at forbedre den model for FF. Hvis "da" er "X", men både de andre 2 indgangene på MUX er både "0" eller "1", så er output bør være den værdi af input. Det er muligt at modellere denne adfærd ved at bruge port (selvom jeg ikke kan huske off-hånd). Regards, Eng Han

 

[joe2moon]

>> Men når "Din" nå cellen langsommere end "da? Det gør ikke noget" DIN "eller" da "signal nå først, så længe de begge er stabile før CLK (ur) stigende kant. Så hvis Deres syntese mødte timing, så skal du ikke se "x" (ukendt) vises i dout (output). ------------------------- -------------------------------------------------- ------------>> der er sådan en kode i mit design, men når jeg syntetisere koden, finder jeg resultatet er forkert. Af den måde, måske bedre er det at gøre logikken ækvivalens check af værktøj, snarere end at gøre det manuelt. (Ex. Conformal-LEC eller formalitet, der kan gøre det godt.) og lav de STA (statisk timing analyse) for at sikre, gate-niveau netlist og tilsvarende SDF (standard forsinkelse format) fil opfylder timing. Endelig, hvis der stadig gate-level simulation problemer eksisterer i design, og derefter sammenligne simuleringen resultat (måske bølgeform) mellem de "forventede" resultat og den "forkerte" en for at finde ud af årsagen. ----- -------------------------------------------------- --------------------------------- Håber ovenstående oplysninger kan hjælpe med mere eller mindre.

 

[ManojG]

Hej Eng Han, tilgiv min uvidenhed. Jeg har en tvivl om den erklæring SDFFRX1 (SI (en), SE (DIN), D (1'b0), CK (CLK), RN (rst_n), Q (dout)......); == SDFFRX1 (SI (DIN), SE (en), D (1'b0), CK (CLK), RN (rst_n), Q (dout)......) Som pr RTL, når en == 1'b1 dout

 

[AH Ling]

altid @ (posedge CLK eller negedge rst_n) if (! rst_n) dout

 

[jinruan]

Jeg har syntetisere koden med de tre kodning stil, og fandt, at resultatet er det samme.

 

[tony_taoyh]

Jeg tror, du kan prøve at bruge: (! Rst_n) / / Synopsys async_set_reset "rst_n" / / Synopsys sync_set_reset "da" altid @ (posedge CLK eller negedge rst_n), hvis dout

 

[heartfree]

Kan du indsætte adfærd model SDFFRX1 i dit bibliotek? Jeg har samme puslespil med ManojG