Kann es sein, dass die ISE ihre eigenen Berechungen nicht kapiert? Solange ich mein Testdesign auf ganzzahlige 50 MHz = 20ns laufen lasse und die IOs mit <20ns fast input deklariere, frisst sie es. Wehe aber ich will 60MHz nutzen, dann geht es rund: Er ermittelt intern eine Periode von 16,666 ns die natürlich mit den Inputs Constraints von 16,6667 nicht passen wollen. Ist das nur ein "feature" der aktuellen ISE? Wie umgeht man das? Ich könnte auf 16ns gehen und damit virtuelle 60,x MHz im Design fahren, aber dann passt es mit der Testbench nicht. Warum sind Xilinx-tools nur so sch....e?
Also ich sehe das Problem nicht bei 16ns? Du kannst doch die constraints auf 16ns belassen und trotzdem nur 60mhz anlegen und deine Testbench lässt du wie sie ist?
JBB schrieb: > eine Periode von 16,666 ns die natürlich mit den Inputs Constraints von > 16,6667 nicht passen wollen. Ich habe das Problem nicht ganz verstanden. Wie kommst du auf irgendwelche Input-Contraints von 20 oder 16,666 ns? DU SELBER mußt doch Constraints angeben. Und der Takt hat mit dem Eingangsrouting erst mal nichts zu tun. Evtl. sagst du mal mehr zu deiner Aufgabe. Du könntest auch mal dien UCF-File und die passenden Fehlermeldungen posten, oder so...
es geht darum, dass er im editor 16,6667 als ns vorschlägt, was zu den 60MHz passt. Anschließend frisst er es aber nicht. ich habe nun alles händisch auf 16,666 gestellt und es geht
JBB schrieb: > es geht darum, dass er im editor 16,6667 als ns vorschlägt Ja, warum und wo in welchem Editor wann denn? > händisch auf 16,666 gestellt und es geht Was denn? > es geht Ist doch gut...
Es ist der Constraint Editor. Er ermittelt aus der gegebenen Clock Frequenz einen Vorschlag für die IO path delays. Man sollte annehmen, dass das vorgeschlagene Ergebnis vom Tool verstanden wird :-)
Man kann doch im Constraint Editor auch die Periodenzeit in ns vorgeben..
Das ist das Problem: Man muss exakt die Zeit vorgeben, die die Synthese haben will. Die aber ist nicht die, die im Editor vprgeschlagen wird - jedenfalls gibt es Abweichungen: NgdBuild:1212 - User specified non-default attribute value (16.667) was detected for the CLKIN_PERIOD attribute on DCM "mymcm_b/dcm_sp_inst". This does not match the PERIOD constraint value (16.666 ns.). The uncertainty calculation will use the non-default attribute value. This could result in incorrect uncertainty calculated for DCM output clocks. Wie gesgt kommen die 16,666 aus dem Vorschlag, wenn man die IOs festelgen möchte und er dazu die CLK heranzieht.
JBB schrieb: > Das ist das Problem: Man muss exakt die Zeit vorgeben, die die Synthese > haben will. Die aber ist nicht die, die im Editor vprgeschlagen wird - > jedenfalls gibt es Abweichungen: > > NgdBuild:1212 - User specified non-default attribute value (16.667) was > detected for the CLKIN_PERIOD attribute on DCM "mymcm_b/dcm_sp_inst". > This does not match the PERIOD constraint value (16.666 ns.). The > uncertainty calculation will use the non-default attribute value. This > could result in incorrect uncertainty calculated for DCM output clocks. > > Wie gesgt kommen die 16,666 aus dem Vorschlag, wenn man die IOs > festelgen möchte und er dazu die CLK heranzieht. Sorry aber ich kann dir nicht folgen. Constraint heisst Vorgabe und nicht "Empfehlung vom Tool". Du gibts vor wie schnell die FF schalten (PERIOD Constraint) sollen. Ferner teilst du den Tool zwecks Kontrolle vor welchen Takt die DCM bekommen. (CLKIN_PERIOD). Sind keine Teiler etc in der DCM aktiv, sollten beide gleich. Das Tool teilt dir nur mit, das es sich für den langsameren als Vorgabe entschieden hat, weil das wohl der ist der den FPGA-taktet. Ich sehe hier grad keine Notwendigkeit den takt zweimal , dazu mit unterschiedlichen Werten vorzugeben und würde aus Gewohnheit nur PERIOD verwenden. Oder beiden in banchtbarten Zeilen den gleichen Wert zuweisen. MfG,
Man sollte in der Tat die ns selber vorgeben. Wenn man Frequenzen benutzt, die krumm sind, hat die Synthese Poobleme, die entstehenen ns mit denen aus dem UVF in Einklang zu bekommen. Ich mache es so, dass ich auf die nächstgelegene ns abrunde.
Die Frage ist ja, WIE!! Ich setze z.B. die Frequenz in den DCMs auf 90MHz. Welches constraint setze ich dann an? "11.1111ns" werden vom constraint editor vorgeschlagen, aber wenn ich die übernehme, gefallen sie der Synthese nicht. Sie möchte 11.111 - also eine 1 weniger. Das musste ich aber ausprobieren. Derselbe Mist bei der Benuzung von plan ahead: Die angeblichen 11.765ns, die ijn ISE zur 85MHz Taktung prima passen, werden im p.a. als falsch angemahnt. Plan Ahead und die ISE.Synthese sind an vielen Punkten nicht konsitent: Arbeitet man z.B. die location constraints mit p.a. ein, dann baut es sie mit eckigen Klammern, die von der ISE aber nicht erkannt werden und im Editor als unconstraint vorgeschlagen werden. Somit bekommt man dann in einem UCF redundante Informationen: NET "output_v<0>" OFFSET = OUT 11.111 ns AFTER "sys_clk"; NET "output_v[0]" OFFSET = OUT 11.111 ns AFTER "sys_clk"; Aus der Vergangenheit errinere ich soetwas auch hinsichtlich der Gross- und Kleinschreibung. Warum kriegt es die Firma Xilinx nicht hin, sich intern auf eine Schreibweise zu einigen? Ein weiterer Fehler, den ich beim Import eines ISe inplean ahead gesehen habe: Die time spec wird i.d.R. mit 50% d.c. angegeben, plean ahead liest hier aber nicht 50%, sondern 50 ns. Wie schlampig wird dort bei Xilinx gearbeitet? Die tools werden immer komplexer und integrierter und es wird immer schwerer, noch rein text-basiert zu arbeiten, die tool chain hat aber immer mehr bugs! Inzwischen gehen teilweis mehr als 50% meiner Zeit in die Umgehung von xilinx bugs!
Kannst ja auf Rodin warten, da wird dann wieder alles anders. Vielleicht besser, aber eher nur anders. Auf jeden Fall wieder mehr text-basierter Design Flow. Bei mir hatte ich solche argen Probleme nicht. Und wenn da mal eine Info aus der DCM bezüglich der nicht 100% passenden Timing Contraints kommt, wen interessiert das? Dann gib halt lieber 11ns statt 11.1111...ns an.
Ja, Warnung und Nichtfunktion sind schon zwei Paar Schuhe, jedoch sind
für warnings eben nur dann sinnvoll nutzbar, wenn ein tool kritisch mit
meinen Eingaben umghet und sie hinterfragt und nicht tonnenweise
Scheinfehler ausspuckt, weil es mit sich selber nicht klar kommt.
Für mich ist das immer ein Hinweis auf saubere logische Arbeit und
Fokussetzung in der Entwicklung. Viele Firmen täten gut daran, mehr in
die Funktion zu stecken, statt ins Design. Ich habe absolut nichts
davon, wenn sich während der Synthese viele bunte Kreise drehen. Lieber
wäre es mir, man würde solche Inkonsistenzen rausschmeissen. Aber dazu
haben die Programmierer dort offenbar keine Lust.
Ich habe auch immer noch ein grossen Problem, mir vorzustellen, dass
eine Firma Logidesign beherrscht und komplexe Design bauen können will,
wenn sie selbst nach vielen Jahren nicht mal einfachste
Syntax-Geschichten in den Griff bekommt.
>Rodin
??
Wenn man Plan Ahead anfangs sagt, die Constraints Files in ISE Sytax anzulegen klappt das doch auch und alles ist kompatibel. Welche Version hast du denn. Achja, Rodin: "Rodin, basierend auf PlanAhead, löst die XILINX Ent- wicklungsumgebung ISE als solche ab. Damit hat der Ent- wickler ein mächtiges Werkzeug mit zahlreichen Analyse- sowie interessanten Constraining-Möglichkeiten an der Hand." "Mit Einführung der XILINX Release Rodin 2012 wird TCL zur bedeutenden Skript-Tool Flow Unterstützung. Nahezu alle XILINX Tools wie PlanAhead, ISE, iSim, EDK oder Chipscope sind bereits TCL unterstützt und bieten dem Anwender nicht nur eindeutige Implementie- rungsabläufe sondern auch benutzerspezifi sche Flow Steu- erung. Derart erstellte Skripte können leichter gepfl egt wer- den als GUI spezifi sche Menüführung und mit veränderten Anforderungen fl exibler neu angepasst werden. " Quelle: PLC2 Trainingsprogramm 2012: http://www.plc2.de/deutsch/education/pdfs/2012/PLC2-Programm-2012.pdf
"TCL zur bedeutenden Skript-Tool Flow Unterstützung." Na super. Ist ja schön, dass sie sich damit an die "grossen" ASIC-Synthesetools angleichen, aber die haben das grattelige TCL ja auch nur, weil's vor >15 Jahren kaum was anderes als Skriptsprache gab. Aber programmiertechnisch ist TCL ja so ziemlich die grässlichste unter den Skriptsprachen, war ja selbst C64-BASIC noch schöner... Manchmal könnte man glauben, dass FPGA/ASIC-Designer Masochisten sein müssen, bei dem, was sie alles so unter dem Deckmantel der Professionalität tolerieren müssen ;)
Ich hatte auch schon ASIC-Design zu tun und kann nur bestätigen, dass es ein Grauss ist, umherzuscripten. Die Sache ist einfach die, dass die Hengste, die sowas mögen, beim ASIC Design kleben bleiben, die anderen suchen sich was anderes. Und ja, das Scripten wird glorifiziert. Vollkommen zu Unrecht, wie ich finde. Es ist eine Notlösung weil es nicht besseres gibt. Freilich liesse sich mit einer guten GUI vieles toppen, aber ausgerechnet die ISE ist Lichtjahre davon entfernt, eine guten GUI zu sein. Ausserdem glaube ich nicht, dass sich an den vom OP beschriebenen Problemen irgendwas ändert - im Gegenteil.
Ja, TCL ist grausam, das muss man zugeben. Wir bauen unsere Projekte mit den Command Line Tools ohne ISE GUI auf einem TeamCity Server. Das ist zwar erst mal etwas nervig aufzusetzen, weil bei der Hälfte der Programme die Optionen als Command Line Option angehängt werden, bei der anderen Hälfte als Steuerdatei vorliegen. Naja. Aber wenn es einmal eingestellt ist, läufts prima. Man ist auf die GUI nicht angewiesen und auf TCL auch nicht. Aber stimmt schon, wir sind da vielleicht Masochisten. Man sehe sich nur die Bedienoberfläche von ModelSim an. Schauderlich.
Ich kann mir beim besten willen nicht vorstellen, dass es mit einer neuen GUI einfacher werden kann oder wird. Das Problem bei Xilinx ist einfach, dass sie ein Riesenchaos haben und es nicht gebacken bekommen, konzentriert Fehler rauszuräumen. Stattdesssen bauen sie lieber was Neues, was dann sofort neue Fehler hat.
Naja oder sie nutzen die Chance sich von altem Ballast zu befreien und die Erfahrungen der letzten Jahre in die Entwicklung miteinfleßen zu lassen. Ich möchte nicht wissen wieviel Frickleware sich in der ISE angesammelt hat.
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.