Forum: FPGA, VHDL & Co. Ein wirklich blöder Fehler, den ich nicht sehe


von Erik (Firma: private) (erik0015)


Lesenswert?

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.
1
 
2
library IEEE;
3
use IEEE.std_logic_1164.all;
4
use IEEE.numeric_std.all;
5
6
entity Debounce_Test is
7
    port(
8
        BTN : in  std_logic;
9
        LED : out std_logic_vector(7 downto 0) := (others => '0')
10
    );
11
end entity Debounce_Test;
12
13
architecture rtl of Debounce_Test is
14
    signal counter : integer := 0;
15
begin
16
    process(BTN)
17
    begin
18
        if rising_edge(BTN) then
19
            counter <= counter + 1;
20
        end if;
21
    end process;
22
    LED(counter) <= '1';
23
end architecture rtl;

Gruß

Erik

: Bearbeitet durch Moderator
von Falk B. (falk)


Lesenswert?

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.

von Erik (Firma: private) (erik0015)


Lesenswert?

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

von vancouver (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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!

von Erik (Firma: private) (erik0015)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

Erik schrieb:
> Es
> muss also etwas mit dem Prozess zu tun haben, so glaube ich.

Muh, Muh,. blinde Kuh . . .

von Falk B. (falk)


Lesenswert?

https://www.engineersgarage.com/vhdl-tutorial-13-design-3x8-decoder-and-8x3-encoder-using-vhdl/

Kann man aber auch mit weniger Schreibaufwand erreichen, wenn man weiß 
wie.

von vancouver (Gast)


Lesenswert?

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.

von Lutz Lokus (Gast)


Lesenswert?

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/

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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?

von Lutz Locus (Gast)


Lesenswert?

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/

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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... ;-)

: Bearbeitet durch Moderator
von Markus F. (mfro)


Lesenswert?

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
entity Debounce_Test is
2
    port(
3
        BTN : in  std_logic;
4
        LED : out std_logic_vector(7 downto 0) := (others => '0')
5
    );
6
end entity Debounce_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).

von Falk B. (falk)


Lesenswert?

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.

von -gb- (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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!

von vancouver (Gast)


Lesenswert?

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?

von Lutz Locus (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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 :-)

von Alex P. (ra_p)


Lesenswert?

@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.

von Lutz Locus (Gast)


Lesenswert?

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).

