Welche VHDL Version nutzt Ihr?

[Fpga I. (fpga-ing)]

Moin in die Runde,

welchen VHDL Standard nutzt ihr? Viele meiner Kunden setzen noch auf 
VHDL'93, einige trauen sich auch schon an VHDL2008 heran. Wie sind Eure 
Erfahrunge? Habt ihr mit neuern Standards schon Probleme gehabt, dass 
diese beispielsweise von den Tools nicht richtig unterstützt werden?

Mir ist bisher nur aufgefallen, dass VHDL2008 im Vivado 2019.1 Simulator 
zu befehlen führen kann.

[Christoph Z. (christophz)]

Seit 2012 nutze ich einige Features von VHDL2008. In den letzten Jahren 
langsam immer mehr davon, die mir Nutzen bringen, häuptsächlich 
unconstrained types.

Auch heute noch musst du jedes dieser Features ausprobieren und in ALLEN 
deinen Tools testen und dann entscheiden ob du es nutzt oder nicht. Das 
meiste was auf den ersten Blick nützlich erscheint geht auch. Es ist 
viel besser geworden als auch schon aber gerade diesen Frühling hatten 
wir wieder so Beispiele, das Dinge gemäss Standard sauber gehen in 
Modelsim aber nicht in Synplify. Ein bisschen umschreiben und dann 
klappte es dann in beiden Tools.
Ein anderes Feature das ich jetzt seit diesem Jahr nutzen kann, weil wir 
es getestet haben sind range types. Kannte ich bisher gar noch nicht 
aber kann auch eleganteren, sehr lesbaren code ergeben.

2012 hatte ich die Wahl VHDL2008 unconstrained types zu nutzen oder den 
Lattice Reveal (äquivalent zu ChipScope). Mir war es wichtiger viel 
einfacher generischen Code zu schreiben und man sollte eh mehr in der 
Testbench machen als auf der Hardware :-)

[Gustl B. (gustl_b)]

2008 funktioniert eigentlich problemlos. Nur bei Quartus Lite geht noch 
wenig.

[Kay-Uwe R. (dfias)]

Fpga I. schrieb:
> Mir ist bisher nur aufgefallen, dass VHDL2008 im Vivado 2019.1 Simulator
> zu befehlen führen kann.
Vertippt oder was meinst du damit?

[A. F. (chefdesigner)]

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.

[DSGV-Violator (Gast)]

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. (gustl_b)]

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. Gerade die Möglichkeit 
Vieles generisch zu beschreiben und generische Packages zu nutzen ist 
hilfreich.

[DSGV-Violator (Gast)]

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.

[M. H. (bambel2)]

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:

test_proc : process(clk, rst_n) is
     variable counter: unsigned(7 downto 0);
begin
   if rst_n = '0' then
       counter := (others => '0');
   elsif rising_edge(clk) then
        output_strb <= '0';
        if counter = 255 then
            counter := 0;
            output_strb <= '1';
        else
            counter := counter + 1;
        end if;
   end if;
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...

[DSGV-Violator (Gast)]

test_proc : process(clk, rst_n) is
      variable counter: unsigned(7 downto 0);
 begin
    if rst_n = '0' then
        counter := (others => '0');
    elsif rising_edge(clk) then
         output_strb <= '0';
         if counter = 255 then
             counter := 0;
             output_strb <= '1';
         else
             counter := counter + 1;
         end if;
    end if;
 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

test_proc : process(clk, rst_n) is
   variable counter: unsigned(7 downto 0);
begin
   if rst_n = '0' then
       counter     := 0;
       output_strb <= '0';
   elsif rising_edge(clk) then
        if counter = 255 then
           counter     := 0;
           output_strb <= '1';
´        else
           counter     := counter + 1;
     output_strb <= '0';
        end if;
   end if;
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.

[M. H. (bambel2)]

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 :)

[DSGV-Violator (Gast)]

> 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.

[M. H. (bambel2)]

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)

enitity foo is
generic (
   COUNT_MAX: positive := 255
);
port (
   clk : in std_logic;
   rst_n : in std_logic;
   counter_value : out std_logic_vector(INTEGER(CEIL(LOG2(REAL(COUNT_MAX+1)))) -1 downto 0)
);
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. (-gb-)]

M. H. schrieb:
> Solche Konstrukte habe ich neulich tonnenweise aus Code
> entfernt, weil bspw. die Cadence Palladium Synthese sagt: math.real ist
> nicht synthetisierbar.

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

Wie wäre es stattdessen beim Softwarehersteller ein Ticket/Feature 
Request aufzumachen? Ihr legt da vermutlich viel Geld hin, andere 
Hersteller bekommen das schon längst hin, also wieso nicht Druck machen 
oder gleich wechseln?

[Gustl B. (gustl_b)]

Justus schrieb im Beitrag #7450611:
> Gustl B. schrieb:
>> Wie wäre es stattdessen beim Softwarehersteller ein Ticket/Feature
>> Request aufzumachen?
>
> Wo muss man denn einen Request erzeugen?

Steht doch da. Beim Softwarehersteller. In diesem Fall Cadence.

[M. H. (bambel2)]

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. (-gb-)]

Gut, du bist da vermutlich tatsächlich abhängig gefangen. Ich kann deine 
Sicht da voll verstehen. Schade, dass Verilog so weit verbreitet ist ...

[M. H. (bambel2)]

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.

[Marcus H. (mharnisch)]

M. H. schrieb:
> 2. Der VHDL Standard müsste "Synthese-aware" werden und definieren, was
> ein synthesizer zu verstehen hat, und was nicht.

Es gibt doch IEEE 1076.6.

> Dadurch, dass es in Verilog quasi alles "wires" sind,
> kann man auch ohne Probleme durch eionen output port Werete in ein Modul
> bekommen...

Die Regeln sind viel komplizierter als das :-) Verilog leidet unter der 
äußerst schwachen Spezifikation seiner Frühgeschichte und dem Zwang zur 
Rückwärtskompatibilität. Später hat man dann versucht, einige diese 
Schwächen auszubügeln und die Semantik jeweils neuer Sprachkonstrukte zu 
verbessern (z.B. ANSI port lists). Das macht die Sache aber nicht immer 
einfacher. Einige Compiler geben aber zusätzliche Warnungen aus. Oder 
man greift gleich zur statischen Codeanalyse.

[Rick D. (rickdangerus)]

Marcus H. schrieb:
> Es gibt doch IEEE 1076.6.
https://standards.ieee.org/ieee/1076.6/3466/

Status
    Inactive-Withdrawn Standard

[Marcus H. (mharnisch)]

Rick D. schrieb:
> Status
>     Inactive-Withdrawn Standard

Danke für den Hinweis.

> Withdrawn:
>    2010-01-09

Die Zeit fliegt.