www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Spartan 3AN und UCF File


Autor: Christian M. (charlie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

ich beschäftige mich seit kurzem mit FPGA's allerdings komme ich mit den 
Timings noch nicht so ganz zurecht. Ich besitze ein Xilinx Spartan 3 AN 
Starter Kit und experimentiere mit dem 50MHz Oszilator (E12).
Ich habe inzwischen ein Blinklicht (ich weiß, nicht besonders 
herausfordernd) mit Verilog und der ISE 10.1 Sp3 gemacht, das ganze 
indem ich jeweils bei der steigenden Flanke der Ckl einen Zähler 
hinaufgezählt hab, und somit den Takt geteilt hab, was auch wunderbar 
funktioniert hat.

Was mir allerdings auch durch diverse Dokumentationen nicht ganz klar 
wird, ist der "PERIOD" Parameter in der UCF Datei. Ist es möglich mit 
diesem den Takt schon im vorhinein zu Teilen (z.B. indem man die 
benötigte Frequenz eingibt) oder ist dieser nur zur internen Optimierung 
vorgesehen?
Denn jegliche Änderungen des Wertes ergaben keine sichtbaren 
Veränderungen, deshalb bin ich etwas verunsichert was genau dieser 
Parameter verursacht. Oder gibt es noch eine andere Möglichkeit den Takt 
zu verändern, ohne manuell einen Prescaler mittels Zähler zu erstellen? 
Mit einem DCM- Objekt müsste dies doch relativ "einfach" machbar sein, 
wenn ich das richtig gesehen habe.

Ich hatte ausserdem ein kleines Problem bei dem ISE 10 Tutorial 
(stopwatch). Soweit ich das beurteilen konnte, fehlt da die LOC der 
Clock. Ich habe es noch nicht nachgeprüft, bin mir allerdings ziemlich 
sicher.

Vielen Dank für die Hilfe!

Charlie

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... ist der "PERIOD" Parameter in der UCF Datei.
Stichwort: Timing Constraints.

Constraints sind Einschränkungen, die du den Design-Tools zur Arbeit 
übergibst. Wenn du keine Constraints angibst, haben die Tools alle 
Freiheiten: sie können die Pins irgendwohin legen, sie können beliebig 
umständliche (und damit langsame) Routing- und Logikpfade wählen.

Mit dem LOC Constraint gibst du Platzierungs-Vorgaben z.B. Pins.

Mit PERIOD gibst du die einfachste Zeitvorgabe, indem du sagst:
Ich möchte, dass mein Design mit dieser Frequenz läuft.

Wenn du nichts sagst, dann kann es sein, dass alles klappt. Es kann aber 
genausogut sein, dass die Tools sich nicht genügend "anstrengen" und das 
Design nicht ausreichend schnell ist.

Also sollte in der UCF-Datei mindestens
1) die Pinzuordnung und
2) die Taktfrequenz angegeben sein.

