Einsatz von 'buffer' seit VHDL-2008

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.