werden Verzögerungen in der Synthese verwendet

die Hardwarebeschreibungssprache ist eine Sache, wie ein FPGA aufgebaut 
ist und was möglich ist eine andere. Deswegen empfehle ich dir, auch mal 
das Innenleben eines FPGA genauer anzuschauen. Auch wie ein Synthese, 
Place&Route und Routing Prozess bei Erstellung der FW funktioniert. 
Danach dürfte vieles klarer sein.

Kurz zu deiner Frage: Nein, das ist nicht möglich, weil es im FPGA keine 
entsprechenden Ressourcen (hardwarebestandteile) gibt, um solche 
Sprachelemente abzubilden. Solche konstrukte können aber für gewisse 
Sachen sehr hilfreich bei der Simulation sein, um eine höhere 
Testabdeckung seiner Module zu erreichen.

btw.

1

process(clk)

2

begin

3

  if rising_edge(clk) then

4

5

  end if;

6

end process;

gefällt mir persönlich besser wie wait until. Beides kann für diesen 
Fall verwendet werden und ist gleichbedeutend.

Laufzeitleitungen gibt/gab es u.a. in DIL-Bauform.
Typisch z.B. 8 x 5 ns in einem DIL16.

Die kannst du ja extern an deinen FPGA anknuspern.

Dann klappt das auch mit wait und after.
Das musst du dann "nur" noch dem Synthesizer deines
FPGA-Tools beibringen.

Latenzen werden durch Delta-Cycle berücksichtigt.

Andreas S. schrieb:
> So etwas ist auch in den "dickeren" FPGAs in den Transceivern und
> teilweise auch normalen I/O-Blöcken enthalten. Allerdings konfiguriert
> man das nicht durch irgendwelche after-Anweisungen.

sehr richtig. Bei Xilinx heißen die IDELAY/ODELAY und sind halt 
Blackboxen.

Achim M. schrieb:
> Ich war vor Jahren mal bei einem Speicherhersteller zu Gast, die haben
> in ihre DDR5-Speicher einstellbare Verzögerungen eingebaut. Das
> Silicon-Compiler-Synthesetool von denen konnte es halt ;)

sehr unwahrscheinlich, dass sie das für jede einzelne Leitung im Chip 
machen. Das ist nur für die IOs gedacht.

tja schrieb:
> Andreas S. schrieb:
>> So etwas ist auch in den "dickeren" FPGAs in den Transceivern und
>> teilweise auch normalen I/O-Blöcken enthalten. Allerdings konfiguriert
>> man das nicht durch irgendwelche after-Anweisungen.
>
> sehr richtig. Bei Xilinx heißen die IDELAY/ODELAY und sind halt
> Blackboxen.

Die konfiguriert man indirekt über entsprechende timing constraints 
(set_input_delay / set_output_delay) der externen Signale.

Andreas S. schrieb:
> Allerdings konfiguriert
> man das nicht durch irgendwelche after-Anweisungen.
noch nicht :-)

Andreas S. schrieb:
> Allerdings konfiguriert
> man das nicht durch irgendwelche after-Anweisungen.

... und auch nicht durch Anweisungen wie "add delay ..." in den 
XDC-file, wie mancher meint.

Blechbieger schrieb:
> Die konfiguriert man indirekt über entsprechende timing constraints
> (set_input_delay / set_output_delay) der externen Signale.

Auch das nicht!!! Die input delay SPECs dienen dazu, dem timing checker 
mitzuteilen, welches budget die Signale jeweils haben, damit er prüfen 
kann, ob es in Verbindung mit den internen Laufzeiten noch mit dem 
Einhalten des Taktfensters klappt.

Die IODELAY (in den Zellen) müssen explizit konfigutiert werden.

Manche Tools können die Delays einstellen, wenn z.B. der CoreGen das 
iniziiert. Generell aber sind solche Konstrukte wie "add delay" und "add 
clock" in den constraint file so zu lesen wie: "Addiere zu deiner Liste 
der Vorschriften eine weitere Zeile". Das ist etwas ungeschickt und 
wurde von mir in Richtung VHDL Gremien seinerzeit mehrfach moniert, aber 
da sich das von Synopsis her so etabliert hatte, bleibt es wohl so.

Delay ins den IOs sollte man generell selber instanziieren, so wie 
DDR-Zellen, SERDES, PLL und Clock-IOs. Alles auf die oberste Ebene, die 
sich um das konkrete FPGA kümmert.

Den Rest darunter ins Logigdesign. Physikalische Instanziierung wie 
Block-RAMs und andere immer als Wrapper in Form eines Leafs an die 
unterste Ebene in der Hierarchie. Das schafft die einfachste 
Möglichkeit, constraints zu setzen und FPGAs zu tauschen. So sieht das 
dann aus:

TAKT
- CCIO
--  PLL
--- Takt 1
--- Takt 2
--- SERDES PLL-Takte
--- GBT - Takte
- ODDR (Takt inversion)
- OUTDELAY ( <-> Taktverschiebung)
- INDELAY ( <-> Datenverschiebung)

---------------- Schnittstelle zur Physik ------------------
----- (Synthetisierbares / Simulierbares) Logikdesign -----
(nur logische Take mit rising edge, idealen Übergängen)
- Toplevel
-- Hierarchie 1
--- Hierarchie 2
---------------- Schnittstelle zur Physik ------------------
---- unterste Hierarchie
----- BRAM-Wrapper / BRAM-Modell
----- SERDES-Wrapper / SERDES-Modell
----- DDR-WRAPPER / DDR-Modell
----- GBT-WRAPPER / GBT-Modell
------------------------------------------------------------

Für physikalische Simulation von mehreren FPGAs oder FPGAs mit anderen 
Chips:
PIN-DRIVER-DELAY - Modelle
Leitungs-Delay - Modelle
Pull-UP-Widerständs - Modelle
Chip-Modelle mit Timing

Gustl B. schrieb:

> Klar, man teilt dem Tool mit was man möchte oder wie das Timing der
> Signale aussieht. Aber versucht das Tool dann auch das Timing
> einzuhalten?

Es gibt nicht ein tool, es gibt mehrere. Hier wäre es (a) der timing 
analyzer fürs STA und b) das timing driven place and route.

a) constraints sind erstrangig für STA gedacht. diese Analyse verändet 
überhaupt kein Design, sondern rechnet nur nach ob die Laufzeiten so in 
das durch die constraints gegeben Korsett passe,.

timing driven place and route macht da aber auch nicht viel anders, nur 
das es, wenn es beim adhoc-Nachrechnen nicht passt, gleich die benutzte 
Verdrahtung/Platzierung verwirft und eine andere 'auswürfelt' und mit 
der neuen weitermacht.

Die Theorie dahinter nennt sich 'Optimierung', kennt man vielleicht aus 
der Mathematik aus dem Umfeld des Simplexalgoritmus, also der Lösung 
eines unterbestimmten Gleichungssystems  unter Berücktsichtigung von 
Randbedingungen (engl. constraints). Wobei beim Place&Route eher das 
'Simulated Anealing" eingesetzt wird.
https://www.uni-saarland.de/fileadmin/user_upload/Professoren/FreyG/Lehre/SC/Vorlesungen/WiSe_1718/Deutsch/11.Stochastische_Optmierung_Simulated_Anealing.pdf