VHDL benutzen von std_logics

[Alabama J. (alabamajack)]

Hallo,

zu dem Thema gibt es Beiträge im Internet, Beiträge im Studium, Beiträge 
in Büchern zu hauf, trotzdem beschäftigt mich die Frage doch sehr.

Hat es einen Vorteil IMMER std_logics (insbesondere für Ports) zu 
verwenden? Ich meine im Bezug auf synthesierbaren Code?

Ein Beispiel:

Ich will einen entity bauen, die einen "Modus" hat(was weiß ich, auf- 
und abzählend oder so). Für die Ausführung(simulierung) macht es erstmal 
keinen Unterschied, ob ich einen std_logic dafür verwende und dann 
abprüfe ob der gesetzt oder nicht gesetzt ist. Für die Lesbarkeit macht 
es einen "gewaltigen"(in diesem Beispiel vielleicht nicht, bei größeren 
Designs aber mit Sicherheit) ob ich mir dafür, in einem package z.B., 
einen eigenen Typ definiere den ich dann für diesen Port benutze.
Ich persönlich würde die 2te Variante bevorzugen, weil es einfach besser 
lesbar ist.

Ich dachte mir aber auf der anderen Seite auch: Naja ich will das Ding 
synthetisieren, also wie schaut das Ding dannach aus und hab ich dann 
Nachteile wenn ich mir einen eigenen Typ erstelle. Ich würde z.B. auch 
gerne damit eine RTL-Simulation machen.

Also: Welche Vor-/Nachteile habe ich wenn ich anstatt der sturen 
Verwendung von std_logic auch für Ports mal Typen benutze?

[Martin S. (strubi)]

Moin,

ich zögere noch, ob der Begriff "API" bei VHDL zutreffend ist, aber im 
Endeffekt kommt es nur aufs Interface an. Wenn du deine eigene interne 
API mit records oder eigenen Typen definierst, kräht eigentlich kein 
Synthese-Tool nach std_logic - mir ist zumindest keins bekannt.
Die API spielt eigentlich eher bei der Simulation ne Rolle, aber auch 
dort eher in den Tiefen des VHDL-Gesetzbuchs, in dem sich eigentlich 
auch kaum einer so genau auskennen will, denn wir wollen ja Hardware 
beschreiben.
Höchstens die Stolperfallen mit std_logic_arith versus numeric_std 
sollte man im Auge behalten (gerade unter dem Aspekt verschiedener 
herstellerspezifischen Implementationen, die leicht vom strengen VHDL 
abweichen).
Wenn du zudem einen Typen definierst, der sowieso auf std_logic oder 
unsigned aufbaut, hast du keine Nachteile. Ist ja intern immer noch 
dasselbe.
Also nur zu, mach es lesbar, denn das kriegen in der HDL-Welt nicht 
immer alle so gut hin. (ich mach jetzt mal keine Werbung für MyHDL...)

Grüsse,

- Strubi

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Alabama J. schrieb:
> Also: Welche Vor-/Nachteile habe ich wenn ich anstatt der sturen
> Verwendung von std_logic auch für Ports mal Typen benutze?
Kein Problem. Nimm innerhalb des FPGAs, was immer du willst und was 
zielführend ist.
Nimm nach aussen (und am besten auch für Module, die andere ebenfalls 
benutzen müssen) die std_logic.

Vorteil: kompakte Portzuweisung, wenn du z.B. einen Struct oder einen 
"eigenen" Datentyp als Port nimmst.

[Alabama J. (alabamajack)]

Nur nochmal zur richtigstellung wie ich es meinte, nämlich als enum(nur 
um abzuklären, das wir nicht aneinander vorbeireden^^):
ich meinte sowas:

package ...

type Counter-Port-mode is (Counter, Capture);
...

entity mycounter is
port(
    Mode : in Counter-Port;
    ....
); ...

-- anstatt
port(
    Mode : in std_logic; -- '0' -> Counter, '1' -> Capture
    ...
);

Jetzt mal nur für dieses Beispiel, wenn ich es nur intern benutzen 
würde. Das ich Signale die von aussen kommen/gehen besser als std_logic 
definiere, dachte ich mir schon.

Lothar M. schrieb:
> Alabama J. schrieb:
>> Also: Welche Vor-/Nachteile habe ich wenn ich anstatt der sturen
>> Verwendung von std_logic auch für Ports mal Typen benutze?
> Kein Problem. Nimm innerhalb des FPGAs, was immer du willst und was
> zielführend ist.
> Nimm nach aussen (und am besten auch für Module, die andere ebenfalls
> benutzen müssen) die std_logic.
>
> Vorteil: kompakte Portzuweisung, wenn du z.B. einen Struct oder einen
> "eigenen" Datentyp als Port nimmst.

Ich würd mir evtl. auch noch ein generic sparen, wenn ich das Design 
aufwärtskompatibel halten will(also z.B. die Breite von Port "Mode" 
anpassbar halten will, wenn irgendwann noch Modi dazukommen.

-> Dann bin ich gar nicht soweit weg mit meinen überlegungen :)

Noch ne Frage: Mach ich dem Synthetisierer das Leben nicht leichter wenn 
ich einen enum-Typen für sowas definiere?

[Karl (Gast)]

Ich nehm für komplexe Datentypen wie Busse records und typedefs. Bei 
Mode-Einstellungen bei kleinen Untermodulen ist es mir aber den Aufwand 
nicht wert. Oft legt man sowas wie eine Konfigurationsoption - um bei 
deinem Beispiel zu bleiben - auf ein Register. Jetzt müsste ich im 
blödsten Fall wieder Konvertierungsfunktionen nach SL/SLV machen und das 
dann immer mitziehen -> viel zu umständlich.


Bei States macht ein Enum schon Sinn - man könnte das ja auch als SLV 
und mit Konstanten machen. In der Simulation ist es aber schon deutlich 
lesbarer.
Bei so Kleinkram lass ich es aber sein.

[Fpgakuechle K. (Gast)]

boolean ist bauch recht brauchbar, macht er den Code doch fast 
natursprachlich lesbar:

statt

if data_enabled = '1' then

mit boolean:

if data_enabled then

MfG,

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fpga K. schrieb:
> macht er den Code doch fast natursprachlich lesbar:
Dann muss man natürlich bei der Namensgebung ein wenig aufpassen. So 
wäre das schief gegangen:

if data_enable then
...
if read_write then

Denn jetzt wird "natürlichsprachlich" eigentlich nur noch das 
Vorhandensein des Signals an sich abgefragt, nicht mehr der Zustand 
dieses Signals...


Das ist ähnlich wie so eine Funktion:
SetOutput(1);
Scheint klar zu sein...
Und was passiert hier:
SetOutput(0);
Wird hier der Ausgang Nummer 0 gesetzt.
Oder wird der Ausgang auf '0' gesetzt?

Alabama J. schrieb:
> Ich persönlich würde die 2te Variante bevorzugen, weil es einfach besser
> lesbar ist.
Kurz&bündig:
Die Lesbarkeit eines Quelltextes macht man sich meist nicht durch 
Portdefinitionen zunichte, sondern durch unglücklich gewählte Namen...

[Markus F. (mfro)]

Fpga K. schrieb:
> boolean ist bauch recht brauchbar, macht er den Code doch fast
> natursprachlich lesbar:
>
> statt
>
> if data_enabled = '1' then
>
> mit boolean:
>
> if data_enabled then
>
> MfG,

Das geht in VHDL 2008 auch mit std_logic.