Moin, eine Frage, die ich mir gerade gestellt habe: Ist 'buffer' für einen Signal im Entityport seit VHDL-2008 noch für irgendwas gut? Buffer war, soweit ich es gelernt habe, ja nie richtig 'beliebt' und seit VHDL-2008 fällt auch der einzige mir bekannte Einsatzzweck, das Lesen von Ausgangssignalen, weg.
Ich habe es selbst vor VHDL-2008 nie verwendet und jetzt scheint es keinen Unterschied zu out zu geben. Auch im Buch „Effective Coding in VHDL“ steht nichts anderes.
Also erstmal, das wolllte ich eben schon korrigieren, aber der Spamschutz hat mich nicht gelassen: "Ist 'buffer' für ein Signal..." Blechbieger schrieb: > Ich habe es selbst vor VHDL-2008 nie verwendet und jetzt scheint es > keinen Unterschied zu out zu geben. Mir erscheint es auch so. Verwendet habe ich buffer auch fast nie, außer als Anfänger oder zum schnellen Testen. Deshalb frage ich mich, ob 'buffer' inzwischen genau das Gleiche wie 'out' ist.
Dussel schrieb: > Deshalb frage ich mich, ob > 'buffer' inzwischen genau das Gleiche wie 'out' ist. Nein, ist es selbstverständlich nicht. Buffer ist in etwa das, was inout darstellt und passt nur auf das Toplevel. Verwendet man es intern, wird es nach außen getrieben, soweit das möglich ist. Funktionieren kann es aber nur, wenn auch die weiteren Signale als buffer definiert sind und entsprechend verdrahtet werden können. Ich habe da aber schon Pferde kotzen sehen, z.B. bei Datenleitungen von externen RAMs. Am Ende gab es nur noch outputs und die inputs konnten nicht mehr gebaut werden. Man sollte solche Spielchen lieber weglassen und saubere Signal definieren, also IO auf dem LOPLEVEL und innen eins von beiden.
Dussel schrieb: > Buffer war, soweit ich es gelernt habe, ja nie richtig 'beliebt' und Beliebtheit ist hier kein Kriterium, weil es ja um einen formal korrekte Beschreibungssprache für sicheres FPGA-Design und nicht um die Verbreitung einer fetzigen Jugendsprache geht. 'buffer' ist halt wie die Verwendung des 'Goto' in modernen Programmiersprachen: wenn man das im Code findet war offensichtlich ein Idiot am Werk der die passenden Sprach-elemente für diesen Fall nie gelernt hat oder aus Bequemlichkeit ignoriert. Man könnte höchstens nachforschen, ob es im ASIC-Bereich diesbezüglich anders ausschaut.
Messtechnikprofi schrieb: > Buffer ist in etwa das, was inout darstellt und passt nur > auf das Toplevel. Interssant. Ich kannte 'buffer' immer nur als Ausgang. Dann muss ich mich da wohl nochmal genau einlesen. Fpgakuechle K. schrieb: > Beliebtheit ist hier kein Kriterium Und deshalb steht es in Anführungszeichen. Fpgakuechle K. schrieb: > 'buffer' ist halt wie die Verwendung des 'Goto' in modernen > Programmiersprachen Während aber goto grundsätzlich noch (seltene) Anwendungszwecke hat(te), kam es mir so vor, als wären 'out' und 'buffer' jetzt genau das Gleiche oder als wäre 'out' ein universelleres und sichereres 'buffer'. Der Antwort von Messtechnikprofi zufolge ist das aber ja nicht der Fall.
Messtechnikprofi schrieb: > Buffer ist in etwa das, was inout > darstellt und passt nur auf das Toplevel. Sicher? Oder wie ungenau ist deine Floskel "ist in etwa das, was"? Bei inout kann man ein Signal lesen. Man liest immer das, was wirklich auf der Leitung anliegt. Wenn man also eine '0' oder '1' aktiv ausgibt, dann liest man diese auch außer bei einem Konflikt. Wenn man 'Z' ist, dann liest man das was ein anderer Teilnehmer ausgibt. Bei Buffer hat man einen Ausgang. Und nur einen Ausgang. Ja, man kann auch lesen, aber nur das was man selber schreibt. Dafür hat ein Buffer speicherndes Verhalten, da werden also FFs verwendet. Man kann so z. B. direkt einen Buffer als Zähler verwenden, lesen und erhöhen. Oder wie im Anhang ein Bit toggeln. Mit VHDL2008 kann man sowieso Ausgänge auch intern lesen. Wenn man das getaktet macht, dann werden auch dort wie beim Buffer FFs verwendet. Fpgakuechle K. schrieb: > wenn man das im Code findet war offensichtlich ein > Idiot am Werk der die passenden Sprach-elemente für diesen Fall nie > gelernt hat oder aus Bequemlichkeit ignoriert. Nun, Buffer gibt es nicht ohne Grund in der Sprache und in VHDL2008 kann man auch nicht ohne Grund Ausgänge auch intern verwenden. Und zwar weil es die Sprache etwas bequemer macht. Natürlich sollte man wissen was man tut, aber das gilt sowieso immer. Ich finde das also völlig OK und richtig wenn man Sprachfeatures korrekt verwendet. Auch wenn das Features sind die man leicht falsch verwenden kann.
Gustl B. schrieb: > Auch wenn das > Features sind die man leicht falsch verwenden kann. Das ist doch das Problem. Die Beschreibung "Buffer" hat im analogen Bereich die Bedeutung einer Signalentkopplung, insbesondere auch im FPGA im Bezug auf Takte und IOs. Sie rührt her von einer Beschreibung von physikalischen Funktionen und die kollidieren regelmäßig mit denen für das Logikdesign, weil die Pioniere der HDL das eben durcheinandergeworfen haben. Es wäre allemal zweckmäßiger, dies zu trennen und für die logische Funktion des Pufferns eines Signals, also der statischen Speicherung, eine andere Terminologie einzuführen. Um das zu entspannen hilft es daher nur, auf solche unlogischen Konstrukte bei der Bescheibung von Schaltungslogik zu verzichten. Im Bezug auf "buffer" ist das umsomehr nötig, weil es diese physikalische Funktion so in FPGAs nicht mehr gibt.
Jürgen S. schrieb: > Das ist doch das Problem. Nein. Oder anders: Wir sollten vorher mal klären wer eine Sprache wie benutzt. Profis mit viel Erfahrung, professionellere Amateure die schon etwas mehr wissen aber keine Profis sind, Anfänger. Und was ist die Aufgabe der Sprache? Soll die Sprache so sein, dass sich selbst der blutigste Anfänger nicht in den Fuß schießen kann? Oder soll die Sprache so sein, dass ein Profi damit möglichst einfach zum Ziel kommt? Was sollen wir also verbieten? Buffer in VHDL Ports. For ... loop ist für Anfänger auch gefährlich. Variablen auch und es gibt keine Stelle an der man Variablen zwingend verwenden müsste, also auch weg damit? Und wer sollte das verbieten oder beseitigen. Muss schon die Sprache Idiotensicher sein? Warum? Wenn da ein Profi dran sietzt, dann freut der sich über Features die ihm die Arbeit erleichtern und er weiß genau was er tut. Ich bin dafür, dass das die Menschen regeln die eine Sprache verwenden. Man sollte sich selbst einschätzen und dann nur das verwenden was man auch beherrscht. Ist ja auch außerhalb der Sprachen so. Wenn man nicht weiß wie ein Ding funktioniert und durch Fehlbedienung Schaden entstehen kann, dann lässt man es besser. Sowas wie die Kettensäge meine ich. Und dann gibt es ja auch noch Firmen. Die können ihren Mitarbeitern Dinge vorschreiben. Also auch Sprachkonstrukte verbieten. Ich weiß von einer Firma die viel ADA in der Luftfahrt verwendet. Dort ist Rekursion verboten. Und zwar vor allem aus Gründen der Wartbarkeit. Wenn man Code von anderen Mitarbeitern übernehmen soll/muss, dann sollte der einfach zu verstehen sein. Rekursion kann da ein Hindernis sein.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.