Fragen zu VHDL und FPGA (Xilinx)

[Kr2 K. (kr2)]

hallo,

ich hab vor ca. zwei Wochen mit VHDL auf einem Xilinx FPGA angefangen 
und hätte nun ein paar Fragen (verwende Xilinx ISE 10.1).

1.:
ich mach die Zuweisung Signal I/O Pin bisher immer in der .ucf Datei. Da 
kann man aber scheinbar nicht nur Signal zuweisen sondern noch einige 
weiter Dinge beschreiben.

Hat sich erledigt habe es gefunden:
http://www.xilinx.com/itp/xilinx9/books/docs/cgd/cgd.pdf
und dann weiter Informationen dem jeweiligen Degenblatt entnehmen.

2.:
Nach dem man "Synthesize - XST" ausgeführt findet man im Synthesis 
Report ("View Syntesis Report") unter "Timing Summary" eine max. 
Frequenz. Was mich hier jetzt stört ist das zu diesen Zeitpunkt noch 
nicht "Implement Design" ausgeführt wurde und d.h. auch die Signal 
Laufzeiten nicht bekannt sind.
d.h. zwei Fragen:
2.1.:
Sind die Signal Laufzeiten z.B. zwischen zwei lut´s so klein das sie 
nicht berücksichtigt werden müssen?
2.2.:
Kann man auf diese Angabe bauen, also wenn da z.B. steht er schafft 
100MHz das er das dann auch auf m Bord hinkriegt?

3.:
type statetype is ... vs. zB integer
Macht es einen Unterschied ob ich einen Zustandsautomaten mit "type 
statetype is ..." oder z.B. integer realisieren also z.B. am Ende von 
einem Zustand schreibe

state <= state +1;

anstat

state <= "nächster zustand";

Ich gehe mal nicht davon aus, da type ... is ... einfach nur ein eigener 
datentyp ist oder?

Danke im Voraus.

mfg
kr2

[Jan M. (mueschel)]

>Sind die Signal Laufzeiten z.B. zwischen zwei lut´s so klein das sie
>nicht berücksichtigt werden müssen?
Nein, diese sind nicht vernachlässigbar. Normalerweise ist die 
Verteilung grob 50:50 zwischen Logik und Routing. Für das routing werden 
hier vermutliche Laufzeiten eingerechnet.

>Kann man auf diese Angabe bauen, also wenn da z.B. steht er schafft
>100MHz das er das dann auch auf m Bord hinkriegt?
Nein. Erst wenn das place'n'route komplett ist kann man eine Aussage 
über die tatsächliche Geschwindigkeit treffen. Normalerweise ist diese 
niedriger als nach der Synthese angegeben, könnte aber auch höher sein.


>Macht es einen Unterschied ob ich einen Zustandsautomaten mit "type
>statetype is ..." oder z.B. integer realisieren also z.B. am Ende von
>einem Zustand schreibe

Solange du die Optimierung der Codierung von FSM durch die Synthese 
nicht ausschaltest, macht es keinen Unterschied. Mit Namen kann die 
state machine natürlich übersichtlicher werden als nur mit 
durchnummerierten Zuständen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Was mich hier jetzt stört ist das zu diesen Zeitpunkt noch
> nicht "Implement Design" ausgeführt wurde und d.h. auch die Signal
> Laufzeiten nicht bekannt sind.
Hier werden ganz einfach irgendwelche Schätz- und Erfahrungswerte zur 
Geschwindigkeitsermittlung hergenommen.

>Kann man auf diese Angabe bauen...
Wenn dort die Zahl 50 MHz auftaucht, und du 150 MHz willst, wird auch 
der nachfolgende Prozess mit allen Optimierungsmethoden das nicht 
schaffen.

> also z.B. am Ende von einem Zustand schreibe
> state <= state +1;
Das geht natürlich nur mit simpelsten Zustandsautomaten. Du könntest 
genauso gut einen Zähler nehmen, wenn am Ende jedes Zustands ein 
Increment steht. In der Simulation ist es wesentlich übersichtlicher, 
wenn du nicht nur einen Zählerstand siehst, sondern einen Namen, der den 
Zustand beschreibt.

> Macht es einen Unterschied ob ich einen Zustandsautomaten mit "type
> statetype is ..." oder z.B. integer relisiere...
Es ist besser, der Toolchain zu überlassen, wie eine FSM am besten zu 
implementieren ist. Evtl. passt optimal eine One-Hot- oder 
Gray-Implementierung, oder müssten einfach die States binär anders 
durchgezählt werden...
Mit einer expliziten Integer-FSM zwingst du die Synthese dann zu 
Umwegen.

[Kr2 K. (kr2)]

Danke für eure schnellen Antworten.
Gerade ist noch eine Frage aufgetaucht.

4.:
Auf meinem Bord teilen sich Speicher und LCD ein paar Pins d.h. wird es 
wohl irgendwann dazu kommen das ich einen Ausgang durch mehrere 
"Bausteine" ansteuern muss.
Ich hab std_logic und std_logic_vector als datentyp hergenommen und die 
dann auf  'Z' geschaltet wenn ich sie nicht mehr brauche. Passt das so?

mfg
kr2

[Jan M. (mueschel)]

Kleine Ergaenzung zu Lothar:
>Mit einer expliziten Integer-FSM zwingst du die Synthese dann zu
>Umwegen.
Zumindest ISE optimiert mit Standardeinstellungen auch solche schon 
explizit codierten Zustaende.


