mikrocontroller.net

Forum: FPGA, VHDL & Co. [GHDL] Multi-driven Net - Warnt GHDL hier?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johannes K. (krjdev)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Community!

Habe eine kurze Frage zu GHDL. Kann es leider erst nächste Woche testen. 
Wäre also toll, wenn jemand die Frage beantworten könnte.

Warnt GHDL zu mindestens bei der Simulation, wenn mir ein Fehler beim 
coden passiert ist, also wie im Betreff ein Netz an verschieden Stellen 
im Code gleichzeitig gesetzt wird (weiß nicht ob man "multi-driven net" 
so übersetzen kann)?

Würde gerne GHDL verwenden, da es etwas ressourcenschonender als die 
Vivado IDE ist. Weil jetzt passiert mir manchmal, dass zwar in Vivado 
die Synthese funktioniert, dann aber in der Implementation Vivado 
streikt. Da diese Schritte auf meinen derzeitigen Arbeitsgerät recht 
lange dauern, wäre es toll wenn das GHDL abdecken könnte. Also die Logik 
grundlegend überprüfen könnte.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Johannes K. schrieb:
> Weil jetzt passiert mir manchmal, dass zwar in Vivado die Synthese
> funktioniert
Bei multiplen Treibern auf ein Signal? Hast du da mal ein Beispiel?

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
ghdl kann m.E. mittlerweile locker mit kommerziellen Werkzeugen 
aufnehmen.

Was die Geschwindigkeit angeht, ziehen die sogar meist den Kürzeren.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
signal Datenbit: std_logic:='0';
begin
process begin
  wait until rising_edge(CLK);
  Datenbit <= not Datenbit;
end process;

process begin
  wait until falling_edge(CLK);
  Datenbit <= not Datenbit;
end process;

: Bearbeitet durch User
von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> signal Datenbit: std_logic:='0';
> begin
> process begin
>   wait until rising_edge(CLK);
>   Datenbit <= not Datenbit;
> end process;
>
> process begin
>   wait until falling_edge(CLK);
>   Datenbit <= not Datenbit;
> end process;

ist doch nichts falsch dran bzw. woher soll der Simulator wissen, dass 
dies nicht sogar gewollt ist?

Wer da einen Fehler haben möchte, sollte std_ulogic nehmen.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> Wer da einen Fehler haben möchte, sollte std_ulogic nehmen.
Der XST Synthesizer kann das aber eigentlich auch schon erkennen:
ERROR:Xst:528 - Multi-source in Unit <multidriven> on signal <dout>; 
this signal is connected to multiple drivers.

Johannes K. schrieb:
> dass zwar in Vivado die Synthese funktioniert, dann aber in der
> Implementation Vivado streikt.
Evtl. kannst/musst du da noch einen Schalter umschalten, dass schon der 
Synthesizer solche Konflikte melden darf.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Johannes K. schrieb:
>> dass zwar in Vivado die Synthese funktioniert, dann aber in der
>> Implementation Vivado streikt.
> Evtl. kannst/musst du da noch einen Schalter umschalten, dass schon der
> Synthesizer solche Konflikte melden darf.

