Hi, ich habe öfters das Problem, dass mir das Synthesetool (ISE 13.3) interne Netze eines VHDL-Codes (z.B. globale Clocks), die auch auf einen IO-Pin gehen, immer automatisch so umbenennt, wie der IO-Pin heißt. Wenn ich dann bei den Constraints zB diesen Takt beschreiben will, findet der Translater dieses Netz nicht mehr. schemenhaftes Beispiel (nur zur Veranschaulichung): im entity port( ClockOutput: out std_logic); -- Ausgang des Chips (zur Kontrolle) in der architecture: signal gClk50 : std_logic; -- Ausgang eines BUFGs, interner Systemtakt ClockOutput <= gClk50; Im ucf hab ich dann zB folgendes stehen: NET gClk50 PERIOD = 50 MHz HIGH 50 %; Dann findet der Translater dieses Netz nicht mehr: ERROR:ConstraintSystem:59 - Constraint <NET gClk50 PERIOD = 50 MHz HIGH 50%;> [C:/d/Projekte/vhdl_dcamC/src/constraints.ucf(17)]: NET "gClk50" not found. Please verify that: Ich hab natürlich schon gegoogelt und folgende Dinge leider ohne Erfolg ausprobiert: -) "keep" attribute auf das signal -) Synthese Einstellungen durch wie z.B. "keep_hierarchy" -) verschiedene Optimierungseinstellungen Ich könnte natürlich einfach dem Ausgang den gleichen Namen wie dem Ausgang geben, das kommt aber aufgrund der Leserlichkeit und unserer Coding-Guidelines leider nicht in Frage. Hat wer von euch noch eine Idee? Besten Dank im Voraus, lg Harald
Hmmm, das gleiche Problem gibt es bei Lattice (Diamond) auch. Diese Macke ist sehr ärgerlich, keine keine Lösung hierfür.
Versteh das Problem nicht ganz... Was spricht denn dagegen im ucf den Namen des Ausgangs zu verwenden? Außerdem, wenn dein clock aus einem globalen clock-buffer kommt, ist er doch von irgendeinem Eingangstakt abgeleitet. Da sollte es doch reichen, diesen zu constrainen.
Harald Schweitzer schrieb: > Hat wer von euch noch eine Idee? Ich würde den Takt über einen ODDR-Buffer ausgeben. Welchen FPGA verwendest Du? Duke
Hi und danke für eure schnellen Antworten. > Was spricht denn dagegen im ucf den Namen des Ausgangs zu verwenden? Darüber lässt sich sicher streiten, aber kurz gesagt wäre ein Argument: Wir haben platzmäßig ziemlich zu kämpfen und deshalb nur ein paar wenige Signale auf Testpunkte geroutet. Wenn man diese nun verschieden beschaltet (für Debugging), dann ändert sich die Quelle für diesen Ausgang. Und um sprechend zu bleiben, will man im ucf ja nicht einen Testpunkt constrainen, sondern eben ein Clock ö.ä. Nun besser verständlich? > Außerdem, wenn dein clock aus einem globalen clock-buffer kommt, ist er > doch von irgendeinem Eingangstakt abgeleitet. Da sollte es doch reichen, > diesen zu constrainen. Das wäre allerdings möglich, das schau ich mir nochmal an, danke für den Hinweis. Nur ist es keine Lösung für mein ursächliches Problem mit der Namensänderung.
> Ich würde den Takt über einen ODDR-Buffer ausgeben. Hmm, im Falle eines Taktes geht das, stimmt. Dies ist aber ebenfalls eine spezielle Sache und eigentlich auch keine Lösung für das ursächliche Problem. Ich möchte nochmal darauf hinweisen, dass dieses Problem nicht nur für Clock-Netze besteht, sondern auch für Signale verschiedenen Typs. > Welchen FPGA verwendest Du? Spartan 6. Bin zur Zeit erst auf meinem zweiten Design für den 6er. Hab schon öfters gelesen, dass er vom Clocking usw nicht so ganz trivial wie seine Vorgänger sei.
:
Bearbeitet durch User
BTW ich verwende immer zwei constraints für sowas: ein timing net spezifizieren ein constraint an das timing net flanschen. Bsp: NET "M133CLK" TNM_NET=TN_MASTER_CLK; TIMESPEC "TS_period_266M" = PERIOD TN_MASTER_CLK 266 MHz; MfG, Ansosnten das constraint weglassen, alles durchlaufen lassen und dann im PAR-report schauen wie die Taktnetze heißen. Damit dann das constraint schreiben.
Harald Schweitzer schrieb: > Ich möchte nochmal darauf hinweisen, dass dieses Problem nicht nur für > Clock-Netze besteht, sondern auch für Signale verschiedenen Typs. Dann kann ich Dein Problem nicht nachvollziehen. Ich muß mein ucf-File nur sehr selten ändern. Die Namen im ucf und in meinem top-level-Modul sind identisch. Wenn ich Signale umroute, dann mach ich das im top-level mit direkten Zuweisungen oder per alias. Damit muß ich die location-constraints nicht ständig ändern. Timing-Constraints werden im Prinzip nur auf die Eingangstakte angewandt, das Tools generiert dann abgeleitete Takte (DCM, PLL) von allein. Duke
Leonard Lebewohl schrieb: > Ansosnten das constraint weglassen, alles durchlaufen lassen und dann im > PAR-report schauen wie die Taktnetze heißen. Damit dann das constraint > schreiben. Super! Das verdoppelt einfach mal so schnell die Implementationszeit. Sobald das Design länger als 5 min hat wird man das vermeiden wollen.
>> Ansosnten das constraint weglassen, alles durchlaufen lassen und dann im >> PAR-report schauen wie die Taktnetze heißen. Damit dann das constraint >> schreiben. > > Super! Das verdoppelt einfach mal so schnell die Implementationszeit. > Sobald das Design länger als 5 min hat wird man das vermeiden wollen. Hm, das sehe ich ähnlich. Keine wirkliche Option, außer für sehr kleine Designs. > Dann kann ich Dein Problem nicht nachvollziehen. Ich muß mein ucf-File > nur sehr selten ändern. > Die Namen im ucf und in meinem top-level-Modul sind identisch. Wenn ich > Signale umroute, dann mach ich das im top-level mit direkten Zuweisungen > oder per alias. > Damit muß ich die location-constraints nicht ständig ändern. Wie gesagt: ja, das wären alles Wege, um dieses Problem zu UMGEHEN. Trotzdem bleibt die Frage, ob man das dem Synthesetool irgendwie sagen kann (attribute o.ä.), dass er einen Signalnamen erhält und nicht selbständig ändert. Ähnlich zum "volatile" keyword in C. Das mit den Alias hab ich irgendwann mal aufgegeben weil der ISIM das nicht korrekt machte. Klappt das inzwischen besser? Dann wäre das evtl eine Option. > Timing-Constraints werden im Prinzip nur auf die Eingangstakte > angewandt, das Tools generiert dann abgeleitete Takte (DCM, PLL) von > allein. Das ist wahr - hab ich, wie oben bereits geschrieben, übersehen. Danke.
Hi In Diamond funktioniert das: attribute syn_keep : boolean; attribute syn_keep of k_clk,k1_clk : signal is true; attribute PRESERVE_Z : string; attribute PRESERVE_Z of k_clk,k1_clk : signal is "true"; damit werden clock Signal nicht umbenannt. Cheers.
Er hat ja schon geschrieben, dass es mit keep-Attribut nicht funktioniert. Es sollte dann allerdings im Synthese-Report irgendwo stehen, dass das keep ignoriert wurde. Leider ist ISE mit Begründungen oft ziemlich sparsam...
wenn ich dich recht verstehe dann willst du ein constraint auf ein ausgangspin setzen, wobei das constraint sich auf ein netz bezieht das mit dem ausgangspin verbunden ist aber nicht so heisst wie dieses? und das ist ein period constraint? period constraint auf ausgangs pads ist mindestens seltsam, period bezieht sich auf taktnetze (netz auf clock eingänge von FF o.ä. ) wenn das clock signal nur übers pad rausgeht dann ist period eh fehl am platz. wenn es ein internes taktsignal ist das zu testzwecken rausgegeben wird dann genügt das period constraint für das interne netz, da brauchts kein zweites period constraint. was willst du genau für die testsignale constrainen? Meines erachtens hast ist dein problem nicht richtig formuliert. signale werden nicht so ohne weiteres umbenannt. pads heissen so wie der port der topentity und nicht wie das signal daran. alles andere führt nur ins chaos. KEEP und abstellen von dead logic elimination dient nicht zum erhalt von signalnamen, sondern von signalen resp. deren treiber. wenn aber dein netz wegoptimiert wird weil es funktionslos ist, das hast du kein problem das mit attributen etc. zu lösen ist. aber schau dir mal den constraintguide cgd.pdf an. insbesonders das bilden von timing groups. timing constraints beziehen sich auf timing-netze -gruppen und mit einem grupping-constraint TMN_NET, TIMESPEC packst du netze in diese gruppe. heisst das timing constraint selber musst du nicht verändern, nur die gruppe auf die es sich bezieht um das testpin ergänzen. aber am wichtigsten ist meines erachtens dein problem richtig zu formulieren. "signalnamen behalten " ist es meines erachtens nicht. MfG
>aber am wichtigsten ist meines erachtens dein problem richtig zu >formulieren. "signalnamen behalten " ist es meines erachtens nicht. Doch das ist schon ganz treffend beschrieben. Bei Diamond ist es ähnlich: In Abhängigkeit davon, ob man Reveal (integrierter Logicanalyzer) integriert oder nicht werden schon mal Taktnamen willkürlich umbenannt. Einfach so ...
es sind aber auch beide Attribute notwendig, nicht nur "Keep" gruß
franke schrieb: > es sind aber auch beide Attribute notwendig, nicht nur "Keep" > > gruß PRESERVE_Z ist ein Attribute für den Precision Synthesetool von Mentor. syn_keep für Synplify Es kann also nicht sein, dass beide Attributes im Einzelfall nötig sind. Ausserdem setzt der OT ISE ein, also weder Synplify noch Precision.
Joe schrieb: >>aber am wichtigsten ist meines erachtens dein problem richtig zu >>formulieren. "signalnamen behalten " ist es meines erachtens nicht. > > Doch das ist schon ganz treffend beschrieben. > Bei Diamond ist es ähnlich: In Abhängigkeit davon, ob man Reveal > (integrierter Logicanalyzer) integriert oder nicht werden schon mal > Taktnamen willkürlich umbenannt. Einfach so ... Es ist keine bloße Umbennung, das "alte" Taktnetz wird durch ein neues mit anderen Namen ersetzt. Ebenso verhindert keep keine Umbennenung von NAMEN sondern das Wegoptimieren von NETZEN. Das Problem liegt nicht in den Namen/identifiern sondern in den Netzen selbst. VHDL verleidet leider das man Analogien zu Programmiersprachen zieht wie hier Neuvergabe von identifier (Name binding). Das ist aber nicht das zugrunde liegende Problem sondern die Generierung von netzen aus der modellbeschreibung und die Zuweisung von constraints an siesen Will man FPGA-tools verstehen, muß man denken wie diese, eben in Hardware denken. ;-) MfG,
>Es ist keine bloße Umbennung, das "alte" Taktnetz wird durch ein neues >mit anderen Namen ersetzt. Lesen im Kaffeesatz. Fakt ist: Durch mir nicht ersichtliche Gründe greifen die Constraints nicht mehr.
Ich konnte beobachten (Diamond Physical View), dass bei der Wahl des Taktnetztes ein Taktverteiler-Hard-Makro mehr oder weniger (oder anders) verwendet wird (ohne funktionale Änderung des Taktes), was zur Umbenennung des Taktes führt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.