www.mikrocontroller.net

Forum: FPGA, VHDL & Co. vhdl, signalzuweisung aus mehreren processen


Autor: -daniel- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Frage ist eigentlich schon im Betreff gestellt.
Nun ist es aber so, das die Signale vom verschiedenen Typ
sein können. Konkret um einmal bit, einmal std_logic

entity tb is
end;

architecure testbench of tb is
    signal s: bit;
begin
    s <= '0';
    s <= '1';
end;

root@mond---[22:30:49]---/pool/PROG/vhdl/10 # ghdl -a tb.vhd
root@mond---[22:30:52]---/pool/PROG/vhdl/10 # ghdl -e config
root@mond---[22:30:55]---/pool/PROG/vhdl/10 # ./config
.tb(testbench).s
./config:error: several sources for unresolved signal


ich verstehe warum es hier zum Konflikt kommt
und zum Runtime kommt die exception

jetzt das ganze mit std_logic

architecure testbench of tb is
    signal s: std_logic;
begin
    s <= '1';  -- string 1
    s <= 'L';  -- weak 0
end;

std_logic ist resolved, logischerweise gewinnt starke 1

dies ist der Fall worauf meine Frage abziehlt
man hört doch man soll sowas nicht machen
(aus mehreren Processen ein Signal treiben)
allerdings scheint mir, dass es hier kein
undefined behaviour ist (keine Ahnung wie es in vhdl heisst)

was mich aber gewundert hat, ist das

architecure testbench of tb is
    signal s: std_logic;
begin
    s <= '1';  -- string 1
    s <= '0';  -- string 0
end;

zur Laufzeit keine exception schmeisst.
Oder ist es eher so, dass s dann zu 'X' wird?
ein assert s = 'X'; ging leider nicht
operator = war undefiniert

Schreibt VHDL da vor wie sich ein Simulator
verhalten soll?


Gruss, Daniel

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Frage bringt Dich auch nicht weiter. In der Hardware geht sowas
einfach nicht, egal ob der Simulator es kann oder nicht.

Autor: Alex H. (alex123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

wie Du schon richtig schreibts, std_logic ist resolved.
Daher ist es lt. VHDL zulässig, dieses Signal aus zwei
Prozessen (oder Components, Concurrent Assingments, ...)
zu treiben.
Was dann passiert ist in der Resolution Funktion definiert.
So ergibt 1 und L = 1, 1 und 0 aber X.

Bei der Synthese ist sowas aber mit vorsicht zu behandeln.
Ich würde dieses vermeiden wann immer möglich.

Es gibt ein paar Anwendungen, wo sowas Sinn macht - dies
sind i.d.R. Busse, wo mehr als ein Mudol drauf treiben.
Die Busse sind normalerweise tristate (oder haben einen
pull up oder pull down oder bushold - hardwaretechnisch
gesehen). Dabei überschreibt dann 0 oder 1 diese Werte
(Z, H, L, ... H und L sind als "weak" 1 oder 0 definiert,
d.h. wenn z.B. H an den Eingang eines Gatters gelegt
wird, wird das wie ne 1 interpretiert ...)

(Bin kein FPGA Mensch, weiss nicht was welche FPGAs
und FPGA Synthesetools bzgl. Tristate machen/können.)

In der Simulation ist das Verhalten durch VHDL bzw. die
zugehörigen Libraries genau beschrieben (genaugenommen:
std_logic und deren resolved function ist auch nix
anderes, als wenn Du Dir nen eigenen Datentypen
definierst, als resolved und dann die zugehörigen
Resolution Function selber definierts.

Std_logic ist im Package stdlogic definiert. Die Source
dazu steht in aller Regel irgendwo bei Deinem
Simulatio-Install-Verzeichniss, sinnigerweise unter
<source>/IEEE/...
Schau dort einfach mal rein:
Std_logic is resolved Std_ulogic, d.h. Std-ulogic
definiert den Datentyp als UX01ZWLH-
Für Std_logic gibt es ne zugehörige Resolution Function,
die im Package-Body beschrieben ist.
Ach ja, das ganze geht auch als Vector, std_locic_vector -
ist das resolved Pendant zu sld_ulogic_vector.

Bzgl:
> architecure testbench of tb is
>     signal s: std_logic;
> begin
>     s <= '1';  -- string 1
>     s <= '0';  -- string 0
> end;
>
> zur Laufzeit keine exception schmeisst.
> Oder ist es eher so, dass s dann zu 'X' wird?

Genau! Deshalb verwendet man Resolved Signale ;-)
Simulier das einfach mal, dann siehst Du das X ...

-----

Simulation vs. Synthese:
Das Verhalten Deiner Beschreibung wird durch den
VHDL-Standard und die Packages definiert.
Der Simulator bildet dies i.d.R. zu 100% nach (wenn
nicht, würd ich mir nen anderen Simulator suchen ;-).
Die Synthese kann zur Teile von VHDL synthetisieren
und macht dabei bestimmte Angaben.
Anwendungen für Resolved sind z.B. Tri-State-Busse,
kann m.E. sowohl für Simulation als auch für Synthese
sein.
Nur um den Code in einer Testbench vermeintlich
"besser" zu schreiben (z.B. ein Prozess setzt ein
Signal, ein anderer löscht es wieder), würde ich
keine Resolved SIgnale verwenden, da gibt es andere
Lösungen dafür.

Gruss,

Alex

Autor: -Daniel- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten

da ich im Moment eh keine Hardware zur Synthese habe
mit der ich spielen könnte, konzentiere ich mich
auf VHDL aus der Sicht des Simulators

soweit ich mich recht entsinne ist VHDL LRM auch nur
eine Beschreibung von VHDL wie ein Simulator den Code
handhaben soll und nicht was die Synthese daraus macht.

Ich habe 2 weitere Fragen, die mir gestern in den Sinn kamen

1) Hat sich jemand hier schon Gedanken gemacht
wie so eine Event-driven-simulation in C++ ausschaut?
ich dachte da konkret an kleine C++ Engine, die VHDL
nachbildet. Damit wollte ich sichergehen, dass ich
die Reihenfolge der Abarbeitung eines Events verstehe.
Zb wann Signal activ wird, wann event generiert wird.
wie timing ge-handelt wird, wann process execution an der Reihe ist und
so weiter

