VHDL constant bei Synthese oder Simulation

Falls du damit so etwas meinst wie
wait for 10 ms;
oder
signal <= '1' after 10 ms;
dann ist das nicht synthetisierbar.

Es geht bei VHDL nun mal um eine Hardwarebeschreibungssprache, das heißt 
das was man schreibt muss man sich eben auch in Hardware ausgedrückt 
vorstellen können. Und dass der Strom ein paar Nanonsekunden in der 
Leitung wartet, bevor er sich überlegt weiterzulaufen, ist so nicht 
möglich.
Zähler zu synthetisieren wäre dabei auch nicht unbedingt sinnvoll, da 
man ja meist nur einen Zehntel Takt oder ähnlich kurze Zeiten abwarten 
möchte, also nichts zum zählen.

>Ist es möglich, je nach dem ob ich Simuliere oder Syntese
>durchführe die Konstante mit unterschiedlichen Werten zu belegen?
>Die Konstanten legen lange Wartezeiten (ms-Bereich) fest und für
>die Simulation ist es übersichtlicher mit kleineren Werten zu arbeiten.

Solche Probleme löse ich meist durch Test-Parametrierung: Jedes 
relevante FPGA-Modul wird mit einem Testport versehen, der Inputs, 
Outputs und Parameter im Modul je nach gewünschter Funktion umschaltet. 
Gesteuert wird das ganze über Bits, die innen mit einer If-Anweisung die 
passenden Werte und Signale setzen (ist faktisch ein Multiplexer) und 
aussen im globalen Design zu einem Testvektor zusammengeführt werden. 
Dieser Testvektor kommt auf reale FPGA-Pins, die gfs per 
Test-Port-Parameter-Pin mit anderen realen Eingängen gemultiplexed 
werden müssen (s.u).  In der Simulation reicht es dann, dem FPGA einen 
passenden Vektor mit auf den Weg zu geben. In der realen Synthese kann 
man die Funktion während der Entwicklung drin lassen, um das Chip zu 
testen, oder man setzt den parametrierenden Vektor kurz vor der Synthese 
auf auf Null. Dank der Optimierungen der Synthesetools fliegen dann alle 
diese Konstrukte raus.

Wenn man es etwas aufwändiger treiben möchte oder aufgrund sehr 
komplizierter Teststrukturen und der damit verbundenen Laufzeiten durch 
die Multiplexer (-> Änderungen im Fit!) tun muss - oder eben nicht genug 
Test-Pins am FPGA besitzt (s.o.), arbeitet man mit zwei verschiedenen 
Top-Level-Designs, welche einmal den synthesefähigen Teil und einmal den 
synthesefähigen Teil sowie den nicht synthesefähigen Teil kapseln. In 
der Simulation nutzt man dann nur Testbenches, die sich auf die zweite 
Top-Entity mit Testport beziehen. Es gibt dabei kein Laufzeitproblem, da 
Modelsim die asynchronen Multiplexer als 0 rechnet. In der Synthese 
nutzt man hingegen nur das erste Top-Level design, wobei die Test-Pins 
keine reale Verdrahtung im FPGA haben und daher unabhängig von 
eventuellen Vektoren "über den Jordan" gehen.

Danke an fpga spezialist für die Vorschläge.
Da ich mich etwas ungenau bzgl. der Wartezeiten ausgedrückt habe:
Mein Design verwendet einen Zustandsautomaten mit Zähler, d.h.
die Zustände bleiben n Takte erhalten. Beim Einschalten brauche ich
einen Zustand, der ca. 1 ms dauert. Für die Simulation ist es natürlich
ungünstig z.B. 10000 Takte dargestellt zu bekommen, deswegen habe
ich den Wert (die Konstante) statt auf 10000 eben auf 3 gesetzt.

Denkbar wäre sowas:

#if SIMULATION
  constant INIT_CYCLES: natural :=3;
#else
  constant INIT_CYCLES: natural :=10000;
#endif

Aber ich glaube nicht, dass das Prinzip in VHDL geht.

Hallo,

Ich löse dieses Problem über generics. Man kann jeder entity optionale 
Parameter über die Anweisung generic übergeben. Laufen die entities in 
einer test bench, so bekommen z.B. Teiler oder Warteschleifen aus der 
top entity kleine Werte zugewiesen. Laufen sie im echten design, so 
arbeiten sie mit default-Werten. Von außen zugewiesene Werte 
überschreiben natürlich  die defaults. Das übergeben von Werten kann 
pyramidenartig vom top level bis in die kleinste enitiy passieren. Ich 
hoffe, dass die Erläuterung ist halbwegs verständlich ist. Hier noch ein 
Beispiel eines Taktteilers:

1

entity clkdivider is

2

3

  generic (

4

    factor : integer := 10000);          -- division factor

5

  port (

6

    clkin:  in  std_logic;

7

    clkout: out std_logic := '0'

8

    );

9

10

end clkdivider;

11

12

architecture behv of clkdivider is

13

14

begin

15

  ...

16

end;

Dieser arbeitet standardmäßig mit einem Teilungsfaktor von 10000. Er 
kann aber aus der test bench mit einem Teilungsfaktor von 2 instanziiert 
werden.

1

 component clkdivider

2

    generic (

3

      factor : integer := 2);            -- division factor

4

    port (

5

      clkin  : in  std_logic;             -- clk input

6

      clkout : out std_logic);            -- clk output

7

  end component;

Grüße,

Lukasz