Hallo zusammen! Ich bin nach einer kleinen Pause dabei, systematisch weiter zu üben. Als nächstes steht die Verifikation von meinem Mist auf dem Stundenplan, sprich verwendung von Testbenches. Dazu lassen sich sicher Fragen wieder nicht vermeiden, die kommen dann wohl im Laufe der Tage. Meine erste Frage dreht sich aber um das ucf. In ise kann man das ja als Textfile bearbeiten oder auf die grafischen Tools zurückgreifen. Geht auch gemischt? bzw wie macht ihr das. Gehäuse Pins über NET "xyz" LOC = ""; funktioniert, da braucht man das Assign Package Pin sicher nicht. Zumal wenn man einen Rohling für ein Gehäuse erstellt hat. ABER die Frage zu den timing constraints: WAS sollte/müsste/könnte da sinnvoll angegeben werden? Im 'Create Timing constraints' werde ich mit unzähligen Angaben zugeworfen da weiß ich gar nicht was relevant ist. Per ucf texteingabe habe ich NET clk PERIOD = 1 ns ; astronomisch eingestellt und zum Glück geht die Implementierung dann auch den Bach runter. Ein realistischer, aber schneller Takt würde die Synthese entsprechend veranlassen, anders zu routen oder wie muss man sich das vorstellen? Und wie sieht es mit Pad to pad delay Angaben aus? Sieht man die im datenblatt nach (anders ist ja auch nichts in Erfahrung zu bringen denke ich) oder können diese ignoriert werden? Wie immer -erschlagen-. danke euch
> Geht auch gemischt? Ja, aber der Wizzard sortiert dir u.U. alle deine liebevoll von Hand eingefügten Constraints um... :-/ > bzw wie macht ihr das. Anlegen mit der grafischen Oberfläche und danach bearbeiten per Texteditor. > WAS sollte/müsste/könnte da sinnvoll angegeben werden? Mach ein synchrones Design und gib für den Anfang nur mal deine Taktfrequenz vor. > Ein realistischer, aber schneller Takt würde die Synthese entsprechend > veranlassen, anders zu routen oder wie muss man sich das vorstellen? Ja, auf Kosten der Rechenzeit... Evtl. mußt du dann in P&R entsprechende Optimierungsvorgaben anpassen. Das sollte aber für einen Anfänger (noch) nicht nötig sein. Wenn du 50 MHz erreichen willst, dann gib 50 MHz ein. Wenn du das dann nicht erreichst, dann nimmst du die Statische Timinganalyse und siehst nach, in welchem Kombinatorikpfad es klemmt. > wie sieht es mit Pad to pad delay Angaben aus? Die sind sowieso nur für kombinatorisches Routing zwischen 2 Pins nötig. Und da wirst du kaum einen Pfad haben, der sowas braucht. Sobald ein FF dazwischen ist, gelten andere Constraints.
danke dir. ja, ich will es nicht übertreiben und alles über Anfängerlevel hinaus soweit möglich ignorieren :-) Während des rumprobierens schon eine konkrete testbench Frage: habe erfolgreich eine Simulation gemacht. (dabei kommt es mir noch bischen wie Lotto vor, ob die Sourcen an der richtigen Stelle stehen) Testvektoren so definiert:
1 | bin_s <= x"00", x"01" after 50 ns, x"80" after 100 ns, x"ff" after 120 ns; |
soweit so gut für t==0 gibts es noch eine Warning aber es klappt. Da ich aber 255 Werte testen möchte ist das etwas lästig. Also Versuch mit for Schleife. Das hakt aber gewaltig:
1 | bin_s <= x"00"; |
2 | |
3 | for t in 0 to 20 loop |
4 | bin_s <= bin_s + 1; |
5 | wait for 50 ns; |
6 | end loop; |
Wie macht man so was? Außerdem zur Simulation: die behavioral Simulation klappt. (rudimentär, ok. Aber das wird schon) Wenn ich aber irgenwo Schaltzeiten oder interne delays sichtbar machen will wie manchmal schon gesehen, hätte ich an den Reiter "post route simulation" gedacht. Da geht gar nichts. Muss ich dafür eine irgendwie anders geartete tb machen?
Ja, die Schleife stimmt soweit, das Gane muß natürlich noch in einen Prozess. Nur das Rechnen mit bin_s ist möglicherweise so nicht empfehlenswert, je nachdem von welchem Type bin_s ist. Ich vermute, bin_s ist als std_logic_vector definiert. Damit kann man zwar, aber man sollte keine Berechnungen machen. Ein std_logic_vektor ist an und fürsich eben noch keine Zahl, sondern nur eine Reihefolge von bit. Wie diese als Zahl interpretiert wird (unsigned, signed oder gar als float) ist anwendungs-spezifisch. Man sollte zum Rechnen das Paket numeric_std verwenden. Dieses stellt unsigned und signed Typen einer bestimmten Länge zur Verfügung, die dann einfach in einen std_logic_vector gecasted werden können. Oder Du rechnest mit integer typen, und wandelst diese mit entsprechenden Funktionen in std_logic_vector um.
> Oder Du rechnest mit integer typen, und wandelst diese mit > entsprechenden Funktionen in std_logic_vector um. Zähler und alles, womit gerechnet werden soll, mache ich auch mit Integern und wandle sie für die Übergabe um (weil der Port idR. std_logiv_vector ist). Du könntest auch mit Vektoren rechnen, aber ich empfehle statt der alten Synopsis-Libs wie Klaus die aktuelle numeric_std. In der gibt es dann passende Casts und Konvertierungen: http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html
@erschlagen:
> "post route simulation" gedacht. Da geht gar nichts.
Die Xilinx-Bibliotheken verwenden intern einen eigenen Reset. Da musst
Du erstmal sowas wie 100 ns warten, ehe Dein Design losrennt.
Duke
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.