Welche VHDL Version nutzt Ihr?

Fpga I. schrieb:

welchen VHDL Standard nutzt ihr? Viele meiner Kunden setzen noch auf VHDL'93, einige trauen sich auch schon an VHDL2008 heran.

Mit "trauen" hat das wenig zu tun. Wir haben eine SPEC, die besagt, dass man möglichst kompatibel bleiben soll. Das führt u.a. dazu, dass eine Komponente, die in eine andere hinein soll (z.B eine alte SW) möglichst nichts benutzt, was 2008 ist. Anders herum muss eine Komponente, die andere zusammenbindet, mit 2008 umgehen können, soweit die "Gefahr" besteht, dass im Nachhinein eine Komponente in 2008 auftauchen könnte.

Diese Schere geht natürlich immer mehr auseinander und erfordert inzwischen bei den meisten Moduln ein Pragma, dass den Code dynamisch anpasst.

Genaueres müsste man in der Abteilung erfragen. Was ich bei den reviews sehe ist sehr wenig 2008.

Klipp und klar gesagt, für die Synthese ist es wurscht. man kann in jedem VHDL-Dialekt oder in Verilog oder in was auch immer ineffiziente Hardwarestrukturen beschreiben.

Entscheidend ist doch, ob die Hardwarestruktur optimal genutzt wird, also das einem bekannt wie man d-bspw. ie 4er oder 6-LUT optimal einsetzt. oder die anderen Spezifika der jeweiligen Schaltungsfamile. Und wie man die Constraints setzt, Oder die Syntheseschalter. Oder warum für den einen FÜGA aswynchrone Reset ne gute Wahl ist, aber für den anderen nicht.

Das eigentliche FPGA-KnowHow ist erheblich mehr Doku, locker mehrere hundert seiten, deshalb drücken sich manche gerne davor. Die Unterschiede zwischen den VHDL-geschmäckern dagegen sind auf 3-5 Seiten abgehalten und dienen eher der Bequemlichkeit als der tatsächlichen Verbessrung von Leistungsparametern.

https://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/VHDL-2008-Language-Support

https://community.element14.com/technologies/fpga-group/b/blog/posts/architectural-difference-between-spartan-6--spartan-7-series-fpgas-and-considerations-for-migrating-designs

https://docs.xilinx.com/v/u/en-US/ug474_7Series_CLB

Gustl B. schrieb:

DSGV-Violator schrieb:

Die Unterschiede zwischen den VHDL-geschmäckern dagegen sind auf 3-5 Seiten abgehalten und dienen eher der Bequemlichkeit als der tatsächlichen Verbessrung von Leistungsparametern.

Natürlich, wie soll die Sprache denn auch die Ressourcen besser nutzen können? Das ist Sache des Werkzeuges. Aber Spracheigenschaften können dazu führen, dass weniger Fehler gemacht werden und dass die Entwicklung effizienter ist.

Und andere "Spracheigenschaften" können dazu führen, dass mehr Fehler gemacht werden und dass die Entwicklung ineffizienter ist. Insbesonders weil die Entwicklung nicht von einer einzelnen Person getragen wird, sondern von einem Team (Entwickler Anton, Entwickler Börge, Tester Tadeusz, Verifikant Viktor, Produkt Manager Peter Maria, Spec-schreiberin Sindy, ...).

Deshalb wird ein für die gesamte Firma verpflichtender HDL-Style-Guide festgelegt, der u.a. festhält, welche Sprachelemente benutzt werden dürfen und welche nicht. https://webdocs.cs.ualberta.ca/~amaral/courses/329/labs/VHDL_Guideline.html

Die Arbeit mit einem solchen ist IMHO entscheidener als Palaver über den Mut zu irgendwelchen Jahreszahlen.

Fpga I. schrieb:

welchen VHDL Standard nutzt ihr

'93, wenn ich Glück habe. Sonst '87...

Fpga I. schrieb:

Wie sind Eure Erfahrunge?

Schlecht leider. Arbeite in der Halbleiterecke... Wir hacken zwar VHDL. Aber der gesamte Toolflow kämpft aktiv gegen dich. Da sind teilweise VHDL93 Konstrukte schon problematisch.

Fpga I. schrieb:

Habt ihr mit neuern Standards schon Probleme gehabt, dass diese beispielsweise von den Tools nicht richtig unterstützt werden?

