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.
Zuerst dachte ich, die Antwort finde ich schon im Forum in einer nicht
so alten Diskussion, aber das hilft mir noch nicht:
Beitrag "Re: große Dezimalwerte in VHDL zuweisen"
Wie rechne ich das aus, ohne VHDL2019?
PS: Das 2*WIDTH kommt, weil die Konstante zusammen mit multiplizierten
Werten benutzt wird.
Naja, 2 x (2 hoch 15) sind zusammen mit dem Vorzeichen eben 32 Bit.
Ich schreibe Konstanten immer als echte Konstanten hin und nicht als
Ergebnis von Rechnungen. Muss der Code derart skalierbar sein?
Christoph Z. schrieb:> 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.
Das hier finde ich recht hilfreich:
https://freemodelfoundry.com/fphdl/Fixed_ug.pdf
to_sfixed (std_logic_vector) würde ich verwenden oder gleich to_sfixed
(integer).
Jürgen S. schrieb:> Muss der Code derart skalierbar sein?
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.
Christoph Z. schrieb:> 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 ...
BTW:
Der Code verwendet die (
https://de.wikipedia.org/wiki/Bin%C3%A4re_Exponentiation ) Binäre
Exponentation, die die Anzahl der notwendigen Multiplikationen
minimiert.
Damit lassen sich signed-Variablen (fast) beliebiger Länge potenzieren.
BTW:
> 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.
##
Das codebesipiel aus:
Beitrag "Re: Konstanten berechnen >2**32"
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....
DSGV-Violator schrieb:> Falls man hier wegem Stil krümmel
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.
DSGV-Violator schrieb:> Welche Wartung willst du an einer KONSTANTEN vornehmen?!> Eine Konstante ist kein Parameter.Christoph Z. schrieb:> In einem existierendem Code wird eine Konstante berechnet [...] gegeben durch
Generics
Der Wert der Konstanten wird zum Synthesezeitpunkt durch die zwei
Generics parametriert.
Jürgen S. schrieb:> Ich schreibe Konstanten immer als echte Konstanten hin und nicht als> Ergebnis von Rechnungen. Muss der Code derart skalierbar sein?
Ja. Bisher war der code NICHT skalierbar, fix auf 18 bit breite
geschrieben und oh wunder, im aktuellen Projekt brauchen wir jetzt 22
bit oder mehr.
Gustl B. schrieb:> 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...)
DSGV-Violator schrieb:> 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!
DSGV-Violator schrieb:> 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.
DSGV-Violator schrieb:> 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.
Georg B. schrieb:> Eigentlich wird empfohlen, zum Rechnen überhaupt keine Vektoren zu> benutzen. Dafür gibt es die einschlägigen Variablenklassen.
Variablenklassen? In VHDL? Lass mal sehen!
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".
https://nandland.com/variables-vs-signals/
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.
Gustl B. schrieb:> 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".
https://math.stackexchange.com/questions/1290373/difference-between-variables-parameters-and-constants
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.
DSGV-Violator schrieb:> 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).
Gustl B. schrieb:> 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).
Gustl B. schrieb:> 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.
DSGV-Violator schrieb:> 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.
der TO wollte die Konstante "2", dargestellt in einem wohl bereits
längst vorliegenden, über Generics steuerbar variablen Fixed-Format
initialisieren.
Keine Saturn-Rakete starten.
Jürgen S. schrieb:> 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
...
Beitrag "Timestamp in Synthese einbauen"
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.
Ich erlaube mir eine Antwort:
DSGV-Violator schrieb:> Und bezüglich variables in VHDL heisst es eigentlich:> "Only fools and experts uses variables".>> https://nandland.com/variables-vs-signals/
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'.
Dabei wurde das mehr als einmal durchgekaut:
Beitrag "Globale Variablen in VHDL"Beitrag "VHDL variable vs signal"Beitrag "VHDL: Variable in Prozesse"Beitrag "Variable vs Signal"Beitrag "Variable's Initial Value VHDL"> 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!
DSGV-Violator schrieb:> 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.
DSGV-Violator schrieb:> 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.
DSGV-Violator schrieb:> 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.
Jürgen S. schrieb:> 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.
Jürgen S. schrieb:> 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.
DSGV-Violator schrieb:> 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.
Markus F. schrieb:> der TO wollte die Konstante "2", dargestellt in einem wohl bereits> längst vorliegenden, über Generics steuerbar variablen Fixed-Format> initialisieren.>> Keine Saturn-Rakete starten.
Nicht Saturn sondern Jupiter :-)
Vielleicht hat es was mit Bepi-Colombo und JUICE zu tun.
DSGV-Violator schrieb:> 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.
Christoph Z. schrieb:> 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?
Oder macht ihr ein "just in time"-Design, reicht wenn's fertig ist, wenn
die Möhre dort ist?
>>> Keine Saturn-Rakete starten.>> 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)
Ja, diese Trägersystemfamilie ist schon ein Prachtstück
Deutsch-Amerikanischer Ingenieurskunst aus längst vergangenen Tagen. Ist
hier auch schon diskutiert worden, wie es sich gehört, im Offtopic:
Beitrag "Die NASA behauptet"Beitrag "Damit wollen die auf dem Mond gewesen sein?"
Markus F. schrieb:> 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.
DSGV-Violator schrieb:> 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.
Manchmal ist es wirklich erschreckend, zu sehen, auf welchem verbalen
Niveau sich gebildete Menschen bewegen.
Kotzt ihr eigentlich eure direkten Ansprechpartner von Angesicht zu
Angesicht auch gleich so an?
Wenn ja: zum Glück bin ich woanders.
Wenn nein: warum lasst ihr hier im Forum gleich mal die Sau raus?
Christoph Z. schrieb:> 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.
Christoph Z. schrieb:> 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:
Beitrag "Mikroprozessor in der Raumfahrt"Beitrag "weltraumtaugliche Mikrocontroller"Beitrag "Elektrotechnik und Raumfahrt?"
DSGV-Violator schrieb:>> Eigentlich wird empfohlen, zum Rechnen überhaupt keine Vektoren zu>> benutzen. Dafür gibt es die einschlägigen Variablenklassen.>> Variablenklassen? In VHDL? Lass mal sehen!
Du hast keine Ahnung von VHDL, außer dem bissle, was du selbst
verwendest.
DSGV-Violator schrieb:> 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.
Georg B. schrieb:>>> Eigentlich wird empfohlen, zum Rechnen überhaupt keine Vektoren zu>>> benutzen. Dafür gibt es die einschlägigen Variablenklassen.>>>> Variablenklassen? In VHDL? Lass mal sehen!>> 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'"
https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx14_7/xst.pdfhttps://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/Flip-Flop-Registers-with-Rising-Edge-Clock-Coding-Example-VHDL> 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)
Kann man auch gerne im LRM aka Standard nachlesen:
https://peterfab.com/ref/vhdl/vdlande/generate.htmlhttps://edg.uchicago.edu/~tang/VHDLref.pdf
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.
DSGV-Violator schrieb:> 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.
Markus F. schrieb:> DSGV-Violator schrieb:>> 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.
https://support.xilinx.com/s/question/0D52E00006hpgdTSAQ/can-vhdl-shared-variables-be-synthesized?language=en_US
Bei Quartus (Altera) könnte es bis 2009 gedauert haben bis sharerd
variables unterstütz wurden:
https://groups.google.com/g/comp.lang.vhdl/c/5N__T6TLehI
DSGV-Violator schrieb:> 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.
DSGV-Violator schrieb:> 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.
Markus F. schrieb:> 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.
Juergen S schrieb :
>Naja, 2 x (2 hoch 15) sind zusammen mit dem Vorzeichen eben 32 Bit.
Naja, vielleicht in VHDL. In Realitaet ist
2^15 -> 15 bit
+-2^15 -> 16 bit
2* (+-2^15) -> 17 bit
Falls man nun etwas Generisches verwenden will, welches dann ein
Vielfaches von 8 bit ist, waeren 24 oder 32 bit voll genuegend.
Purzel H. schrieb:> Juergen S schrieb :>>Naja, 2 x (2 hoch 15) sind zusammen mit dem Vorzeichen eben 32 Bit.>> Naja, vielleicht in VHDL. In Realitaet ist>> 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.
DSGV-Violator schrieb:> ist wohl gemeint das:> * 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.
Markus F. schrieb:> DSGV-Violator schrieb:>> ist wohl gemeint das:>> * 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:
DSGV-Violator schrieb:> also 32 bit und nicht 17 bit für das Produkt.
Ich glaube, das ist wohl trivial, daß 16 Bit-Zahlen multipliziert auf 32
Bit hinauslaufen.
Thread beobachten
Seitenaufteilung abschalten