Horloge domaine de passage erreur de chronométrage

[s3034585]

Salut Guys
Dans ma conception, il ya 2 CLKS appelé comme fastclk et slwclk et ils sont générés à l'aide de DCM.J'utilise un signal qui est du domaine slwclk pour déclencher un automate d'état dans CLK rapide.Mais avant de l'utiliser je ne le synchroniser en utilisant 2 FFS cadencé par CLK rapide.Cependant, je me fais quelques erreurs de timing et j'ai une incapacité à le comprendre.Quelqu'un peut-il m'aider à le comprendre ..

Merci d'avance
Tama

l'erreur est ---->

Slack:-1.899ns (exigence - (chemin de données - skew chemin horloge incertitude))
Source: gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn (FF)
Destination: gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r (FF)
Exigence: 0.003ns
Data Path Delay: 1.902ns (niveaux de la logique = 0)
Clock Skew Path: 0.000ns
Source horloge: slow_clk augmente à 110135.805ns
Destination Horloge: fast_clk augmente à 110135.808ns
Incertitude Clock: 0.000ns

Data Path: gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn à gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r
Type de localisation Delay Delay (ns) des ressources physiques
Logical ressource (s)
------------------------------------------------- -- ------------------
SLICE_X86Y145.YQ Tcko 0.568 gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/transation_done
gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn
SLICE_X86Y144.BY net (fanout = 1) 0,964 gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwr_dn
SLICE_X86Y144.CLK Tdick 0.370 gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r
gen_coproc.i_copro_top/g1.0.si_c/i_vg_gray/dvwrdn_r
------------------------------------------------- -- --------------------------
Total 1.902ns (0.938ns logique, 0.964ns route)
(49,3% de logique, route 50,7%)

-------------------------------------------------- ------------------------------

 

[benradu]

Ça dépend comment vous faites la synchronisation.Idéalement, vous devriez générer une impulsion avec la même largeur que la période fastclk et l'utiliser pour déclencher la machine d'état.
Aussi, à partir de votre poste, je vois le% 50,7 de retards est de routage, ce qui peut être améliorée si vous jouez avec les paramètres de la carte un RAP.Accroître l'effort de routage, la synchronisation utiliser la cartographie moteur ...

 

[anmolvlsi13]

Utilisez plus de FF au lieu de 2 pour synchroniser le CLK croît comme le FFreduce la probabilité de Metastabilty.

Anmol

 

[Aastik]

Salut,

Je pense que vous avez trouvé le mou (erreur) parce que l'horloge source et l'horloge de destination sont différents.lorsque l'horloge source et destination sont différents d'horloge sur un chemin de l'outil est censé donner voilations calendrier pour ce chemin.puisque vous êtes en utilisant 2 FFS pour la synchronisation, qui devrait fonctionner correctement et vous pouvez simplement ignorer le voilation timing.Pour de tels cas, il est recommandé de donner TIG (Timing Ignorer) contrainte entre les deux domaines d'horloge.Si vous donnez TIG entre votre fastclk et slowclk, cette voilation calendrier ne sera pas rapportée dans TWR.

Merci.

 

[gold_kiss]

Vous devez définir le chemin de faux signaux du passage d'un domaine à un autre.

 

[Alfred_zhang]

dans vos UCF, l'utilisation
Timespec "TS_XXX" = FROM "slow_clk" TO "fast_clk" TIG;

peut-être utile.

 

[avimit]

Lorsque corrsing domaines d'horloge, vous obtiendrez toujours une erreur de chronométrage.Il est parfaitement bien.parce que vous aurez les violations de synchronisation dans le silicium comme bien.Maintenant il ya deux façons de l'aborder:
1.Simplement l'ignorer
2.Déclarer une fausse voie (s) entre deux domaines d'horloge.
Kr,
Avi
http://www.vlsiip.com

 

[nag123]

Ce qui est faux chemin et la façon de déclarer celui-là?

 

[avimit]

Un chemin est un chemin de faux calendrier qui n'est jamais sensibilisés à la réalité, mais n'existe dans la puce.Depuis STA outil ne peut pas le trouver, et ses seuls l'ingénieur qui connaît sa fausse route, il est possible que mai STA fait état d'une violation de calendrier, et en fait une ingénieurs sait que cette violation n'est pas vrai.

Mais dans ce cas le chemin d'un domaine d'horloge à l'autre n'est pas une «vraie fausse route», car il seront sensibilisés sur puce.Mais puisque nous savons qu'il y aurait des violes calendrier et nous avons mis en place des mesures afin que nos silicium ne fonctionne malgré cela, nous utilisons l'utilitaire 'fausse route »pour la déclarer une« fausse route »afin que STA ne produit pas de calendrier erreurs:
Dans le compilateur de conception que vous pouvez déclarer une fausse voie comme ceci:
set_false_path-à partir de CLK1 à CLK2
d'autres exemples mai être vu à
http://www.vlsiip.com/dc_shell mai ou que vous voulez voir la page de manuel de 'set_false_path'
D'autres questions?laissez-moi savoir et je vais essayer d'éclaircir.
Kr,
Aviral Mittal