een probleem in de pre-simulatie met annoteren sdf

[jinruan]

Hi, all.
Ik heb een probem in de pre-simulatie.Toen ik de poort-netlist simuleren zonder sdf informatie, de stroom is OK, maar als ik de poort simuleren-netlist met sdf annotatie, de klok signaal golf verkeerd is (bijvoorbeeld dem_clk is een van de kloksignaal in mijn ontwerp, en het is trager dan mijn verwacht. Waargenomen van de golfvorm, dem_clk is 8MHz in de simulatie geen sdf annotatie, maar dem_clk is alleen veel langzamer dan 8MHz in de simulatie met annotatie sdf), en ik heb gemerkt dat wanneer ik lopen pre-simulatie met sdf annotatie zijn er enkele waarschuwing in ncverilog logbestand.zij aangeven wat de timing negatieve waarde in het sdf-bestand.
Ik geef de waarschuwing als volgt, geef me wat te adviseren.
dank vooraf!

PS1: (waarschuwing in DC logbestand voor kloksignaal en reset-signaal)
write_sdf active_design "_syn.sdf"
Informatie: vertragingen cel Geannoteerde 'wordt verondersteld dat de belasting vertraging op te nemen.(UID-282)
Informatie: Actualisering informatie over het ontwerp ...(UID-85)
:!: Waarschuwing: blue_modem Design '' bevat 2 hoge fanout netten.Een fanout aantal van 1000 zal worden gebruikt voor berekeningen met betrekking tot uitstel van deze netten.(TIM-134)
Informatie: Schrijven timing informatie naar bestand '/ export/user/jinruan/project2005/bluemodem/V2.0/syn/blue_modem_syn.sdf'.(WT-3)

<img src="http://www.edaboard.com/images/smiles/icon_question.gif" alt="Vraag" border="0" />

(Een van de 2 high-fanout netten is dem_clk signaal)
PS2: (waarschuwing in ncverilog log-bestand)
:!: ncelab: * W, SDFNL1 (/ export/user/jinruan/project2005/bluemodem/V2.0/lib/csm25.v, 19189 | 12): Poging om annoteren een negatieve waarde aan een 1 limiet timing check-in aanleg (test_blue_modem.BLUEMODEM.BLUEDEM.IFIR.GFTROM6.dout_reg_20), waarin tot 0 </ export/user/jinruan/project2005/bluemodem/V2.0/syn/blue_modem_syn.sdf, lijn 460649>.
$ herstel (posedge RN, posedge CK, TREC $ RN, NOTIFIER);

 

[eda_wiz]

ikQuote:

t's trager dan mijn verwachting

 

[luancao]

de klok signaal moet worden ingesteld met set_dont_touch_network attribuut te houden onaangeroerd in de synthese.Dat is een ding.Maar het lijkt erop dat zelfs buffers worden ingevoegd om uw klok in de synthese uw klok frequentie zal worden unchange.

Als je het zou kunnen beschrijven geval in detail kunnen wij u helpen.

- Je klok is toe te voegen in testbench die 8M.Waar heb je in acht werd het veel "langzamer" (bv. om 7M)?Op de CK pin van de DFF?Bij de ingang van uw ontwerp?of een knooppunt andere dan hierboven?

 

[leeenghan]

Hi jinruan,

Ik zie dat je nog steeds worstelen met post-synthese simulatie.

Ik denk dat de volgende uit het logbestand:

> PS1.
U hebt ten minste een grote fan-out net (meer dan 1000) in uw ontwerp.Je hebt een buffer creëren geen boom voor de hoge fan-out-net, die juist is.Echter, als je gaat een sdf op dit punt te genereren, de poort rijden de hoge fan-out net gaat heel erg traag zijn.Als de hoge fan-out net is de klok, de klok sloeg hugh zal de FF vertraging zeer zeer traag.U kunt:

1.Vertel het gereedschap dat de hoge fanout net is "ideale net".Kan dit doen in Ambit, maar niet zeker of dit kan worden gedaan in DC.Iedereen kan verlichten ons?

2.ga door naar synthese de hoge fan-out netto (dat wil zeggen niet ingesteld dont-touch-net).Echter, de netlist dan goed voor simulatie, maar niet zo goed voor P & R.Mei tegenkomt probleem als clock skew (als de hoge fan-out is net klok)

3.bewerken van de sdf-bestand.Wijzig de vertraging van de klok bestuurder en de vertraging van de hoge fanout net.> PS2
Er is een negatieve setup of houd controleren.Nieuwe versie van SDF Synthax accepteert geen negatieve instelling en houd controleren, en zal de waarde nul.Groeten,
Eng Han

 

[jinruan]

Hi Han
Ik heb set_dont_touch toe te kennen aan "dem_clk" en "CLK" "rst_n", "dem_clk" "CLK" zijn de gegenereerde klok in mijn ontwerp, en "rst_n" is de gegenereerde reset signaal in het ontwerp.Ik heb opzoeken de schending rapport dat "CLK" en "rst_n" zijn de hoge fanout netten.het zijn de volgende overtredingen:
PS1:
max_transition

Vereiste Actueel
Netto Overgang Overgang Slack
-------------------------------------------------- ---------------
rst_n (dont_touch) 4,50 394,25 -389,75 (geschonden)max_capacitance

Vereiste Actueel
Netto Capacitance Capacitance Slack
-------------------------------------------------- ---------------
rst_n (dont_touch) 6,24 1012,00 -1005,76 (geschonden)
CLK (dont_touch) 6,24 7,63 -1,39 (geschonden)

en ik heb het gecontroleerd. sdf-bestand en vinden dat de timing vertraging waarde van "rst_n" en "CLK"
is meer dan 50 (het is dus groter).

PS2: Ik heb enige twijfel als volgt:
1) "dem_clk", "CLK" beide zijn de gegenereerde klok, en ik hebben dezelfde toegeschreven aan hen, en zij beiden rijden veel DFF, waarom "CLK" hebben het ontwerp-regel violaiton maar "dem_clk" is dat niet geval is?
2) wanneer simulatie, "dem_clk" is veel trager dan 8MHz, heb ik controleerde de golfvorm dat "dem_clk" is ongeveer 250kHz (waarom? Waar komt het vandaan kwam?)

 

[leeenghan]

Hi Jinruan,

Ik denk dat je weet wat er gaande is naar "PS1".

Voor "PS2", kan ik niet denken van een reden.Ik stel voor dat je de golfvorm trace van de inbreng van van de gegenereerde klok om de output van de gegenereerde klok.Moet in staat zijn om uit te zoeken de oorzaak op deze manierGroeten,
Eng Han

 

[dcreddy1980]

PS2: (waarschuwing in ncverilog log-bestand)
:!: ncelab: * W, SDFNL1 (/ export/user/jinruan/project2005/bluemodem/V2.0/lib/csm25.v, 19189 | 12): Poging om annoteren een negatieve waarde aan een 1 limiet timing check-in aanleg (test_blue_modem.BLUEMODEM.BLUEDEM.IFIR.GFTROM6.dout_reg_20), waarin tot 0 </ export/user/jinruan/project2005/bluemodem/V2.0/syn/blue_modem_syn.sdf, lijn 460649>.
$ herstel (posedge RN, posedge CK, TREC $ RN, NOTIFIER);Om de hierboven genoemde probleem, plz proberen om dezelfde beperkingen stellen zoals i / p vertraging, clkdelay ..... en zo verder in ur testbench ook.