von Lutz Locus (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

: Bearbeitet durch User
von atoyot (Gast)


Lesenswert?

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...

von vancouver (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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."

von Gustl B. (-gb-)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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)?

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

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.

von Erik (Firma: private) (erik0015)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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;

von Lutz Locus (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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
library IEEE;
2
use IEEE.std_logic_1164.all;
3
use IEEE.numeric_std.all;
4
5
entity Debounce_Test is
6
    port(
7
        BTN : in  std_logic;
8
        LED : out std_logic_vector(7 downto 0) := (others => '0')
9
    );
10
11
end entity Debounce_Test;
12
13
architecture rtl of Debounce_Test is
14
signal counter : integer range 0 to 10:= 0;
15
begin
16
    process(BTN)
17
    begin
18
        if rising_edge(BTN) then
19
            counter <= counter + 1;
20
        end if;
21
    end process;
22
    LED(counter) <= '1';
23
end architecture rtl;


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.

von Lutz Locus (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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?

von Gustl B. (-gb-)


Lesenswert?

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.

: Bearbeitet durch User
von Dussel (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

Genau. Interessant wäre noch Quartus Prime Standard und Pro und Lattice, 
...

von vancouver (Gast)


Lesenswert?

Btw, offenbar ist der Code des TO doch gar nicht soooo falsch, wie 
manche Krawallmacher behauptet haben. Sowas auch.

von Gustl B. (-gb-)


Lesenswert?

Bei Xilinx macht der code genau das was er soll.

Er ist allerdings unnötig komplex. Für kleine Werte von komplex.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

: Bearbeitet durch Moderator
von Lutz Locus (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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).

von -gb- (Gast)


Lesenswert?

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.

von -gb- (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Angehängte Dateien:

Lesenswert?

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 : out std_logic_vector(7 downto 0) := "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
1
led(counter) <= '1';
1
led <= std_logic_vector(unsigned'("00000001") sll counter mod 8);
(weist also alle Elemente des out-Ports zu, kommt das richtige raus 
(richtig.png)

von Lutz Locus (Gast)


Lesenswert?

-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 ;-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

Sorry, Linkfehler, man vergleiche bitte die Lösungsvarianten

https://www.mikrocontroller.net/attachment/highlight/581072 und
https://www.mikrocontroller.net/attachment/highlight/581177

 mit dem Ansatz des TO.

von vancouver (Gast)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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.

von atoyot (Gast)


Lesenswert?

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!

von Lutz Locus (Gast)


Lesenswert?

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 ...

von vancouver (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von vancouver (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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;

von Markus F. (mfro)


Lesenswert?

Komischerweise wird der Initialwert durchaus berücksichtigt. Nimmt man 
den Prozess raus und initialisiert (z.B.) mit
1
led : out std_logic_vector(7 downto 0) := "10101100"
(also so, dass nur der Initialwert ausgegeben wird),
bleibt das hier übrig:
1
  Warning (13410): Pin "led[0]" is stuck at GND
2
  Warning (13410): Pin "led[1]" is stuck at GND
3
  Warning (13410): Pin "led[2]" is stuck at VCC
4
  Warning (13410): Pin "led[3]" is stuck at VCC
5
  Warning (13410): Pin "led[4]" is stuck at GND
6
  Warning (13410): Pin "led[5]" is stuck at VCC
7
  Warning (13410): Pin "led[6]" is stuck at GND
8
  Warning (13410): Pin "led[7]" is stuck at VCC

Quartus versteht also durchaus, was gewünscht ist.

von Dussel (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Angehängte Dateien:

Lesenswert?

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."

von Dussel (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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?

von Lutz Locus (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

Gustl B. schrieb:
> Markus F. schrieb:
>> Quartus versteht also durchaus, was gewünscht ist.
>
> Welche Version und FPGA?

20.1 (Light) und MAX10

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite



Lesenswert?

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
    end process;


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
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
4
entity decoder1aus8 is
5
    Port ( clk : in  STD_LOGIC;
6
           LED : out  STD_LOGIC_VECTOR (7 downto 0));
7
end decoder1aus8;
8
9
architecture Behavioral of decoder1aus8 is
10
signal cnt : integer range 0 to 7 := 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
   process begin
18
   wait until rising_edge(clk);
19
      if cnt=7 then cnt <= 0;
20
      else cnt <= cnt+1;
21
      end if;
22
   end process;
23
24
    -- Diamond ok / XST ok
25
    process (cnt) begin 
26
       LED <= (others => '0');
27
       LED(cnt) <= '1';
28
    end process;
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
end Behavioral;
Siehe die angehängten ISIM Screenshots der Waveform: im Falle der 
concurrent-Zuweisung bleibt unverändert der Initialwert aktiv.

: Bearbeitet durch Moderator
von Lutz Locus (Gast)


Angehängte Dateien:

Lesenswert?

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

von Lutz Locus (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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

von vancouver (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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" sll cnt;
(und man kann's auch in einem concurrent Context hinschreiben)

: Bearbeitet durch User
von Lutz Locus (Gast)


Lesenswert?

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

von Markus F. (mfro)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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.pdf

https://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.

von Achim S. (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

Lutz Locus schrieb:
> Und was trägt sieser, dein Beitrag hier zur Wissenvermittlung bei?!
> Reine zwanghafte Profilierungssucht, komplett für den Arsch.

Siehste.

von Markus F. (mfro)


Lesenswert?

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.

: Bearbeitet durch User
von vancouver (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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?

von Markus F. (mfro)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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).

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

: Bearbeitet durch Moderator
von Markus F. (mfro)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

Tatsächlich ist der TO anscheinend nicht der erste, der auf die 
Problematik gestossen ist:

https://community.intel.com/t5/Intel-Quartus-Prime-Software/Latch-initialization-in-quartus-prime/m-p/1324020

Nur leider scheint's den Intel-Support nicht so fürchterlich 
interessiert zu haben...

von Lutz Lokus (Gast)


Lesenswert?

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".

von Dussel (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Angehängte Dateien:

Lesenswert?

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
entity mylatch is
2
    port
3
    (
4
        enable          : in std_ulogic;
5
        d               : in std_ulogic_vector(1 downto 0);
6
        q               : out std_ulogic_vector(1 downto 0)
7
    );
8
end entity mylatch;
9
10
architecture rtl of mylatch is
11
    signal o    : std_ulogic_vector(q'range) := "01";
12
begin
13
    p : process(all)
14
    begin
15
        if enable then
16
            o <= d;
17
        end if;
18
    end process p;
19
    q <= o;
20
end architecture rtl;

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.

von Laientheater (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

Und wozu in aller Welt braucht es für einen rein kombinatorischen 1:N 
Dekoder Latches? Jaja, unsere 
ELfenbeinturmphilosophenreinigungsfachkräftemangelmahner . . . . ;-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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ß.

von -gb- (Gast)


Lesenswert?

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.)

von Laientheater (Gast)


Lesenswert?

-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

von Markus F. (mfro)


Lesenswert?

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'.

von vancouver (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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.

von -gb- (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

-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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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?!

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Lutz Locus (Gast)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch Moderator
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch Moderator
von vancouver (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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 ..

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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=9

Lutz 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.

: Bearbeitet durch Moderator
von vancouver (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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

von Markus F. (mfro)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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?"

von vancouver (Gast)


Lesenswert?

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
> spielen

Laientheater 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.

von Laientheater (Gast)


Lesenswert?

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!

von Dussel (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Angehängte Dateien:

Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

Warum key[1:0]? Gehst du von einen Wechsler aus?

von vancouver (Gast)


Lesenswert?

vancouver schrieb:
> Warum key[1:0]? Gehst du von einen Wechsler aus?

Habs gerade durchblickt, es sind zwei Taster. Sorry.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

: Bearbeitet durch User
von Laientheater (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von vancouver (Gast)


Lesenswert?

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? :-)

von Lutz Locus (Gast)


Angehängte Dateien:

Lesenswert?

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

von vancouver (Gast)


Lesenswert?

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!

von Laientheater (Gast)


Lesenswert?

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!

von Markus F. (mfro)


Lesenswert?

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).

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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 ???

von Laientheater (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Markus F. (mfro)


Lesenswert?

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.

: Bearbeitet durch User
von Laientheater (Gast)


Angehängte Dateien:

Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

> 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.

von Laientheater (Gast)


Lesenswert?

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.

von Laientheater (Gast)


Lesenswert?

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.

von vancouver (Gast)


Lesenswert?

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.

Beitrag #7295187 wurde von einem Moderator gelöscht.
von -gb- (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

-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'".

von vancouver (Gast)


Lesenswert?

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.

von Lutz Locus (Gast)


Lesenswert?

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!

von -gb- (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.