www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Synthesefreundlicher VHDL-Code


Autor: xst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mache gerade meine ersten Schritte mit synthetisiertem VHDL-Code. 
VHDL wurde im Studium recht intensiv behandelt, dadurch habe ich keine 
Probleme, funktional korrekten Code zu schreiben. Ebenso wurde die 
Synthetisierbarkeit intensiv diskutiert, grundsätzlich synthetisierbaren 
Code bringe ich also zustande.

Was mir aber Fragezeichen bereitet: Wie bringe ich es zustande, dass die 
Synthese sinnvolle und effiziente Umsetzungen findet. Ich bin mir nie 
sicher, ob das Tool meine Idee auch tatsächlich erfasst und sie 
effizient umsetzt, oder ob es mehr oder weniger stur meinen Text 
wortwörtlich interpretiert und dann potentiell ungünstige Hardware 
erzeugt.

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

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du vorher per Hand optimierst.

Nun die Synthesetools sind mittlerweile schon sehr fortschrittlich und 
oft kommt auch genau das oder noch besser raus was man haben will.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-na...
Oder der hier (Gimmick):
http://www.lothar-miller.de/s9y/archives/52-Kompak...
Oder sowas:
http://www.lothar-miller.de/s9y/archives/55-Finde-...
Oder das:
http://www.lothar-miller.de/s9y/archives/65-Vektor...
Oder:
http://www.lothar-miller.de/s9y/archives/1-Clock-E...
usw. usf...

Autor: xst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist interessante Lektüre, danke für den Tipp. So weiss man zumindest 
mal, wie man herumspielen soll, um nach besseren Resultaten zu suchen.

Wenn wir von Synthese sprechen: Wie wichtig ist im FPGA-Bereich 
eigentlich die Post-Synthesis-Simulation?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller 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.

Kann ich bestätigen.

Für funktionale Fehler ist die Post-Synthesis-Simulation viel zu langsam 
und (seltene) Synthesefehler in den Netzlisten zu finden ist nicht 
trivial.

Duke

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: xst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> 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.

Dem muss ich jetzt allerdings widersprechen. Die FPGAs haben ja 
zahlreiche Spezialelemente wie Block-RAM oder Multiplizierer drauf. 
Damit diese korrekt erkannt werden, muss der Code gewisse Regeln 
einhalten. (Siehe beispielsweise XST Userguide)

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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
   -- Lach jetzt nicht: Das ist VHDL...
   -- Nur eben nicht synthetisierbar.
   process (a,b,c) begin
     if rising_edge(c) then
        q <= '1'
     elsif falling_edge(b) then
        x <= a;
        q <= z;
     elsif (a='0') then
        q <= '1';
     else
        w <= b;
     end if;
   end process;
Und wenn er dann mal in FFs und LUTs denkt, dann darf er sich auch mal 
den Rest auf dem FPGA ansehen...

Autor: Some User (seraphe)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
   process (clk) begin
     if    rising_edge(clk)  then
        q <= '1'
     elsif falling_edge(clk) then
        q <= '0';
     end if;
   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... ;-)

Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
>
>    process (clk) begin
>      if    rising_edge(clk)  then
>         q <= '1'
>      elsif falling_edge(clk) then
>         q <= '0';
>      end if;
>    end process;
> 

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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.