Was heißt neu? Probleme kenne ich über alle Standards hinweg. Die Toolhersteller zeigen einem immer wieder die "Nutz doch Verilog"-Karte. Wir wollten mal das VHDL fixed point package verwenden. Nach 2 Monaten Kampf mit dem Toolflow aufgegeben und das Ganze mit High-Level-Synthese gemacht, weil das Tooling das fixed point package nicht frisst. VHDL 2008, wo es dabeigewesen wäre, gibt es zwar als Compile-Flag. Aber da war das Package nicht drin. Und wenn man das Package als source code einbindet, frisst es das Tool nicht, oder synthetisiert falsches Zeug.

Probleme, die ich schon hatte:

• Aliase synthetisieren ohne Fehlermeldung nicht richtig.
• Procedures die in Prozessen definiert sind, sind kategorisch nicht synthetisierbar.. Warum auch immer.

Anderer Fall:

1

test_proc : process(clk, rst_n) is

2

     variable counter: unsigned(7 downto 0);

3

begin

4

   if rst_n = '0' then

5

       counter := (others => '0');

6

   elsif rising_edge(clk) then

7

        output_strb <= '0';

8

        if counter = 255 then

9

            counter := 0;

10

            output_strb <= '1';

11

        else

12

            counter := counter + 1;

13

        end if;

14

   end if;

15

end process test_proc;

Die Variable counter sollte eigentlich durch die Beschreibung Flip Flops generieren und als normaler counter fungieren. Viele machen das so, damit lokale counter nicht die Signal-Liste in der Architecture zumüllen... Die Antwort diverser Tools auf dieses Konstrukt:

• Synthetisiert nicht
• Counter zählt immer von 0 nach 1 nach 0 nach 1 usw.
• Antwort vom Toolhersteller: "VHDL ist immer bisschen schwierig. Verilog kann das alles besser"

Generell ist meine Erfahrung bei FPGA-Synthese durchaus positiv. Viele 2008er Features funktionieren ganz gut. Aber die Asic-Welt mobbt den VHDL-User durchaus.

Das merkt man auch an den Coding-Styles, die für VHDL in der Asic-Welt gebräuchlich sind. Ich persönlich kodiere VHDL relativ high-level und lasse gern die Synthese auskaspern, wo jetzt welches Gatter hinkommt... Aber viele Asic-VHDL Codes sehen quasi aus wie Netzliste von Hand getippt... Mit jedem kombinatorischen Pfad einzeln ausgecoded, weil die Leute das so gewohnt sind...

1

test_proc : process(clk, rst_n) is

2

      variable counter: unsigned(7 downto 0);

3

 begin

4

    if rst_n = '0' then

5

        counter := (others => '0');

6

    elsif rising_edge(clk) then

7

         output_strb <= '0';

8

         if counter = 255 then

9

             counter := 0;

10

             output_strb <= '1';

11

         else

12

             counter := counter + 1;

13

         end if;

14

    end if;

15

 end process test_proc;

Anmerkungen:

• die Variable counter wird auf zwei verschiedene (Schreib-)Weisen genullt, mal als vector mit bits '0', dann wieder mit der Ganzzahl 0
• output_strb hat anscheinend keinen reset Wert resp. es ist hier nicht erkennbar
• das im else Zweig output_strb '0' wird, ist nicht direkt erkennbar

Man könnte es also auch so schreiben

1

test_proc : process(clk, rst_n) is

2

   variable counter: unsigned(7 downto 0);

3

begin

4

   if rst_n = '0' then

5

       counter     := 0;

6

       output_strb <= '0';

7

   elsif rising_edge(clk) then

8

        if counter = 255 then

9

           counter     := 0;

10

           output_strb <= '1';

11

´        else

12

           counter     := counter + 1;

13

     output_strb <= '0';

14

        end if;

15

   end if;

16

end process test_proc;

Wie man einen counter synthesekorrekt beschreibt, sollte immer in den Synthese style guide des jeweiligen synthese tool stehen (und nicht in irgendwelchen Papers irgendwelcher Standardisierungsgremien).

Und natürlich findet man im Synthese-Log-file, ob/wie der code verstanden wurde oder nicht ("inferred") siehe Anhang.

DSGV-Violator schrieb:

Anmerkungen:

• die Variable counter wird auf zwei verschiedene (Schreib-)Weisen genullt, mal als vector mit bits '0', dann wieder mit der Ganzzahl 0
• output_strb hat anscheinend keinen reset Wert resp. es ist hier nicht erkennbar

Mist. Da hab ich doch beim tippen ein paar Fehler eingebaut... War nur ein Beispiel. Ich hoffe man versteht es trotzdem.

DSGV-Violator schrieb:

• das im else Zweig output_strb '0' wird, ist nicht direkt erkennbar

Offenbar doch ;)

