Hoffe, heute könnt ihr mir mal helfen, da ich endlich mal eine Frage für euch habe :-)
In einem existierendem Code wird eine Konstante berechnet die einer 2 entspricht in einem fixed-point Format gegeben durch Generics als Wortbreite (WIDTH) und Stellen hinter dem Punkt (FRACTIONAL):
1
constantCONST2:signed((2*WIDTH)+1downto0):=
2
to_signed(2*2**(2*FRACTIONAL),(2*WIDTH)+2);
Das klappt auch, so lange FRACTIONAL < 15 ist. Darüber überläuft dann der 32bit Integertyp von VHDL.
In einem existierendem Code wird eine Konstante berechnet die einer 2
entspricht in einem fixed-point Format gegeben durch Generics als
Wortbreite (WIDTH) und Stellen hinter dem Punkt (FRACTIONAL):
Aber der Code macht das nicht. Der Code erzeugt ein signed. Aber du willst doch ein sfixed oder ufixed wenn ich das richtig lese?!
Aber mit WIDTH und FRACTIONAL kannst du dir die 2 als langen std_logic_vector selber bauen und dann nach ufixed casten. Oder gleich die Integer 2 nach ufixed konvertieren.
Naja, ist zwar nicht mein Code, aber wenn man Komponenten schreibt, dann sollen die doch möglichst generisch sein. Wenn ich einen FIFO schreibe dann soll die Tiefe/Breite/... später per Generic einstellbar sein. So muss man dann auch nur eine Komponente warten. Für mich ist das also guter Stil was der TO erreichen möchte.
Hoffe, heute könnt ihr mir mal helfen, da ich endlich mal eine Frage für
euch habe :-)
Klar, darauf haben "wir" gewartet, das "Du" Dir eine Frage aus dem A... extra für "uns" pullst.
Die Lösung ist doch simple, du benutzt den datentyp std_logic_vector durchgängig. Für Ausdrücke länger als 32 bit berechnest Du die teilterme, die die mit dem Verkettungsoperator "&" zu der gewünschten breite zusammenfügst. Bei To_unsigned dagegen haste wieder den beschränkten Datentyp integer im funktionsargument. Gück doch in den Quellcode der standard libs die du verwendest.
Wenn du den Unterschied zwischen einem int-Datentyp (scalar) und einen std_logic_vector (array, 'string') verstamden, löst sich die Denkblockade wie von selbst auf. Aber das dazu nötige intellektuelle Inventar bringt nicht jeder mit ...
So muss man dann auch nur eine Komponente warten. Für mich ist das also
guter Stil was der TO erreichen möchte.
Welche Wartung willst du an einer KONSTANTEN vornehmen?! Eine Konstante
änderbar vorzusehen ist ne reichlich blödsinnige Idee. Da macht dann fehlersuche richtig Spass, wenn dann irgendein scriptkiddy eine Bibliothek importiert und aus Langeweile kommentarlos PI := 22/7 vorgibt.
Eine Konstante ist kein Parameter.
Falls man hier wegem Stil Krümmel kacken möchte, dann könnte man darauf hinweisen, das manche VHDL-Übersetzer es überhaupt nicht mögen, wenn mehr als ein return in einer Funktion auftaucht. Oder irgendwo mittendrin statt am Schluß der Funktion. Aber das lediglich ein Krümel, etwas schwerer wiegt der sparsame Umgang mit erläuternden Kommentaren....
Krümmel ist ein Ort im Westerwald (und Orte kann man nicht kacken).
JA, der "**"-Operator ist schnell hingeklatscht und soll lediglich das Prinzip zeigen. Den "wasserdicht" zu machen, überlasse ich - wie auch das mehr oder weniger zielführende Meckern - dem mehr oder weniger geneigten Leser.
Aber der Code macht das nicht. Der Code erzeugt ein signed. Aber du
willst doch ein sfixed oder ufixed wenn ich das richtig lese?!
Uhh, so weit sind wir hier noch nicht, das wir durchgängig sfixed einsetzen. Dieser Code wurde jetzt endlich mal "sanft" überarbeitet, damit er keine längst obsoleten Firmen internen Libraries mehr braucht, numeric_std nutzt und die alte testbench läuft unverändert fehlerfrei durch (parallel zu meiner mit wesentlich höherer coverage...)
Für Ausdrücke länger als 32 bit berechnest Du die
teilterme, die die mit dem Verkettungsoperator "&" zu der gewünschten
breite zusammenfügst.
Da es sich hier in dem Fall um eine dezimale 2 handelt, also eine einzelne binäre '1' an der richtigen Stelle, werde ich mir das wohl so zusammen bauen, weil es hier einfach zum Ziel führt.
Danke @mfro für die Idee mit der Potenzfunktion für signed Typen!
Die Lösung ist doch simple, du benutzt den datentyp std_logic_vector
durchgängig. Für Ausdrücke länger als 32 bit berechnest Du die
teilterme, die die mit dem Verkettungsoperator "&" zu der gewünschten
breite zusammenfügst.
Eigentlich wird empfohlen, zum Rechnen überhaupt keine Vektoren zu benutzen. Dafür gibt es die einschlägigen Variablenklassen.
Welche Wartung willst du an einer KONSTANTEN vornehmen?! Eine Konstante
änderbar vorzusehen ist ne reichlich blödsinnige Idee.
Ja ist es das?
Als Beispiel will man einen Testbildgenerator schreiben dem man die Bildauflösung als Generic mitgeben kann.
Klar kann man dann drinnen alles nur mit diesen Generics rechnen, aber es ist durchaus sinnvoll dort Konstanten zu definieren für Frontporch, Backporch, ... und die sind dann von den Generics abhängig.
Konstanten sind eben oft dazu da um Ausdrücke zu vereinfachen. Damit eine konstante Rechnung, abhängig von Generics, nicht öfter an vielen Stellen, sondern nur einmal an einer STelle im Code steht.
Und das ist auch gut und sinnvoll, denn es ist wartbarer Code weil ein Fehler in der Berechnung nur einmal bei der Konstantenzuweisung gefixt werden muss.
So wie Du das hier in den Raum wirfst, klingt das eher nach heißer Luft eines Wichtigtuers statt einem tatsächlichen Expertenrat-
Zumal ein type wie *_vector oder keine class ist.
Und bezüglich variables in VHDL heisst es eigentlich:
"Only fools and experts uses variables".
Wahrscheinlich willst lediglich darauf hinweisen, das in einer Simualtion skalare typen wie int i.d.R. weniger runtime benötigen als arrays wie signed greifst aber bezügliche der Fachtermini ins Klo respektive bewegst Dich im Umfeld einer anderen Beschreibungssprache als VHDL.
Und das ist auch gut und sinnvoll, denn es ist wartbarer Code weil ein
Fehler in der Berechnung nur einmal bei der Konstantenzuweisung gefixt
werden muss.
Du verwechselst die Termini "Konstante" und "Parameter".
In dem genannten Beispiel (Videocontroller) macht man es eigentlich so das man die generic-Sätze als constant in unterschiedlichen packages definiert. Oder unterschiedlich benamste Konstanten benutzt (bspw.: C_V_Pulse_start_800x600 und C_V_Pulse_start_1024x768). Oder unterschiedliche records (bspw. 800x600.C_V_Pulse_start). Andernfalls riskiert man den Überblick zu verlieren vor lauter 'gefixten' aka veränderten aber nicht unbenannten Konstanten.
Du verwechselst die Termini "Konstante" und "Parameter".
Ne.
Ja, man kann ein Package mit Konstanten machen und dann in der Komponente einbinden oder man kann generic Packages verwendet, ...
Man kann aber auch Konstanten in der Komponente berechnen die nur von Generics abhängen. Vielleicht nicht so schön, aber immer noch besser als an vielen Stellen vom Code die gleiche Berechnung stehen zu haben.
Ich finde also das was der TO vor hat durchaus OK und gut auch wenn es vielleicht noch elegamnter ginge (das weiß man aber nicht weil der Kontext fehlt).
... Konstanten in der Komponente berechnen die nur von Generics abhängen.
Vielleicht nicht so schön,
Wenn ich mich recht erinner wird das vom modelsim und XST mit ner warning ("Non-locally static" o.ä. ) quittiert. Auch die Verwendung eines Functionsaufrufes (bei der Typ-Convertierung bspw.) kann bei der Konstantendeclaration (unnötige?) warnings/errors hervorbringen.
Ja, manche lesen sich alle Warnings während der Compilaton/Synthese durch, andere nicht. Und ja, 'ne warning ist nur 'ne warning.
Naja, ist zwar nicht mein Code, aber wenn man Komponenten schreibt, dann
sollen die doch möglichst generisch sein. Wenn ich einen FIFO schreibe
dann soll die Tiefe/Breite/... später per Generic einstellbar sein.
Generell stimme ich da zu, aber man muss Aufwand und Nutzen abwägen. Die Skalierbarkeit erfordert einen nicht unerheblichen Mehraufwand und das nicht nur beim Programmieren. Die Möglichkeiten, die sich daraus ergeben, müssen auch untersucht und gfs. eingeschränkt werden - gerade bei Anforderungen an den Code in bestimmten Branchen. Bei der Verifikation ist es auch einfach durchsichtiger mit tatsächlich konstanten Werten zu arbeiten, die evident sind und nicht nachvollzogen werden müssen.
Und was man auch sehen muss: Die Skalierbarkeit muss dann auch durchgezogen werden, wenn sie Sinn machen soll, was oft nicht der Fall ist. D.h. man hat eine skalierbare Komponente, die aber gar nicht skaliert werden kann, weil der Rest des Codes die Situation einfriert und fixiert. Da muss dann wieder dokumentiert werden, was skalierbar ist und wie und welche Einschränkungen vorliegen. Als black box, um die man sich scheinbar nicht kümmern muss, ist das zunächst gut und schön, ich kann aber dutzende Fälle benennen, wo dann irgendwas nicht funktierte weil der Ersteller nicht alles berücksichtigt hat.
Ich hatte gerade eben wieder so einen Fall mit einer Komponente, die ein Array von Signalen verwendet, das man theoretisch einfach hätte um einige Signale erweitern können müssen, indem man den Wert größer wählt. Ging aber aus unerfindlichen Gründen nicht. Tief im design war irgendwas dann doch noch festgenagelt und es gab sich offenbar widersprechende Generics. Trotz aufwändiger Suche war es nicht zu lösen. Eine scheinbar intelligente und als fertig angesehene Komponente, die man auf die Schnelle hätte einsetzen sollen, die aber am Ende einen Haufen Stress gemacht hat. Einfach stumpf runterprogrammiert, um es per COPY und PASTE zu erweitern, hätte es einfacher gemacht und auch in der Zeit noch funktioniert. (Der Entwickler selber empfahl am Ende, es neu zu machen).
Als Beispiel will man einen Testbildgenerator schreiben dem man die
Bildauflösung als Generic mitgeben kann.
Das mag sinnvoll sein, allerdings muss man dann eben auch hergehen und alle Variablen und Signale von dem Bildformat abhängig machen und nicht jedes Element einzeln aus Konstanten zu berechnen, wie es oft gemacht wird. Dann ist es nämlich möglich, unmögliche Videoformate und timings vorzugeben, d.h. die Komponente in einen nicht funktionierenden Zustand zu bringen, weil intern Zählerabfragen und Überläufe in den möglichen Formaten getestet funktionierten, aber in den ungetesten, die man der Flexibilität wegen eingebaut hatte, ausgefallen waren. Das sind einfach zu viele Möglichkeiten.
Wenn das dann von Außen nicht richtig angefahren wird, versagt das System dann in ungünstigen Fällen, weil die keiner auf dem Schirm hatte und es nicht simuliert wurde. Kunden von mir sind schon einige male mit solchen Sachen schwer auf den Hintern gefallen und dies auch deshalb weil die Komponente mal erweitert wurde und die Skalierbarkeit a) mangels Verständnis und b) wegen der Komplexität nicht stringent durchgezogen wurde.
Um das richtig sicher zu machen, müsste es also in allen Lagen eingeschränkt werden und die Kombinationen möglicher Fälle gegen die nicht erlaubten abgegrenzt werden. Das aber geht im Aufwand sehr schnell in Regionen, die es unwirtschaftlich werden lassen.
Da in vielen Bereichen der Code und dessen Funktion - aber auch dessen Varianz (eben jene Verwendbarkeit) detailliert untersucht und dokumentiert werden muss, ist es einfacher und schneller (und auch sicherer) das nur auf die wenigen Fälle zu beschränken, die wirklich benötigt werden und den Rest zu fixieren. Damit muss dann den Entwickler eines Derivats eben die Doku bemühen, um seine Version zu erzeugen, tappt aber dabei auch nicht in die Falle, dass etwas nicht automatisch hinhaut. Er steht auch nicht vor dem Dilemma die Komponente updaten und erweitern zu müssen, um dann alles in die alten Repositories spielen zu müssen und/oder mit einem flick arbeiten zu müssen um seine Arbeit abschließen zu können.
Solche Effekte sind nämlich dann die Konsequenz von "flexiblem" Code, den man aufbläst, um ihn wiederverwertbar zu machen. Der Erstentwickler muss gut nachdenken und weit bauen, sonst kommen nämlich für das Ding doch immer wieder updates oder man hat Aufwand mit unterschiedlichen Ausbaustufen. Und dann schnappt sich jemand die falsche Ausbaustufe und fällt auf die Nase.
Am Ende ist der Aufwand aus Projektsicht meistens höher und ufert aus!
Ich empfehle bei den wachsenden Komplexitäten der FPGA Designs damit allen Kunden und Entwiclern, sich generell genau zu überlegen, wieviel man in resuability stecken will, die am Ende keinen Benefit hat sondern noch Probleme aufwirft. Stattdessen sollte man schauen, dass man designs so weit wie möglich trennt und entflechtet.
In dem genannten Beispiel (Videocontroller) macht man es eigentlich so
das man die generic-Sätze als constant in unterschiedlichen packages
definiert. Oder unterschiedlich benamste Konstanten benutzt (bspw.:
C_V_Pulse_start_800x600 und C_V_Pulse_start_1024x768).
Das ist genau das, worauf es hinausläuft. Und für dieses Beispiel würde das nicht einmal reichen, weil es für solche Parameter mehr Variationsmöglichkeiten innerhalb der Video-Modes gibt, je nach Interlaced oder Progressive bzw. Bildfrequenz / Horizontaltakt. Ich habe schon solche Videogeneratoren geschrieben und sie für 24Hz, 50Hz, 60Hz sowie 59,94 und "falsche 50" angepasst. Dazu gab es Videomodes für Kameras die das Rohformat des Sensors ausgeben können.
Schon mit nur einer anderen Wiederholrate und verändertem Rand-Offset für die Messpixel bekommt man eine Matrix für jeden einzelnen Parameter. In einem Fall habe ich das tatsächlich im Code implementiert, weil der Kunde es in im Betrieb umschalten wollte.
In der Regel setze ich aber ein Excelblatt an, dass diese Fälle berücksichtigt und für alle benötigten Kombis einen Codesatz erzeugen kann, gfs mit VHDL-Ausgabe. Dann wird das so erzeugte Excel eingefroren und zu dem ebenfalls eingefrorenen Code beigepackt. Die kriegen einen Namen und die Kombi geht als getestet in die Liste - wird später im Testplan vermerkt und final auch abgehakt und bestätigt. Ende der Fahnenstange.
Ein Entwickler kann dann auf einen getesteten und dokumentierten Code zurückgreifen und damit wissen, dass er etwas funktionables nutzt oder muss es selber bauen und simulieren. Er kann sich dabei von einem ähnlichen Beispiel inspirieren lassen, die Werte übernehmen, um mit dem Master-Excel "seine" Version rasch parametrieren zu lassen. Konstanten für die Vektorbreiten zu nehmen, steht dem nicht entgegen. Sie werden aber nicht im Code berechnet und wenn dann nur in sehr einfachen Fällen.
Auf diese Weise weis der Entwickler, welchen Stand er da in Händen hält und kann komplett agieren.
Findet er einen Fehler im Excel, der bisher noch nicht aufgetaucht war, weil eine Einschränkung oder Problem mit einem neuen Mode übersehen worden war, kann er das selber updaten ohne irgendetwas anderes anfassen zu müssen. Die alten Codes bleiben wie sie sind, weil sie ja getestet wurden und von diesem Fall nicht betroffen sind. Kein Änderungsantrag, kein SW-Update, keine geänderte Common-Komponente, kein SAP-Nachttrag, kein Zeitaufwand für Diskussionen, keine neue Version eines Universalcodes, keine Änderungsmitteilung, keine Info an den Projektleiter oder Design Owner, keine Besprechung und Abstimmung wie man vorgeht, kein garnichts.
Einfach nur ein neues upgedates Excel auf dem Server, das nun etwas mehr kann, als das eigene und einmal COPY & PASTE aus der Excel-Spalte in die Parameterliste des VHDL. Wenn das VHDL ausgebaut werden muss, um einen Fehler abzufangen oder einen neuen Modus zu können, kommt das Ding parallel mit einer neuen Versionsnummer dazu und der nächste Entwickler hat es wieder einfach.
Um es am Beispiel der Videogeneratoren zu zeigen, gibt es dann für jedes Gerät (und nicht Modus) einen eigenen Videogenerator, der genau das kann, was dieses Gerät können muss. Er kann kein bischen weniger oder mehr, sodass Test und Spec 1:1 zusammenpassen. Alle Kombis, die möglich sind, sind genau einmal vorhanden, einmal simuliert und einmal getestet.
Dann kann es auch nicht passieren, dass sich einer beim build script vertut und das falsche in die Kompenten eintreibt und dann wieder was falsches gebaut wird, was erst nach tagelanger Fehlersuche auffällt. Mit einer solchen Aktion ist alles, was an scheinbarer Einsparung bei der Pflege erreicht werden könnte, doppelt und dreifach vernichtet, soforn nicht schon die Einbau der Flexibilität jeglichen Benefit verunmöglicht hatte. Ob ich die Parameter ins Excel haue oder in die Generics, ist ja Wuppe.
Schnelles und sicheres Entwickeln funktioniert generell nicht so, dass es sich der Entwickler einfach macht und lokale Automatisierungen eintreibt, sondern Code klar und explizit macht. Eher sollte man sogar mehr Aufwand in die Entwicklung stecken, um die Varifikation und die Inbetriebnahme zu vereinfachen, denn dort wird die meiste Zeit verbraten.
In der Regel setze ich aber ein Excelblatt an, dass diese Fälle
berücksichtigt und für alle benötigten Kombis einen Codesatz erzeugen
kann, gfs mit VHDL-Ausgabe. Dann wird das so erzeugte Excel eingefroren
und zu dem ebenfalls eingefrorenen Code beigepackt.
Das ist ein weiterer Lösungsansatz für das Problem des TO, den Wert der constant nicht per VHDL-Boardmittel zu bestimmen, sondern in einem extra script (Pyzhon,C,TCL/TK,csh,...) das dann den entsprechenden VHDL code als txt-string ausgibt.
So ähnlich wie man bspw bei Register packages macht. Oder um den Zeitpunkt der FPGA-Synthese in den VHDL-code zu bringen. Die generics müsst man dann per command line options übergaben. Oder als .json. Oder ...
Und das kann man wunderbar in den design flow einbringen, wenn man zur synthese nicht die KlickieKackie-GUI benutzt sondern ein buildscript mitliefert.
Wieder einer jener threads, der im Grunde wichtige Dinge enhtält, die es zu diskutieren gälte, der aber durch die Art und Weise der Diskussion und des vorgebrachten stils jedermann abschreckt, teilzunehmen.
DSGV-Violator schrieb :
... viel herablassendes Zeug, das die Frage aufkommen lässt, welche Natur diese Person ist.
Mit solchen pauschalen GUT-SCHLECHT-Aussagen kommt man nicht weiter.
Auch hilft es keinem wenn man sie zitiert. Noch dazu im falschen Kontext und Tenor.
Variablen haben ihre Berechtigung dort, wo es sinnvolle Stückelungen von komplizierten Berechnungen braucht und das nicht keineswegs etwas nur für die "Profis".
Mit solchen pauschalen GUT-SCHLECHT-Aussagen kommt man nicht weiter.
Auch hilft es keinem wenn man sie zitiert.
Das ist eine Redewendung wie "a fool with a tool, remains a fool" und keine Bewertung. Natürlich hilft die Regel, nur dann variable statt signal in VHDL zu verwenden, wenn man genau weiß was man damit tut und sich bewusst ist, das man sich damit u.U. Unterschiede im Verhalten in Simulation und Synthese einhandelt.
Variablen haben ihre Berechtigung dort, wo es sinnvolle Stückelungen von
komplizierten Berechnungen braucht und das nicht keineswegs etwas nur
für die "Profis".
Sorry, du hinterlässt hier den Eindruck nichts über den Unterschied zwischen "variable" in C u.ä.-Programmiersprachen und dem in VHDL/FPGA zu wissen. Und das es 'signal' in VHDL gibt. Und "komplizierte Berechnungen" werden im FPGA nicht "gestückelt" sondern ge-'pipelined'.
der aber durch die Art und Weise der Diskussion
und des vorgebrachten stils jedermann abschreckt, teilzunehmen.
Vielleicht wird ja hier nicht diskutiert (Palaver unter Gleich-/(Halb|Un)-Wissenden) sondern Wissen/Erfahrung von Wissenden (Befragten) zum Un-/Falsch-Wissenden (Frager) verteilt?
Ja vielleicht geht es ja auch genau darum, Mistige Offtopic-Diskussionen über des Kaisers Bart, seine Stil, seinen Tenor und seine Manieren von Beginn an zu unterbinden?!
Warum treibst du dich überhaupt im Forum herum? Offensichtlich nicht, um (von den Besten) zu lernen!
Und "komplizierte
Berechnungen" werden im FPGA nicht "gestückelt" sondern ge-'pipelined'.
Das sind verschiedene Dinge.
Ja, es gibt Pipelines, das sind dann mehere Takte.
Man kann Rechnungen aber auch zerteilen und trotzdem in einem Takt laufen lassen. Sinnvoll ist das, wenn die Rechnung von Dingen abhängt. Dann kann man die Einzelteile mit Variablen rechnen und dann abhängig vom Wert dieser Variablen im gleichen Takt daraus ein Ergebnis errechnen und einem Signal zuweisen.
Ist aber auch egal, das mit den Variablen gibt es schlicht nicht in Hardware, da gibt es nur FFs, LUTs, Leitungen, und Spezialkram.
Variablen sind nie zwingend notwendig, man kann das immer auch mit Signalen lösen, aber Variablen sind ein sehr hilfreiches Konstrukt, das einem das Leben einfacher macht. Sie verhalten sich aber auch anders als Signale. Das sollte man wissen und sie dementsprechend korrekt verwenden.
Aber was schreibe ich hier eigentlich? Jeder der mit irgendwelchen Werkzeugen arbeitet, sollte diese kennen und beherrschen. Mit Variablen sicher umzugehen sollte für einen Entwickler der mit VHDL zu tun hat genauso selbstverständlich sein wie der Umgang mit numeric_std oder ... das ist eben Teil des Handwerkzeugs.
Sorry, du hinterlässt hier den Eindruck nichts über den Unterschied
zwischen "variable" in C u.ä.-Programmiersprachen und dem in VHDL/FPGA
zu wissen.
Ganz im Gegenteil, der Umstand dass du den Sinn von Variablen im Bezug auf das Aufspalten von Gleichungen nicht verstehst und wild herumzitierst, zeigt, dass du nichts wesentliches kennst.
werden im FPGA nicht "gestückelt" sondern ge-'pipelined'.
Falsch. Variablen werden in Prozessen unter anderem dazu benutzt, dass KEINE pipeline entsteht, sondern es in einem Takt berechnet wird. Die Rechung ist nur nicht sinnvoll in einem einzigen VHDL-Konstrukt niederzuschreiben.
Du scheinst mit komplexeren VHDL-Aufgaben nichts zu tun zu haben.
Sorry, du hinterlässt hier den Eindruck nichts über den Unterschied
zwischen "variable" in C u.ä.-Programmiersprachen und dem in VHDL/FPGA
zu wissen.
Ganz im Gegenteil, der Umstand dass du den Sinn von Variablen im Bezug
auf das Aufspalten von Gleichungen nicht verstehst und wild
herumzitierst, zeigt, dass du nichts wesentliches kennst.
Naja, eins drüber steht richtig das es in einer FPGA-Implementierung keine "variables" (mehr) gibt. Was willst Du hier also auf Biegen und Brechen beweisen?
Und was regst Du Dich über angebliches "wildes Herumzitieren" künstlich auf? Es ist üblich, das man seine Aussagen mit Links belegt. Und warum soll man sich die Mühe machen, einem halsstarrigen und in seine Achtelwahrheiten verliebten Famulus vorzukauen und in mundgerechte Stücke zerlegt einzutrichtern, wenn sich der entsprechende Lehrtext mit Klick erreichen lässt? Wenn der Famulus sich weigert, dem Click zu folgen und sich mit dem Lehrtext auseinanderzusetzen - sein Problem, stirbt er halt dumm.
Die
Rechung ist nur nicht sinnvoll in einem einzigen VHDL-Konstrukt
niederzuschreiben.
Klar kann es "sinnvoll" sein eine komplexere Berechnung in einen einzigen VHDL-Konstrukt bspw. einem process festzuhalten.
Die "Lesbarkeit", insbesonders die durch ein Script-Kiddie ist eine andere Frage. Bring doch mal ein konkretes Source-beispiel. Aber bitte in einem neuen thread, den haste schon genug mit off-topic zugemüllt.
Und in Zeiten von VHDL-Generatoren wie simulink und verschlüsselten IP-Netzlisten ist die Rätselei über die Typografie eines VHDL-Pedants ohnehin müßig.
Du scheinst mit komplexeren VHDL-Aufgaben nichts zu tun zu haben.
Jajajaj, wir wissen alle das du nicht bereit ist anzuerkennen, wer hier praktische Erfahrungen hat und wer hier grad nur heisse Luft angereichert mit Pseudo-Buzzwords wie "VHDL-Konstrukte" oder "einschlägige Variablenklasse" aus den Backen drückt. Auch schon damit, das jemand eine andere Herangehensweise hat und in deiner nur nebulös beschriebenen Vorgehensweise keinen Vorteil sieht ist ein Affront für Dich, worauf der Thread mit offtopic wie "Hilfe, ich werde herablassend behandelt" oder "Der xyz hat keine Manieren" zugekackt wird.
Echt, damit stiehlt man anderen Leuten nur die Zeit.
Generell stimme ich da zu, aber man muss Aufwand und Nutzen abwägen. Die
Skalierbarkeit erfordert einen nicht unerheblichen Mehraufwand und das
nicht nur beim Programmieren. Die Möglichkeiten, die sich daraus
ergeben, müssen auch untersucht und gfs. eingeschränkt werden - gerade
bei Anforderungen an den Code in bestimmten Branchen. Bei der
Verifikation ist es auch einfach durchsichtiger mit tatsächlich
konstanten Werten zu arbeiten, die evident sind und nicht nachvollzogen
werden müssen.
Klar muss man den Aufwand und Nutzen abwägen, wir haben auch immer ein begrenztes Budget.
Wenn man etwas zum ersten mal macht, dann lieber weniger flexibel und sehr eingeschränkt. Man weiss ja gar noch nicht, ob es so klappen wird und was man braucht.
Später stellen sich die Wünsche dann von selber ein, dann entwickelt man es weiter in diese Richtungen, wo mehr flexibilität gefordert wird. Oder eben auch nicht, wenn keine Wünsche bestehen.
Die Testbenchs existieren ja, also kann ich da was umbauen und bin sicher, das der frühere use-case noch geht.
Ich empfehle bei den wachsenden Komplexitäten der FPGA Designs damit
allen Kunden und Entwiclern, sich generell genau zu überlegen, wieviel
man in resuability stecken will, die am Ende keinen Benefit hat sondern
noch Probleme aufwirft.
Geh mal in die Raumfahrt, da zählt design reuse und heritage mehr als alles andere. Ob der alte code jetzt was taugt oder nicht ist egal, am Besten ist er schon mehrere male geflogen.
Neu schreiben braucht eine neue Qualifikation, umschreiben/erweitern erfordert nur eine delta-Qualifikation. Das macht es wirtschaftlich interessant.
Das ist ein weiterer Lösungsansatz für das Problem des TO, den Wert der
constant nicht per VHDL-Boardmittel zu bestimmen, sondern in einem extra
script (Pyzhon,C,TCL/TK,csh,...) das dann den entsprechenden VHDL code
als txt-string ausgibt.
Ja, nutzen wir auch in verschiedenen Ausprägungen.
Z. B. Excel um Registeradressen zu verwalten, ist gleichzeitig Dokumentation, VHDL code generierung und Matlab code generierung.
Python um AXI slaves aus YAML zu bauen
Matlab um Stimuli und expected responses für Testbenches zu rechnen etc.
Wenn ich mich recht erinner wird das vom modelsim und XST mit ner
warning ("Non-locally static" o.ä. ) quittiert. Auch die Verwendung
eines Functionsaufrufes (bei der Typ-Convertierung bspw.) kann bei der
Konstantendeclaration (unnötige?) warnings/errors hervorbringen.
Ja, manche lesen sich alle Warnings während der Compilaton/Synthese
durch, andere nicht. Und ja, 'ne warning ist nur 'ne warning.
Ja, lesen und VERSTEHEN all dieser log Einträge gehört hier dazu und vordere ich auch ein.
In diesem Fall gibt es keine Non-locally static Warnung. An anderer Stelle im selben code schon, kommt drauf an, wie die Konstante dann genutzt wird. In einem Case statement z. B. kommt dann diese Warnung.
Und ja, 'ne warning ist nur 'ne warning.
Es gibt Projekte und Kunden, wo wir am Projektende im Verification Report für jede Warning eine Begründung angeben müssen, wieso sie akzeptabel ist (Waiver).
Ein Astronaut hat ein lebendiges interesse daran, ob es nur eine Warnung ist oder doch etwas Wichtiges.
Nicht Saturn sondern Jupiter :-)
Vielleicht hat es was mit Bepi-Colombo und JUICE zu tun.
Interessant. Kommst Du da nicht ein wenig zu spät? Ich meine letztere
Mission wäre vergangene Woche losgeflogen, erstere längst unterwegs?
Also bezugnehmend auf das geflügelte Wort von der "rocket science" war wohl weder eine Planetenmission zum ♄ oder zum ♃ gemeint, sondern schlicht die Trägerrakete "Saturn": https://de.wikipedia.org/wiki/Saturn_(Rakete)
Interessant. Kommst Du da nicht ein wenig zu spät? Ich meine letztere
Mission wäre vergangene Woche losgeflogen, erstere längst unterwegs?
Wir bzw. meine älteren Arbeitskollegen waren beides mal rechtzeitig :-)
Jetzt müssen wir gucken, dass wir für die nächsten Missionen rechtzeitig sind.
Und da brauche ich jetzt eben Erweiterungen, die die ursprüngliche Rechnung mit Integern nicht mer hergibt. Darum die Frage, wie man das sauber in VHDL machen könnte, so dass es sowohl in der alten Variante wie mit der neuen läuft, also testbar ist.
Da es eine 2 ist, habe ich mir ja dann einen passenden Vektor zusammengebastelt anstatt zu rechnen. Löst mein Problem aber ich hätte gehofft, dass es da eine universellere Lösung gäbe, die ich auch sonst anwenden kann.
Also bezugnehmend auf das geflügelte Wort von der "rocket science" war
wohl weder eine Planetenmission zum ♄ oder zum ♃ gemeint, sondern
schlicht die Trägerrakete "Saturn":
https://de.wikipedia.org/wiki/Saturn_(Rakete)
Klar hatte ich das verstanden. Aber Raketen sind im Vergleich ja "einfach", deren Job ist nach 5-20 min erledigt. Unser Zeug fliegt zum Teil erst mal 8 Jahre zum Einsatzgebiet oder in den Anforderungen steht z. B. dass es 15 Jahre funktionieren muss.
Unser Zeug fliegt zum
Teil erst mal 8 Jahre zum Einsatzgebiet oder in den Anforderungen steht
z. B. dass es 15 Jahre funktionieren muss.
... tut's leider nicht immer. Ich habe (das ist schon so lange her, dass es kaum mehr wahr ist) Teile der Telemetriesoftware für ein Raummodul des ERS-1 geschrieben. War gut genug, um den RAMs des 8-Prozessor-Z80-Moduls für ein paar Stunden nach dem Launch beim Latch-Up zuzugucken...
War zum Heulen.
Klar hatte ich das verstanden. Aber Raketen sind im Vergleich ja
"einfach", deren Job ist nach 5-20 min erledigt.
Ist halt ne Frage wo der Ort der "unangenehmsten" Strahlendosis liegt. Das kann auch schon mal der van-Allen-Gürtel in kanapp 1k km Höhe sein oder die südatlantische Anomalie deren Durchquerung in 1700 km Höhe für den Ausfall der Elektronik in den Globalstarsatelliten verantwortlich gemacht wird. Oder die sonde wird völlig unerwartet durch einen Sonnensturm "abgeschossen" wie 2002 "Nozomi" beim Earth swing-by.
Aber auch für solche elektronik und Space Betrachtungen gibt es threads in den passendere subforen:
wenn man genau weiß was man damit tut und
sich bewusst ist, das man sich damit u.U. Unterschiede im Verhalten in
Simulation und Synthese einhandelt.
Welche sollten das denn bitte sein? Variablen werden in beiden Welten genau gleich gehandhabt, wer da Unterschiede sieht, hat den Sinn nicht verstanden und aufgrund seines eigenen Unwissens falsche Erwartung gehabt.
Die Variablen werden immer und zu jeder Zeit vom Compiler in gleicher Weise behandelt und interpretiert - inbegriffen ihres Auftretens und Position im Code und der sich ergebenden zeitlichen Abarbeitung. Das ist der große Vorteil gegenüber Signalen. Ohne Variablen gäbe es keine Schleifen und somit keine Möglichkeit, identische Gebilde in einem Design mehrfach automatisch aufzubauen.
Du hast keine Ahnung von VHDL, außer dem bissle, was du selbst
verwendest.
Das ist keine Antwort!
Was meinst Du mit "einschlägiger Variablen-Klasse" als Ersatz für den Typ Vector?! Tipp: ein Codebeispiel sagt mehr als hundert peinliche Beleidigungsversuche.
wenn man genau weiß was man damit tut und
sich bewusst ist, das man sich damit u.U. Unterschiede im Verhalten in
Simulation und Synthese einhandelt.
Welche sollten das denn bitte sein? Variablen werden in beiden Welten
genau gleich gehandhabt, wer da Unterschiede sieht, hat den Sinn nicht
verstanden und aufgrund seines eigenen Unwissens falsche Erwartung
gehabt.
Mumpitz! In C u.ä. sind Variablen Speicherstellen (Register, Arbeitsspeicher) im FPGA dagegen Simualtionsobjekte ohne timestamp. Nach der Synthese sind variable oft nur reine Leitungsbündel oder auch mal böse Latches. Kann man gerne im synthesis style guide nachlesen. Dort steht beispielsweise
"Chapter 3: XST HDL Coding Techniques
The XST VHDL analyzer accepts shared variables, but errors out in the HDL
Synthesis step if a shared variable does not describe a valid RAM macro."
Oder
" WARNING: [Synth 8-327] inferring latch for variable 'Q_reg'"
Die Variablen werden immer und zu jeder Zeit vom Compiler in gleicher
Weise behandelt und interpretiert - inbegriffen ihres Auftretens und
Position im Code und der sich ergebenden zeitlichen Abarbeitung. Das ist
der große Vorteil gegenüber Signalen.
Das ist eher ein Nachteil, kein Vorteil, weil die Signalverzögerung im FPGA nun mal real ist. Deshalb entstehen ja u.U. böse Unterschiede zwischen Simulation und "wahren FPGA Leben".
Ohne Variablen gäbe es keine
Schleifen und somit keine Möglichkeit, identische Gebilde in einem
Design mehrfach automatisch aufzubauen.
Jetzt sprichste aber von den generate resp. loop 'Variablen'. Das ist was anderes als die variable die man in processen/subprogramms deklariert .
In loop und generate gibt es beispielsweise keinen typ *vector, sondern nur integer oder enum mit range. Und im LRM heisst es an dieser Stelle (loop, generate) nicht "variable" sondern "parameter" , genauer "parameter_specification". (VHDL 2000 abschnitt 635 (generate), 465 (loop), im Gegensatz dazu: 215 (variable declaration)
Ehrlich, nachdem du grad öffentlich demonstrierst hast, das du nicht in der Lage bist variables und Schleifenparameter auseinderzuhalten, wird der Unsinn in der Behauptung Beitrag "Re: Konstanten berechnen >2**32" noch offensichtlicher.
Und das Du auch noch 4d später keinerlei Begründung vorbringen kannst sondern nur einen kindischen persönlichen Angriff weist auf eine Lernresistenz, ja -ablehnung hin.
The XST VHDL analyzer accepts shared variables, but errors out in the
HDL
Synthesis step if a shared variable does not describe a valid RAM
macro."
Hier zitierst Du "shared Variable". Das ist was anderes als eine simple Variable.
Die kann man nur innerhalb eines Prozesses benutzen (und bringt ihre Werte nur über Signale nach aussen), die shared Variable kann man - wie ein Signal - prozessübergreifend benutzen.
The XST VHDL analyzer accepts shared variables, but errors out in the
HDL
Synthesis step if a shared variable does not describe a valid RAM
macro."
Hier zitierst Du "shared Variable". Das ist was anderes als eine simple
Variable.
Das LRM definiert shared variable als Untergruppe der variable, wohl weil das Verhalten das selbe ist.
"There are four classes of objects: constants, signals, variables, and files. The variable class of objects also has an additional subclass: shared variables."
Bei dem Beispiel -hier dualported RAM- funktioniert die Beschreibung in einem einzelnen Prozess nur in sehr wenigen Fällen, wenn überhaupt.
Die kann man nur innerhalb eines Prozesses benutzen (und bringt ihre
Werte nur über Signale nach aussen), die shared Variable kann man - wie
ein Signal - prozessübergreifend benutzen.
Auch architecture übergreifend? in subprograms darf es wohl wieder nie shared sein.
"It is an error if a variable declaration in a subprogram declarative part declares a shared variable. (See 4.3.1.3
and 8.1.4.)"
"Variables declared immediately within subprograms and processes
must not be shared variables."
Shared variables sollte auch relativ neu sein, der TO schliesst ja VHDL-2019 explizit aus. shared gibt es ab VHDL-1993. Das sollte aber wohl die heute benutzen tools unterstützen.
Bei dem Beispiel -hier dualported RAM- funktioniert die Beschreibung in
einem einzelnen Prozess nur in sehr wenigen Fällen, wenn überhaupt.
Huh?
Eine shared Variable kann bei der Synthese nur ein (dual ported) RAM erzeugen. Alles andere wird scheitern.
Oder welches andere FPGA-Element würde wohl zwei Driver gleichzeitig erlauben?
Bei dem Beispiel -hier dualported RAM- funktioniert die Beschreibung in
einem einzelnen Prozess nur in sehr wenigen Fällen, wenn überhaupt.
Huh?
Zwei Taktdomainen erfordern zwei Prozesse mit jeweils eigenen Takt in der sensetivity list. Und dualport Rams werden eben gern an der Grenze zweier unabhängig getaktete Systeme eingesetzt (Sync-Fifo, Framebuffer, mem-cache,...).
Oder welches andere FPGA-Element würde wohl zwei Driver gleichzeitig
erlauben?
Eine variable ist ein VHDL-Element und nicht unbedingt ein "FPGA-Element". Wie der Simulator und ggf. Synthese mit mehreren Treibern umgeht ,ist eine Frage der "resolution function" und damit des verwendetetn type.
std_logic -> mit resolution function
std_ulogic -> without resolution function
Einfach mal in den source code der 1164 Biblithek schauen, sollte doch jeder toolchain beiliegen. Muss man sich mal die zeit nehmen den source zu lesen und ggf einen VHDL-Standard zu Erläuterung der details benutzen.
Zwei Taktdomainen erfordern zwei Prozesse mit jeweils eigenen Takt in
der sensetivity list
Sowohl die Quartus- als auch (soweit ich weiss) die X-Syntheseguidelines empfehlen für das Inferral von echtem Dual Clock Dual Port RAM Shared Variablen.
X-Syntheseguidelines empfehlen für das Inferral von echtem Dual Clock
Dual Port RAM Shared Variablen.
Grad mal in die UG901 geschaut, da gibt es für symmetrische Datenport die variable und für unsymmetrische signal variante, bei beiden jeweils typ array of std_logic_vector. und damit hätte der TO kein Problem mit der integer 32bit Grenze.
Bei den unsymmetrischen DP-RAMS und bei den FIFO's kann man aber auch mit anschaulicheren Block-memory-Generator o.ä. arbeiten. Nicht das man einen Parameter (read nefore write o.ä.) übersieht. Bei Angabe der Init-werte kann man in diesem Fall auch auf VHDL Boardmittel verzichten.
Eine direkte Empfehlung konnte ich beim Überfliegen nicht ausmachen. Bei Speicher wird meines Wissens häufiger auf den generator als auf handgeschrieben Code verwiesen. Grad bei sync-fifos an Verschiedenen clock domainen tut man es sich mit genrierten Code leichter, bspw beim Vergleich von speicherpointern zur ermiitöung der Füllstandflags.
2^15 -> 15 bit
+-2^15 -> 16 bit
2* (+-2^15) -> 17 bit
Naja, da haste wohl die (Ingenieurs-) Kurzschrift vom Jürgen gründlich missverstanden oder gar absichtlich fehlinterpretiert um hier jemanden "einen Fehler anzuhängen".
mit:
"2 x (2 hoch 15)"
ist wohl gemeint das:
zwei jeweils 15 bit lange Zahlen (+1bit für Vorzeichen) miteinander multipliziert werden
In dem Fall braucht man für die tatsächliche Realität doch mehr als 17 bit für das Resultat ... Zweiundreißig bit sind da schon angemessen, auch wenn es ein bit weniger auch machen würde.
Das geht auch aus dem Kontext des TO-Postings ("2*WIDTH ... Konstante zusammen mit multiplizierten> Werte benutzt ...") hervor und sollte doch jedem als Digitaltechnik-Grundlage bekannt sein: bei einer Multiplikation reserviert man für das Ergebnis soviel bits wie für die einzelnen Faktoren zusammen.
Und eigentlich wird das schon in der Grundschule gelehrt, wenn auch für das Zehner und nicht für das Binärssystem.
zwei jeweils 15 bit lange Zahlen (+1bit für Vorzeichen) miteinander
multipliziert werden
Das nun ganz bestimmt nicht. Das würde bedeuten, dass -1 0x80000001 entspräche und dass wir plötzlich eine positive und eine negative 0 hätten.
Das sind zwei 16 Bit lange Zahlen in Zweierkomplementdarstellung. Wenn schon.
zwei jeweils 15 bit lange Zahlen (+1bit für Vorzeichen) miteinander
multipliziert werden
Das nun ganz bestimmt nicht. Das würde bedeuten, dass -1 0x80000001
entspräche und dass wir plötzlich eine positive und eine negative 0
hätten.
Das sind zwei 16 Bit lange Zahlen in Zweierkomplementdarstellung. Wenn
schon.
Und? Auch im Zweierkomplement entspricht ein bit dem Vorzeichen. Nur das mit der Inversion dieses Vorzeichen-Bits auch der Betrag (Bedeutung der nicht-Vorzeichensbits) der selben ändert, weil der Wertebereich nicht mehr symmetrisch zur 0 ist.
Bei 16 bit 2'er complement hat man den Bereich von:
