Synthesefreundlicher VHDL-Code

xst schrieb:
> Wie bringe ich es zustande, dass die
> Synthese sinnvolle und effiziente Umsetzungen findet.
1. Erfahrung
> Ich bin mir nie sicher, ob das Tool meine Idee auch tatsächlich erfasst
2. XST-User-Guide
;-)

Du mußt einfach mal irgendwelche Dreizeiler durchkauen und lernst dann 
Schwachpunkte eher kennen. Z.B. hier Beispiele 3 und 4:
http://www.lothar-miller.de/s9y/archives/76-BCD-nach-ASCII.html
Oder der hier (Gimmick):
http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html
Oder sowas:
http://www.lothar-miller.de/s9y/archives/55-Finde-das-MSB.html
Oder das:
http://www.lothar-miller.de/s9y/archives/65-Vektormanipulation.html
Oder:
http://www.lothar-miller.de/s9y/archives/1-Clock-Enable-in-einer-ISE-VHDL-Beschreibung.html
usw. usf...

xst schrieb:
> Wenn wir von Synthese sprechen: Wie wichtig ist im FPGA-Bereich
> eigentlich die Post-Synthesis-Simulation?
Eher unwichtig. Fehler findest du damit idR. kaum.

Wichtiger sind koreekte und ausreichende Timing-Constraints und die 
statische Timinganalyse.

Hallo xst,

xst schrieb:
> Wie kann man dem Synthesetool helfen, die geforderte Funktionalität
> möglichst effizient umzusetzen?

Bei der Modellierung einer digitalen Logik sollte man, unabhägig von der 
verwendeten Sprache und dem Zielbaustein, immer im Blick behalten, dass 
das Synthesetool nur D-Flipflops und Gatter zur Verfügung hat, um die 
gewünschte Funktionalität zu erzeugen. Dein geschriebener Code ist für 
das Synthesetool eine Vorgabe, die eine Menge von Flipflops und die 
davor bzw. dahinter liegende Logik"wolken" definiert. Wenn dir das klar 
ist, dann machen die Tools schon den Rest, keine Sorge. Schwieriger ist 
oftmals, den Tools die richtigen Vorgaben für die Einhaltung des Timings 
mit auf den Weg zu geben.

Harald

xst schrieb:
> Für synthetisierbaren Code reicht die D-FF- und Logikwolken-Denkweise,
> nicht aber, wenn man dem Synthesetool helfen will, das FPGA wirklich gut
> zu nutzen.
Ich muß Harald recht geben, denn ich sage es auch immmer selber:
Für einen Anfänger reicht die D-FF und Kombinatorik-Denkweise sehr weit. 
Denn dann schreibt er schon mal nicht so seltsame Prozesse wie:

1

   -- Lach jetzt nicht: Das ist VHDL...

2

   -- Nur eben nicht synthetisierbar.

3

   process (a,b,c) begin

4

     if rising_edge(c) then

5

        q <= '1'

6

     elsif falling_edge(b) then

7

        x <= a;

8

        q <= z;

9

     elsif (a='0') then

10

        q <= '1';

11

     else

12

        w <= b;

13

     end if;

14

   end process;

Und wenn er dann mal in FFs und LUTs denkt, dann darf er sich auch mal 
den Rest auf dem FPGA ansehen...

ihr meint aber nicht die instanziierung von chipspezifischen primitiven 
direkt im vhdl-code, oder? bringen die überhaupt vorteile?

Some User schrieb:
> ihr meint aber nicht die instanziierung von chipspezifischen primitiven
> direkt im vhdl-code, oder?
Nein, es geht nicht darum, FFs und LUTs direkt instatiieren (das dürfen 
erst Fortgeschrittetne ;-)
Sondern es geht darum , sich mal das Innenleben eines Logikblocks (CLB, 
Slice...) näher anzuschauen und zu überlegen, was damit alles gemacht 
werden kann.
Und dann ist klar:
So ein FF hat einen Takt-Eingang und einen Set- und einen Reset-Eingang. 
Und mehr kann das Ding nicht. Aus diesem Grund kann so eine Beschreibung 
nicht funktionieren, weil es im FPGA kein Bauteil dafür gibt:

1

   process (clk) begin

2

     if    rising_edge(clk)  then

3

        q <= '1'

4

     elsif falling_edge(clk) then

5

        q <= '0';

6

     end if;

7

   end process;

Und es ist auch sinnvoll zu wissen, dass abhängig von der 
VHDL-Beschreibung die Betriebsart einiger Komponenten umgeschaltet wird. 
So kann eine LUT4 beim S3 auch mal ein 16x1 RAM werden, oder das FF wird 
in einen synchronen bzw. asynchronen Reset-Modus umgeschaltet, usw...