Die Sache auf die ich hinauswollte: Der VHDL support ist teilweise furchtbar mit der Einstellung, dass eh keiner VHDL verwendet und man halt verilog nehmen soll. Und spätestens, wenn Tools den Code zwar fressen, aber falsche Dinge tun, hört imho der Spaß auf.

DSGV-Violator schrieb:

Wie man einen counter synthesekorrekt beschreibt, sollte immer in den Synthese style guide des jeweiligen synthese tool stehen (und nicht in irgendwelchen Papers irgendwelcher Standardisierungsgremien).

Und da unterscheiden sich unsere Meinungen. Natürlich ist es selbstverständlich, dass ein Synthesetool nicht alles von VHDL synthetisieren kann. Aber, dann erwarte ich auch, dass es das nicht stillschweigend zu irgendwas verarbeitet. Die Sprache definiert das Verhalten exakt und wenn die Synthese das nicht kann, soll sie einen Fehler werfen. Würden sich C Compiler so verhalten, wie Synthesetools, wäre der Shitstorm gigantisch. Aber bei Synthesetools haben die Leute das einfach akzeptiert, dass die komisch sind :)

Aber, dann erwarte ich auch, dass es das nicht stillschweigend zu irgendwas verarbeitet.

Da passiert doch nichts "stillschweigend", das steht doch alles im log. Darauf wurde doch mehr als einmal hingewiesen, wie man die Ergebnisse des Compile-Lauf zu überprüfen und zu interpretieren hat.

In anderen Programmiersprachen wie C ist es auch nicht anders, auch muss man erst den Compiler "zum Schwatzen bsingen" (-Wall alle warnings anschalten) und zweitens diese Warnings/Fehlermeldungen auswerten und ernst nehmen.

Unabhängig davon, das Verilog für Einstieger besser sein könnte, weil weniger "mächtig" als VHDL, liegt das Problem eher beim Code-Schreiber, der nicht weiß, was er alles für eine vollständige Schaltungs-Beschreibung angeben muß. Da hört man dann oft "das soll nichts tum wenn es nicht angesprochen ist". Aber "nichts tun gibt es nun mal nicht in der Schaltungstechnik und was "default" bei bei beispielsweise nicht angesprochenen Schaltungsteilen passuert ist nun mal Herstellerabhängig und kann nicht im VHDL-Standard-Syntax generall verbindlich festgelegt sein.

DSGV-Violator schrieb:

Da passiert doch nichts "stillschweigend", das steht doch alles im log.

Das ist eben nicht so. Und vor allem macht es die Wiederverwendung von VHDL Code total schwierig. Ich habe hier VHDL Code, der für Xilinx mittels Synplify Premiere einwandfrei und ohne irgendeinen suspekten Output synthetisiert. Dann geht man im selben Haus eine Tür weiter zum Synopsys Design Compiler NXT und der synthetisiert das nicht. Glücklicherweise in diesem Fall mit Fehler.

Bspw: Beitrag "Re: VHDL ALIAS synthetisiert nicht "richtig""

Nicht ohne Grund gibt es formale Tools, die auf Netzlistenäquivalenz prüfen. Bspw. Synopsys Formality: https://www.synopsys.com/implementation-and-signoff/signoff/formality-equivalence-checking.html

Und man glaubt es kaum... Das findet teilweise wirklich Sachen, wo der Synthese output einfach hart falsch ist. Teilweise erst nach einer Optimierung. Sobald man das in VHDL etwas umcodiert, geht es dann...

DSGV-Violator schrieb:

In anderen Programmiersprachen wie C ist es auch nicht anders, auch muss man erst den Compiler "zum Schwatzen bsingen" (-Wall alle warnings anschalten) und zweitens diese Warnings/Fehlermeldungen auswerten und ernst nehmen.

Natürlich ist das in C anders: Das hat den markanten Unterschied, dass ein C Compiler, der halbwegs in Ordnung ist, auch alle C konformen Eingaben frisst und nicht einfach zufällig sagt: "Integer kann ich nicht dividieren. Das geht nur mit chars." oder so was.

Der Mist daran ist einfach, dass VHDL nicht spezifiziert, welche Teile der Sprache tatsächlich synthetisierbar sein müssen und welche nicht. Und da hier jeder sein eigenes Süppchen kocht, sorgt das dafür, dass man wiederverwendbaren VHDL Code so hart abspecken muss, dass es einfach keinen Sinn macht etwas neueres als VHDL93 zu verwenden. Die VHDL2008 und 2019 features sind zwar teilweise wirklich schön und auch sinnvoll... Aber der Support ist einfach nicht da und es bringt mir ja nichts, wenn ich das tippen kann aber dann nach ner Woche merke, dass der Syntheseflow das nicht frisst.