Hängt halt auch von der Architeture konkreten FPGA-Typ ab. Manche FPGA's 
haben dual edge FF, andere nicht. Bei Spartan 2 und Co konnte man auch 
interner tristates beschreiben, die vom Implementierungsfrontend in 
muxer umgesetzt werden. Dem Synthesetool das aus HDL eine EDN macht ist 
dagegen die konkrete Architektur egal, es sei dann man aktiviert 
passende Funktionen ('physical optimizations' 'timing driven 
synthesis').

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Ja war ein schlechtes Beispiel, aber das hatte ich genommen weil genau 
so vermutlich oft versucht wird ein DDR FF zu beschreiben.

von C. A. Rotwang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Ja war ein schlechtes Beispiel, aber das hatte ich genommen weil genau
> so vermutlich oft versucht wird ein DDR FF zu beschreiben.

Mglw., sollte man sich aber IMHO nicht erst angewöhnen.
Ich  nehme da lieber Instanzen von den DDR-FF in den Pads im VHDL-Code. 
Ist vielleicht altmodisch, weil architectur-abhängiges HDL, aber es tut.

Wie kommt eigentlich GHDL mit solchen Herstellerspezifischen Primitiven 
zurecht?!

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Ist richtig, habe ich mir auch nicht angewöhnt. Das war quasi ein 
Negativbeispiel.

Aber auch ein

Data <= '0';
Data <= '1';

Außerhalb vom Prozess ist dann Data doch auch multi driven.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Wie kommt eigentlich GHDL mit solchen Herstellerspezifischen Primitiven
> zurecht?!

Wenn der Hersteller für seine herstellerspezifischen Primitive 
einigermassen vernünftiges VHDL mitbringt: ganz prima.

Jedenfalls hat es einen Satz von Skripten (für X, A/I und Lattice) an 
Bord, mit denen man die Vendor-Simulationslibraries umsetzen kann.

Zu den anderen kann ich nichts sagen, aber zumindest für Altera/Intel 
funktioniert das ganz brauchbar.

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Zu den anderen kann ich nichts sagen, aber zumindest für Altera/Intel
> funktioniert das ganz brauchbar.

Als ich GHDL zuletzt benutzt habe, hat das für Xilinx auch problemlos 
geklappt. Man muss halt einmal die ganzen Xilinx-Klamotten compilieren, 
dann kann GHDL damit umgehen.

Das mit den Multi-driven nets ist so eine Sache. Im Simulationskontext 
sind Multidriven-Nets nicht grundsätzlich verboten. Als Signalwert kommt 
dann ggf. 'X' heraus, was in der Simulation ein gültiger Zustand ist. 
Daher meckern manche Simulatoren das gar nicht an. Haben beide Treiber 
immer den gleichen Wert, wäre das theoretisch auch in der Hardware kein 
Fehler, und von solchen Technologie-abhängigen Sachen wie Timing im 
sub-Clk-Bereich weiß der Simulator nichts, wenn man nicht explizit 
Timing-Delays vorgibt. So gesehen ist es garnicht die Aufgabe des 
Simulators, Multi-driven Nets aufzudecken.

Wenn man wirklich Synthese-Semantik braucht, ist wie oben schon erwähnt 
std_ulogic der richtige Weg, aber dann beraubt man sich eben aller 
Signalwerte außer 0 und 1, die in der Simulation auch recht nützlich 
sind.

von Johannes K. (krjdev)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Johannes K. schrieb:
>> Weil jetzt passiert mir manchmal, dass zwar in Vivado die Synthese
>> funktioniert
> Bei multiplen Treibern auf ein Signal? Hast du da mal ein Beispiel?
Auf die schnelle hab ich derzeit kein Beispiel auf Lager. Werde das aber 
am Laufe des Tages nachholen. Mir fällt auf die Schnelle derzeit keines 
ein.

Was jetzt so gesehen auch gut ist. War Anfangs mit VHDL aufgrund der 
eingeprägten C Denkweise (squenzielle) öfters der Fall, dass ich hier 
auf was nicht geachtet habe.

Beitrag #6142175 wurde vom Autor gelöscht.
von Johannes K. (krjdev)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Aber auch ein
>
> Data <= '0';
> Data <= '1';
>
> Außerhalb vom Prozess ist dann Data doch auch multi driven.

Hab das jetzt ausprobiert. Was besseres ist mir bis jetzt noch nicht
eingefallen....

Dieses Vorhaben geht tatsächlich durch. Inklusive erfolgreicher
Implementation.
Kritische Warnungen gibt er im Synthese Tool schon aus. Nützliche
Meldungen zur Fehlersuche allerdings nicht. Siehe Screenshot (Kein Wort
bei welchem Signal und auch keine betreffenden Zeilen im VHDL Code.)

Hätte mir schon erwartet das er zu mindestens das betreffende Signal
(some_signal) angibt.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Gut, da müsste man Signale bauen die sich auch verändern.
signal Bit0: std_logic:='0';
signal Bit1: std_logic:='1';
signal Ausgabe: std_logic:='0';
begin
process begin
  wait until rising_edge(CLK);
  Bit0 <= not Bit0;
  Bit1 <= not Bit1;
end process;

Ausgabe <= Bit0;
Ausgabe <= Bit1;

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Johannes K. schrieb:
> Dieses Vorhaben geht tatsächlich durch. Inklusive erfolgreicher
> Implementation.

Machst du mit dem some_signal anschließend noch irgendetwas? Ansonsten 
wird das bei oder nach der Synthese wegoptimiert. Sonst müsste zumindest 
der DRC ganz am Schluss dem Treiben ein Ende setzen. Andernfalls wäre 
das sehr merkwürzig.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> Wenn man wirklich Synthese-Semantik braucht, ist wie oben schon erwähnt
> std_ulogic der richtige Weg, aber dann beraubt man sich eben aller
> Signalwerte außer 0 und 1, die in der Simulation auch recht nützlich
> sind.
Das stimmt so nicht ganz, da geht noch mehr als nur 0 und 1:
PACKAGE std_logic_1164 IS

    -------------------------------------------------------------------    
    -- logic state system  (unresolved)
    -------------------------------------------------------------------    
    TYPE std_ulogic IS ( 'U',  -- Uninitialized
                         'X',  -- Forcing  Unknown
                         '0',  -- Forcing  0
                         '1',  -- Forcing  1
                         'Z',  -- High Impedance   
                         'W',  -- Weak     Unknown
                         'L',  -- Weak     0       
                         'H',  -- Weak     1       
                         '-'   -- Don't care
                       );
...

Duke

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

ghdl --synth (nur in brandneuen Releases) meckert's definitiv an, d.h. 
da ist es ein Fehler.
Ansonsten, siehe -Werror flag.

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Das stimmt so nicht ganz, da geht noch mehr als nur 0 und 1:

Oops, stimmt... ich war gedanklich bei 'bit', das ist ein echter 2-State 
Typ, also mit Synthese-Semantik. Sorry. Trotzdem liefert std_ulogic 
einen Fehler bei Mehrfach-Zuweisungen.

von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> Trotzdem liefert std_ulogic
> einen Fehler bei Mehrfach-Zuweisungen.

und das soll es auch. Ich finde es recht nützlich die Komponenten in 
std_ulogic zu schreiben. Wenn ich irgendein Tristate brauche, dann nutze 
ich auch explizit std_logic.

Empfehlenswert ist es auch auf Top-Level das Interface oder bei AXI-IPs 
wieder mit std_logic zu schreiben. Es kracht sonst einfach zuviel, da 
die Tools dir versuchen wieder alles mit std_logic zu verdrahten. Auch 
bei AXI-IPs ist es zu lästig mit std_logic zu arbeiten.

Ist auch einfach Geschmackssache, ob man bei einfach bei nur std_logic 
bleibt und dafür noch den Linter oder die Synthese extra anwirft.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> C. A. Rotwang schrieb:
>> Wie kommt eigentlich GHDL mit solchen Herstellerspezifischen Primitiven
>> zurecht?!
>
> Wenn der Hersteller für seine herstellerspezifischen Primitive
> einigermassen vernünftiges VHDL mitbringt: ganz prima.
>
> Jedenfalls hat es einen Satz von Skripten (für X, A/I und Lattice) an
> Bord, mit denen man die Vendor-Simulationslibraries umsetzen kann.

Super, aber ich schätzte bei enyrypted simulation models mancher 
IP-Lieferanten ist man wieder bei modelsim/isim ?!

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Super, aber ich schätzte bei enyrypted simulation models mancher
> IP-Lieferanten ist man wieder bei modelsim/isim ?!

Natürlich (ohne Tricks). Aber man ist ja - zumindest im Hobby-Bereich, 
wenn man die kostenfreien Toolchains einsetzt - Kummer gewohnt.

Da ist man ja schon auf sich selbst gestellt, wenn ein superschlauer 
Wizard nur unleserliches (System-) Verilog erzeugen kann.

Die umsonstenen Simulatoren können keinen Mixed Mode.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Die umsonstenen Simulatoren können keinen Mixed Mode.

Und leider auch kein umfangreiches Code Coverage.

Ich bin jetzt auch nur in der Welt von Mentor Zuhause was die 
kostenpflichtigen Tools angeht und da kann GHDL in unfassbar vielen 
Bereichen absolut nicht mithalten (durch die vopt Moeglichkeiten ist 
auch GHDL keineswegs schneller, selbst mit dem GCC Backend), speziell 
was grafische Debugmoeglichkeiten angehen.

Aber zum Glueck das grosse Aber: Mit GHDL kann man soviel einfacher 
kleine Docker Images bauen um seine CI Pipeline damit zu fuettern. Das 
ist mit den ganzen kommerziellien Tools allein schon wegen dem ganzen 
Lizenzgeraffel mega nervig. Ebenso ist es praktisch unmoeglich ein 
schlankes Image zu bauen, Modelsim/Questaprime liefert einfach soviel 
Overhead mit auf den man in einem CI Build laessig verzichten kann.

: Bearbeitet durch User
von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Der Vivado Simulator kann gleichzeitig VHDL und Verilog.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Und leider auch kein umfangreiches Code Coverage.

Das geht per gcov sehr gut.

Gustl B. schrieb:
> Der Vivado Simulator kann gleichzeitig VHDL und Verilog.

..und folgt nach wie vor dem VHDL-Standard nicht zu 100%. Das kann zu 
Faellen fuehren, wo das synthetisierte Ergebnis was anderes rechnet als 
die Simulation, besonders, wenn man Verilog (mit implizierter 
Konvertierung) und VHDL (explizite Konvertierung) mischt. Von so etwas 
bin ich definitiv geheilt und ziehe GHDL als goldene Referenz vor.

GHDL macht bei der Synthese auch schon ne ganz gute Nummer, so dass 
jetzt auch schon die CI die Simulation gegen echte FPGA-Hardware 
gegentesten kann.
Ist aber noch etwas Wegstrecke, man kann noch keine komplexen Designs 
'mal eben' migrieren.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Das geht per gcov sehr gut.

Ja, aber wie geschrieben, nicht sehr umfangreich. Vergleiche mal die 
Moeglichkeiten zwischem dem was Modelsim bietet mit gcov. Da liegen 
Welten dazwischen.

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.

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