plaats en route in soce met / zonder vergrendeling

L

ludan

Guest
Hi guys,

Ik ben geconfronteerd met het volgende probleem sinds een tijdje: blockA <-> blockB,
aan de uitgang van blockA er een FF en een draad die verder gaat als input voor een klinkinrichting
in blockB.
Als ik deze twee blokken in soc ontmoeting met een bepaalde afstand (5 mm)
Ik zie een zekere vertraging (~ 3ns) op de link koppeling van de twee blokken.

Nu als ik de plaats van de vergrendeling in blockB met een FF en ik plaats de blokken op de
dezelfde afstand van 5 mm, de vertraging Ik zie op de interconnectie link 1.7ns

Kijkend naar de timing rapport, is het duidelijk dat het gebruik van aan beide zijden van de FFS,
de tool optimaliseert de link inferring buffers met een grote drive sterkte.
In het voorbeeld met 1ff en 1 klinkinrichting, de buffers afgeleid zijn kleiner en de
vertraging is veel hoger.

Nu mijn vraag: is er een specifieke reden waarom het instrument niet herkent
een dergelijke lange verbinding tussen A en B als het kritieke pad in geval gebruik ik een klinkinrichting?
Het is duidelijk het kritieke pad (zoals aangetoond door het experiment met 2 FFS), maar
om wat voor reden dan wanneer ik een klinkinrichting die pad wordt niet herkend als kritisch,
daarom het streven naar optimalisering van de band is laag en de definitieve interconnectietarieven
vertraging nogal hoog (en teleurstellend)

<img src="http://www.edaboard.com/images/smiles/icon_sad.gif" alt="Triest" border="0" />Ideeën?

 
Heeft u een setup schendingen met ofwel aanpak?Het is mogelijk dat de tool gebruikt tijd lenen bij het gebruik van de vergrendeling.Controleer het gereedschap variabelen te zien hoe je klinkinrichting tijd lenen aan / uit en lopen wat meer tests.

 
In beide gevallen heb ik schendingen het enige verschil is hoe groot ze zijn:
- Zowel FF: 1.7ns
- 1 FF en 1 klinkinrichting: 3ns

Voor zover ik kan zien uit de report_timing in prime time:

Punt Incr Pad
...
..
tijd ontleende eindpunt 0,00 0,64
...
...

wat betekent dat er geen tijd is geleend

<img src="http://www.edaboard.com/images/smiles/icon_sad.gif" alt="Triest" border="0" />de andere grappige is dat het instrument niet lijkt te herkennen dit pad als kritisch te wijten aan het feit dat de bemonstering gebeurt met dezelfde klok verzonden vanaf blockB.Inderdaad, dit is iets wat ik vergeten te zeggen in de vorige post: blockA stuurt de klok om de vergrendeling / FF in blockB samen met de gegevens.Kan dit de reden waarom dit pad wordt niet gezien als kritisch?

Sante

 

Welcome to EDABoard.com

Sponsor

Back
Top