Neueste Entdeckung: (Geklaut bei http://www.lothar-miller.de/s9y/archives/72-Breite-eines-Vektors-berechnen-log2.html)

1

enitity foo is

2

generic (

3

   COUNT_MAX: positive := 255

4

);

5

port (

6

   clk : in std_logic;

7

   rst_n : in std_logic;

8

   counter_value : out std_logic_vector(INTEGER(CEIL(LOG2(REAL(COUNT_MAX+1)))) -1 downto 0)

9

);

10

end entity foo;

Das ist denke ich auch etwas, was die meisten VHDL-Nutzer schonmal gesehen haben. Solche Konstrukte habe ich neulich tonnenweise aus Code entfernt, weil bspw. die Cadence Palladium Synthese sagt: math.real ist nicht synthetisierbar. Punkt. Und dann bricht die einfach ab. Die anderen Tools, die ich zur Verfügung habe, fressen das alle und können die Konstante auflösen. Steht natürlich im Handbuch. Ist aber trotzdem Mist, weil bestehender Code, der auch so in Silizium schon existiert, nicht auf dieser Plattform baut.

Gustl B. schrieb:

Wie wäre es stattdessen beim Softwarehersteller ein Ticket/Feature Request aufzumachen?

Kurze Antwort: Die sagen dir eiskalt, dass du halt Verilog nehmen sollst, oder RTFM. Was an der Stelle tatsächlich auch drinstand. Mit VHDL ist man da tatsächlich so exotisch, dass die meisten Toolinghersteller einfach mit der Schulter zucken und dann ist das für die vorbei.

Gustl B. schrieb:

also wieso nicht Druck machen

Naja. Es ist schwierig seinem Chef zu erklären, warum man alles anzündet und einen Haufen Geld verbrennt, wenn man einfach 2 Tage Arbeit oder nen Studenten ransetzen kann, da mal durchzuwühlen.

Gustl B. schrieb:

Ja toll, wenn Entwickler wie du solchen Code nicht nutzen, dann entsteht auch kein Druck das zu unterstützen.

Ich würde das sofort nutzen. Nur werde ich dafür bezahlt, etwas zu basteln, was tut und nicht die Supporthotlines sämtlicher Großkonzerne in der VLSI Welt anzuzünden. Die Hersteller Mentor, Cadence, Synopsys und wie sie alle heißen haben dermaßen große Monopole auf ihre Spezialgebiete, dass du einfach als Truppe aus lass es mal 1000 HDL Designern sein einfach keinen Druck aufbauen kannst.

Gustl B. schrieb:

oder gleich wechseln?

Wohin? Kannst du mir eine Alternative zu bspw. Cadence Palladium nennen? Oder zum Synopsys Design Compiler, wenn die Standardzellen von synopsys gemacht wurden und oh Wunder auch nur in einem Format existieren, dass ausschließlich Synopsys-Tools verstehen? Wo soll man da hin?

Bei den Simulatoren gibt es mehr Auswahl. Sobald es da dann aber groß wird oder Anforderungen wie volle AMS Simulation etc. dazukommen, fallen da auch viele weg.

Gustl B. schrieb:

Schade, dass Verilog so weit verbreitet ist ...

Schade, dass VHDL das nicht ist ;)

Das Problem würde sich imho nur beheben lassen, wenn es

1. Eine größere Nutzerbasis von VHDL mit mehr Geld dahinter gäbe. Sprich wenn Giganten wie Samsung, Intel, AMD, die ja quasi bei den toolingherstellern cutting edge dran sitzen, großteils VHDL verweden würden.

2. Der VHDL Standard müsste "Synthese-aware" werden und definieren, was ein synthesizer zu verstehen hat, und was nicht. Hat aber ohne Punkt1 auch nur zur Folge, dass der VHDL Support dann ganz rausfällt, weil es zu stressig wäre das auch noch zu implementieren.

Dann würde sich da viel lösen... Aber ich bin da mittlerweile komplett desillusioniert. Wir sind bei VHDL2019 angekommen und teilweise macht VHDL93 noch Probleme...

Ich bin trotzdem froh, in VHDL zu codieren und nicht in Verilog. Die impliziete Sicherheit, die allein durch die Sprache schon sichergestellt wird, verhindert schon so viel an Problemen. Habe neulich festegestellt, dass es in verilog egal ist, ob ein port in einem module ein input oder ein output ist. Dadurch, dass es in Verilog quasi alles "wires" sind, kann man auch ohne Probleme durch eionen output port Werete in ein Modul bekommen... Das war mir auch neu. Gruselig das Ganze.