Hallo zusammen,
ich mache schon länger etwas mit VHDL und dachte, ich hätte einiges
verstanden. Dem ist nicht so. Ich möchte über den folgenden Code bei
einem Tastendruck (steigende Flanke / Bouncing soll erst mal keine Rolle
spielen) nach und nach eine der 8 LEDs ansteuern. Jedoch sind nach dem
Download alle LEDs unmittelbar an, noch bevor ich den Taster gedrückt
habe.
Erik schrieb:> ich mache schon länger etwas mit VHDL
Drei Wochen?
> und dachte, ich hätte einiges> verstanden. Dem ist nicht so.
In der Tat.
Du glaubst, daß man so einen 1:N Dekoder in VHDL sauber beschreibt? Ich
nicht.
Mir war schon von Anfang an bewusst, dass man hier - wenn ich andere
Forenbeiträge mit Antworten sehe - meisten Hohn und Spott erntet, also
werde ich diese Antwort einfach mal ignorieren und auf einen
konstruktiven Beitrag hoffen.
Gruß
Erik
Sind die LEDs vielleicht so angeschlossen, dass die leuchten, wenn der
Ausgang auf '0' liegt? Dazu musst du mal in das Schematic deines Boards
schauen (du sagst es zwar nicht, aber ich vermute mal, die hast ein
FPGA-Board verwendet). Zudem musst du mal noch überlegen, was passiert,
wenn dein Counter einen Wert > 7 annimmt. Ich nehme an, du willst nicht
248-mal den Taster drücken, bis die erste LED wieder angeht?
Die Frage ist weiterhin, was dein Simulator dazu meint.
Und ja, einige Leute nutzen dieses Forum, um sich zu profilieren.
Ignorieren ist da die richtige Methode.
Erik schrieb:> Mir war schon von Anfang an bewusst, dass man hier - wenn ich andere> Forenbeiträge mit Antworten sehe - meisten Hohn und Spott erntet,
Wir ernten was wir sähen.
Kleiner, konstruktiver Tip. Versuchs mal mit einem Prozess, welcher ALLE
Bits von LEDs beschreibt.
Zusatzzahl, ähhh, Tipp. In VHDL werden mehrere, nacheinander
geschriebene Zuweisungen in eine parallele Logik überführt.
Du schaffst das!
Danke für die Antwort!
Nach dem Download - noch bevor ich also den Taster betätige - sind alle
LEDs sofort an. das ist es, was mich stutzig macht, denn der Process
wird erst nach dem Ereignis BTN mit positiver Flanke aufgerufen. Wenn
ich den Prozess komplett entferne, bleiben auch alle LEDs dunkel. Es
muss also etwas mit dem Prozess zu tun haben, so glaube ich.
Gruß
Erik
Nach dem Einschalten ist counter==0, und wegen LED(counter) <= 1 ist
LED(0) eingeschaltet. Aber was ist mit den anderen LEDs? Du hast
nirgendwo gesagt, dass sie ausgeschaltet sein sollen, warum sollten sie
also ausgeschaltet sein?
Wenn du den Prozess weglässt, wird möglicherweise das ganze Design
wegoptimiert, dann sind natürlich alle LEDs aus.
Nochmal, bevor du ein Design auf den FPGA lädst, musst du es simulieren,
sonst erkennst du nicht, warum dein Design nicht funktionieren kann.
Erik schrieb:> ich mache schon länger etwas mit VHDL und dachte, ich hätte einiges> verstanden. Dem ist nicht so.
Das ist ungequirlte Bullenscheisse, alles zwischen architecture und end
architecture löschen und complett neu machen.
In der Entity die standardports clk und rst ergänzen. Die
initialisierung in der portlist ist auch ganz schlechter Stil.
Und schauen wie man eine signalflanke (nicht clock) in der
Digitaltechnik sauber detektiert.
Beispielcode gibt es genug im Netz:
https://surf-vhdl.com/how-to-design-a-good-edge-detector/
So, viel Spaß.
Eigentlich willst du gar keinen Zähler sondern nur ein Bit
herumschieben.
Und ja BTN ohne Entprellung ist doof, daher hab ich dir noch eine
Komponente hochgeladen die auch das macht und sogar rise und fall
ausgibt.
Gustl B. schrieb:> Und ja BTN ohne Entprellung ist doof, daher hab ich dir noch eine> Komponente hochgeladen die auch das macht und sogar rise und fall> ausgibt.
Ob DAS pädagogisch so sinnvoll ist?
Falk B. schrieb:> Gustl B. schrieb:>> Und ja BTN ohne Entprellung ist doof, daher hab ich dir noch eine>> Komponente hochgeladen die auch das macht und sogar rise und fall>> ausgibt.>> Ob DAS pädagogisch so sinnvoll ist?
Wo Hopfen und Malz verloren sind, erreicht man mit Pädagogik auch nichts
mehr.
Der TO zeigt doch Null eigene Anstrengung, reiner Mitleidstour.
Eigenes Scheitern wird eingeräumt aber relativiert. "Da steckt nur ein
blöder Fehler drin, pleas help" - von wegen, da ist schon der Ansatz
komplett falsch.
Aber offensichtlich zeigt eine Manipulationstechnik Erfolg, führt aber
nicht zu Erkenntnis :-(
https://www.lernen.net/artikel/manipulation-7-strategien-einflussnahmen-3198/
Erik schrieb:> Nach dem Download - noch bevor ich also den Taster betätige - sind alle> LEDs sofort an
Wie sieht denn die Beschaltung des Taster aus? Hat der einen
Pullup/Pulldown?
Erik schrieb:> der Process wird erst nach dem Ereignis BTN mit positiver Flanke> aufgerufen
Du denkst in Software. Denn da wird bei einem Tastendruck nichts
aufgerufen, sondern du beschreibst da einen Zähler mit 32 Bit Breite,
deessen Flipflops mit jeder Flanke vom Button eins weiter zählt.
In den Warnings der Toolchain wirst du vermutlich sehen, dass dabei 29
Bits dieses Zählers wegoptimiert werden, weil 3 Bits zur Adressierung
deiner 8 LED ausreichen.
Mein Tipp zusätzlich zur Sache mit der Simulation: Sieh dir den
RTL-Schaltplan an, den der Synthesizer aus deiner Beschreibung macht.
Daran siehst du gleich, ob der Synthesizer verstanden hat, welche
Schaltung du beschrieben hast.
Erik schrieb:> über den folgenden Code bei einem Tastendruck> nach und nach eine der 8 LEDs ansteuern.
Du wirst dich ganz hübsch wundern, wie sehr so ein Taster pellen kann
und wie schnell ein FPGA ist. Da ist nichts mit "nach und nach".
Falk B. schrieb:> Wir ernten was wir sähen
Wenn wir sähen, wie Bauern säen, wären wir auf dem Land... ;-)
Absolut schwache Leistung, liebe VHDL-Experten, ich bin enttäuscht.
Alle wissen, wie man's macht, aber keiner findet den eigentlichen Fehler
(es it tatsächlich - eigentlich - nur einer drin).
Und der ist schon hier:
1
entityDebounce_Testis
2
port(
3
BTN:instd_logic;
4
LED:outstd_logic_vector(7downto0):=(others=>'0')
5
);
6
endentityDebounce_Test;
das "(others => '0')" macht hier etwas völlig anderes, als anscheinend
von allen angenommen. Am dichtesten dran (aber immer noch auf dem
Holzweg) ist
Lutz Lokus schrieb:> Die> initialisierung in der portlist ist auch ganz schlechter Stil.
Das ist keineswegs schlechter Stil, sondern valides VHDL (LRM 4.3.2).
Die scheinbare "initialisierung" ist allerdings keine, sondern lediglich
der Initialwert (die Zuweisung findet nur ein Mal statt). Nutzen kann
man das sinnvoll, um auch nicht verbundenen Ports einen validen Wert
zuzuweisen.
Das eigentliche (Kern-) Problem mit dem Code (mal abgesehen von der
fehlenden Entprellung, aber auch ohne die hätten die LED's bei einem
Tastendruck wenigstens mal ein bisschen geflackert) ist also, dass die
LED-Bits zwar gesetzt, aber nie zurückgesetzt werden. Beim Start geht
also erst mal alles an, aber nie wieder aus.
Enttäuschend, dass das keiner sieht (vom Stil der Antworten will ich mal
gar nicht reden).
Markus F. schrieb:> Absolut schwache Leistung, liebe VHDL-Experten, ich bin enttäuscht.
Du bist nur ein Schwätzer und Wichtigtuer, sonst GAR NICHTS!
> Alle wissen, wie man's macht, aber keiner findet den eigentlichen Fehler
Wirklich?
> Das eigentliche (Kern-) Problem mit dem Code (mal abgesehen von der> fehlenden Entprellung, aber auch ohne die hätten die LED's bei einem> Tastendruck wenigstens mal ein bisschen geflackert) ist also, dass die> LED-Bits zwar gesetzt, aber nie zurückgesetzt werden. Beim Start geht> also erst mal alles an, aber nie wieder aus.
Aha!
> Enttäuschend, dass das keiner sieht
Das mit dem sinnerfassenden Lesen über wir dann noch mal.
Beitrag "Re: Ein wirklich blöder Fehler, den ich nicht sehe"
"Kleiner, konstruktiver Tip. Versuchs mal mit einem Prozess, welcher
ALLE
Bits von LEDs beschreibt."
> (vom Stil der Antworten will ich mal> gar nicht reden).
Tja, die Generation Snow Flake lebt halt emotional im Teletubbyland und
kann mit der alten Kunst der Ironie nix anfangen. Auch gut.
Markus F. schrieb:> zwar gesetzt, aber nie zurückgesetzt werden.
Doch. Sie werden anfangs mit
Erik schrieb:> LED : out std_logic_vector(7 downto 0) := (others => '0')
Alle auf 0 gesetzt und dann nacheinander mit
Erik schrieb:> LED(counter) <= '1';
auf 1.
Und da bleiben die dann auch stehen.
Ich vermute, dass hier statt dem Button die Clock verwendet wurde. Dann
geht das nämlich wirklich in ganz kurzer Zeit alles auf 1.
Oder aber die LEDs sind bei 0 an, dann müsste er nur mal den Button
drücken und sehen wie die nacheinander aus gehen.
Das Synthesetool hat erkannt, dass alle LEDs entweder 1 oder don't care
sind. In der Optimierungsphase wurden dann alle LEDs hart auf 1
verkabelt, was vollkommen korrekt ist - die Initialisierung auf 0 wird
sofort überschrieben und ist daher wirkungslos.
Ich bin ziemlich erstaunt, was hier für ein Shitstorm losbricht, nur
weil ein Anfänger einen falschen VHDL-Code gepostet hat. Ich habe das
FPGA-Forum immer für eine Insel der Zivilisation gehalten.
Dabei haben wir alle irgenwann einmal einen solchen Schwachsinn
produziert. Aber man gewinnt den Eindruck, die Gurus dürfen auf keinen
Fall durch Anfängerfragen in ihrer göttlichen Tiefenmeditation gestört
werden, weil sonst das innere Gefüge der Welt aus dem Gleichgewicht
gerät. Das ist eine Blasphemie, die umgehend mit einer Flutwelle aus
verbalen Rohrkreppierern geahndet werden muss.
vancouver schrieb:> Ich bin ziemlich erstaunt, was hier für ein Shitstorm losbricht, nur> weil ein Anfänger einen falschen VHDL-Code gepostet hat.
Noch so ein dummes Gelaber. Das Modewort "Shitstorm" ist hier mehr als
unpassend. Mal abgesehen davon, daß den Op keiner angegangen ist. Ach
so, ein wenig Ironie und subtile Kritik ist natürlich heute TOTAL
aggressiv. Mann O Mann!
vancouver schrieb:> Lutz Lokus schrieb:>> ungequirlte Bullenscheisse,>> Lutz Locus schrieb:>> zeigt doch Null eigene Anstrengung, reiner Mitleidstour.>> Lutz Locus schrieb:>> Eigenes Scheitern>> Subtile Kritik? Ernsthaft jetzt?
Ja, in den bereichen die du (absichtlich?) nicht zitierst hat, du
Hint*...
Siehe Beitrag "Re: Ein wirklich blöder Fehler, den ich nicht sehe"
Wenn ich grad so über meine VHDL-Anfänger-Zeit nachdenke, war es gerade
hilfreich, das man zu diesen Zeiten eben nicht Das Internet
benutzen/missbrauchen konnte um seine Hausaufgaben zu machen, sondern
gezwungen war:
-sich selbst mit "Trial/Error" und Literaturrecherche durchzukämpfen
-sozial befähigt zu sein, die Mitstudenten und Übungsleiter um
Unterstützung zu bitten
-als Werksstudent/Praktikant durch "dabei und aufmerksam sein"
Praxisrelevante Erfahrung zu sammeln.
Markus F. schrieb:> Lutz Lokus schrieb:>> Die>> initialisierung in der portlist ist auch ganz schlechter Stil.>> Das ist keineswegs schlechter Stil, sondern valides VHDL (LRM 4.3.2).> Die scheinbare "initialisierung" ist allerdings keine, sondern lediglich> der Initialwert (die Zuweisung findet nur ein Mal statt).
Auch wenn es nach Simulationsstandard (mehr ist VHDL-2008 nicht)
"erlaubt" ist ist es noch lange nicht guter stil.
Guter stil ist es, etwas leicht verständlich zu beschreiben und genau so
wie man es umplementiert haben möchte. Hier also ein signal mit
definierten Initwert, also alle Angaben in der Signaldekleartion und
nicht verteilt über entity, architecture body und mglw. configuration
declaration.
> Nutzen kann> man das sinnvoll, um auch nicht verbundenen Ports einen validen Wert> zuzuweisen.
Welchen Nutzen hat ein Initwert an einen als 'open' deklarierten
(unverbundenen) Port?!
ein Offener Port ist in real life "floating" also undefiniert. Und genau
das ist auch ein Signal ohne Zuweisung/Initwert.
vancouver schrieb:> Das Synthesetool hat erkannt, dass alle LEDs entweder 1 oder don't care> sind.
Wieso don't care? Der Initialierungswert ist doch eindeutig und sollte
tatsächlich erst nach Betätigung von BTN überschrieben.
Wenn ich den Code für ein CPLD synthetisieren lasse bekomme ich (neben
vielen erwartbaren anderen Warnungen) auch die Warnung:
WARNING:Xst:1426 - The value init of the FF/Latch LED_0 hinder the
constant cleaning in the block Debounce_Test.
You should achieve better results by setting this init to 1.
Das klingt für mich nicht danach, als würde sich das Synthesetool schon
die Freiheit nehmen, die 0 von der Initialiserung fix mit 1 zu
überschreiben.
Der Fitter liefert dabei z.B.
-- LDCP (Q,D,G,CLR,PRE);
LDCP_LED7: LDCP port map (LED(7),NOT '0',,'0','0');
LED_G(7) <= (counter(0) AND counter(1) AND counter(2) AND
NOT counter(3));
Sieht für mich ebenfalls nicht danach aus, als sollten die LEDs zunächst
auf 0 stehen und erst nach Erreichen eines bestimmten Zählerstands auf 1
gehen.
vancouver schrieb:> Ich bin ziemlich erstaunt, was hier für ein Shitstorm losbricht, nur> weil ein Anfänger einen falschen VHDL-Code gepostet hat. Ich habe das> FPGA-Forum immer für eine Insel der Zivilisation gehalten.
Viele Antworten in diesem Thread (von wenigen Verfassern) haben einen
völlig unangemessenen Umgangston. Aber immerhin wird hier zumindest auch
noch fachlich diskutiert, und der Thread ist nicht gleich zur reinen
Streiterei ausgeartet. Insofern ist ein bisschen "Insel der
Zivilisation" noch übrig geblieben :-)
@Erik,
wahrscheinlich bis du Weg gerannt weil keiner sich um was du bescrhieben
hast kümmern will, wie oben steht... Hohn und Spott. Schade.
Was manchmal hilft, zusäztlich zu simulieren ist, für einfache
Schaltungen, eine Schaltung zu zeichnen, und oder einen Spannung vs Zeit
Diagramm zu mahlen.
Ohne genau zu wissen wie die LEDS ein und aus gehen sollen, denke ich
daß evtl. du willst daß für jeden Tastendruck (sagen wir die Taste
liefert nur einen Puls per Tastendruck) die LEDs in Sequenz von 0 bis 7
Läuchten. Ich würde an Flip-Flops denken die den Zustand "speichern".
Dann würde ich denken, wenn den Stromlaufplan gezeichnet wurde, es mit
z.B. Logisim (evolution oder nicht) simulieren und dann es in VHDL
umwandeln und weiter mit z.B. GHDL, oder ModelSim oder vcs zu
simulieren.
Viel Glück.
Alex P. schrieb:> wahrscheinlich bis du Weg gerannt weil keiner sich um was du bescrhieben> hast kümmern will, wie oben steht... Hohn und Spott.
Mumpitz, von wegen "nur Hohn und Spott". Oben wird sehr konkret
Lösungsvorschläge genannt, besprochen, durchsimuliert und Idiotensicher
wiedergegeben.
Den "Tritt in den Hintern" damit der TO seine Aufgaben letzlich selbst
erledigt gibts gratis dazu.
Denn "Ein Tritt in den Hintern ist auch ein Schritt vorwärts",
Montgomery Burns (zugesprochen).
Achim S. schrieb:> Viele Antworten in diesem Thread ... haben einen> völlig unangemessenen Umgangston.
Der Umgangston ist der Situation (TO will seine Hausaufgaben von anderen
erledigt haben) völlig angemessen.
Lutz Locus schrieb:> das man zu diesen Zeiten eben nicht Das Internet> benutzen/missbrauchen konnte
Genau, früher war sowieso alles besser (tm). Es gab kein Internet, und
wenn doch, hätten wir uns nie getraut, es zu benutzen. Wir haben VHDL
noch aus handgeschrieben Folianten gelernt. Wir haben unsere Schaltungen
im Kopf synthetisiert und anschließend die Timingsimulation mit einem
Rechenschieber gemacht. Wir brauchten nicht mal Strom! Wir wären nie auf
die Idee gekommen, weitere Informationsquellen zu nutzen oder gar
irgendwelche Leute zu fragen, wenn wir ein Problem hatten. Das machten
nur degenerierte Weicheier. In einem Forum für VHDL und FPGA eine Frage
zu VHDL und FPGA zu stellen, war für uns unvorstellbar, das war quasi
der Gipfel der sozialen Inkompetenz.
vancouver schrieb:> Lutz Locus schrieb:>> das man zu diesen Zeiten eben nicht Das Internet>> benutzen/missbrauchen konnte>> Genau, früher war sowieso alles besser (tm). Es gab kein Internet, und> wenn doch, hätten wir uns nie getraut, es zu benutzen. Wir haben VHDL> noch aus handgeschrieben Folianten gelernt. Wir haben unsere Schaltungen> im Kopf synthetisiert und anschließend die Timingsimulation mit einem> Rechenschieber gemacht. Wir brauchten nicht mal Strom! Wir wären nie auf> die Idee gekommen, weitere Informationsquellen zu nutzen oder gar> irgendwelche Leute zu fragen, wenn wir ein Problem hatten. Das machten> nur degenerierte Weicheier. In einem Forum für VHDL und FPGA eine Frage> zu VHDL und FPGA zu stellen, war für uns unvorstellbar, das war quasi> der Gipfel der sozialen Inkompetenz.
Und wieder reisst du das Zitat (absichtlich) aus dem Kontext. Natürlich
haben wir früher weiter Quellen zur Information genutzt. Aber genau das
tut der TO nicht, schon sein Eröffnungspost lässt er sich von einem
Moderator in eine Form bringen, die minimalen Ansprüchen genügt.
Weil es ja "Dumme" im Internet gibt die für lau alles machen, wenn man
Ihnen genügend Mitleidsschmuss um die Lippen schmiert, strengt er sich
nicht sonderlich an, sondern gibt "sein Problem" anderen Leuten vor die
Tür. Und gerade da liegt dasProblem, wo (unbeabsichtigt) die Möglichkeit
zum Parasitismus/Missbrauch entsteht, findet sich auch ein Parasit, der
diese nutzt. Und ein weiterer, der aus "Parasitenabwehr" sich einen
moralischen Hammer schnitzt.
vancouver schrieb:> In der Optimierungsphase wurden dann alle LEDs hart auf 1> verkabelt
In der Tat, das ist korrekt.
Nur verstehe ich das nicht.
Und zwar das hier:
> die Initialisierung auf 0 wird> sofort überschrieben und ist daher wirkungslos.
Denn überschrieben wird doch nur
LED(counter) <= '1';
und da counter 0 ist, wird sofort die LED(0) <= '1';
Die anderen LEDs werden doch erst mindestens eine Flanke an BTN später
zu '1'. Das zeigt übrigens auch die Simulation. Klar, nach 7 Flanken an
BTN sind alle LEDs auf '1' und bleiben dort auch, aber eben nicht
sofort.
Edit:
Pack man
LED(counter) <= '1';
mit in den getakteten Teil, so wird das nicht wegoptimiert.
vancouver schrieb:> Falk B. schrieb:>> Muh, Muh,. blinde Kuh . . .>> Falk B. schrieb:>> Drei Wochen?>> Lutz Lokus schrieb:>> ungequirlte Bullenscheisse,>> Lutz Locus schrieb:>> zeigt doch Null eigene Anstrengung, reiner Mitleidstour.>> Lutz Locus schrieb:>> Eigenes Scheitern>> Subtile Kritik? Ernsthaft jetzt?
Früher waren Falks Beiträge tatsächlich hilfreich,
jetzt rotzt er meisten nur noch beleidigend rum!
Schade eigentlich...
Gustl B. schrieb:> Denn überschrieben wird doch nur>> LED(counter) <= '1';
Ja, aber alle anderen LED sind don't care. Die LED-Ausgänge haben ja
keinen internen Zustand, in dem sie die initiale 0 speichern. Daher
verliert die Initial-0 sofort ihre Gültigkeit. Da anschließend nirgendwo
eine LED auf 0 gesetzt wird, setzt der Optimizer sie alle auf 1. Das ist
nicht das intuitive Verhalten, aber es ist logisch richtig und optimal,
weil es keine Ressorcen benötigt.
atoyot schrieb:> Früher waren Falks Beiträge tatsächlich hilfreich,> jetzt rotzt er meisten nur noch beleidigend rum!> Schade eigentlich...
Schade für wen? Für den Hausaufgaben-Schmarotzer?! Tja, pech gehabt, die
Welt ist gerecht - ohne Fleiß keinen Preis ;-)
Und beleidigend wäre es nur wenn es nicht den Tatsachen entsprehcen
würde ...
Und Falk hat schon in seinem ersten Post ein wichtiges Stichwort gegben
1:N Decoder, und weitere spätere.
Tja halt die üblichen Kinderspiele mit dem Mitleid; "huhu, der böse Falk
hat mir ein leid getan."
Dachte ich ebenfalls, also hab ich dem noch ein Signal spendiert:
architecture rtl of Debounce_Test is
signal counter : integer := 0;
signal s_led : std_logic_vector(7 downto 0) := x"00";
begin
process(BTN)
begin
if rising_edge(BTN) then
counter <= counter + 1;
end if;
end process;
s_led(counter) <= '1';
LED <= s_led;
end architecture rtl;
Und siehe da, auch damit werden alle LEDs hart auf '1' gelegt.
Achim S. schrieb:> Sieht für mich ebenfalls nicht danach aus, als sollten die LEDs zunächst> auf 0 stehen und erst nach Erreichen eines bestimmten Zählerstands auf 1> gehen.
Ups: ein sinnentstellender Fehler von mir: das "nicht" war zu viel. Der
Fitter sieht offensichtlich vor, dass die LEDs zunächst auf Null stehen
und erst nach Erreichen des passenden Zählerstands auf 1 gehen.
vancouver schrieb:> Ja, aber alle anderen LED sind don't care. Die LED-Ausgänge haben ja> keinen internen Zustand, in dem sie die initiale 0 speichern.
Dass interne Signale wegoptimiert werden können weil sie für keinen
Ausgang relevant sind, wäre klar. Aber dass "Ausgangswerte wegoptimiert
werden" weil keine internen Signale zum Speichern vorhanden wären, wäre
mir neu.
Und nochmal: wenn ich es z.B. für ein Coolrunner CPLD implementiere,
dann wird zumindest laut Fitter-Report nichts wegoptimiert:
Achim S. schrieb:> -- LDCP (Q,D,G,CLR,PRE);> LDCP_LED7: LDCP port map (LED(7),NOT '0',,'0','0');> LED_G(7) <= (counter(0) AND counter(1) AND counter(2) AND> NOT counter(3));
Das LDCP-Latch (und damit der LED-Ausgang) ist nach Power Up erst mal
auf 0. (Standardverhalten von LDCP). Und erst mit dem passenden
Zählerstand wird sein G aktiviert, so dass die 1 durchgeschalten wird.
Der Speicher für die initiale 0 ist das LDCP Latch. Und erst der
passende Zählerstand bewirkt den Übergang nach 1.
Gustl B. schrieb:> Und siehe da, auch damit werden alle LEDs hart auf '1' gelegt.
Wo beobachtest du diese Verhalten. Hast du es selbst in Hardware
ausprobiert?
Was sagt dein Fitter-Report (falls du ein CPLD nutzt)?
Achim S. schrieb:> Wo beobachtest du diese Verhalten. Hast du es selbst in Hardware> ausprobiert?
Klar, mit Quartus Prime Lite 20.1.1 für einen MAX10.
Info:
*******************************************************************
Info: Running Quartus Prime Analysis & Synthesis
Info: Version 20.1.1 Build 720 11/11/2020 SJ Lite Edition
Info: Processing started: Sun Dec 18 15:33:10 2022
Info: Command: quartus_map --read_settings_files=on
--write_settings_files=off Debounce_Test_max10 -c Debounce_Test_max10
Warning (18236): Number of processors has not been specified which may
cause overloading on shared machines. Set the global assignment
NUM_PARALLEL_PROCESSORS in your QSF to an appropriate value for best
performance.
Info (20030): Parallel compilation is enabled and will use 4 of the 4
processors detected
Info (12021): Found 2 design units, including 1 entities, in source file
debounce_test_max10.vhd
Info (12022): Found design unit 1: Debounce_Test_max10-rtl
Info (12023): Found entity 1: Debounce_Test_max10
Info (12127): Elaborating entity "Debounce_Test_max10" for the top level
hierarchy
Info (10041): Inferred latch for "s_led[0]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[1]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[2]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[3]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[4]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[5]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[6]" at
Debounce_Test_max10.vhd(46)
Info (10041): Inferred latch for "s_led[7]" at
Debounce_Test_max10.vhd(46)
Warning (13024): Output pins are stuck at VCC or GND
Warning (13410): Pin "LED[0]" is stuck at VCC
Warning (13410): Pin "LED[1]" is stuck at VCC
Warning (13410): Pin "LED[2]" is stuck at VCC
Warning (13410): Pin "LED[3]" is stuck at VCC
Warning (13410): Pin "LED[4]" is stuck at VCC
Warning (13410): Pin "LED[5]" is stuck at VCC
Warning (13410): Pin "LED[6]" is stuck at VCC
Warning (13410): Pin "LED[7]" is stuck at VCC
Info (16010): Generating hard_block partition
"hard_block:auto_generated_inst"
Info (16011): Adding 0 node(s), including 0 DDIO, 0 PLL, 0 transceiver
and 0 LCELL
Warning (21074): Design contains 1 input pin(s) that do not drive logic
Warning (15610): No output dependent on input pin "BTN"
Info (21057): Implemented 9 device resources after synthesis - the final
resource count might be different
Info (21058): Implemented 1 input pins
Info (21059): Implemented 8 output pins
Info: Quartus Prime Analysis & Synthesis was successful. 0 errors, 12
warnings
Info: Peak virtual memory: 4780 megabytes
Info: Processing ended: Sun Dec 18 15:33:19 2022
Info: Elapsed time: 00:00:09
Info: Total CPU time (on all processors): 00:00:20
Das ist Analysis & Synthesis, der Fitter baut das dann auch so.
Hallo zusammen,
ich, der das Ganze hier quasi ins Rollen gebracht hat, meldet sich ein
letztes Mal zu Wort. Es ist beschämend zu sehen, wie Menschen in der
Anonymität des Internets, miteinander umgehen. Das trifft man in allen
sozialen Netzen querbeet. da erzähle ich euch sicherlich nichts Neues.
Dieses Verhalten ist in allen Themenbereichen dieser Plattform hier zu
erkennen und es macht mich traurig. Die Frage ist: Warum? Ich kenne
vermutlich die Antwort, aber ich möchte nicht noch mehr Öl ins Feuer
gießen.
Ich bin raus!
Herzlichen Gruß
Erik
Hui, nichtmal das hier funktioniert, ich bin doch etwas verwirrt oder
schon sehr blind:
architecture rtl of Debounce_Test_max10 is
signal counter : unsigned(2 downto 0) := "000";
signal s_led : std_logic_vector(7 downto 0) := x"00";
begin
process(BTN)
begin
if rising_edge(BTN) then
counter <= counter + 1;
end if;
end process;
process(counter)
begin
for i in 0 to 7 loop
if i = counter then
s_led(i) <= '1';
end if;
end loop;
end process;
LED <= s_led;
end architecture rtl;
Gustl B. schrieb:> Hui, nichtmal das hier funktioniert, ich bin doch etwas verwirrt oder> schon sehr blind:
Also der Pferdefuß in dem TO-Vorschlag ist IMHO der dynamische Index:
1
s_led(i)<='1';
Oben kam doch schon der Vorschlag mit dem Schieberegister, das sollte
die optimale CPLD/FPGA-Losung sein.
Ein Kleiner Fallstrick ist dabei die Anfangsbeding alles aus, die sollte
man mit einem gezielten Set beim Initstate abfangen.
Gustl B. schrieb:> Das ist Analysis & Synthesis, der Fitter baut das dann auch so.
Danke für die Klärung.
Warning (13410): Pin "LED[7]" is stuck at VCC
Das ist eine ziemlich klare und eindeutige Meldung, auch wenn ich weiter
nicht nachvollziehen kann, wieso sich Quartus das rausnimmt ;-)
Ich hab den Code des TO mit minimalen Änderungen in der ISE probiert:
1
libraryIEEE;
2
useIEEE.std_logic_1164.all;
3
useIEEE.numeric_std.all;
4
5
entityDebounce_Testis
6
port(
7
BTN:instd_logic;
8
LED:outstd_logic_vector(7downto0):=(others=>'0')
9
);
10
11
endentityDebounce_Test;
12
13
architecturertlofDebounce_Testis
14
signalcounter:integerrange0to10:=0;
15
begin
16
process(BTN)
17
begin
18
ifrising_edge(BTN)then
19
counter<=counter+1;
20
endif;
21
endprocess;
22
LED(counter)<='1';
23
endarchitecturertl;
Dort gibt es keine Meldung zu "stuck high". Stattdessen werden laut
Report jeweils transparente Latches verbaut (sowohl bei
CPLD-Implementierung als auch bei FPGA), die mit 0 starten und die erst
durch den sich ändernden Zählerstand auf 1 wechseln. Dementsprechend ist
bei mir in allen ISE-Implementierungen auch wirklich ein Zähler
vorhanden (der in deiner Quartus-Implementierung tatsächlich
wegoptimiert ist).
Hab leider grade kein freie Hardware verfügbar, um es mal in real zu
testen. Aber ich gehe momentan davon aus, dass der Code auf
"ISE-basierter Hardware" das erhoffte Verhalten hätte.
Erik schrieb:> Ich bin raus!
Schade. Denn du hast auch eine Menge Leute hier, die dein Thema
ernsthaft diskutieren.
Du hattest weiter oben geschrieben:
Erik schrieb:> also> werde ich diese Antwort einfach mal ignorieren und auf einen> konstruktiven Beitrag hoffen.
Wenn du dich entschließen könntest die ärgsten Beiträge von 2-3
Teilnehmern zu ignorieren, blieben als Rest des Threads hauptsächlich
konstruktive Diskussionen übrig.
Achim S. schrieb:> Wenn du dich entschließen könntest die ärgsten Beiträge von 2-3> Teilnehmern zu ignorieren, blieben als Rest des Threads hauptsächlich> konstruktive Diskussionen übrig.
Nope, am meisten bringt es wenn der TO seine eigenen beitrag ignoriert
und das Ganze von 0 Hardwaregerecht aufbaut. Aber dazu müsste er bereit
sein sich mit digitaler Schaltungstechnik zu befassen.
Anbei ein Code-beispiel für ein Design auf Basis shiftregister.
Lutz Locus schrieb:> Also der Pferdefuß in dem TO-Vorschlag ist IMHO der dynamische Index:> s_led(i) <= '1';
Wieso sollte das ein Pferdefuß sein? Das setzt die ISE genau wie
gewünscht in einen Dekoder um, mit dem sie die einzelnen Latches der
LEDs ansteuert. Mit dem uneingeschränkten integer als Zähler wird der
Dekoder natürlich ziemlich groß, aber mehr als 40 Pterms schluckt die
Schaltung selbst damit nicht.
Lutz Locus schrieb:> Oben kam doch schon der Vorschlag mit dem Schieberegister, das sollte> die optimale CPLD/FPGA-Losung sein.
Dass es andere/schönere/einfachere Lösungen gäbe, bezweifelt niemand.
Gustl B. schrieb:> nichtmal das hier funktioniert,
Naja, die Logik dahinter is ja genau dieselbe wie vorher: Nirgendwo wird
eine LED auf 0 gesetzt, nur auf 1. Und damit hat der Optimizer die
Erlaubnis, mit den LEDs, die gerade nicht explizit auf 1 gesetzt werden,
zu tun, was er will, also setzt er alle auf 1, weil das den Counter
überflüssig macht.
Die Initialisierung der LEDs mit 0 bedeutet nur, die Signale so lange
auf null zu halten, bis sie einen anderen Wert bekommen, und den
bekommen sie vom Optimizer, weil er es darf in diesem Fall. Um die LEDs
auf 0 zu halten, muss man dem Optimizer verbieten, Ihren Wert zu ändern,
d.h. entweder mit einem Register und einem Resetwert von 0, oder durch
durch vollständige Auscodierung aller Zustände. Wenn du dem Optimizer
Freiraum lässt, wird er ihn nutzen.
Erik schrieb:> Ich bin raus!
Verständlich nach der Schlammschlacht hier. Aber du kannst in diesem
Forum durchaus wertvolle Informationen bekommen, es gibt hier Leute, die
ihr Wissen gerne weitergeben. Man muss sie nur finden zwischen all dem
Müll.
Gustl B. schrieb:> Hui, nichtmal das hier funktioniert, ich bin doch etwas verwirrt oder> schon sehr blind:
Ändert sich was, wenn du der Schaltung noch ein "externes" Resetsignal
spendierst mit dem du die LEDs "zur Laufzeit" auf 0 setzen könntest?
So, jetzt habe ich mal auch Vivado angeworfen und siehe da, bei Quartus
wird LED hart auf x"FF" gelegt aber bei Vivado entsteht die Logik die
die einzelnen LEDs nacheinander auf '1' setzt.
Bei identischem VHDL.
Ist in VHDL irgendwo definiert ob und wenn ja wie vorinitialisierte
Ports umgesetzt werden müssen?
Andererseits kann das nicht der Grund sein, denn auch mit einem Signal
funktioniert es mit Quartus nicht korrekt.
vancouver schrieb:> Naja, die Logik dahinter is ja genau dieselbe wie vorher:
Dass das identische Logik erzeugt war Sinn der Übung. Ich wollte testen
ob es an einem Syntaxkonstrukt liegt, dass Quartus das wegoptimiert.
> Nirgendwo wird eine LED auf 0 gesetzt, nur auf 1.
Doch. Für Vivado genügt es wenn der Port vorinitialisiert wird.
Und für Quartus hatte ich extra noch ein Signal eingebaut und trotzdem
wird das wegoptimiert.
Gustl B. schrieb:> Ist in VHDL irgendwo definiert ob und wenn ja wie vorinitialisierte> Ports umgesetzt werden müssen?
Ich habe mal irgendwo gelesen, dass man im Normalfall keinen Reset
einbauen, sondern sich auf die Initialwerte verlassen soll. Diese
Erinnerung ist natürlich nicht sehr zuverlässig, aber es war wohl eine
glaubhafte Quelle, sonst hätte ich es mir nicht gemerkt.
Deshalb wundert mich das Verhalten von Quartus auch.
Von der Logik her ist es klar. Wenn ich einem Signal initial 0 zuweise
und es nur bedingt auf 1 setze, ist es falsch, das Signal fest auf 1 zu
verdrahten.
Wie gesagt, wenn das Verhalten eines Signals nicht explizit spezifiziert
ist, dann kann er Optimizer machen was er will, und Vivado optimiert
offenbar anders als Quartus. Logisch richtig sind beide Lösungen, aber
intuitiv ist natürlich nur die von Vivado. Auf jeden Fall ein
interessantes Ergebnis.
Wie auch immer, die saubere Lösung ist es, die LEDs explizit
auszuschalten, wenn sie aus sein sollen.
Die Initialisierung von Signalen ist ohnehin sehr fragwürdig. Als
Resetwert für Register ok (aber nur im FPGA, bei ASICs funktionieren
solche Späße nicht), bei konstanten Signalen auch ok, aber in allen
anderen Fällen führt sie zu Verwirrung, wie man im vorliegenden Fall
sieht.
Erik schrieb:> Es ist beschämend zu sehen, wie Menschen in der Anonymität des> Internets, miteinander umgehen.
Ohne Witz: du tust da aber schon arg überrascht. Bist du neu im
Internet? Diese ganze hehre An- und Absicht wie Menschen miteinander
umgehen sollten und die Aufregung darüber, dass das nicht der Fall ist,
wird dir nicht bei der Lösung deines Problems helfen.
> Ich bin raus!
Jetzt, wo die Kindereien durch sind und es eigentlich erst richtig
interessant wird...
vancouver schrieb:> offenbar ist der Code des TO doch gar nicht soooo falsch, wie manche> Krawallmacher behauptet haben.
Deshalb hatte mich von vorn herein der RTL-Schaltplan interessiert. Auch
am Ressourcenverbrauch kann man leicht erkennen ob es schiefgeht: wenn
da mehr als 11 Flipflops benötigt werden, dann ist etwas faul...
vancouver schrieb:> Btw, offenbar ist der Code des TO doch gar nicht soooo falsch, wie> manche Krawallmacher behauptet haben.
Soso, also die Personen, die Probleme nicht unter den Teppich kehren
sondern klar benennen (Hausaufgaben sind dazu gedacht das man
Selbermachen was elbst lernt, falscher lösungsansatz, lückenhaftes
Verständnis der Möglichkeiten einen Zähler zu implementiern, Grundlagen
Code Style) werden neuerding zu ('phösen') Krawallmacher abgestempelt?!
Und der Code ist syntaktisch fehlerfrei aber weder funktional korrekt
noch wird er der zugrundeliegenden Hardwarestruktur gerecht.
Da von "nicht so falsch" zu reden ist soch ziemlich scheinheilig. Zumal
es nichts zwischen den beiden Binären Werten 'falsch" und 'richtig'
gibt.
Lutz Locus schrieb:> weder funktional korrekt noch wird er der zugrundeliegenden> Hardwarestruktur gerecht.
Der Code beschreibt ein Verhalten. Man sieht das auch in der Simulation
und bei Xilinx dann auch in der Logik.
Wenn der Code also ein gewünschtes Verhalten erzeugt, dann erfüllt er
genau die Anforderung.
Könnt man auch anders machen, muss man aber nicht. Das ist eben eine der
vielen möglichen Lösungen wie man einen Vektor mit Einsen befüllt.
Lutz Lokus schrieb:> Das ist ungequirlte Bullenscheisse, alles zwischen architecture und end> architecture löschen und complett neu machen.
Aber dein Verhalten ist nachvollziehbar wenn man sieht wie weit du mit
deiner Aussage oben daneben lagst. Es hilft aber nicht sich einzureden,
dass man doch recht gehabt hätte. Akzeptiere, die Tatsachen und lerne
daraus.
vancouver schrieb:> Wie gesagt, wenn das Verhalten eines Signals nicht explizit spezifiziert> ist, dann kann er Optimizer machen was er will, und Vivado optimiert> offenbar anders als Quartus. Logisch richtig sind beide Lösungen,
Ich halte das für einen Fehler in Quartus. Das scheint den Default-Wert
in der Port-Liste schlicht zu ignorieren (selbst wenn man dort z.B.
1
led:outstd_logic_vector(7downto0):="10101100"
schreibt, wird das zwar akzeptiert, aber es kommt nichts anderes dabei
raus, was m.E. dem LRM - zumindest dem von 2000 - widerspricht). Das ist
dann wohl auch der Grund "warum man das nicht macht"...
(falsch.png) - Quartus sieht keinen Grund, den out-Port irgendwie zu
bespassen.
Macht man aus
-gb- schrieb:> Lutz Lokus schrieb:>> Das ist ungequirlte Bullenscheisse, alles zwischen architecture und end>> architecture löschen und complett neu machen.>> Aber dein Verhalten ist nachvollziehbar wenn man sieht wie weit du mit> deiner Aussage oben daneben lagst.
Wieso daneben liegen? Vergleiche bitte die Lösungsvarianten
https://www.mikrocontroller.net/attachment/highlight/581072 und
Beitrag "Re: Ein wirklich blöder Fehler, den ich nicht sehe"
mit dem Ansatz des TO.
Da stimmt nichst in der architecture überein und obendrein ist eine
Variante noch von dir. Deine und meine Variante sind sich sehr ähnlich
und doch behauptest Du eine läge daneben.
> Es hilft aber nicht sich einzureden,>dass man doch recht gehabt hätte.
Genau das macht der TO, er redet sich ein, er hätte mit seiner
umständlichen und obendrein fehlerhaften Umweg-variante über einen
3bit-binärcounter 'recht'.
>Akzeptiere, die Tatsachen und lerne>daraus.
Das sag mal den TO, der kennt nur 'beleidigte Leberwurscht'. Zitat:
"ich, ... meldet sich ein
letztes Mal zu Wort. Es ist beschämend zu sehen, wie Menschen in der
Anonymität des Internets, miteinander umgehen....
Dieses Verhalten ist in allen Themenbereichen dieser Plattform hier zu
erkennen und es macht mich traurig.
Ich bin raus!"
Klar, musterhafzes Beispiel für einen lernwilligen Forumsteilnehmer, der
akzeptiert das er Fehler macht ;-)
Lutz Locus schrieb:>> wenn da mehr als 11 Flipflops benötigt werden, dann ist etwas faul...> Es sind aber nur neun 1-bit speicher nötig (debounce nicht betrachtet).
Es ist doch völlig uninteressant, was "nötig" ist und/oder wie man die
Aufgabe sonst noch lösen könnte.
Das einzig Interessante hier ist das Verhalten des Synthesizers. Denn
der wird so einen erkennbaren Blödsinn auch bei anderen Beschreibungen
machen. Und dann ist dieses Fehlverhalten evtl. besser versteckt iund
nicht so leicht zu erkennen.
Lothar M. schrieb:> wenn> da mehr als 11 Flipflops benötigt werden, dann ist etwas faul...
Bzw. wenn gar kein FF verwendet wird, obwohl da ein Zähler drin sein
sollte.
Lutz Locus schrieb:> Hausaufgaben
Ich lese hier immer Hausaufgaben. Wo hat der TO etwas von Hausaufgaben
gesagt?
> falscher lösungsansatz,
Wie Gustl B. nachgewiesen hat, ist der Lösungsansatz nicht falsch.
> lückenhaftes> Verständnis der Möglichkeiten einen Zähler zu implementiern
Immerhin ist der Zähler auf_eine_ mögliche Weise implementiert worden.
> Grundlagen Code Style
Kein Anfänger beherrscht guten Code Style. Hast du auch nicht.
> werden neuerding zu ('phösen') Krawallmacher abgestempelt?!
Du kennst den Spruch mit dem Ton und der Musik?
> weder funktional korrekt> noch wird er der zugrundeliegenden Hardwarestruktur gerecht.
Und darüber müssen wir uns doch erstmal kräftig aufregen.
Kleiner Tip an Locus, Falk & Co: Wenn euch die Anfängerfragen zu sehr
aufregen, dann lest sie einfach nicht. Beim ersten Anzeichen von
Nervosität schnell den Thread wechseln, tief durchatmen und an etwas
Schönes denken z.B. dass bald Weihnachten ist. Alles wird gut, ok?
Lutz Locus schrieb:> Klar, musterhafzes Beispiel für einen lernwilligen Forumsteilnehmer, der> akzeptiert das er Fehler macht ;-)
Sieh mal in den Spiegel: du bist der, der bis zum letzten Blutstropfen
auf irgendeinem herumhackt, der schon lange die Segel gestrichen hat.
Dieses Hinterhertreten und "seht ihr, ich hatte doch Recht"-Gehabe
interessiert hier keinen.
Lothar M. schrieb:> Sieh mal in den Spiegel: du bist der, der bis zum letzten Blutstropfen> auf irgendeinem herumhackt, der schon lange die Segel gestrichen hat.
Ich hacke nicht auf eine rum, schon garnicht um Blut zu sehen, ich
benenne klar und deutlich die Fehler und Fehlannahmen die der TO von
Anfang an macht. Und das lange bevor der TO einen auf beleidigte
Leberwurst macht. Sogar code-beispiel hat man geschrieben mund
hochgeladen. Aber für den Lothar ist das "aufs Blut herumgehacke".
> Dieses Hinterhertreten und "seht ihr, ich hatte doch Recht"-Gehabe> interessiert hier keinen.
Schon mal von der zeitlichen Abfolge her kann man hier nicht von
Nachtreten reden. Und der TO fordert doch explizit auf ihm zu zeigen wie
man es recht macht.
Also Leutschens, regt Euch ab.
Lutz Locus schrieb:>> Sieh mal in den Spiegel: du bist der, der bis zum letzten Blutstropfen>> auf irgendeinem herumhackt, der schon lange die Segel gestrichen hat.>> Ich hacke nicht auf eine rum, schon garnicht um Blut zu sehen, ich> benenne klar und deutlich die Fehler und Fehlannahmen die der TO von> Anfang an macht. Und das lange bevor der TO einen auf beleidigte> Leberwurst macht. Sogar code-beispiel hat man geschrieben mund> hochgeladen. Aber für den Lothar ist das "aufs Blut herumgehacke".>>> Dieses Hinterhertreten und "seht ihr, ich hatte doch Recht"-Gehabe>> interessiert hier keinen.>> Schon mal von der zeitlichen Abfolge her kann man hier nicht von> Nachtreten reden. Und der TO fordert doch explizit auf ihm zu zeigen wie> man es recht macht.> Also Leutschens, regt Euch ab.
Bist halt doch nur ein typischer Rechthaber der sich aufbläst und
doch nur unbelehrbar vor sich hin Motzt und nix zur Problemlösung
beiträgt und auch sonst nix kann!
atoyot schrieb:> Bist halt doch nur ein typischer Rechthaber der sich aufbläst und> doch nur unbelehrbar vor sich hin Motzt und nix zur Problemlösung> beiträgt und auch sonst nix kann!
Netter Versuch ...
Markus F. schrieb:> Ich halte das für einen Fehler in Quartus. Das scheint den Default-Wert> in der Port-Liste schlicht zu ignorieren
Da kommt daher, dass der Initialwert in diesem Beispiel keine Bedeutung
hat. Der LED-Vektor ist ein Signal, das seinen Wert aus einem Schaltnetz
bekommt, und zwar sofort. Und das Schaltnetz wurde optimiert unter
Ausnutzung der don't-cares, daher wird alles auf 1 gesetzt. Default-Wert
kommt damit gar nicht erst zum Tragen. Anders wäre es, wenn das
LED-Signal konstant wäre oder ein Register, das erst beim nächsten Takt
überschrieben werden kann.
Das ist eine Spitzfindidigkeit, und man kann darüber streiten, ob die
Umsetzung in Quartus so sinnvoll ist. Aber logisch gesehen ist sie
richtig.
Mich wundert nur, dass in deinem Falsch-Beispiel der Counter nicht
wegoptimiert wird. Aber das kommt vermutlich später im Design flow.
Lutz Locus schrieb:> Ich hacke nicht auf eine rum
Äh: doch, genau das macht den großen Teil deiner Beiträge aus.
Lutz Locus schrieb:> ich benenne klar und deutlich die Fehler und Fehlannahmen die der TO von> Anfang an macht
wo du glaubst angebliche Fehler erkannt zu haben, liegst du gerne auch
mal fachlich falsch. ein Beispiel gefällig?
Lutz Locus schrieb:> Also der Pferdefuß in dem TO-Vorschlag ist IMHO der dynamische Index:>> s_led(i) <= '1';
wie gezeigt wurde ist dieser dynamische Index klar nicht das Problem.
sofern die Initialisierung des Signals so behandelt wird wie von TO (und
anderen erwartet), wird auch der dynamische Index problemlos in einem
Dekoder umgesetzt.
vancouver schrieb:> Mich wundert nur, dass in deinem Falsch-Beispiel der Counter nicht> wegoptimiert wird. Aber das kommt vermutlich später im Design flow.
der wird wegoptimiert (in der Technology Map view sind nur noch 8
IO_OBUFS übrig). Aber es ist ja wenig sinnvoll, einen leeren Screenshot
zu posten, gell?
vancouver schrieb:> Der LED-Vektor ist ein Signal, das seinen Wert aus einem Schaltnetz> bekommt, und zwar sofort. Und das Schaltnetz wurde optimiert unter> Ausnutzung der don't-cares, daher wird alles auf 1 gesetzt.
Richtig.
So würde der Initialwert funktionieren, weil für die LED Flipflops nötig
sind:
1
:
2
:
3
process(BTN)
4
begin
5
if rising_edge(BTN) then
6
counter <= counter + 1;
7
LED(counter) <= '1';
8
end if;
9
end process;
10
:
11
:
Lutz Locus schrieb:> wenn da mehr als 11 Flipflops benötigt werden, dann ist etwas faul...
Stimmt, das hatte ich auf dem Handy übersehen (naja, kleiner
Bildschirm...).
Mit dem Code des TO waren es tasächlich nur 3 Flipflops des
32-Bit-Integers, die letztendlich für den Zähler "gebraucht" (und
wegoptimiert) werden, aus dem dann konbinatorisch die (sicher
unbeabsichtigten) LED-Latches gesetzt werden. Mit meinem Code hier
braucht es letztlich diese 11 Flipflops: 3 für den Zähler und 8 für die
LEDs.
Lothar M. schrieb:> So würde der Initialwert funktionieren, weil für die LED Flipflops nötig> sind:
Aber auch nur am Anfang, oder? Wenn eine LED einmal eingeschaltet wurde,
bleibt sie für immer an, weil der Initialwert weg ist, nach meinem
Verständnis.
Lutz Locus schrieb:> Wieso daneben liegen? Vergleiche bitte die Lösungsvarianten>> https://www.mikrocontroller.net/attachment/highlight/581072 und> Beitrag "Re: Ein wirklich blöder Fehler, den ich nicht sehe">> mit dem Ansatz des TO.> Da stimmt nichst in der architecture überein und obendrein ist eine> Variante noch von dir. Deine und meine Variante sind sich sehr ähnlich> und doch behauptest Du eine läge daneben.
Du liegst mit deiner Aussage daneben, das sei Bullshit was der TO da
geschrieben hat. Seine Hardwarebeschreibung funktioniert korrekt bei
Xilinx und Modelsim.
Lutz Locus schrieb:> ich> benenne klar und deutlich die Fehler
Nö, ein Fehler wurde da nicht benannt.
Lothar M. schrieb:> So würde der Initialwert funktionieren, weil für die LED Flipflops nötig> sind::> :> process(BTN)> begin> if rising_edge(BTN) then> counter <= counter + 1;> LED(counter) <= '1';> end if;> end process;
Ja, aber wieso funktioniert die kombinatorische Zuweisung nicht, wenn
man ein Signal verwendet (da hat man ja auch Register/Latches)?
Das hier Nachfolgende funktioniert nämlich ebenfalls bei Quartus nicht,
mit Vivado aber schon.
----
architecture rtl of Debounce_Test is
signal counter : integer := 0;
signal s_led : std_logic_vector(7 downto 0) := (others => '0');
begin
process(BTN)
begin
if rising_edge(BTN) then
counter <= counter + 1;
end if;
end process;
s_led(counter) <= '1';
LED <= s_led;
end architecture rtl;
vancouver schrieb:> Markus F. schrieb:>> Ich halte das für einen Fehler in Quartus. Das scheint den Default-Wert>> in der Port-Liste schlicht zu ignorieren>> Da kommt daher, dass der Initialwert in diesem Beispiel keine Bedeutung> hat. Der LED-Vektor ist ein Signal, das seinen Wert aus einem Schaltnetz> bekommt, und zwar sofort. Und das Schaltnetz wurde optimiert unter> Ausnutzung der don't-cares, daher wird alles auf 1 gesetzt. Default-Wert> kommt damit gar nicht erst zum Tragen.
Das sehe ich anders. Der Defaultwert sagt dem Compiler/Synthesiser,
welchen Wert ein Signal am Anfang haben darf. Der darf nach meinem
Verständnis nur ignoriert werden, wenn das Signal sofort bedingungslos
einen anderen Wert zugewiesen bkommt. Wenn jemand einen Nachweis hat,
dass das im Standard anders definiert ist, bin ich interessiert.
Hier wird der Wert des Signals aber nicht sofort überschrieben, sondern
nur unter einer Bedingung (rising_edge(BTN)).
Hier wird gesagt, fange mit LED=000... und counter=0 an. Wenn
(irgendwann) BTN eine Flanke hat, zähle counter hoch. Setze LED(counter)
auf 1.
Solange BTN keine Flanke hatte, ist counter=0, also darf nur LED(0) auf
1 gesetz werden, die anderen nicht.
Wenn der Optimierer daraus macht 'setze alle LED bedingungslos auf 1',
sehe ich das als falsch an.
PS: Hat mal jemand getestet, ob rising_edge(BTN) vielleicht das Problem
verursacht? Vielleicht kommt Quartus durcheinander, weil es bei
rising_edge ein Taktsignal erwartet, aber BTN nicht als Takt definiert
ist?
Quartus kann schonmal komische Fehler verursachen.
Gustl B. schrieb:> mit Vivado aber schon.
Welche Zielplattform?
Xilinx-FPGAs haben die Möglichkeit, Flipflops zu Latches
umzukonfigurieren. Die kann man dann auch mit Initialwerten vorbelegen.
Markus F. schrieb:> Quartus versteht also durchaus, was gewünscht ist.
Aber es nimmt den Initialwert wohl nur als Default-Wert für den
Power-Up. Und beim gewünschten Verhalten des Signals bezieht es den
Initialwert nicht zwingend ein sondern begnügt sich mit der Beschreibung
innerhalb der Architektur, wo nichts anderes als 1 zugewiesen wird.
Lothar M. schrieb:> Welche Zielplattform?> Xilinx-FPGAs haben die Möglichkeit, Flipflops zu Latches> umzukonfigurieren.
bezüglich Vivado müsste die Antwort von Gustl kommen. Bezüglich ISE
funktioniert es für Cool Runner 2 und für Spartan 6, wobei in beiden
Fällen Latches eingesetzt werden.
Dussel schrieb:> Der Defaultwert sagt dem Compiler/Synthesiser,> welchen Wert ein Signal am Anfang haben darf. Der darf nach meinem> Verständnis nur ignoriert werden, wenn das Signal sofort bedingungslos> einen anderen Wert zugewiesen bkommt.
Das ist es, was die meisten von uns intuitiv als Regel angenommen
hätten. Ob der Standard das für die Nutzung der Initialwerte auch so
vorschreibt, hat aber noch keiner gefunden. Da Quartus es anders macht
vermute ich, dass der Standard dies nicht eindeutig regelt.
Falk B. schrieb:> Du glaubst, daß man so einen 1:N Dekoder in VHDL sauber beschreibt? Ich> nicht.
Eben. Anbei die sechs Musterlösungen aus dem Blue book dazu. Vielleicht
erhellt das den TO.
--
> Du liegst mit deiner Aussage daneben, das sei Bullshit was der TO da> geschrieben hat. Seine Hardwarebeschreibung funktioniert korrekt bei> Xilinx und Modelsim.
Ach, obwohl der TO schreibt, es verhält sich auf seiner Hardware nicht
so wie erwartet, erklärst Du ihm jetzt, das es doch funktioniert? Willst
Du den TO in den Wahnsinn treiben?
Also ich bin der Meinung, man sollte von Anfang narrensicheren FPGA-Code
schreiben. Und das heisst eben Initialisierungen nur bei Signalen die
als FF/Latch realisiert werden ("eben in der signal declaration und
nicht in der Portlist).
Und für decoder etc. eben die bewährten synthesefähige Konstrukte
verwenden (siehe Anhang)
Und rising_edge eben nur für Takt-signale oder anderes was unbedingt an
den CLK-Input muß.
Und nicht glauben, das man ein Genius wäre, weil man exotische
Konstrukte verwendet. Denn wie schön heisst es bspw. bzgl. Latches:
"Only idiots and geniuses use latches."
Achim S. schrieb:> Das ist es, was die meisten von uns intuitiv als Regel angenommen> hätten. Ob der Standard das für die Nutzung der Initialwerte auch so> vorschreibt, hat aber noch keiner gefunden.
Tatsächlich. Ich habe jetzt auch nichts gefunden. Weder beim Standard,
noch bei Quartus. Dann ist aber die Frage, was ein Initialwert bringen
soll. Für unveränderliche Signale kann man auch schnell
signal<=Initialwert in den Code schreiben.
Lothar M. schrieb:> Welche Zielplattform?
7er Serie.
Aber bei Quartus funktioniert das ja auch dann nicht, wenn man ein
Signal für LED verwendet. Ja, wird kombinatorisch gesetzt, aber
könnte/sollte speichernd sein.
Markus F. schrieb:> Quartus versteht also durchaus, was gewünscht ist.
Welche Version und FPGA?
Dussel schrieb:> Achim S. schrieb:>> Das ist es, was die meisten von uns intuitiv als Regel angenommen>> hätten. Ob der Standard das für die Nutzung der Initialwerte auch so>> vorschreibt, hat aber noch keiner gefunden.> Tatsächlich. Ich habe jetzt auch nichts gefunden. Weder beim Standard,> noch bei Quartus.
Weil sowas bei Xilinx steht.
UG429 p.6 https://docs.xilinx.com/v/u/en-US/ug429_7Series_Migration
White Paper 272 https://docs.xilinx.com/v/u/en-US/wp272
Meines Wissens, kann Xilinx-FPGA die Initwerte eine signal decleration
bei der FPGA configuration (also vor/ohne Reset) realisieren. Altera
dagegen nicht oder nur für wenige Bauteilfamilien.
Bei CPLDS die keine FF in der logic-fabric haben, sondern nur eins an
den Pins mag etwas anders realisiert sein.
Lutz Locus schrieb:> Falk B. schrieb:>> Du glaubst, daß man so einen 1:N Dekoder in VHDL sauber beschreibt?>> Ich nicht.> Eben. Anbei die sechs Musterlösungen aus dem Blue book dazu.
Dass man einen Dekoder sinnigerweise so schreibt, dass er keine Latches
ergibt, ist ja wohl zwischenzeitlich jedem klar.
> Vielleicht erhellt das den TO.
Genau das nenne ich endlose Nachtreterei. Der TO ist schon lange fertig,
es interessiert ihn nicht, dass du meinst, mit dem blauen Buch auch
gleich das schlaue Buch in der Hand zu haben. Dabei steht da nicht mal
die kürzeste Variante drin:
1
process(cnt)begin
2
LED<=(others=>'0');
3
LED(cnt)<='1';
4
endprocess;
Mal wieder zur Sache...
Die LSE von Lattice Diamond 3.12 meldet zum Code des TO:
1
WARNING - Initial value found on instance LED_7__I_0_i3 will be ignored.
2
WARNING - Initial value found on instance LED_7__I_0_i2 will be ignored.
3
WARNING - Initial value found on instance LED_7__I_0_i1 will be ignored.
4
WARNING - Initial value found on instance LED_7__I_0_i4 will be ignored.
5
WARNING - Initial value found on instance LED_7__I_0_i5 will be ignored.
6
WARNING - Initial value found on instance LED_7__I_0_i6 will be ignored.
7
WARNING - Initial value found on instance LED_7__I_0_i7 will be ignored.
8
WARNING - Initial value found on instance LED_7__I_0_i8 will be ignored.
9
WARNING - c:/projekte/fpga/lattice/debounce_test/debounce_test.vhd(7): mRegister LED_7__I_0_i8 has stuck clock, removing...
Der Ressourcenverbrauch ist dann plausibel:
1
Number of register bits => 10 of 1604 (0 % )
2
CCU2D => 2
3
FD1S1B => 7
4
FD1S3AX => 3
5
GSR => 1
6
IB => 1
7
LUT4 => 9
8
OB => 8
Man erkennt hier: Lattice hat (wie Xilinx) im MachXO2 mit dem FD1S1B ein
dediziertes "Positive Level Data Latch with Positive Level Asynchronous
Preset".
Der alternative Synthesizer Synplify Pro meldet mit diesem Code aber
lapidar, dass der counter unnötig sei und wegoptimiert werde:
1
Pruning unused register counter(2 downto 0). Make sure that there are no unused intermediate registers.
Und mangels Zähler wird dann zu jedem einzelnen LED-Bit gemeldet:
1
All reachable assignments to LED(0) are '1'; removing register. To preserve a constant register, use the syn_preserve attribute.
Der erzeugte RTL-Schaltplan überzeugt dann auch mit großer
Schlichtheit... ;-)
Mein Lösungsansatz zur Aufgabe des TO wäre etwa so gewesen:
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
4
entitydecoder1aus8is
5
Port(clk:inSTD_LOGIC;
6
LED:outSTD_LOGIC_VECTOR(7downto0));
7
enddecoder1aus8;
8
9
architectureBehavioralofdecoder1aus8is
10
signalcnt:integerrange0to7:=5;
11
begin
12
-- -- Diamond 3.12 ok / ISE 14.7 err "bad synchronous description" / ISIM ok
13
-- cnt <= 0 when rising_edge(clk) and cnt=7 else
14
-- cnt+1 when rising_edge(clk);
15
16
-- Zähler / Diamond ok / ISE ok
17
processbegin
18
waituntilrising_edge(clk);
19
ifcnt=7thencnt<=0;
20
elsecnt<=cnt+1;
21
endif;
22
endprocess;
23
24
-- Diamond ok / XST ok
25
process(cnt)begin
26
LED<=(others=>'0');
27
LED(cnt)<='1';
28
endprocess;
29
30
-- -- Diamond: Err choice is not constant / XST Err: Choices must be locally static
31
-- -- ISIM: ok
32
-- process (cnt) begin
33
-- LED <= (cnt => '1', others => '0');
34
-- end process;
35
36
-- -- Diamond: Err choice is not constant / XST Err: Choices must be locally static
37
-- -- ISIM: statisch "00100000"
38
-- LED <= (cnt => '1', others => '0');
39
40
endBehavioral;
Siehe die angehängten ISIM Screenshots der Waveform: im Falle der
concurrent-Zuweisung bleibt unverändert der Initialwert aktiv.
Um eine voll synchrone Variante zu erstellen, die ohne die (nicht
allgemein verfügbare) Registerinitialisierung auskommt, ist man
gezwungen weiteren TO-Code über Bord zu werfen und neu zu schreiben.
Im Anhang ein Beispiel das:
-den Integer counter auf 3 bit Breite begrenzt
-den Integer-Überlauf explizit abfängt
-synchron zum Systemtakt arbeitet
-einen reset zur Initialisierung nutzt
Das hätte man schon am Samstag haben können, wäre man den am Samstag
nachmittag genannten Tipps gefolgt.
Aber hier sind ja Streicheleinheiten für beleidigte Leberwürschte
wichtiger als Sacharbeit. SCNR
Lothar M. schrieb:> Lutz Locus schrieb:> Genau das nenne ich endlose Nachtreterei. Der TO ist schon lange fertig,> es interessiert ihn nicht, dass du meinst, mit dem blauen Buch auch> gleich das schlaue Buch in der Hand zu haben.
Soso, jede Beschäftigung mit dem Code nachdem der TO beleidigt
abgedampft ist, ist für Dich 'üble Nachtreterei'? Oder, nur wenn 'Lutz
Locus' seine Zeit opfert und sich mit den TO-Ergüssen befasst? Weil,
auch der 'Lothar' macht am TO-Code weiter, will aber nicht selbst als
Nachtreter da stehen ... echt, das nenn ich selbstgerechte Bigotterie in
Reinstkultur.
--
> Dabei steht da nicht mal> die kürzeste Variante drin:
Die steht nicht drin, weil sie nicht von jedem Synthesetool identisch
verstanden wird.
Manche steigen komplett aus, manche meinen aus dem Index
(bit_cnt:integer) einen ROM mit 8bitDaten und 3bit (oder 32bit weil
integer?) address zu erkennen und nur einige machen die gewünschte
Gatterliste draus. Das ist doch deutlich in diesem thread zu erkennen.
Also lehrt man die allgemein etablierten Varianten, auch wenn sie einige
Anschläge mehr bedeuten. Mit 120 Anschlägen/min ist das doch Pillepalle,
erst recht wenn man bedenkt wieviel Stunden das anschliesende Debugging
durch die Toolchain-Warnings etc. kostet.
Dussel schrieb:> Das sehe ich anders. Der Defaultwert sagt dem Compiler/Synthesiser,> welchen Wert ein Signal am Anfang haben darf. Der darf nach meinem
Das ist richtig. Die Frage, die man sich hier aber stellen muss, ist,
wann "der Anfang" zuende ist, d.h., wann darf das Signal einen neuen
Wert annehmen:
bei konstanten Signalen -> niemals
bei Registern -> im nächsten Takt
bei kombinatorischen Signalen -> sofort
Der LED-Vektor ist ein kombinatorisches Signal.
> Hier wird der Wert des Signals aber nicht sofort überschrieben, sondern> nur unter einer Bedingung (rising_edge(BTN)).
Nein, das gilt nur für LED(0) gleich am Anfang, was mit den anderen
passieren soll, wird in diesem Design nicht spezifiziert. Also krallt
sich der Optimizier diese Signale und belegt sie mit einem logischen
Zustand, der es ihm erlaubt, das ganze Design möglichst optimal zu
gestalten. In diesem Fall setzt er alle auf 1, und in diesem Augenblick
ist der Initialwert futsch. Der Initialwert is maximal rezessiv, er
verschwindet sofort, weil der nicht vollständig auscodierte LED-Bus vom
Optimizer sofort belegt wird. Das ist zumindest die Quartus-Strategie,
Vivado versucht den Initialzustand zu halten. Streng genommen wird der
Initialzustand damit zu einem Defaultzustand, der immer wieder erreicht
werden kann. Keine Ahnunug, ob das im LRM so gemeint ist.
Ehrlich gesagt, gefällt mir die Quartuslösung besser. Es ist nicht das
was man erwartet, aber es zwingt einen, über das Problem nachzudenken
und das Design wasserdicht zu schreiben, so dass es keinen
Interpretationsspielraum mehr gibt. Dann kommt man zu einer Lösung, wie
sie wie Markus F. oder lkmiller vorgeschlagen haben
Lutz Locus schrieb:> Die steht nicht drin, weil sie nicht von jedem Synthesetool identisch> verstanden wird.> Manche steigen komplett aus,
Hast du da mal ein Beispiel für ein Tool, was bei diesem Konstrukt
aussteigt? Das ist nämlich korrekter VHDL-Code, ein Tool was da
aussteigt, ist folglich buggy. Jetzt sag bitte nicht ISE11.3 oder sowas.
vancouver schrieb:> Der LED-Vektor ist ein kombinatorisches Signal.
Ich habe schon angefangen, dir zu widersprechen, aber jetzt weiß ich,
was du meinst. Es wird kein speicherndes Element definiert.
Das stand oben schon, aber irgendwie habe ich das falsch verstanden.
Lothar M. schrieb:> Dabei steht da nicht mal> die kürzeste Variante drin: process (cnt) begin> LED <= (others => '0');> LED(cnt) <= '1';
Wenn's auf kurz ankommt: (noch) kürzer wäre wohl (VHDL 2008):
1
led<=8u"1"sllcnt;
(und man kann's auch in einem concurrent Context hinschreiben)
vancouver schrieb:> Der LED-Vektor ist ein kombinatorisches Signal.
Nicht wenn er in einem if-Konstrukt mit rising_edge() o.ä. gesetzt wird.
Die Frage ist, wie der TO es gerne hätte und welche Möglichkeiten seine
Hardware bietet, beispielsweise Output-Pad-FF. Aber damit will der TO
sich wohl nicht auseinandersetzen, der geht kindischerweise davon aus,
das VHDL-Code für beliebige PLD-Implementierungen gleich funktioniert.
> Das ist zumindest die Quartus-Strategie,> Vivado versucht den Initialzustand zu halten.
Das ist weniger die Frage des Sythesetools als eine Frage der
(physischen) Init-Möglichkeiten des Ziel-Bausteins. Und auch die
'Quartus-strategie' für Devices deren FF ein Init-Value (neben dem
Reset) zugewiesen werden kann ,ist per Optionen änderbar, bspw:
https://www.intel.com/content/www/us/en/docs/programmable/683762/22-1/disabling-the-register-power-up-ini.html
Abgesehen davon, das es nicht genau einen 'Quartus' gibt, sondern an die
Hundert.
Es gibt also keine generelle "Quartus-Strategie". Deshalb muss man
angeben, welche Targets (Altera Stratix, Altera Cyclone, Xilinx Spartan,
CPLD) geplant sind um zu entscheiden ob die Init-werte bei der
signaldecleration einen Einfluss auf die Implementierung haben oder
nicht.
Die RTL-Simulation gibt in dem Fall nicht unbedingt das Verhalten auf
dem Evalboard wieder. Es genügt eben nicht, sich wie bei der C-Hackerei
nurden C-Syntax und den Compiler zu kennen, man muss auch die Details
der Hardware (Target-IC) und andere Componenten der Toolchain
(IO-Constraints, bitgen Optionen, Power-Up-timing PLD) kennen.
Aber was erzählt man den Achtel-Wissenden von der Wirklichkeit, wenn's
dann nur als Krakelerei abgestempelt wird. SCNR
Lutz Locus schrieb:> Aber was erzählt man den Achtel-Wissenden von der Wirklichkeit, wenn's> dann nur als Krakelerei abgestempelt wird. SCNR
Ich (und sicher auch andere) würde deine Beiträge lesen (und
wahrscheinlich schätzen), wenn du nicht immer zwanghaft diese üble
Überheblichkeit raushängen müsstest.
vancouver schrieb:> Lutz Locus schrieb:>> Die steht nicht drin, weil sie nicht von jedem Synthesetool identisch>> verstanden wird.>> Manche steigen komplett aus,>> Hast du da mal ein Beispiel für ein Tool, was bei diesem Konstrukt> aussteigt? Das ist nämlich korrekter VHDL-Code, ein Tool was da> aussteigt, ist folglich buggy. Jetzt sag bitte nicht ISE11.3 oder sowas.
Auf diese unmögliche Formulierung kann es keine Antwort gegeben!
Korrekter Code ist jener der korrekt in der Hardware umgesetzt wird. Und
VHDL ist nur für die Simulation standardisiert, aber nicht für die
Synthese. Es gibt völlig standardkonformen Code den modelsim anstandslos
simuliert, der aber von Synthesetools nicht umgesetzt werden kann.
Welche VHDL-Untermenge wie vom Tool umgesetzt wird steht in den
jeweiligen synthese style guides. "Its not a bug, it's a feature" !
https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx14_7/xst.pdfhttps://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx2021_2/ug901-vivado-synthesis.pdf
Klar kannste wie rumpelstilzchen auf einem bein springen über den
angeblich "buggy compiler" schimpfen, du kannst aber auch gleich
synthesegerechten robusten VHDL-code benutzen und dir so den Ärger mit
Simualtion/Synthesise Missmatch vom Halse halten.
vancouver schrieb:> Das ist richtig. Die Frage, die man sich hier aber stellen muss, ist,> wann "der Anfang" zuende ist, d.h., wann darf das Signal einen neuen> Wert annehmen:>> bei konstanten Signalen -> niemals> bei Registern -> im nächsten Takt> bei kombinatorischen Signalen -> sofort>> Der LED-Vektor ist ein kombinatorisches Signal.
Hier beißt sich die Katze beim Erklären in den Schwanz.
Die Xilinx-Software nimmt den Initialisierungszustand als verbindlich
bis zum späteren Überschreiben im Prozess. Und weil sie das tut, ist für
sie der LED-Vektor kein kombinatorisches Signal sondern ein Latch. Denn
nur mit einem Latch lässt sich das eigentlich gewünschte Signalverhalten
(erst null, später eins) ohne Takt speichern. Und dass unvollständig
auskodierte Signalzuweisen eine Beschreibungsform von Latches
darstellen, ist normal.
Um das beschriebene Signalverhalten umsetzen zu können kommt die
Xilinx-Software also zum Schluss, dass für LED-Vektor ein
kombinatorisches Signal nicht ausreicht sondern dass dies eine spezielle
Beschreibung eines Latches sein muss. Und sobald das festliegt, ist auch
das halten des Initialisierungswerts im Latch kein Thema mehr.
Die Qartus-Software entscheidet sich, dass LED-Vektor ein
kombinatorisches Signal ist. Und nur weil sie dies tut hat sie den
Freiheitsgrad zu bewerten, dass beim kombinatorischen Signal der neue
Wert sofort anwendbar sei und deswegen auch fix auf 1 verbunden sein
darf.
"Der Initialwert darf ignoriert werden, weil LED-Vektor ein
kombinatorisches Signal beschreibt" und
"LED-Vektor ist ein kombinatorisches Signal, weil der Initalwert nicht
gespeichert werden muss" passt als Argumentation beides gleich. Beide
Aussagen "Initialwert muss nicht gespeichert werden" und "LED-Vektor ist
ein kombinatorisches Signal" sind zwei Seiten einer Medaille. Sobald man
eine Festlegung getroffen hat, gilt die andere automatisch mit. Deshalb
finde ich es schwierig, eine davon als Argument für die andere zu
nutzen.
Markus F. schrieb:> Lutz Locus schrieb:>> Aber was erzählt man den Achtel-Wissenden von der Wirklichkeit, wenn's>> dann nur als Krakelerei abgestempelt wird. SCNR>> Ich (und sicher auch andere) würde deine Beiträge lesen (und> wahrscheinlich schätzen), wenn du nicht immer zwanghaft diese üble> Überheblichkeit raushängen müsstest.
Was ist an dem Hinweis das hier sachlich fundierte Beiträöge als
"Krakelerei verunglimpft werden, überheblich?
Wer sich nicht wehrt, lebt verkehrt. Und ich wehre mich eben gegen
Rotzereien wie:
Beitrag "Re: Ein wirklich blöder Fehler, den ich nicht sehe" . Erst
recht, wenn es kein andere hier (Moderator?) für mich tun will.
Und was trägt sieser, dein Beitrag hier zur Wissenvermittlung bei?!
Reine zwanghafte Profilierungssucht, komplett für den Arsch.
Lutz Locus schrieb:> Und was trägt sieser, dein Beitrag hier zur Wissenvermittlung bei?!> Reine zwanghafte Profilierungssucht, komplett für den Arsch.
Siehste.
Achim S. schrieb:> Die Qartus-Software entscheidet sich, dass LED-Vektor ein> kombinatorisches Signal ist. Und nur weil sie dies tut hat sie den> Freiheitsgrad zu bewerten, dass beim kombinatorischen Signal der neue> Wert sofort anwendbar sei und deswegen auch fix auf 1 verbunden sein> darf.
Ähm, nein:
1
Info (10041): Inferred latch for "led[0]" at tst028.vhd(36)
2
Info (10041): Inferred latch for "led[1]" at tst028.vhd(36)
3
Info (10041): Inferred latch for "led[2]" at tst028.vhd(36)
4
Info (10041): Inferred latch for "led[3]" at tst028.vhd(36)
5
Info (10041): Inferred latch for "led[4]" at tst028.vhd(36)
6
Info (10041): Inferred latch for "led[5]" at tst028.vhd(36)
7
Info (10041): Inferred latch for "led[6]" at tst028.vhd(36)
8
Info (10041): Inferred latch for "led[7]" at tst028.vhd(36)
auch Quartus ist der Ansicht, dass das ein Latch sein müsse. Dürfte also
- wenn ich deine Argumentation richtig verstehe - die "Optimierung"
nicht durchführen. Ich halte das weiterhin für fehlerhaftes Verhalten.
Lutz Locus schrieb:> Nicht wenn er in einem if-Konstrukt mit rising_edge() o.ä. gesetzt wird.
Das ist aber hier nicht der Fall. Zwischen LED-Vektor und Counter sitzt
noch ein Decoder. Damit ist LED kombinatorisch. Oder Decoder und Zähler
werden wegoptimiert, dann ist LED konstant.
> Aber damit will der TO> sich wohl nicht auseinandersetzen, der geht kindischerweise davon aus,> das VHDL-Code für beliebige PLD-Implementierungen gleich funktioniert.
Der TO hat (vermutlich unbewusst) richtigerweise versucht,
plattformunabhängigen RTL-Code zu schreiben und das Technologiemapping
so weit wie möglich den Tools zu überlassen. Dass seine Umsetzung auf
verschiedenen Plattformen zu verschiedenen Ergbnissen führt, wusste er
nicht und das wusste auch von uns offensichtlich niemand.
Also eigentlich müsstest du dem TO dankbar sein, weil du aus seinem
Codebeispiel auch noch etwas lernen kannst.
> Abgesehen davon, das es nicht genau einen 'Quartus' gibt, sondern an die> Hundert.
Meine Aussage zur Strategie bezog sich auf diejenige Quartus-Version,
die Gustl B. verwendet hat. Sie unterscheidet sich von der Strategie von
Vivado, und das ist das worauf es hier ankommt. Außerdem bezog sich
meine Aussage auf die Strategie des Optimierers, nicht auf die
Initialisierung von Registern.
> Details> der Hardware (Target-IC) und andere Componenten der Toolchain> (IO-Constraints, bitgen Optionen, Power-Up-timing PLD) kennen.
Das war dem TO anscheinend bewusst, sonst hätte er es nicht geschafft,
seine LED_pins im Design zu verwenden.
> SCNR
Wir haben ganz ehrlich nichts anderes erwartet.
Markus F. schrieb:> auch Quartus ist der Ansicht, dass das ein Latch sein müsse.
Bleiben diese Latches bis zum Schluss erhalten, oder werden sie
irgendwann wegoptimiert?
wie oben schon gezeigt, am Ende landet Quartus hier:
Warning (21074): Design contains 1 input pin(s) that do not drive logic
Warning (15610): No output dependent on input pin "btn"
(was ja offensichtlich nicht korrekt ist) und es bleibt nichts übrig.
Markus F. schrieb:> Warning (21074): Design contains 1 input pin(s) that do not drive logic> Warning (15610): No output dependent on input pin "btn"
Eigentlich genau, was man erwarten würde. Der Optimizer erkennt, dass
die LEDs nur auf 1 aber nirgendwo auf 0 gesetzt werden, verkabelt sie
alle hart auf 1 und entfernt die Latches und den Zähler, die die
Synthese erzeugt hat. Was übrig bleibt, sind 8 konstante Ausgänge und
ein unbenutzter Eingang.
Markus F. schrieb:> auch Quartus ist der Ansicht, dass das ein Latch sein müsse. Dürfte also> - wenn ich deine Argumentation richtig verstehe - die "Optimierung"> nicht durchführen. Ich halte das weiterhin für fehlerhaftes Verhalten.
Ich wollte zeigen, dass ich die Argumentation schwierig finde: "Der
Initialwert darf sofort überschrieben werden, weil LED-Vektor ein
kombinatorisches Signal ist (kein Latch)". Und ich finde sie schwierig,
weil die Nachfolgefrage zum Zirkelschluss führt: "Warum ist LED-Vektor
ein kombinatorisches Signal und kein Latch? Na, weil der Initialwert
sofort überschrieben werden darf."
Und ich bin deiner Meinung: wenn selbst die Quartus Software LED-Vektor
wirklich als Latch betrachet, dann hätte sie die Initialzuweisung nicht
wegoptimieren dürfen. Offensichtlich hat sie sich irgendwo im Ablauf der
Implementierung noch "umentschieden".
Letztlich läuft es immer auf die selbe Frage raus: ist die
Initialisierung als vollwertige Signalzuweisung ernst zu nehmen oder
nicht. Xilinx und Quartus haben sich für unterschiedliche Antworten
entschieden.
vancouver schrieb:> Der Optimizer erkennt, dass> die LEDs nur auf 1 aber nirgendwo auf 0 gesetzt werden,
Wenn man die Initialisierung nicht als vollwertige Signalzuweisung
sieht, dann wird den LEDs nur 1 zugewiesen. Wenn man sie als
Signalzuweisung sieht, dann werden den LEDs unterschiedliche Werte
zugewiesen. 0 (bei Power Up) und 1 (bei Erreichen des Zählerstands).
Lutz Locus schrieb:> Die steht nicht drin, weil sie nicht von jedem Synthesetool identisch> verstanden wird.
Zeig doch mal das Syntheseergebnis einer Toolchain, die diese ordinäre
sequentielle Zuweisung unterschiedlicher Werte an ein Signal im Prozess
nicht kann.
Ich sehe da keine Freiheitsgrade für ein "Unverständnis" einer
Toolchain. Diese Zuweisung ist tadellos:
1
LED<=(others=>'0');
Auch am indizierten Arrayzugriff hier gibt es nichts zu deuteln:
1
LED(cnt)<='1';
Und dass in einem Prozess ein "weiter oben" an ein Signal zugewiesener
Wert "weiter unten" wieder überschrieben werden kann, ist eine der
elementaren Grundlagen von VHDL.
Das Beispiel 6 in deinem Foto vom blauen Buch verwendet übrigens
ebenfalls eine solche Vorbelegung für das Signal Y (wobei dort auch noch
ein Copy-Paste-Fehler vom Beispiel 5 drin ist...).
Achim S. schrieb:> Und ich bin deiner Meinung: wenn selbst die Quartus Software LED-Vektor> wirklich als Latch betrachet, dann hätte sie die Initialzuweisung nicht> wegoptimieren dürfen.
Der "Witz" ist, dass der Optimizer erkennt, dass er die Werte gar nicht
vorbelegen kann, weil dem FPGA ein entsprechender vorbelegbarer
kombinatorischer Speicher fehlt (wie gesagt: Xilinx und Lattice können
ihre Flipflops in einen solchen Modus umschalten).
Und weil er den Speicher nicht vorbelgegen kann, nimm er in logischer
Konsequenz dann gleich einen ihm genehmen und für das Ergebnis
"optimalen" Weg. So wie es Synplify anstelle der LSE auch macht...
vancouver schrieb:> Eigentlich genau, was man erwarten würde.
Erwarten würde ich tatsächlich, dass - wenn der Initialwert richtig
berücksichtigt würde - das erst nach dem 7. Tastendruck der Fall ist.
Markus F. schrieb:> Nur leider scheint's den Intel-Support nicht so fürchterlich> interessiert zu haben...
Warum sollte es den support interessieren?
Sind halt dumme Fehler die der Fragesteller gemacht hat. In jeder
Anleitung/datenblatt steht es, wie man es richtig macht.
Sobald er korrekten Code schreibt funktioniert es, unabhängig vom
Support. Oder es funktioniert eben nicht, weil der IC eben nicht die
Wunschfunktion unterstützt und der Simulator eben den Wunsch-Code
nachstellt, aber nicht das volle IC-Model. Also ein typischer Fall von
"Selbst schuld".
Markus F. schrieb:> Nur leider scheint's den Intel-Support nicht so fürchterlich> interessiert zu haben...
Das ist ja auch erst ein Jahr her. ;-)
Ich hatte um 2020 rum ein Problem, das sich nicht so einfach umgehen
ließ. Bei meiner Suche habe ich im Forum des Herstellers (ich glaube,
bin aber nicht ganz sicher, dass es Intel war) einen Beitrag von 2013
mit diesem Problem gefunden. Da hieß es vom Support, dass das in einer
neuen Version behoben wird. 2014 hat jemand nachgefragt, wie es denn
jetzt damit aussieht, 2017 nochmal. 2020 hatte ich genau dieses Problem,
mit der aktuellen Version.
VHDL-2008 ist fast 15 Jahre alt (eine Ewigkeit in Computerjahren) und
wird immer noch nicht voll unterstützt.
Tja. Ich denke, Lothar hat mal wieder recht.
Intel-FPGAs können Latches nicht mit Init-Werten vorbelegen, weil keine
entsprechende Hardware dafür vorhanden ist.
1
entitymylatchis
2
port
3
(
4
enable:instd_ulogic;
5
d:instd_ulogic_vector(1downto0);
6
q:outstd_ulogic_vector(1downto0)
7
);
8
endentitymylatch;
9
10
architecturertlofmylatchis
11
signalo:std_ulogic_vector(q'range):="01";
12
begin
13
p:process(all)
14
begin
15
ifenablethen
16
o<=d;
17
endif;
18
endprocessp;
19
q<=o;
20
endarchitecturertl;
Das Intel/Altera-Latch (latch.png, o[0]/o[1]) ist schlicht eine
kombinatorische Schleife.
Schaut man in die entsprechende LE (cell.png), sieht man, dass die
sload/sclr Eingänge (die für Presets benutzt werden) am FF hängen, das
aber - weil nur die LUT aktiv ist - komplett umgangen wird.
Hätte einem ja auch mal einer sagen können (ich wüsste nicht, wo in den
Quartus bzw. Intel-FPGA Manuals das - ausser einer generellen Warnung
vor Latches - erwähnt wird). M.E. sollte Quartus für die nicht erfolgte
Initialisierung mindestens eine Warnung ausspucken.
Markus F. schrieb:> Hätte einem ja auch mal einer sagen können (ich wüsste nicht, wo in den> Quartus bzw. Intel-FPGA Manuals das - ausser einer generellen Warnung> vor Latches - erwähnt wird). M.E. sollte Quartus für die nicht erfolgte> Initialisierung mindestens eine Warnung ausspucken.
Aehm, es lernt eigentlich jeder in der ersten Stunde Digitaltechnik das
man generell FF/register über reset initialisiert.
Aber da sich hier im Wiki eine typische vermurkste Formulierung für
Weicheier finden lässt:
https://www.mikrocontroller.net/articles/VHDL#Synchroner_oder_asynchroner_Reset?
ist es nicht verwunderlich, das manche user an der falschen Stelle den
reset weglassen. VHDL-2008 unterstützt diese 'Schlamperei' in einigen
Fällen noch mit dem schlüsselwort "all" in der sensitivity list.
Und wozu in aller Welt braucht es für einen rein kombinatorischen 1:N
Dekoder Latches? Jaja, unsere
ELfenbeinturmphilosophenreinigungsfachkräftemangelmahner . . . . ;-)
Falk B. schrieb:> Und wozu in aller Welt braucht es für einen rein kombinatorischen 1:N> Dekoder Latches?
Ist inzwischen wohl soweit klar, dass das ein Designfehler eines
Anfängers ist.
Laientheater schrieb:> Aehm, es lernt eigentlich jeder in der ersten Stunde Digitaltechnik das> man generell FF/register über reset initialisiert.
Später lernt man, dass das nicht generell nötig ist.
> ist es nicht verwunderlich, das manche user an der falschen Stelle den> reset weglassen.
Wie hätte denn da in der obigen (fehlerhaften) Beschreibung ein Reset
geholfen?
> VHDL-2008 unterstützt diese 'Schlamperei' in einigen> Fällen noch mit dem schlüsselwort "all" in der sensitivity list.
Da hast du aber was in den falschen Hals bekommen. Dem Synthesizer war
die Sensitivliste immer schon völlig schnuppe. Der hat sich das (all)
ganz einfach so herausgenommen. Und dann lapidar gemeldet, dass die
Simulation nicht zur Hardware passt.
Lothar M. schrieb:>> VHDL-2008 unterstützt diese 'Schlamperei' in einigen>> Fällen noch mit dem schlüsselwort "all" in der sensitivity list.> Da hast du aber was in den falschen Hals bekommen.
ich hätte mal eher "unterstütz" in Gänsefüßen schreiben sollen.
Gemeint ist, wenn der VHDL-code eben wie (immer mehr) C-Code ausschaut,
denkt der Autor eben, das er auch so funktioniert wie C-Code. Das eben
die "Variablen"/signals vom "Compiler" vor programmstart mit dem
Init-wert "beschrieben" werden. Und das man nicht an reset-netzwerk etc.
denken muß.
Laientheater schrieb:> denkt der Autor eben, das er auch so funktioniert wie C-Code.
Ja nun, das ist hier wohl wirklich nicht die Fehlerquelle. Der Autor hat
da sogar dran gedacht und dem Port einen Initialwert mitgegeben.
Und siehe da, das funktioniert in der Simulation und auch bei Xilinx im
FPGA wunderbar. Also kein Fehler, höchstens unschön.
Bei Intel ist das mit dem initialisierten Port ebenfalls nicht das
Problem. Auch nicht die Initialisierung generell, denn wenn man ein
Signal nimmt greift die Initialisierung ebenfalls nicht.
Das Problem ist, dass die Zuweisung nicht getaktet ist. Und wenn man das
taktet wird die Initialisierung korrekt verwendet. Ja wieso geht das bei
Intel also nicht? Vielleicht weil es die Hardware nicht kann. Jedenfalls
sollte es da mindestens eine Warnung geben, denn das was bei rauskommt
entspricht nicht der Hardwarebeschreibung (spätestens dann nicht, wenn
man ein Signal mit Initialwert nimmt).
Aus meiner Sicht also weiterhin eine korrekte Hardwarebeschreibung
(zumindest wenn man ein Signal nimmt) und bei Intel tendiere ich zu
einem Bug.
(Ja, könnte man auch alles anders Lösen, ist hier aber völlig egal weil
auch diese Beschreibung funktionieren sollte.)
-gb- schrieb:> a nun, das ist hier wohl wirklich nicht die Fehlerquelle. Der Autor hat> da sogar dran gedacht und dem Port einen Initialwert mitgegeben.
Ein Port in VHDL ist aber kein speicherndes element das initialisiert
werden müsste. Das ware ein Signal, das aber der TO hier für led
überhaupt nicht voprgesehen hat.
> Und siehe da, das funktioniert in der Simulation und auch bei Xilinx im> FPGA wunderbar. Also kein Fehler, höchstens unschön.
Neee, eine Simulation die ein anderes Verhalten zeigt als das Original
in der Realität "funktioniert" nicht sondern ist schlicht fehlerhaft, ja
"grundfalsch".
Deshalb schreibt man möglischt gar keine Init-werte in die
Signaldeklaration um eben so ne Realitätsferne Simulation mit
unrealistischen Startwerzen von grund auf zu unterbinden.
Oder man 'initialisiert' mit "U" (ohnehin der Geburtswert der signale)
was eben "unitialized" bedeudet. (und nicht "Unknown", denn das wäre
'X'). Aber daran denkt natürlich der gemeine C-Coder nicht.
https://www.vhdl-online.de/courses/system_design/vhdl_language_and_syntax/extended_data_types/standard_logic_type
Laientheater schrieb:> Oder man 'initialisiert' mit "U"
das kannst Du machen. Oder bleiben lassen - nicht initialisierte Signale
gibt es in VHDL nicht (die werden - zumindest in der Simulation - mit
T'left initialisiert).
Und das ist bei std_logic ohnehin 'U'.
Laientheater schrieb:> Neee, eine Simulation die ein anderes Verhalten zeigt als das Original> in der Realität "funktioniert" nicht sondern ist schlicht fehlerhaft, ja> "grundfalsch".
So gesehen ist aber jede Simulation grundfalsch, weil sie einen großen
Teil der physikalischen Parameter (z.B. die Zeit) nicht berücksichtigt.
Ein Simulation ist immer zu einem gewissen Grad eine Abstraktion.
> Deshalb schreibt man möglischt gar keine Init-werte in die> Signaldeklaration um eben so ne Realitätsferne Simulation mit> unrealistischen Startwerzen von grund auf zu unterbinden.
Zumindest nicht in den Fällen, wo der RTL-Code auf die eine oder andere
Weise interpretiert werden kann.
Markus F. schrieb:> das kannst Du machen. Oder bleiben lassen - nicht initialisierte Signale> gibt es in VHDL nicht (die werden - zumindest in der Simulation - mit> T'left initialisiert).
Genau das ist mit 'Geburtswert' gemeint ...
Und genau daran erkennt man eine Simulation, das man ein Model mit dem
Wert/Symbol "ist nicht initialisiert" initialisiert ;-)
Und in einer FPU gibst bei der internen Zahlenrepräsentation die Zahl
"NaN" als Abkürzung für "Not a Number" ...
https://de.wikipedia.org/wiki/NaN
Da wundert man sich nicht, das manche Mathematiker im (temporären)
Wahninn endeten ... https://de.wikipedia.org/wiki/John_Forbes_Nash_Jr.
Laientheater schrieb:> Ein Port in VHDL ist aber kein speicherndes element das initialisiert> werden müsste. Das ware ein Signal, das aber der TO hier für led> überhaupt nicht voprgesehen hat.
Das sehen Modelsim und Vivado anders.
Und mit Quartus funktioniert das selbst mit Signal nicht wie ich
mittlerweile mehrmals geschrieben habe.
Laientheater schrieb:> Deshalb schreibt man möglischt gar keine Init-werte in die> Signaldeklaration um eben so ne Realitätsferne Simulation mit> unrealistischen Startwerzen von grund auf zu unterbinden.
Du willst Sprachfeatures vermeiden nur weil es damit bei bestimmten
Herstellern und Bausteinen Probleme geben kann? Man kann bei vielen
Dingen viel weglassen weil es Probleme machen kann. Beim Auto die
Servolenkung, das ABS, ... und warum hat man das trotzdem? Weil es
bequem ist und fast immer funktioniert. Ich belege Signale gerne mit
Initialwerten weil das gut funktioniert.
-gb- schrieb:> Laientheater schrieb:>> Deshalb schreibt man möglischt gar keine Init-werte in die>> Signaldeklaration um eben so ne Realitätsferne Simulation mit>> unrealistischen Startwerten von grund auf zu unterbinden.>> Du willst Sprachfeatures vermeiden nur weil es damit bei bestimmten> Herstellern und Bausteinen Probleme geben kann?
Ja natürlich! Nennt sich auch KISS-prinzip -
https://de.wikipedia.org/wiki/KISS-Prinzip
Oder eben Komplexitätsvermeidung zur Erhöhung der Sicherheit, siehe auch
MurphiesGesetz - "Alles was schief gehen kann, wird irgendwann schief
gehen".
https://de.wikipedia.org/wiki/Murphys_Gesetz
Sprachfeature insbesonders bei der Simulation sind kein Selbstzweck oder
Spielzeug sondern folgen dem Zweck etwas möglichst Realitätsnah
wiederzugeben. Und es entspricht eben nicht der Realität, das ein
Speicher nach PowerUp immer den gewünschten-Wert hat.
> Man kann bei vielen> Dingen viel weglassen weil es Probleme machen kann.> Beim Auto die> Servolenkung, das ABS, ... und warum hat man das trotzdem? Weil es> bequem ist und fast immer funktioniert.
Nicht alles was hinkt, ist auch ein Vergleich.
> Ich belege Signale gerne mit> Initialwerten weil das gut funktioniert.
Oder auch nicht, siehe Thread.
Und xilinx sagt auch nicht, man soll alle signale reseten sondern nur
die wo es nötig ist. Und viele Tests beruhen eben darauf, das man mit
random (noise) pattern als Input arbeitet um eben nicht aus
"Bequemlichkeit" die kritischen Fälle zu verpassen.
Laientheater schrieb:> KISS-prinzip ... Komplexitätsvermeidung
Also der TO hat das doch schön einfach geschrieben. Komplex ist daran
auch nichts.
Laientheater schrieb:>> Ich belege Signale gerne mit>> Initialwerten weil das gut funktioniert.>> Oder auch nicht, siehe Thread.
Das Problem ist hier nur zum Teil der Initialwert. Das vom TO
funktioniert auch bei Intel wunderbar - mit Initialwert am Port - wenn
man die Zuweisung "taktet", also so schreibt:
if rising_edge(BTN) then
counter <= counter + 1;
LED(counter) <= '1';
end if;
Und bei Intel hätte ich ganz klar eine Warnung/Fehler erwartet, dass man
etwas in HDL beschrieben hat/haben will, was es im FPGA nicht gibt. Nur
Warning (13410): Pin "LED[0]" is stuck at VCC
ist etwas wenig.
Gustl B. schrieb:> Und bei Intel hätte ich ganz klar eine Warnung/Fehler erwartet, dass man> etwas in HDL beschrieben hat/haben will, was es im FPGA nicht gibt.
Eben, HDL ist eine modellierung/simulationssprache. Das erlaubt die
Simulation deiner Wünsche, aber garamtiert nicht deren Umsetzung. Die
1:1 Umsetzung deiner Wünsche würdest du durch Erstellung einer
Gatterliste erreichen. Und dann würde es auffallen das eben in der
benutzten Technologie keine FF-"Gatter" gibt, deren PowerUp-Wert (ohne
Resetbeschaltung) einen garantierten Wunschwert annimmt. Oder alle
FF-Gatter auf beide Flanken (if xyz'event then ) schalten. Oder interne
Tristates. Oder den sonstigen (technisch gesehen) Schwachsinn den man
mit Modelsim zwar simulieren aber eben nicht in der vorhandenen
Digitaltechnik realisieren.
> Nur> Warning (13410): Pin "LED[0]" is stuck at VCC> ist etwas wenig.
Die Tool sagen dir, was sie aus deinem Source machen und das ist dir zu
wenig?!
Laientheater schrieb:> Ein Port in VHDL ist aber kein speicherndes element das initialisiert> werden müsste. Das ware ein Signal, das aber der TO hier für led> überhaupt nicht voprgesehen hat.
Wenn hinter dem Port ein Flipflop steckt, dann wird es durchaus
initialisiert. In der Simulation mit "U"ninitialized und in der Realität
mit '0', wenn nicht ein anderer Initialwert vorgegeben wird und dieser
vom FPGA umgesetzt werden kann.
Das Problem hier ist, dass Intel im Gegensatz zu Xilinx und Lattice
keine dedizierten Latch-Speicherelemente hat, sondern das Latch aus der
obigen kombinatorischen Schleife in einer LUT aufbauen. Und diese
Kombinatorik kann ganz einfach nicht mit einem Wunschwert
initialisiert werden.
Laientheater schrieb:> Und es entspricht eben nicht der Realität, das ein Speicher nach> PowerUp immer den gewünschten-Wert hat.
Wenn du mit "Speicher" ein RAM meinst, dann ist das so. Aber die
Flipflops in den Logicblöcken im FPGA werden beim Start jedesmal aus
einem Config-ROM mit einem definierten Pegel initialisiert. Besser
bekommt ein dedizierter Reset-Impuls das auch nicht hin.
Gustl B. schrieb:> Nur> Warning (13410): Pin "LED[0]" is stuck at VCC> ist etwas wenig.
Naja, wenn die Sensitivliste nicht stimmt, dann gibt es nicht mal eine
Warnung, sondern nur eine "Info". Und das, obwohl ganz sicher was
anderes herauskommt als in der Simulation.
Lothar M. schrieb:> Das Problem hier ist, dass Intel im Gegensatz zu Xilinx und Lattice> keine dedizierten Latch-Speicherelemente hat, sondern das Latch aus der> obigen kombinatorischen Schleife in einer LUT aufbauen. Und diese> Kombinatorik kann ganz einfach nicht mit einem Wunschwert> initialisiert werden.
Njein, die Probleme (Plural, nicht Singular wie der TO vorschlägt)
liegen darin:
-das der TO Latch-code schreibt, obwohl er wohl einen synchronen Zähler
will
-er nichts über die Hardware sagt, wie er verwendet
-keinen vollen Plan hat welche Hardware er überhaupt bauen will
-grundlegende Kenntnisse wie der Aufbau eines FF im Unterschied zu einem
Latch fehlen
-wie sauberer code ausschaut (also der in Echt wie in der Simulation
gleich funktioniert)
-welche signal auf ein clk-netzwerk geroutet werden können und welche
nicht
-was rising_edge (in diesem Zusammenhang) bedeutet
- ...
Wenn der TO nicht alle Angaben macht, dann muß die Fehlende durch
Annahmen ersetzt werden und diese Annahmen dokumentiert werden.
Beispielsweise durch comment-zeilen im Arbeitscode wie
https://www.mikrocontroller.net/attachment/highlight/581236
Sonst schnattert hier jeder über seinen ganz eigenen Spezialfall.
Solche Pauschal-aussagen wie , Xilinx hat das, Quartus nicht, sind
falsch, weil jeder Hersteller unterschiedliche Typen mit
unterschiedlichen Eigenschaften hat. Oder das Ganze in einer ASIC-Fab
oder diskret mit ner halb handvoll TTL 74 gebaut werden soll. Im Anhang
ein Xilinx-Coolrunner, bei dem die FF über globale Set/Reset Netzwerke
initialisiert werden.
Deshalb der Vorschlag, ab jetzt (nur noch) als Beuspiel ein Altera
MAX-10
Board vorauszusetzen und kein anderes. (es sei den der TO kommt mit
endlich mal mit dieser essentiellen Information rüber).
Als nächstes wird das design in seine zwei Teile zerlegt, in einen 3-bit
counter und in einen decoder.
der decoder wqird in einer LogigTablle (IN/OUTPUT) spezifiziert. Etwas
so
PowerUp -> "00000000"
Zähler=0 -> "00000001"
Zähler=1 -> "00000010"
...
BTW: man kann LED auch so verdrahten, das sie be1 '0' leuchten und
nicht bei '1'. Auch das hätte der TO klarstellen können.
Ansosnten ist dieser Teil des Designs unproblematisch da genügend
Standardbeispiele verfügbar
der counter wird auch spzifiziert, insbesonders der Wert nach
Einschalten und was an der oberen Zahlgrenze passiert
Und dann entscheidet man sich wie der Zähler am besten auf der
Zielhardware realisiert wird. ich habe mich in meinem beispiel für einen
synchronen Zähler mit synchronen low-aktiven reset entschieden. Also
'rising_edge mit clk und nicht mit irgendwelchen Tasterscheiss.
Und dann beschreibt man das Ganze entsprechend der vom jeweiligen
Toolhersteller vorgegebenen templates (bspw. "synthesis style guide) und
sagt sich nicht irgendwelchen HDL aus den im LRM stecknden Fingern.
Also wie gleich zu Beginn gesachrieben, den Code vom TO grösstenteils
wegschmeißen, fehlende Informationen vom TO einfordern und von Grund auf
richtig machen.
Bitte keine -- (Doppelminus) am Zeilenanfang verwenden.
--
Das wird für Handynutzer zur FETTEN Großschrift (Überschrift).
Dann schon eher --- (drei Minuszeichen) vor dem Text, denn das wird dann
zur Linie:
---
Lutz Locus schrieb:> Xilinx hat das, Quartus nicht, sind falsch, weil jeder Hersteller> unterschiedliche Typen mit unterschiedlichen Eigenschaften hat.
In konkreten Fall hier ist es aber so: in Xilinx/AMD und Lattice FPGAs
gibt es diesen vorkonfigurierbaren/initialiserbaren "Latch" Modus für
die Speicherzellen in den Logikzellen.
Bei Intel/Altera FPGAs werden Latches kombinatorisch über die LUT
abgebildet. Und diese Latches können eben nicht mit Initialwerten
geladen werden.
Und natürlich muss man zur Verwendung solcher Bauteile immer das
jeweilige Datenblatt anschauen.
Lutz Locus schrieb:> -das der TO Latch-code schreibt, obwohl er wohl einen synchronen Zähler> will
Der Zähler ist synchron. Nur hat er an der Stelle, wo ein Schaltnetz
hingehört, eine Bank von Latches oder einen konstanten Vektor
fabriziert. Beides ist nicht das, was hier gewollt ist, und beides wird
verursacht durch die Verwendung von Initialwerten.
Ich habe Signalinitialisierungen nie verwendet (weil ich sie bisher
nicht auf dem Schirm hatte), aber wenn ich etwas aus diesem Thread
gelernt habe, dann, dass man am besten die Finger davon lässt. Selbst
die Lösungen, die wie erwartet funktionieren, erzeugen Latches, was
völlig widersinning ist an dieser Stelle. Initialwerte in der Portliste
grenzen dabei schon an Code Obfuscation.
Die einzige sinnvolle Verwendung von Initialwerten ist bei Registern,
wenn man unbedingt auf den Reset verzichten will und stattdessen lieber
den FPGA neu konfiguriert. (Da ich hauptsächlich ASIC-Designs bzw.
FPGA-Designs als ASIC-Prototyping baue, kommt auch das nicht in Frage.
Plattformunabhängiger RTL-Code ist bei uns der heilige Gral.)
Die oben vorgeschlagenen Lösungen mit voll auscodierten LED-Zuständen
sind kristallklar und unmissverständlich, sie sind kurz und lassen
keinen Spielraum für irgenwelche obskuren Latches. Der LED-Zustand ist
vollständig in ein oder zwei Zeilen Code beschrieben und nicht über den
ganzen RTL-Code verteilt. Es funktioniert mit jeder Toolchain (außer sie
ist komplett verbuggt) und liefert in der Simulation die gleichen
Ergebnisse wie auf der Hardware. In diesem Fall wäre es dann auch völlig
egal gewesen, welche Plattformm der TO verwendet.
vancouver schrieb:> Lutz Locus schrieb:>> -das der TO Latch-code schreibt, obwohl er wohl einen synchronen Zähler>> will>> Nur hat er an der Stelle, wo ein Schaltnetz> hingehört, eine Bank von Latches oder einen konstanten Vektor> fabriziert. Beides ist nicht das, was hier gewollt ist, und beides wird> verursacht durch die Verwendung von Initialwerten.
Njein, einen taktsynchronen Zähler bekommt man, wenn man den VHDL code
für einen taktsynchronen zähler verwendet. Und das heisst eben u.a. die
Verwendung v. rising_edge(clk) (o.ä. Takt-Flanken)
und ein setzten eines Anfangswertes des Zähler-signals (nicht des Ports
einer nachgeschalteten Kombinatorik). Und (clk) meint hier das
Taktnetzwerk und nicht irgendein beliebiges kombinatorisches Signal wie
Tastereingang.
ich meine also, das die Initialisierung in der portlist höchstens einen
Anteil an der Latch-Genreirung trägt, aber nicht allein die Ursache ist.
In der Altera doc steht unter "counter" lediglich wie das
kombinatorische netzwerk codiert wird, aber nicht das hier
problematische 3bit register, wie man dieses codiert steht unter
register (S.44).
https://www.intel.com/content/dam/support/us/en/programmable/support-resources/bulk-container/pdfs/literature/hb/qts/qts-qii51007.pdf
Schreibt es wie in den den jeweiligen "Recommended HDL Coding style"
oder wie immer es dort heisst, dann ist man bezüglich der Synthese auf
der sicheren seite, auch bezüglich des supports. Irgendwelche
Argimentation wie "Aber das LRM gestattete auch diese For,ulierung und
modelsim akzeptiert es" triftt berechtigterweise auf taube Ohren.
Lothar M. schrieb:> Bitte keine -- (Doppelminus) am Zeilenanfang verwenden. Das wird für> Handynutzer zur FETTEN Großschrift (Überschrift).
Diesen Hinweis sollte man schnellstens in die
Forums-formatierungshilfetexte schreiben, noch besser natürlich
deaktivieren, weil Doppelminus ja grade bei VHDL eine kommentarzeile
einleitet ..
Lutz Locus schrieb:> Njein, einen taktsynchronen Zähler bekommt man, wenn man den VHDL code> für einen taktsynchronen zähler verwendet. Und das heisst eben u.a. die> Verwendung v. rising_edge(clk) (o.ä. Takt-Flanken)> und ein setzten eines Anfangswertes des Zähler-signals
Das ist hier ja der Fall.
> Und (clk) meint hier das Taktnetzwerk und nicht irgendein beliebiges> kombinatorisches Signal wie Tastereingang.
Jeder beliebige Eingang und auch ein Tastereingang kann ohne weiteres
als Takt verwendet werden, warum nicht? Es ist halt ein ziemlich
schlechter Takt, mit dem alles Mögliche passieren kann. Aber sobald ein
'event im Code auftaucht, dann macht der Synthesizer ein Flipflop draus.
Nochmal: es steht völlig ausser Frage, dass ein Anfängerdesign genau 1
Takt hat und der von 1 Oszillator kommt, der an 1 Takteingang
angeschlossen ist. Alles Andere wird dem Anfänger dann irgendwann auf
den Kopf fallen. Aber genau so funktioniert Lernen. Ich habe meinen
Kindern immer gesagt: fass nicht an den Ofen, der ist heiß. Trotzdem
verbrannten sich alle die Finger. Aber sie haben dabei gelernt, wie sich
Hitze anfühlt.
Man kann übrigens mit so einem rising_edge() auf ein externes Signal
dann z.B. auch Vorgänge "zwischenspeichern", die kürzer sind als dass
man sie mit dem üblichen Oversampling per globalem Takt abtasten könnte:
http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html
Wer hier im Forum ein paar ganz klassische Anfängerfehler zum "Selber
nachmachen" finden will, der sucht einfach nach "Postulate":
https://www.mikrocontroller.net/search?query=Postulate&forums%5B%5D=9Lutz Locus schrieb:> weil Doppelminus ja grade bei VHDL eine kommentarzeile einleitet ..
Dagegen gibt es dann ja die [vhdl] Tags, die direkt über jeder
Texteingabebox beschrieben sind.
Lothar M. schrieb:> Aber sobald ein> 'event im Code auftaucht, dann macht der Synthesizer ein Flipflop draus.
Später im FPGA wird vermutlich sogar ein Clocknetz für das Signal
verwendet. Den Tools ist es herzlich egal, ob da ein zappeliger
Pushbutton als Taktoszillator verwendet wird. Die Implementierung des
Counters hat der TO also vollkommen korrekt gemacht.
vancouver schrieb:> Den Tools ist es herzlich egal, ob da ein zappeliger> Pushbutton als Taktoszillator verwendet wird.
Nein denen ist es nicht 'egal', die Tools (p&r) meckern schon an, wenn
da ein signal von anderer Quelle als BUFG (Globaler Treiber) aufs
taknetzwerk soll.
Der XST mecker dann von wegen combinatorial clock found o.ä.
https://support.xilinx.com/s/question/0D52E00006hpZnYSAU/warning-xst-2170-signal-forming-combinatorial-loop?language=en_US
Bei PLD's wie coolrunner mag es anders ausschauen.
> Die Implementierung des> Counters hat der TO also vollkommen korrekt gemacht.
Das er integer verwendet ist halbwegs gut, dagegen ist der Rest vom
counter offensichtlich für den Arsch. Kein CE, kein overun, kein reset,
kein range, ... . Sogesehen sind 25% gemacht, 25% sind falsch und 50%
fehlen. In einer HDL-prüfung wäre das durchgefallen.
Laientheater schrieb:> wenn> da ein signal von anderer Quelle als BUFG (Globaler Treiber) aufs> taknetzwerk soll.
Das ist nur dann ein Problem, wenn der Button an ein einem
nicht-clockfähigen Pin angeschlossen ist.
> Kein CE
Wozu, wenn der Counter durchlaufen soll? Wer soll den Counter denn
steuern in diesem Design?
> kein overun
Wozu, wenn den Überlauf niemanden interessiert? Wo soll diese
Information denn verwertet werden?
> kein reset,
Wozu, wenn der Counter einen Initialwert bekommt? Das ganze Design hat
halt einfach keinen Reset.
> kein range
Unschön, aber nicht falsch.
Ja, es ist keine Implementierung nach Lehrbuch, aber sie funktioniert
und damit ist sie korrekt.
vancouver schrieb:> Laientheater schrieb:>> wenn>> da ein signal von anderer Quelle als BUFG (Globaler Treiber) aufs>> taknetzwerk soll.>> Das ist nur dann ein Problem, wenn der Button an ein einem> nicht-clockfähigen Pin angeschlossen ist.
Und genau das wird der Fall sein, weil, wie oben genannt, der Taster
entprellt werden muß. Und diese Entprellung im selben Device vorgesehen
ist. Es ist nicht davon auszegehen, das der TO eine sichere analoge
Entprellung (RC-Tiefpass) auf seiner Hardware vorgesehen hat.
>> Kein CE> Wozu, wenn der Counter durchlaufen soll? Wer soll den Counter denn> steuern in diesem Design?
TO-beitrag nicht gelesen?! Der Counter soll nicht durchlaufen, der soll
Tasterbetätigungen zählen!
>> kein overun> Wozu, wenn den Überlauf niemanden interessiert? Wo soll diese> Information denn verwertet werden?
Bei der Ansteuerung des 8 bit breiten led-vectors beispielsweise. Das
fällt dir das erste Mal auf die Füße, wenn die 8 erreicht wird, weil es
keinen Index (8) gibt. Und dann wieder am oberen Ende vom Integer. Das
der TO das Verhalten ab Druck 8+1 nicht in seiner "Spec."beschrieben
hat, ist keine Entschuldigung diesen typischen Counter-Corner-Case zu
behandeln.
>> kein reset,> Wozu, wenn der Counter einen Initialwert bekommt? Das ganze Design hat> halt einfach keinen Reset.
Der TO fordert aber was anderes, die led(0) soll als erstes leuchten.
Und man stelle sich so einen zufälligen Startwert mal in Echt vor:
"Feueralarm, die Firewall fällt in 10 Sekunden, Count down beginnt: 2,
1, Klappe zu" ;-)
>> kein range> Unschön, aber nicht falsch.
Ja, sagte sich die Entwickler der Ariane-5 Software auch ... bis dann
krachte: https://de.wikipedia.org/wiki/Ariane_V88#Fehlerursachen Und in
einem PLD nacht es schon einen Unterschied ob man 3 oder 32 FF (von 64
verfügbaren) verbrennt.
Auch 'freut' sich modelsim das es beim Test die corner cases schnell und
rechtzeitig erreicht um den den User mit "fatal error: range overflow"
aus dem Büroschlaf zu wecken.
> Ja, es ist keine Implementierung nach Lehrbuch, aber sie funktioniert> und damit ist sie korrekt.
Naja, also ich lege "Korrektheit" eher nach dem Massstäben des
britischen Protokolls oder der des höheren Staatsbeamtentums aus.
Dannach ist die vorgelegte Formalie bestenfalls als "schlampig" und
"unvollständig in der Ausführung". Und für einen Zähler im Grunde
"dysfunktional", das ist ein binärer incrementer, da fehlt noch einiges
zum Zählwerk. https://de.wikipedia.org/wiki/Z%C3%A4hlwerk
Laientheater schrieb:> Ja, sagte sich die Entwickler der Ariane-5 Software auch
Klar, dass das kommen muss. Wird immer wieder als Beispiel für
Software-Fehler gebracht, obwohl's hier definitiv keiner war.
Die Software war korrekt entsprechend der Spezifikation, sie passte
lediglich (aufgrund der Tatsache, dass die eben falsch war) nicht zur
Rakete.
Markus F. schrieb:> Laientheater schrieb:>> Ja, sagte sich die Entwickler der Ariane-5 Software auch>> Klar, dass das kommen muss. Wird immer wieder als Beispiel für> Software-Fehler gebracht, obwohl's hier definitiv keiner war.
Ein/mehrere Softwerker hat ein (potentielles) Problem mit der Software
nicht adequat behandelt, das ist erst mal Fakt.
Ob sie dafür verantwortlich sind, oder das systemengineering oder das
Configurationsmanagment oder die Testabteilung ist erst mal
nebensächlich. Bei der Ursprungsversion hatte der Programmer wenigstens
bewiesen, das er sich nicht um den Wertebereichsüberschreitung kümmern
muss. Und die späteren Programmer haben den Code einfach unverändert
gelassen, obwohl sich der physikalisch mögliche Wertebereich änderte.
Das mindeste wäre gewesen, diesem Missmatch zw. Software und
Anwendungsszenario weiter zu kommunizieren.
Bei dem Zählwerk wie der TO es programmiert hat, dagegen wird es
zusammen mit der Index des LED-Vektors zum Problem, modelsim steigt beim
aktivierten range-check aus. in der software wäre das wohl ein "pointer
Overrun". und um die Folgen eines solchen weglaufenden pointers nicht
behandeln zu müssen, setzt man einen Range. Also setzt man einen range,
weglassen desselben "spart" höchstens Sekunden in der Codeerstellung.
Wurde schon vor jahren diskutiert:
Beitrag "Re: Wie wendet man "range" in VHDL an?"
Laientheater schrieb:> Und genau das wird der Fall sein, weil, wie oben genannt, der Taster> entprellt werden muß. Und diese Entprellung im selben Device vorgesehen> ist.
Der TO hat deutlich gesagt, dass er das Problem der Entprellung zunächst
ignorieren möchte:
Erik schrieb:> Bouncing soll erst mal keine Rolle> spielenLaientheater schrieb:> Der Counter soll nicht durchlaufen, der soll> Tasterbetätigungen zählen!
Und er soll jede Tasterbetätigung zählen, wozu ist also dann ein
Clock-Enable gut?
Laientheater schrieb:> fällt dir das erste Mal auf die Füße, wenn die 8 erreicht wird, weil es> keinen Index (8) gibt
Das ist richtig, in diesem Fall bleiben alle LEDs aus. Es wäre sinnvoll,
das im Zähler abzufangen, aber man könnte die LEDs auch mittels (counter
mod 8) addressieren. Oder man könnte sagen, es reicht für diesen Test,
wenn die Kette einmal durchlaufen wird.
Laientheater schrieb:> Der TO fordert aber was anderes, die led(0) soll als erstes leuchten.
Das tut sie ja auch, weil der Counter mit 0 initialisiert wird.
Laientheater schrieb:> Und man stelle sich so einen zufälligen Startwert mal in Echt vor:
Der Startwert des Counter ist nicht zufällig, er ist 0. Zeile 14. Da der
Counter ein Register ist, funktioniert der Initialisierungswert an
dieser Stelle korrekt.
Das Thema ist irgendwie langsam augelutscht. Nein, der Counter ist nicht
ideal beschrieben, man kann vieles besser machen, was der TO als
Anfänger nicht weiß und was in seinem Testdesign auch erstmal keine
Rolle spielt.
Wenn du dein erstes Modellflugzeug baust, bist du froh, wenn das Teil
überhaupt abhebt, und es interessiert dich nicht, dass die
Schlechtwetter-Kunstflugeigenschaften erstmal noch miserabel sind. Dann
fängst du an, in unendlich vielen Iterationen das Design verbessern und
zu schauen, was geht und was nicht. Das nennt sich Lernen und es dauert
üblicherweise eine ganze Weile.
Der Counter wird mit 0 initialisiert und zählt anschließend jede
steigende Signalflanke vom prellenden Button. Mehr wollte der TO erstmal
nicht. Mission accomplished.
vancouver schrieb:> Das Thema ist irgendwie langsam augelutscht. Nein, der Counter ist nicht> ideal beschrieben, man kann vieles besser machen, was der TO als> Anfänger nicht weiß und was in seinem Testdesign auch erstmal keine> Rolle spielt.
Da haben wir entgegengesetzte Qualitätsansprüche.
Was der TO hier als counter vorlegt ist schlampig, funktioniert mehr
schlecht als recht. Ein gute Lehrmeister lässt das nicht durchgehen.
Wenn Du ein schlechter lehrmeister sein willst, dein Problem!
vancouver schrieb:> Das Thema ist irgendwie langsam augelutscht. Nein, der Counter ist nicht> ideal beschrieben, man kann vieles besser machen, was der TO als> Anfänger nicht weiß und was in seinem Testdesign auch erstmal keine> Rolle spielt.>> Der Counter wird mit 0 initialisiert und zählt anschließend jede> steigende Signalflanke vom prellenden Button. Mehr wollte der TO erstmal> nicht. Mission accomplished.
Sehe ich auch so. Die Gedankengänge waren grundsätzlich richtig und auch
erfahrene VHDL-Entwickler haben die Beschreibung als logisch richtig
angesehen. Dass Xilinx und ModelSim es wie angenommen umsetzen, zeigt ja
auch, dass es nicht komplett falsch gewesen sein kann.
Ob die Umsetzung in Quartus ein Bug oder nur ein Fallstrick ist, braucht
man, glaube ich, gerade im Anfängerkontext, nicht zu diskutieren.
Wir wissen jetzt, dass das Konstrukt unterschiedlich interpretiert wird
und dass man aufpassen muss.
Auch wenn es nicht beabsichtigt war, finde ich es gut, mal in die
Grenzbereiche des Standards vorzudringen (natürlich nicht im produktiven
Einsatz), um mal die Erfahrung zu machen, was da passiert.
Dussel schrieb:> Wir wissen jetzt, dass ... man aufpassen muss.
Die Quintessenz des Ganzen ist eigentlich sowas:
----
Wenn in irgendeinem Report eines Anfängerdesigns irgendwas von "Latch"
auftaucht, dann ist noch ein Fehler drin.
Laientheater schrieb:> Wenn Du ein schlechter lehrmeister sein willst, dein Problem!
Naja, da gibts ja verschiedene Ansätze. Manche ziehen einen
Lehrbuch-Zähler aus dem Regal und sagen seht her, so wird's gemacht,
punkt. Und so machen es die Leute dann auch, weil sie sonst in der
Prüfung Punkteabzug bekommen. Bis zu dem Tag, wenn mal spezielle
Anforderungen abseits des Mainstreams kommen und dann das tiefere
Verständnis fehlt. Das heißt es "des hatten mer ned in der
Berufsschule".
Ich lasse die Leute lieber experimentieren und auf Probleme stoßen, die
sie dann lösen müssen, wodurch sie einsehen, warum man es manchmal
besser so und manchmal besser andersherum macht. Die Initalwerte sind
doch das beste Beispiel. Selbst von uns hatte niemand auf dem Schirm,
wie problematisch die sein können und was die Tools für einen Unsinn
daraus basteln. Hätte der TO gleich die Retortenlösung verwendet, wäre
diese Diskussion nie aufgekommen. (Dass der TO aufgrund des Umgangstons
hier die Veranstaltung vorzeitig verlassen hat, ist eine anderes Thema,
aber vielleicht liest er ja noch mit.)
Das erinnert mich machmal an die Geschichte von C.F. Gauss, der in einer
Mathematikschulaufgabe die Zahlen zwischen 1 und 100 addieren sollte und
ihm dazu sein geniales Verfahren einfiel, mit dem er die Aufgabe in 10
Sekunden lösen konnte. Trotzdem bekam er eine 6, weil der Lehrer auf die
Holzhammermethode bestand.
Das ist hier genauso. Entweder du machst es so, wie ich es dir sage,
oder es ist falsch. Ob das ein guter Ansatz ist... naja, darüber kannst
du (und einige andere) ja nochmal nachdenken.
vancouver schrieb:> Trotzdem bekam er eine 6, weil der Lehrer auf die> Holzhammermethode bestand.
Gibt es dafür eine Quelle? Das hört sich nach dem Original anders an:
https://books.google.de/books?id=h_Q5AAAAcAAJ&pg=PA13#v=onepage&q&f=false
Aber grundsätzlich ist die Aussage schon richtig und solches Verhalten
gibt es tatsächlich an Hochschulen und Universitäten.
Dussel schrieb:> Gibt es dafür eine Quelle?
Ja, meinen ehemaligen Mathematiklehrer :-) Der hat es uns so erzählt,
aber nachgelesen habe ich das natürlich nicht.
Sollte jemand Lust haben, sich über den Button-Entpreller, den ich
persönlich für richtig halte (ganz einfach, weil's meiner ist), das Maul
zu zerreissen, der ist hier:
https://github.com/mfro0/button_debouncer
Das Repository enthält einen Test (der auf dem DECA-Board mit den beiden
Tasten ein Lichtlein hin- und herschieben kann) und einen
konfigurierbaren Key-repeat.
Nö, reset ist keiner drin (braucht's nicht). Dafür viele Inits.
Lothar M. schrieb:> Wenn in irgendeinem Report eines Anfängerdesigns
Nebenbedingung:
VHDL-Anfänger = 1 Jahr ab Lernbeginn. Ausnahmen bestätigen die Regel.
Markus F. schrieb:> das Maul zu zerreissen
Ich würde da einen Prescaler für den Takt vorsehen, denn wenn du den
Takt auf jedes instantiiterte Komponente gibst, dann müssen die 100MHz
jedesmal komplett heruntergeteilt und verglichen werden. Das braucht
m.E. unnötig Ressourcen.
Mir gefällt da der MAX6816 ganz gut:
http://www.lothar-miller.de/s9y/categories/5-Entprellung
Laut dessen Datenblatt wird eine Zeit von 20..80 ms auf die 64
Zählschritte verwendet. Der Oszillator da drin arbeitet also mit
800...3200 Hz. Da ist ein Prescaler auf 1 ms Zykluszeit sicher nicht
völlig falsch.
Lothar M. schrieb:> Ich würde da einen Prescaler für den Takt vorsehen, denn wenn du den> Takt auf jedes instantiiterte Komponente gibst, dann müssen die 100MHz> jedesmal komplett heruntergeteilt und verglichen werden. Das braucht> m.E. unnötig Ressourcen.
Wie Du vielleicht gesehen hast, wird (aus dem Grund) im Key-Repeat
tatsächlich nur eine (konfigurierbare) Anzahl höherwertiger Bits
verglichen (allerdings laufen die Zähler auch dort mit der gesamten
Breite). In einem "echten" Design würde ich einen separaten (PLL-) Takt
dafür vorsehen, aber dann wäre das Beispiel nicht mehr portabel.
Dussel schrieb:> Auch wenn es nicht beabsichtigt war, finde ich es gut, mal in die> Grenzbereiche des Standards vorzudringen (natürlich nicht im produktiven> Einsatz), um mal die Erfahrung zu machen, was da passiert.
Eben das ist meines Erachtens ein böser Trugschluss, das es bei der
Synthese irgendetwas wie einen Standard gäbe. Und das das derselbe wäre
wie bei modelsim. Und das man da einen Grenzbereich ausloten dürfte. Man
überlegt sich vorher, was (Digitaltechnik) man will und tippt dann den
HDL Code den das Synthesetool für diese erwartet.
Und gerade bei der Schaltungstechnik sehe ich dir größten Lücken bei den
Neuänfanger. Wobei Schaltungstechnik eben nicht Transistorlevel
bedeudet, sondern lediglich 'complexgatter' wie ADDER, MUXER, SRCEFF,
FIFO, FSM, Addressdecoder, synchroncounter.
Als Indiz für das Schaltungstechnische Banausentum des TO kann gelten,
das er bis heute nicht das Board genannt hat mit er seine Hardweare
testet. Und er nur blind im Code herumstochert statt zielgerichtet zu
debuggen. Da passt der Kommentar "Muh, Muh,. blinde Kuh . . ." zu 100%.
Ich habe den Eindruck, das viele Anfänger ihrer Wissenslücken bzgl.
Schaltungstechnik versuchen durch HDL-Syntax-Künste zu Kompensieren. Und
das resultiert da in solchen lückenhaften Scheiss wie nichtinitialiserte
kombinatorisch gewurschtelte Latches.
Aber das meine Meinung, kultiviert Eure Eigene.
vancouver schrieb:> Dussel schrieb:>> Gibt es dafür eine Quelle?>> Ja, meinen ehemaligen Mathematiklehrer :-) Der hat es uns so erzählt,> aber nachgelesen habe ich das natürlich nicht.
Klar, wieder den Falschen seine Geschichte geglaubt. Und wer weiß, ob
nicht der Sechser bei gauß die beste Note war (wie inner Schweiz). Wird
beim Einstein auch gerne falsch verstanden, damit der Abstand zwischen
der eigenen Geisteskraft und der des Genies nicht so verheerend groß
ausschaut.
----
> Wenn in irgendeinem Report eines Anfängerdesigns irgendwas von "Latch"> auftaucht, dann ist noch ein Fehler drin.
Eben. und da von 'korrekten Code' zu reden zeugt vom tiefgreifenden
Unverständnis bzgl der Notwendigkeit vom synchronen Schaltungs-Design,
oder dem Nachteil eines Latches gegenüber einem (flankengesteuerten) FF.
Zusammenfassend habe zumindest ich aus diesem Thread wieder was
gelernt. Auch wenn mir das Problem hinterher schon vorher klar war...
;-)
Laientheater schrieb:> Und wer weiß, ob nicht der Sechser bei gauß die beste Note war
Gauß hat da gar keine Note bekommen, sondern der Lehrer erkannte, dass
dieser Schüler bei ihm nichts mehr lernen konnte:
https://de.wikipedia.org/wiki/Gaußsche_Summenformel
Laientheater schrieb:> Und gerade bei der Schaltungstechnik sehe ich dir größten Lücken bei den> Neuänfanger.
So eine Überraschung.
Lothar M. schrieb:> Zusammenfassend habe zumindest ich aus diesem Thread wieder was> gelernt.
Full ack. Gut, dass wir mal drüber geredet haben.
> Auch wenn mir das Problem hinterher schon vorher klar war...> ;-)
Bist du nebenberuflich Astrologe? :-)
Lothar M. schrieb:> Zusammenfassend habe zumindest ich aus diesem Thread wieder was> gelernt. Auch wenn mir das Problem hinterher schon vorher klar war...> ;-)
Und ich habe gelernt zu welchen hanebüchenen Blödsinn die pauschalierte
Aussage "Reset ist unnötig" geführt hat. So ein Geschlampe hatte ich
nicht erwartet, da wird wild in den Initdaten der Simulation
herumgepfuscht und das dann zwangsläufige von der Realität abweichende
Simulationsergebniss mit "Compilerbugs" und "mangelhaften intel IC"
abgetan. Nein, wer Scheisse codiert, bekommt Scheiss-ergebnisse.
Also nochmals Urschleim:
Es ist nötig alle Speicherelemente auf einen definierten Anfangswert zu
bringen. Dafür gibt es verschiedene Zeitpunkte und verschiedene
Möglichkeiten. Betrachten wir mal C. Da gibt es die Möglichkeit, die
variable bei der dekleration zu initialisieren oder bei der ersten
Verwendung.
Bei der Dekleartion bedeutet, das der loader, der das kompilierte
Programm (data- wie code-segment) in den RAM zur Ausführung schreibt,
auch den Datenbereich im RAM für die Variablen beschreibt und die
Initwerte dort reinschreibt. Im zweiten Fall, wenn der Startwert bei der
ersten Verwendung im Programm geschrieben wird, führt diese Zuweisung
dagegen nicht der Loader sondern das Programm selbst aus. Es gibt also
zwei Zeitpunkte für einen möglichen Init einer C-Variable, whrend der
runtime und davor. Der Nachteil der ersten Variante ist, das es nur
einmal beim Laden des Programms ausgeführt wird und während der
Laufzeit/runtime auf diese Weise nicht mehr möglich ist.
Ahnlich kann man das jetzt bei Digitallogic sehen. Prinzipiell kann man
einen Speicher vor oder während der 'Runtime' auf seinen Startwert
setzen. Runtime bedeudet hier, das der Takt im design anliegt, also bei
der Konfiguration.
Will man also während der Laufzeit wieder auf (start zurück) geht das
nicht anders als durch einen kompletten Neustart. Das ist je nach
Anforderungen kein oder im gegenteil ein sogar grosse Problem. Ein
grosses Problem ist es wegen der Dauer des FPGA-Startes(Bootphase bspw.
Zynq) und das alle FPGA-Pins wieder irgendwelche Anfangszustände
durchfahren müssen, was zu neuen Verzögerungen führt. Bei
Flugueugelektronik mag das in etwa bedeuten, das die Steuerflächen auf
Startkonfiguration gehen und die Triebwerke neu zünden ...
Die zweite Möglichkeit, während der "Runtime", ist bei der
Digitaltechnik das Resetnetzwerk. Das hat den Vorteil, das die
Schaltungsteile schnell (innerhalb eines Taktes) in einen definierten
Zustand überführt werden.
Der Nachteil eines Resetnetzwerkes zeigt sich
erst an großen designs, bei denen das Resetnetzwerk schon so 'lang'
werden könnte, das es die maximale erreichbare taktfrequenz herabsetzt.
Nach meiner Erfahrung, zeigte sich das erst bei Spartan-3 Designs auf
einem -100 0 FPGA, dessen Logik zu 95% ausgelastet wird und dessen
timingconstraint von 133 MHz dan nur schwerlich erreichbar war.
Um grosse Resetnetzwerke beherrschbar zu machen, schlug dann Xilinx
einige Massnahmen zur Verkleinerung - aber nicht zur Abschaffung
desselben - vor. Erstens, nur die FF zu reseten die es wirklich brauchen
(bspw. FSM). Keinen Reset brauchen meist schieberegister,
DSP-Zwischenstufen etc.. Also Hardware wo man ohnehin einige Takte,
Totzeiten(Latenz) wartet bis gültige Daten anliegen und die ungültigen
Daten werden für die ersten takte ignoriert, "weg-geshifted).
Zweitens wurde darauf verwiesen, das FF nach der FPGA-Konfiguraion einen
definierten und (bei Xilinx) aus '0' und '1' frei wählbaren
Anfangzustand haben. Dieser FF-Anfangszustand kann an mehrern Stellen
vom Designer vorgegeben werden, bspw mit constraints, im FPGA-Editor
(ISE, in Vivado heisst es wohl Chiepview o.ä.), oder auch in der
Signal-declaration. Natürlich wurde hingewiesen, das das ganz in der
Verantwortung des Designers liegt und der hat bspw. durch
(Post-PAR)-Simulation oder HIL-tests machzuweisen, das es immer noch so
tut.
Es ist keine Aufforderungen das globale Reset-Netzwerk immer und
komplett wegzulassen. Deshalb titelt das dokument auch "think smart" und
nicht "Ignore": https://docs.xilinx.com/v/u/en-US/wp272
Und weil es sehr gern von mittelmäßigen und schlechten Designer
überlesen wird. Dort steht immer von den Schwierigkeiten eines
"globalen" Resetnetzwerkes (an alle FF). Ein oder mehrer lokale (kleine)
Resetnetzwerke sind dagegen kein Problem für P&R. Und hier wäre es eben
der counter und die led-treiber-FF die einen reset nötig haben. Deshalb
muss jeder Designer lernen wie man den Code für ein reset-Netzwerk
schreibt.
##
Anbei ein Ausschnitt aus der auch als gedrucktes Buch erhältlichen:
https://tams-www.informatik.uni-hamburg.de/vhdl/doc/kurzanleitung/vhdl.pdf
Zusammenfassung dieser Vorlesung: Nimm das, was am besten zu deinem
Problem passt und mach es richtig. Wenn dein Design keinen Reset
braucht, dann lass ihn weg.
Schöne Feiertage, gehabet euch wohl!
vancouver schrieb:> Zusammenfassung dieser Vorlesung: Nimm das, was am besten zu deinem> Problem passt und mach es richtig. Wenn dein Design keinen Reset> braucht, dann lass ihn weg.
Das wäre eine Irrlehre, jedes design braucht definierten Startwerte.
Falls
es tatsächlich keine braucht, bekommt es trotzdem welche, weil sonst ist
es nicht testbar (test = definierter Zustand zum zeitpunkt t=0)
>Schöne Feiertage, gehabet euch wohl!
Verbreite keinen Unsinn und lies mal ein Lehrbuch über die freien tage!
Lutz Locus schrieb:> Und ich habe gelernt zu welchen hanebüchenen Blödsinn die pauschalierte> Aussage "Reset ist unnötig" geführt hat.
Wer hat gesagt, "Reset ist unnötig"?
Es gibt Situationen, da ist er tatsächlich unnötig und es gibt welche,
da ist er das nicht (aber das hast Du ja selbst schon geschrieben).
Deine Litanei geht aber leider haarscharf am Problem vorbei. Das Problem
des TO's war kein fehlender Reset. Sein Problem war, dass er ein Latch
gebaut hat. Und das Altera-Latch lässt sich nun mal nicht initialisieren
- weder mit noch ohne Reset.
Dass er ein Latch gebaut hat, war wiederum darauf zurückzuführen, dass
sein Design keinen Takt hat. Und das hat er nicht gemacht, weil jemand
"Jehova" (Reset ist unnötig) geschrien hätte, sondern weil er's nicht
besser wusste.
Jetzt weiss er's (wahrscheinlich).
Hätte er von Anfang an sein Design mit getakteten FFs aufgebaut, wäre
(für diese Anwendung) Reset und Initialisierung funktional gleichwertig
gewesen (mit dem Unterschied, dass der Reset mehr Ressourcen verbraucht
hätte).
Lutz Locus schrieb:> die pauschalierte Aussage "Reset ist unnötig"
Ich sehe hier keinen, der irgendwie "pauschal" sagt, dass Resets
generell unnötig sind. Allerdings bist du der, der ausdauernd
pauschaliert, dass immer ein Reset nötig ist. Das Eine ("Reset ist
völlig unnötig") ist mindestens genauso falsch wie das Andere ("Reset
ist zwingend nötig").
Tatsache ist, dass jedes FPGA mit RAM-Konfigzellen (und das sind von den
Actel/Microsemi abgesehen eigentlich alle) beim Start mit einer
Konfiguration aus einem Flash geladen wird. Und bei diesem Vorgang kann
auch ein Initialwert in die Fipflops geladen werden ODER es kann ein
Inverter vor den Reset-Eingang konfiguriert werden. In beiden Fällen
läuft das FPGA nach dem Verlassen der Bootphase jedes Mal mit den selben
Werten an.
Wenn man es genau wissen will, dann macht man es wie bei jedem
elektronischen Baustein: man liest das Datenblatt.
Lothar M. schrieb:> Das Eine ("Reset ist> völlig unnötig") ist mindestens genauso falsch wie das Andere ("Reset> ist zwingend nötig").
Nein! In deterministischen System ist die Schaffung eines defininierten
Ausgangszustandes immer zwingend nötig!
Alles andere führt zu Zufallsgeneratoren und anderem Chaos.
Markus F. schrieb:> Deine Litanei geht aber leider haarscharf am Problem vorbei. Das Problem> des TO's war kein fehlender Reset. Sein Problem war, dass er ein Latch> gebaut hat. Und das Altera-Latch lässt sich nun mal nicht initialisieren> - weder mit noch ohne Reset.
Und was ist die Ursache für das Latch?
Komm recherchier mal bevor du hier wieder freidrehende Theoriefindung
verkündest.
Welche 'Fehler' muss eine HDL-Beschreibung enthalten das das
Synthese-tool ein Latch statt ein FF baut? Und könnte das vielleicht
damit zu tun haben, das der TO das Verhalten und insbesonders die State
transitions nicht vollständig beschrieben hat?
Was sollte also beschreibungstechnisch ergänzt werden das aus dem latch
ein FF wird ???
Markus F. schrieb:> Jetzt weiss er's (wahrscheinlich).
Nö, wahrscheinlich nicht, weil nachdem ihm der Tipp gegeben wurde, es
mal nach Lehrbuch mit clk und rst zu beschreibenhat er sich unter
Gemecker wegen "Umgangston" verabschieden. Weil, weitere Mitarbeit des
TO wäre "Öl im feuer". So eine pussy.
> Hätte er von Anfang an sein Design mit getakteten FFs aufgebaut, wäre> (für diese Anwendung) Reset und Initialisierung funktional gleichwertig> gewesen
Ja er hätte eine wichtige Lektion im Digitalendesign gelernt, das
Ressourcen für den synchronen reset im FPGA schon vorhanden sind. Und
das "Unbenutzt" nicht wirklich das selber wie "verbraucht" sind. Und
vielleicht hätte er ja auch mal weiter in die Möglichkeiten des Designs
mit FF geforscht und hätte entdeckt wie man mit der passenden
reset-beschreibung sein design auf 50% verkleinert:
https://docs.xilinx.com/v/u/en-US/wp275
(mit dem Unterschied, dass der Reset mehr Ressourcen verbraucht
hätte).
Zwei Beispiele im Anhang, mit Reset kleiner und schneller, ohne reset
größer und langsamer.
Alter, ihr seid solche Amateure, SCNR.
Laientheater schrieb:> und hätte entdeckt wie man mit der passenden reset-beschreibung sein> design auf 50% verkleinert: https://docs.xilinx.com/v/u/en-US/wp275
Man sollte Appnotes eines Herstellers nicht verallgemeinern. Dieses WP
passt genauso wie das WP272 eben nur auf die (Xilinx-)FPGAs, die das
können, weil sie solche konfigurierbare Flipflops in den Logikblöcken
haben: https://docs.xilinx.com/v/u/en-US/wp272> Zwei Beispiele im Anhang, mit Reset kleiner und schneller, ohne reset> größer und langsamer.
Selektive Wahrnehmung? Da ist nur dargestellt, dass man ein Flipflop,
das einen synchronen(!!) Reset-Eingang hat, einfacher zurücksetzen kann
als eines, das einen solchen Eingang nicht hat.
> Alter, ihr seid solche Amateure, SCNR.
Völlig kindisch und niveaulos, mit solchen billigen persönlichen
Attacken daherzukommen.
Schöne Feiertage noch.
Anscheinend gibt's so was wie Schreib-Tourette.
Laientheater schrieb:> Zwei Beispiele im Anhang, mit Reset kleiner und schneller, ohne reset> größer und langsamer.
Aha. Und die Reset-Beschaltung fällt vom Himmel? Und "mit Reset" ist
schneller, weil das Signal zwischen den beiden LUTs im Bildchen keine
Schnörkel hat?
Laientheater schrieb:> Und was ist die Ursache für das Latch?
Ein nicht vorhandener Reset? Du machst dich lächerlich.
Laientheater schrieb:> Ja er hätte eine wichtige Lektion im Digitalendesign gelernt, das> Ressourcen für den synchronen reset im FPGA schon vorhanden sind.
Auch das ist falsch. Der TO benutzt Quartus, hat also offensichtlich ein
Intel/Altera FPGA. Und die haben keinen synchronen Reset, den muss man
sich da erst bauen.
Lothar M. schrieb:> Laientheater schrieb:>> und hätte entdeckt wie man mit der passenden reset-beschreibung sein>> design auf 50% verkleinert: https://docs.xilinx.com/v/u/en-US/wp275> Man sollte Appnotes eines Herstellers nicht verallgemeinern. Dieses WP> passt genauso wie das WP272 eben nur auf die (Xilinx-)FPGAs, die das> können.
Nö, die Auswahl zwischen FF mit/Ohne D/CE/S/R/PRE/CLR hat man auch bei
anderen Herstellern, bspw. Stratix von Altera. Und damit kann man die
Aussage das man gegenüber einem D-FF das zwei LUT für die complette
Truth-Table benötigt auch eins mit Set/reset Eingängen mit nur einer LUT
benutzen kann. Also auch Altera.
>> Zwei Beispiele im Anhang, mit Reset kleiner und schneller, ohne reset>> größer und langsamer.> Selektive Wahrnehmung? Da ist nur dargestellt, dass man ein Flipflop,> das einen synchronen(!!) Reset-Eingang hat, einfacher zurücksetzen kann> als eines, das einen solchen Eingang nicht hat.
Ja, eben, Reset keine verschwendende Ressource wie behauptet.
>> Alter, ihr seid solche Amateure, SCNR.> Völlig kindisch und niveaulos, mit solchen billigen persönlichen> Attacken daherzukommen.
Klar doch , alles was gegenteiliger Aussage ist, muß in den Augen eines
selbstgefälligen Moderators, egal wie gründlich recherchiert und belegt,
"Billig und niveaulos sein.
Na viel Spass noch in Deiner Kindergartenblase.
Laientheater schrieb:> Nein! In deterministischen System ist die Schaffung eines defininierten> Ausgangszustandes immer zwingend nötig!
Was für ein kompletter Unsinn. Beipiel: Das Addressregister für den
Datenbus in einem RISC-V-Prozessor wird nicht resettet und ist deswegen
am Anfang undefiniert. Das hat nicht den geringsten Effekt, weil es erst
von einer Instruction geladen wird, bevor es benutzt wird. Vorher ist
der Zustand völlig egal. Ein großer Teil der Register im RISC-V ist
uninitialisiert und wird erst im Laufe des Betriebs geladen. Das
reduziert den Fanout auf dem Reset-Netz drastisch. Das spart
Routingressourcen und Buffer. Das verhindert einen gewaltigen Peak in
der Switching-Activity nach dem Einschalten, den du dir bei
Ultra-Lowpowersystemen nicht leisten kannst. Letzeres spielt nur bei
AISCs eine Rolle, aber die Welt hört nun mal nicht mit den FPGAs auf.
> Alles andere führt zu Zufallsgeneratoren und anderem Chaos.
Nein, es führt zu einem effizienten Design. Jedes Register zu
initialisieren ist wie ein in Wagenfarbe lackierter Auspufftopf: Teuer
und nutzlos.
Hattest du mir empfohlen, ein Fachbuch zu lesen? Das gebe ich gerne
zurück. Kleiner Tip: "VHDL kompakt" ist noch nicht das Ende der
Fahnenstange, es gibt da noch, wie heißt es so schön, weiterführende
Literatur.
> Laientheater schrieb:>> Zwei Beispiele im Anhang, mit Reset kleiner und schneller, ohne reset>> größer und langsamer.>> Aha. Und die Reset-Beschaltung fällt vom Himmel?
Natürlich muss man dafür seinen HDL source ordentlich schreiben und
nicht so schlampig wie der TO. Der Mehraufwand für die 3 Zeilen
zusätzlichen Code sollte nicht wesentlich sein.
> Und "mit Reset" ist> schneller, weil das Signal zwischen den beiden LUTs im Bildchen keine> Schnörkel hat?
Die Anzahl der LUT's bestimmt in der matrixstruktur eines FPGA direkt
das delay zwischen Q und D und damit die taktfrequenz. Ein LUT 2 ns
delay, zwei LUT 4 ns, ... Alter, wer lässt hier Leute ohne
Grundlagenkenntnisse der TimingAnalyse an FPGA's Und für
Begriffsstutzige steht neben den Bildchen auch erläuternder Text.
> Laientheater schrieb:>> Und was ist die Ursache für das Latch?>> Ein nicht vorhandener Reset? Du machst dich lächerlich.
Und du rechchierst nicht und benutzt deinen Kopf nicht zum denken über
Digitaltechnik. Naja ist der Ruf erst ruibiert, plärrt es sich ganz
ungeniert.
> Laientheater schrieb:>> Ja er hätte eine wichtige Lektion im Digitalendesign gelernt, das>> Ressourcen für den synchronen reset im FPGA schon vorhanden sind.>> Auch das ist falsch. Der TO benutzt Quartus, hat also offensichtlich ein> Intel/Altera FPGA.
So ,so aus welchen der vier Beiträge des TO schliesst du, das er Quartus
benutzt? Das nennt er nirgends. Auch aus seinem Quelltext nicht zu
erkennen, das er jemals was von Resetbeschreibung egal für welche
Toolchain gehört oder gelehrt bekommen hat.
vancouver schrieb:>> Alles andere führt zu Zufallsgeneratoren und anderem Chaos.>> Nein, es führt zu einem effizienten Design. Jedes Register zu> initialisieren ist wie ein in Wagenfarbe lackierter Auspufftopf: Teuer> und nutzlos.
Mumpitz, Initialisieren ist nötig. Bei PGP(?) gabs eine
Sicherheitslücke die auf zuviel Initialisierung zurück zu führen war,
dort wurde gerade von nichtinitialisierten Speicher gelesen um ein
random seed für die key-gerierung zu erzeugen. Aber das war es auch
schon.
> Hattest du mir empfohlen, ein Fachbuch zu lesen? Das gebe ich gerne> zurück. Kleiner Tip: "VHDL kompakt" ist noch nicht das Ende der> Fahnenstange, es gibt da noch, wie heißt es so schön, weiterführende> Literatur.
Ich schick dir kein Foto von meinem Regal mit ca. 100 Stück
fachliteratur. OK FPGA macht da nur 20% aus. VHDL-Kompakt war wohl
Nummer 7 aus der FPGA-Ecke, Kaufargument die detailierte beschreibung
von "null" und anderen Tricks bei der Signaltreiber simulation . Diverse
Xilinx-Handbücher stehen da auch, endet aber vor ca 15 Jahren, weil dann
Xilinx nichts mehr druckte. Ebensoxcell-magazine. Dazu
Schulungsunterlagen von Ken Chapman bis R&S.
Nein, ich glaube nicht das du in deiner Einfalt mir irgendwelche
weiterführende Literatur nennen kannst. Bleib mal lieber bei deinen
Auspufftöpfen.
vancouver schrieb:> Laientheater schrieb:>> Nein! In deterministischen System ist die Schaffung eines defininierten>> Ausgangszustandes immer zwingend nötig!>> Was für ein kompletter Unsinn. Beipiel: Das Addressregister für den> Datenbus in einem RISC-V-Prozessor wird nicht resettet und ist deswegen> am Anfang undefiniert. Das hat nicht den geringsten Effekt, weil es erst> von einer Instruction geladen wird, bevor es benutzt wird. Vorher ist> der Zustand völlig egal. Ein großer Teil der Register im RISC-V ist> uninitialisiert und wird erst im Laufe des Betriebs geladen. Das> reduziert den Fanout auf dem Reset-Netz drastisch.
Und, an der spannenden Stelle mit eigenem Denken aufgehört?
Also oben beginnste mit "reset ist unnötig" und weiter unten ist dann
plötzlich von einem vorhandenen Reset-Netz die rede. Reduziert, aber
eben nicht Null.
Und das was du da am RISC-V beschreibst ist kalter Kaffee, das machte
schon der Z80 vor knapp 50 Jahren so:
http://www.primrosebank.net/computers/z80/z80_special_reset.htm
Ohne definierte Startbedingung gehts halt nicht determiniert. Wird auch
gern zur Erhöhung der Zuverlässigkeit genutzt (strukturelle redundanz).
Wenn da einer von de 2n+1 (n>1) identischen Computern andere Werte
ausspuckt ist feierabend für diesen.
Laientheater schrieb:> oben beginnste mit "reset ist unnötig"
Nein, du beginnst mit "Schaffung eines defininierten
Ausgangszustandes immer zwingend nötig!" und ich habe dir anhand eines
aktuellen Designs gezeigt, dass das Unsinn ist und auch nicht gemacht
wird.
> Und das was du da am RISC-V beschreibst ist kalter Kaffee, das machte> schon der Z80 vor knapp 50 Jahren so:> http://www.primrosebank.net/computers/z80/z80_special_reset.htm
Nein, da gehts um was völlig anderes. Beim Special Resetwird nur der PC
resettet, während der Rest der CPU ihren Zustand behält. Da wird nicht
gesagt, ob alle Register der CPU beim Starten in einen definierten
Zustand gebracht werden.
Zum x-ten Mal. Es wird langweilig. Einem ahnungslosen Anfänger die
VHDL-Basics zu erklären macht mehr Spaß als das hier.
Machts mal gut, ich geh jetzt Weihnachtsbaum aufstellen.
Laientheater schrieb:> In deterministischen System ist die Schaffung eines defininierten> Ausgangszustandes immer zwingend nötig!
Nein.
Gegenbeispiele:
1. Im FPGA steckt nur Kombinatorik die direkt aus Eingängen zum Ausgang
führt.
2. Eine LED am FPGA soll einmal je Sekunde blinken. Das macht sie auch,
wenn man den Zähler nicht initialisiert. Vielleicht blinkt sie das erste
Mal zu früh, ist aber für die Anwendung egal.
Aber ja, oft macht die Initialisierung Sinn. Wenn das die Hardware kann,
dann kann man das direkt so machen, andernfalls braucht man einen Reset.
-gb- schrieb:> Aber ja, oft macht die Initialisierung Sinn. Wenn das die Hardware kann,> dann kann man das direkt so machen, andernfalls braucht man einen Reset.
Ich interpretiere das jetzt so:
Erst die Speziallösung realisieren, die nur bei Erfüllung bestimmter
Voraussetzungen (Hardware, Toolchain) funktioniert, erst dann die
allgemein funktinierende Variante realisieren. ?!
Das ist m.E. die weniger empfehlenswerte Vorgehensweise, sinnvoller ist
die allgemeine Lösung (hier Reset Netzwerk) und, wenn notwendig,
anschließend eine Speziallösung (hier Initialisierung bei
Signalzuweisung).
Zum einen ist der Nachfragende (TO) ein Anfänger, der nicht abschätzen
kann, ob die Vorraussetzungen bei seinem Board/Toolchain überhaupt
erfüllt sind. Wie gesagt er lässt immer noch das gesamte Forum im
Dunkeln bzgl 'seines Bausteines' tappen. Dagegen ist Anfängern mit 100%
allgemeneinen Lösungen sofort geholfen
Des weitern ist eine allgemeine Lösung gut für Re-Use. Wer kann sich
nach ein paar Jahren noch erinnern unter wolchen Spezialbedingungen das
Modul es so tut wie beschrieben. Die Modulintegration ist auch
einfacher, wenn die Interface jedes Moduls gleich sind. Hier also die
allgemein zutreffende Variante mit clk und rst_n statt wie beim
Spezialfall ohne. Wenn man das Signal rst nicht nutzen will kann man das
immer noch innerhalb des Moduls ignorieren. Wichtig ist das der Anfäner
lernt, das in die Entityt zu 95% eine rst-Leitung gehört.
der (vandalierende) vancouver kritzelte:
>Zusammenfassung dieser Vorlesung: Nimm das, was am besten zu deinem>Problem passt und mach es richtig. Wenn dein Design keinen Reset>braucht, dann lass ihn weg.
Das ist komplett falsch wiedergegeben. Und von einem Anfänger kann man
eine Auswahl an HDL-Varianten (die am Besten zu seiner Aufgabe passen)
nicht erwarten, da er als Anfänger, keine kennt und sich irgendwas aus
den Fingern saugt. So wie der Pilsammler, der nur die Pilze sammelt die
er kennt, aber eben ausser Fliegenpilze nix identifizieren kann. Ein
Anfänger muss erst Erfahrungen sammeln, was zu ihm passt. Also ist er
gut geraten Erfahrungen in Standard-/Lehrbuchösungen zu sammeln.
Und oft ist "das passt nicht zu meinem Design" nur die Entschuldigung
für "das kann ich nicht" oder "das liegt ausserhalb meiner
'Komfortzone'".
Ihr habt ja recht. Ich hab mal nachgelesen, und im Advanced VHDL Design
Guide, Volume 1 - Student's Edition, von Locus/Laientheater (1. Auflage,
also das Originalwerk) habe ich Folgendes gefunden:
Einen effizienten 32-bit Rückwärtszähler baut man aus einer Kaskade von
vier standardisierten 8-bit Vorwärtszählern und einem nachgeschalteten
Konstantensubtrahierer aus 32 standardisierten Volladdierern mit einer
Standard-Ripple-Carrychain. Da alle Komponenten über ein AXI4-Interface
verfügen, wird noch ein AXI4-Crossbar sowie ein Z80-Core zur Steuerung
des Systems nebst einer Standard-Z80-AXI4-Bridge benötigt. Ein leicht
verständliches Pascal-Programm für den CPU-Core findet sich im Anhang.
Das Design kommt mit weniger als 15000 Zeilen VHDL-Code aus und benötigt
nur 31704 LUTs. Damit ist es bereits für preiswerte
Virtex-Ultrascale+-FPGAs geeignet und sehr energieeffizient. Aufgrund
der standardisierten Interfaces ist es vielfältig verwendbar und auch
für Anfänger ohne viel Lernaufwand leicht zu verstehen. Allerdings ist
darauf zu achten, dass alle Komponenten über ein Clock-Enable und ein
synchrones Reset-Signal verfügen (auch der kombinatorische Subtrahierer,
gerade Anfänder vergessen das immer gerne), da sonst unbeabsichtigt ein
Zufallsgenerator mit Poissonverteilung entstehen kann. SCNR.
In diesem Sinne, ganz ohne Sarkasmus, ein frohes Fest und ein besseres
2023.
vancouver schrieb:> Ihr habt ja recht. Ich hab mal nachgelesen, und im Advanced VHDL Design> Guide, Volume 1 -> Das Design kommt mit weniger als 15000 Zeilen VHDL-Code aus und benötigt> nur 31704 LUTs. Damit ist es bereits für preiswerte> In diesem Sinne, ganz ohne Sarkasmus, ein frohes Fest und ein besseres> 2023.
Ja klar, sorry, aber:
Dont piss on my leg and tell me it's raining!
Lutz Locus schrieb:> Ich interpretiere das jetzt so:> Erst die Speziallösung realisieren, die nur bei Erfüllung bestimmter> Voraussetzungen (Hardware, Toolchain) funktioniert, erst dann die> allgemein funktinierende Variante realisieren. ?!
Das ist der Normalfall.
Vielleicht nicht bei quelloffen auf Github, aber bei kommerziellen
Projekten. Da ist oft viel IP von Xilinx oder Intel drinnen und schon
alleine an dem Punkt hat man sich gegen Portierbarkeit entschieden.
Die Hardware für das Design ist also bekannt und wird sich auch nicht
ändern. Wenn doch, dann muss das Design sowieso angefasst werden.
Ist das jetzt gut und richtig?
Naja, man kommt schneller zu Ziel. Erstmal. Man kann sich auch viel IP
selber schreiben um portierbar zu bleiben aber das kostet viel Zeit und
ob das dann auch auf zukünftigen FPGA Familie funktioniert ist unklar.
Eine schwierige Abwägung.