> bringen die überhaupt vorteile?
Wenn du eine LUT direkt instatiierst, dann kannst du die Toolchain 
zwingen, diese LUT nicht wegzuoptimieren. Sowas braucht man aber 
höchstens alle Schaltjahre mal.
Wenn du aber andere Bauteile meinst (Clock-Manager, RAMs...) dann macht 
es durchaus Sinn, die auch zu instatiieren, denn du hast sie ja mit dem 
FPGA gekauft und bezahlt... ;-)

Lothar Miller schrieb:
> Some User schrieb:
>> ihr meint aber nicht die instanziierung von chipspezifischen primitiven
>> direkt im vhdl-code, oder?
> Nein, es geht nicht darum, FFs und LUTs direkt instatiieren (das dürfen
> erst Fortgeschrittetne ;-)
> Sondern es geht darum , sich mal das Innenleben eines Logikblocks (CLB,
> Slice...) näher anzuschauen und zu überlegen, was damit alles gemacht
> werden kann.
> Und dann ist klar:
> So ein FF hat einen Takt-Eingang und einen Set- und einen Reset-Eingang.
> Und mehr kann das Ding nicht. Aus diesem Grund kann so eine Beschreibung
> nicht funktionieren, weil es im FPGA kein Bauteil dafür gibt:
>

1

>    process (clk) begin

2

>      if    rising_edge(clk)  then

3

>         q <= '1'

4

>      elsif falling_edge(clk) then

5

>         q <= '0';

6

>      end if;

7

>    end process;

8

>

Klar.

> Und es ist auch sinnvoll zu wissen, dass abhängig von der
> VHDL-Beschreibung die Betriebsart einiger Komponenten umgeschaltet wird.
> So kann eine LUT4 beim S3 auch mal ein 16x1 RAM werden, oder das FF wird
> in einen synchronen bzw. asynchronen Reset-Modus umgeschaltet, usw...

Auch wahr. Kann man der Synthese natürlich auch abgewöhnen. LUTs können 
ja heute auch Schieberegister werden bspw.

>> bringen die überhaupt vorteile?
> Wenn du eine LUT direkt instatiierst, dann kannst du die Toolchain
> zwingen, diese LUT nicht wegzuoptimieren. Sowas braucht man aber
> höchstens alle Schaltjahre mal.
> Wenn du aber andere Bauteile meinst (Clock-Manager, RAMs...) dann macht
> es durchaus Sinn, die auch zu instatiieren, denn du hast sie ja mit dem
> FPGA gekauft und bezahlt... ;-)

Naja, es geht aber ja natürlich auch manchmal darum, portablen Code zu 
schreiben, also möglichst generisch und hoffen, dass die Toolchain 
nachher möglichst passgenau den Chip konfiguriert. Oder ist die Annahme 
zu optimistisch?

Some User schrieb:
> und hoffen, dass die Toolchain nachher möglichst passgenau den Chip
> konfiguriert. Oder ist die Annahme zu optimistisch?
Das hat mit "Hoffen" nichts zu tun. Natürlich wird ein in VHDL 
beschriebenes RAM auf einigen anderen Plattformen im Verhalten auch wie 
ein RAM umgesetzt werden.
Aber u.U.. wäre es für eine spezielle Plattform besser, dieses RAM ein 
klein wenig anders zu beschreiben, denn dann könnte evtl. eine 
Hardwarekomponente (BlockRAM) eingesetzt werden...

Für Xilinx gibt es da den XST User Guide, bei anderen Herstellern 
ähnliche Guides, in denen beschrieben ist, wie etwas beschrieben werden 
muß, damit die Synthese "automatisch" was passendes draus macht.

Irgendwann kommt das Design auf die Hardware, und je näher man an die 
Grenzen der Hardware kommt, umso mehr gilt die Gleichung
generisch = suboptimal

Some User schrieb:
> Naja, es geht aber ja natürlich auch manchmal darum, portablen Code zu
> schreiben, also möglichst generisch und hoffen, dass die Toolchain
> nachher möglichst passgenau den Chip konfiguriert. Oder ist die Annahme
> zu optimistisch?

Nein, nein, der Optimismus ist berechtingt. Wenn Du portablen Code 
schreiben willst, dann kann ich dir folgende Methode empfehlen: Solange 
Du "einfache Logik" modellliert, also Gatter und Fliflops, ist alles 
easy. Denke an Register und Wolke und gut. Die Synthesetools machen den 
Rest.
Sowie es an chipspezifische Module geht, die echt als separate Schaltung 
auf dem Silizium vorhanden sind (RAM, Multiplizierer, ...), vergiss das 
User Guide von Hersteller A, denn dies gilt nur für Hersteller A. 
Gleiches gilt für Hersteller B. Statt dessen, mach' es so wie es die 
Anbieter von IP-Modulen für ASIC-Implementierung machen: Interface > 
Wrapper-Modul > RAM-Modul. Das letzte davon kann man mit den 
Generator-Tools der FPGA Hersteller erzeugen.

Harald