>4.:
Ja, den port als inout deklarieren und wenn ein anderer Baustein treiben 
soll, dann auf 'Z' legen. Aber Vorsicht beim Programmieren, nicht dass 
irgendwann zwei Bausteine gleichzeitig treiben. Ausserdem darf das 'Z' 
nur direkt am Ausgang benutzt werden, da es ja keine internen tristates 
gibt.

[Chris (Gast)]

Hallo zusammen,

>Nein. Erst wenn das place'n'route komplett ist kann man eine Aussage
>über die tatsächliche Geschwindigkeit treffen. Normalerweise ist diese
>niedriger als nach der Synthese angegeben, könnte aber auch höher sein.

Wo in den Reports steht eigentlich die tatsächliche maximale Frequenz 
(nach dem Place&Route)? Ich finde nur im Synthesis Report eine Angabe.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klapp mal alle Zweige im Process-View auf und such nach dem Begriff 
"Static Timing". Dort findest du dann auch gleich den kritischen Pfad, 
der das Timing begrenzt.

[Chris (Gast)]

Ist es das hier? Und das Limit 12.259, also 81,5 MHz?



Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)

Clock Clock to Pad
------------+------------+------------------+--------+
            | clk (edge) |                  | Clock  |
Destination |   to PAD   |Internal Clock(s) | Phase  |
------------+------------+------------------+--------+
AN0         |   10.017(R)|Clock_BUFGP       |   0.000|
AN1         |    9.658(R)|Clock_BUFGP       |   0.000|
DataOut<0>  |   11.628(R)|Clock_BUFGP       |   0.000|
DataOut<1>  |   11.293(R)|Clock_BUFGP       |   0.000|
DataOut<2>  |   11.665(R)|Clock_BUFGP       |   0.000|
DataOut<3>  |   11.182(R)|Clock_BUFGP       |   0.000|
DataOut<4>  |   11.437(R)|Clock_BUFGP       |   0.000|
DataOut<5>  |   11.480(R)|Clock_BUFGP       |   0.000|
DataOut<6>  |   12.001(R)|Clock_BUFGP       |   0.000|
DataOut<7>  |   12.272(R)|Clock_BUFGP       |   0.000|
led<0>      |   12.864(R)|Clock_BUFGP       |   0.000|
led<1>      |   12.218(R)|Clock_BUFGP       |   0.000|
led<2>      |   12.443(R)|Clock_BUFGP       |   0.000|
led<3>      |   12.757(R)|Clock_BUFGP       |   0.000|
led<4>      |   12.844(R)|Clock_BUFGP       |   0.000|
led<5>      |   12.663(R)|Clock_BUFGP       |   0.000|
led<6>      |   12.477(R)|Clock_BUFGP       |   0.000|
------------+------------+------------------+--------+

Clock to Setup on destination clock Clock
---------------+---------+---------+---------+---------+
               | Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock   |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
Clock          |   12.259|         |         |         |
---------------+---------+---------+---------+---------+

[Christian R. (supachris)]

Gib doch im ucf einfach vor, wie schnell dein CLK sein muss, dann 
versucht der Router das zu erreichen, und sagt die am Ende, ob es 
geklappt hat und auch wieviel "Luft" noch ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

@  Chris
>Ist es das hier?
Ja.

Christian R. schrieb:
> Gib doch im ucf einfach vor, wie schnell dein CLK sein muss...
Das ist der übliche Weg, und es taucht im Report eine solche Zeile auf:

   Minimum period is   12.259ns.

Wenn die Toolchain es nicht schafft die Anforderungen einzuhalten, dann 
gibt es einen Fehler:

   1 constraint not met.

und eine genaue Aufstellung, was schiefgeht:

    Delay type         Delay(ns)  Logical Resource(s)
    ----------------------------  -------------------
    Tcko                  0.626   hs/delay_2
    net (fanout=4)        1.111   hs/delay<2>
    Tiooceck              0.524   hs/outp
    ----------------------------  ---------------------------
    Total                 2.261ns (1.150ns logic, 1.111ns route)
                                  (50.9% logic, 49.1% route)

Anforderung war hier 2 ns Takt.

[Christian R. (supachris)]

Wobei zu beachten ist, dass gerade bei etwas langsameren Vorgaben, der 
Optimierer aufhört, sobald er die Vorgabe erreicht hat. Dadurch hat man 
wesentlich kürzere Routing-Zeiten. Wenn man das absolute Maximum 
ermitteln will, muss man eher eine CLK Vorgabe machen, die unmöglich zu 
halten ist. Dann rödelt der ewig und spuckt am Ende aus, wie schnell er 
maximal kann. Wenn man nix vorgibt, ist es meiner Erfahrung nach 
irgendeine Fantasie-Zahl, die der dann ausgibt, weil offenbar der 
Optimierer nicht richtig benutzt wird.

[Kr2 K. (kr2)]

5.:
Ich hab bei meinem aktuellen "Baustein" nur clock als Eingang. Wenn ich 
das jetzt simuliere ("post route simulation" also nach "implement 
desing") entspricht das dann auch der Realität, also wenn ich das auf 
den FPGA packe kommt dasselbe raus?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> "post route simulation"
Macht man mit synchronen Designs und sinnvoll gesetzten Constriants 
nicht, weil das nur Zeit kostet. Eine Verhaltensimulation und die 
statische Timinganalyse reicht völlig.

> also wenn ich das auf den FPGA packe kommt dasselbe raus?
Das Simulationsergebnis wird so nah wie möglich an der 
Worst-Case-Realität liegen. Ob du mit der "Best-Case" Realität (also mit 
den geringsten Verzögerungszeiten) auf deiner Hardware auch klarkommst, 
das steht auf einem anderen Blatt.