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?
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
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.
Nur nochmal zur richtigstellung wie ich es meinte, nämlich als enum(nur um abzuklären, das wir nicht aneinander vorbeireden^^): ich meinte sowas:
1 | package ... |
2 | |
3 | type Counter-Port-mode is (Counter, Capture); |
4 | ...
|
5 | |
6 | entity mycounter is |
7 | port( |
8 | Mode : in Counter-Port; |
9 | ....
|
10 | ); ... |
11 | |
12 | -- anstatt
|
13 | port( |
14 | Mode : in std_logic; -- '0' -> Counter, '1' -> Capture |
15 | ...
|
16 | );
|
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?
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.
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,
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...
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.