2) resolved ist also da um Busse zu beschreiben
könnte jemand kleines Beispielkode einfügen, wie
eine tri-state fähige Hardware in VHDL beschrieben wird?
(nicht nur für Simulation sondern auch Synthese)

Gruss, Daniel

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube das ghdl, das Du verwendest, ist in C++ programmiert.
Dort könntest Du dir den ganzen Mechanismus einmal ansehen.
Der Mechanismus in allen Feinheiten ist aber komplizierter als es den
Anschein hat, dazu gibt es ganze Bücher.

Kurze Zusammenfassung :
Zuerst einmal gibt es für jedes Signal und für jeden Prozess, der das
Signal ändert, eine Event Queue (Ereignis-Liste), in der die
zukünftigen Signal-Änderungen festgehalten werden (Neuer Pegel,
Zeitpunkt der Änderung).

Dann gibt es eine Reihe von Prozessen, welche die Signale ändern.
Prozesse entstehen nicht nur wenn man ein prozess-Statement schreibt,
sondern sogar die Zeile

s <= '1';

aus Deinem Beispiel erzeugt einen Prozess.
Alle Prozesse werden beim Starten der Simulation aktiviert und laufen
bis zum Ende oder bis zu einem wait-statement.
Dabei erzeugen sie Signal-Änderungen für zukünftige Zeitpunkte.
In Deinem Beispiel erzeugt
s <= '1';
die Signaländerung von 'U' auf '1'.
Der VHDL-Simulator verwendet dabei eine Methode, die man Delta Zyklus
nennt. Wenn in der Zuweisung keine Verzögerung angegeben ist, gilt die
Zuweisung für den gleichen Zeitpunkt, aber einen "Augenblick" (1
Delta-Zyklus) später.
In Deinem Beispiel ist die Zeit bei der Zuweisung 0 ns, der neue Wert
gilt für 0 ns + 1 Delta Cycle.

Erst wenn ALLE Prozesse abgearbeitet sind, dann werden die Werte für
die Signale neu berechnet und zugewiesen.

In Deinem Fall hat es 2 Prozesse gegeben, welche das Signal s zu
Zeitpunt t = 0 ns + 1 Delta ändern wollten. Das Ergebnis ist 'X'.
Der Simulator rückt dann die Zeit weiter (eventuell nur um einen Delta
Zyklus) und startet alle Prozesse neu (oder setzt sie am wait-statement
fort), welche auf eine Änderung der geänderten Signale warten.
In Deinem Fall gibt es keine solchen Prozesse, und außerdem keine
weiteren Signal-Änderungen -> d.h. der Simulator stoppt.


Zur Synthese von resolved signalen :
Wie gesagt wurde braucht man resolved Signale zur modellierung von
Bussen, und bei Bussen soll immer nur ein Modul den Bus treiben, alle
anderen sollen tri-staten.
Es gibt aber wenige FPGA's, welche interne, tri-state fähige Busse
haben. Resolved Signale werden deshalb meist nur in Testbenches
sinnvoll eingesetzt.
Man verwendet andererseits auch bei Modulen, die man synthetisiert,
meistens den type "std_logic", aber unnötigerweise.

Grüße
Klaus

Autor: -daniel- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

Danke für die ausführliche Erklärung
Ich lese zZ ein Buch "VHDL for logic Synthesis" von
Andrew Rushton und er beschreibt kurz die Arbeitsweise vom
Simulator.
Das auch simple
s <= '1';
ein Process ist, das war mir klar. Auch wenig gebrauchte Syntax

name: s <= '1';

ist analog zu

name: process
begin
end process;

Autor: -daniel- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin auf Returntaste aus Versehen und zu schnell abgeschickt :)

name: process
begin
    s <= '1';
end process;

ist äqivalent zu

name: s <= '1';

wobei der letzte Process implizit Abhängig von allen
Events die auf der rechten Seite von <= stehen.
und beim ersten muss explizit eine sensitive list stehen.
(oder "wait on" im Processblock)

ghdl ist in Ada geschrieben, ich denke weil Frontend
von Ada und vhdl ähnlich sind(?)

Gruss, Daniel

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.