Autor: Christian M. (charlie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

danke für die Antwort!

also das mit den Pinzuordnungen habe ich verstanden, also dass die ucf 
die verwendeten I/O's aus dem VHDL/Verilog Design auf die Pins des 
FPGA's abbildet.

Aber nochmal zu den Timing-Constraints der Clock. Wie gesagt: ich habe 
einen 50Mhz Oszillator auf dem Board, ich schreib also in die UCF (laut 
Datenblatt):

NET "clk" LOC = "E12";
NET "clk" PERIOD = 20.0ns HIGH 40%;

bzw. laut Mikrocontroller.net und diverse andere Quellen:

NET "clk" LOC = "E12";
NET "clk" TNM_NET = clk_div;
TIMESPEC "TS_CLK" = PERIOD "clk_div" 20ns HIGH 40%;

Die beiden Varianten sind ja prinzipiell gleich, funktionieren auch. 
Diese Quelle ist also nur zur Information für das Placing und Routing- 
Tool und kann hier nicht weiter verändert werden, verstehe ich das 
ungefähr richtig?

Ich hatte die Vorstellung, dass ich die Period eventuell auf 40.0 hätte 
setzen können, um den vom Oszillator kommenden Takt schon automatisch im 
FPGA halbieren zu können. Das geht so wohl nicht?

Autor: Henk ten Bakker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der letzt construct ist nur ein alias konstruct, er hilft, wenn viele 
signale zu bussen geschaltet werden können und gemeinsam constrained 
werden

Autor: Nephilim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die angaben der Timing Constrains im UCF File haben keinen direkten 
einfluss auf die funktionalität, also man kann dort nich den takt 
schonmal vorteilen oder ihn sonst irgendwie manipulieren. hier gibt man 
nur an, mit welcher geschwindigkeit das design hinterher auch sicher 
laufen soll. sprich, man gibt dem systhese tool eine 
mindestgeschwindigkeit, die das design hinterher auch erfüllen muss und 
das sythesetool versucht dann alles so zu optimieren, dass es auch so 
schnell ist hinterher.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich hatte die Vorstellung, dass ich die Period eventuell auf 40.0 hätte
> setzen können, um den vom Oszillator kommenden Takt schon automatisch im
> FPGA halbieren zu können. Das geht so wohl nicht?

Nein. Würdest du PERIOD auf 40.0 setzen, dann würde der 
place-and-route-Schritt mit diesen (falschen) Angaben rechnen und evtl. 
das Design so langsam umsetzen, dass es nur mit 25 MHz noch läuft, unter 
der Annahme dass der Takt ja nur 25 MHz beträgt, und dann lieber z.B. 
die Größe optimiert wird.

Für deine Theorie mit dem Halbieren müssten die Synthesetools ja auch 
überhaupt erst einmal wissen, dass der Takt 50 MHz beträgt. Das wissen 
sie aber nicht. Im Gegenteil, mit PERIOD machst du genau diese Angabe, 
also sollte sie auch richtig sein.

Wenn du den Takt halbieren, verdoppeln oder sonstwas willst, dann musst 
du einen DCM (clock manager) verwenden. Beispiel halbieren: Stelle den 
DCM auf halbieren, 50 MHz Takt rein, 25 MHz Takt raus, gib PERIOD 20.0 
für den ersten Takt, und PERIOD 40.0 für den erzeugten Takt. 
Genaugenommen könntest du PERIOD 20.0 für den Eingangstakt weglassen, 
solange keine Logik dran hängt, denn PERIOD ist ja wie gesagt nur eine 
Zielvorgabe für die Logikminimierung und place-and-route.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Genaugenommen könntest du PERIOD 20.0 für den Eingangstakt weglassen...
Noch genauergenommen könntest du nur den Eingangstakt spezifizieren, und 
der Takt nach dem/den DCM wird automatisch von der Toolchain 
constrained. Das ist schön wenn z.B. mehrere DCM verwendet werden und 
verschiedene Teiler- bzw. Multiplikator-Verhältnisse eingestellt werden.

Autor: Christian M. (charlie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Erklärungen. Ich denke ich habe die Problematik, 
zumindest im thoeretischen Sinne, verstanden. Bei Gelegenheit werde ich 
das mal praktisch anwenden.

Autor: Christian M. (charlie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lothar: hab deine Antwort leider zu spät bemerkt.
Das heißt im Klartext, ich gebe nur den Eingangstakt, also meine 20ns 
vom 50Mhz Oszillator an, und alle aus den DCM resultierenden 
Taktfrequenzen werden dann automatisch constrained? Es sind also keine 
weiteren Einträge in der UCF notwendig?

Ich hatte mir schon gedacht, dass das automatisch (von der ISE) gemacht 
werden könnte, da alle Spezifikationen angegeben werden. Zumindest wenn 
es sich um Frequenzänderungen mit DCM' s handelt.

Wie sieht das dann aber aus, wenn ich die Frequenz "von Hand" erzeuge, 
also ein Binärzähler implementiere und dann so eine Art PWM erzeuge?

also in Verilog wär das dann sowas z.B. (nur die Instanz):

wire clk_x    // hier sei dann das resultierende "PWM"

// Instanz erzeugt "PWM"
div_clk clk_1 (
    .CLK_IN(CLK_25),   // Seien die 50/2 = 25MHz von einem DCM
    .CLK_OUT(clk_x)    // Taktfrequenz resultiert von Binärzähler
    );

Wenn ich clk_x in die UCF aufnehmen möchte (brauch ich das überhaupt) 
wie würde so ein Eintrag dann Beispielsweise aussehen?

Sorry für die Fragerei, aber ich mach es mir gerade bei den 
Timing-Constraints vielleicht schwerer als ich müsste. Den Sinn und 
Zweck hab ich verstanden, nur an der Umsetzung haperts leider noch.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip musst du nur den Eingangstakt angeben, alle anderen 
Abhängigkeiten kennt das Design-Tool ja und bastelt die Contraints (wenn 
nötig) daraus.

Ob allerdings eine Taktteilung mittels Binärzähler sinnvoll ist, lassen 
wir mal dahingestellt....

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie sieht das dann aber aus, wenn ich die Frequenz "von Hand" erzeuge,
> also ein Binärzähler implementiere und dann so eine Art PWM erzeuge?
Dann wirst du u.U. schon mal Probleme haben das Ganze wieder auf ein 
Globales Taktnetz zu bekommen.

Am Anfang (oder für Anfänger) gilt einfach:
nur 1 Takt im ganzen Design.
Weil im ganzen FPGA jetzt nur 1 Takt da ist, werden die restlichen 
Timings werden über Clock-Enable-Signale gesteuert.
Du wirst nicht glauben, was du dir für seltsame Effekt einhandelst, wenn 
du mehrere/verschiedene Takte auf dem FPGA hast. Gerade am Anfang, wenn 
du noch soviel anderes zu lernen hast, wirst du damit einige schlaflose 
Nächte mit der Fehlersuche zubringen.

Autor: Christian M. (charlie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, ok.

Also den Takt beibehalten, alle Prozeduren mit diesem Takt steuern, also 
sowas wie

always @ (posedge clk) begin
   if( enable )begin
     ....

und nur das enable wird dann auf einem anderen weg erzeugt. Also wenn 
man jetzt beispielsweise sowas wie ein Blinklicht machen würde, müsste 
man noch eine Logik, die den Takt irgendwie weiter Teilt (DCM o.Ä.), 
entwerfen und damit enable ansteuert.. (Blinklicht ist jetzt nicht 
unbedingt so Zeitkritisch, aber ich denke ihr versteht was ich damit 
meine).

Das Löst einige Warnungen und noch mehr Probleme.. Vielen Dank nochmal

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> also sowas wie
> always @ (posedge clk) begin
>    if( enable )begin
>      ....
> und nur das enable wird dann auf einem anderen weg erzeugt.
Ich beschreibe selber zwar in VHDL, aber das sieht richtig aus.

> die den Takt irgendwie weiter Teilt (DCM o.Ä.)
Nein, dazu würde ich einen ordinären Binärzahler nehmen, und den Enable 
lokal dort erzeugen, wo er gebraucht wird. Solche DCM-Geschichten sind 
Hardware-Ressourcen,
- die 1. Zielsystemabhängig sind (DCM gibts nur bei Xilinx)
    [jajaja, klar gibts sowas ähnliches in allen anderen FPGAs]
- die 2. nur in begrenzter Anzahl auf dem FPGA vorhanden sind
- die 3. nicht FPGA-weit implementierbar sind (die sind lokalisiert)

Autor: J.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich hier noch mal einhaken?

Das bedeutet also für einen schnelleren und einen langsameren Takt z.B. 
fum entprellen oder für 7-Seg Anzeige, daß für den langsamen Takt in den 
Modulen die den brauchen, der schnelle Systemtakt mit einem entsprechend 
langsamen "slow_clock_enable" geundet werden sollte?

Ich habe derzeit ein Takt Modul das spuckt wirklich einen langsamen takt 
aus, der entsprechend mit rising_edge erkannt wird. So also nicht, 
sondern if( rising_edge(fast_clock) and slow_clock_enable ).

Was genau schiefgeht (früher oder später) wenn man es nicht macht lässt 
sich vermutlich für mich verständlich nicht in 3 Sätzen erklären? ;-) 
ich hätte nämlich vermutet, daß Probleme bei der Taktverteilung nur für 
'schnelle' relevant wäre und bei so was wie 200 Hz zum entprellen keine 
Rolle spielt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.