Fragen zu VHDL und FPGA (Xilinx)

>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.

> 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.

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

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.

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.

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.

@  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:

1

   Minimum period is   12.259ns.

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

1

   1 constraint not met.

und eine genaue Aufstellung, was schiefgeht:

1

    Delay type         Delay(ns)  Logical Resource(s)

2

    ----------------------------  -------------------

3

    Tcko                  0.626   hs/delay_2

4

    net (fanout=4)        1.111   hs/delay<2>

5

    Tiooceck              0.524   hs/outp

6

    ----------------------------  ---------------------------

7

    Total                 2.261ns (1.150ns logic, 1.111ns route)

8

                                  (50.9% logic, 49.1% route)

Anforderung war hier 2 ns Takt.

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.

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?

> "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.