Problem beim Hochzählen

[Kodi (Gast)]

Hallo,

ich habe ein Problem mit meinem VHDL-Code. Der Code ist dazu da, um ein 
Sieben-Segment von 0 bis 9 hochzuzählen (Code siehe unten). Der Compiler 
meckert ständig bei der Zeile:
var_Seg := var_seg + 1;

Dort kommt die Fehlermeldung: + can not have such operands in this 
context.

Ich habe keinen Rat. Variablen sind gleich den Signalen und auch auf 
Null gesetzt.
Vielleicht kann einer von Euch mir helfen oder mir nur einen kleinen Rat 
geben.

Dankeschön
Kodi


VHDL-CODE:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;


entity Sieben_Segment is
    Port ( Enable : in  STD_LOGIC;
           Reset : in  STD_LOGIC;
        clk: in STD_LOGIC;
           Segment : out  STD_LOGIC_VECTOR (6 downto 0));
end Sieben_Segment;

architecture Behavioral of Sieben_Segment is
SIGNAL sig_Seg: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0000";
begin
PROCESS(clk)
VARIABLE var_cnt: INTEGER RANGE 0 TO 49999999 := 0;
Variable test : STD_LOGIC_VECTOR (3 DOWNTO 0);
VARIABLE var_Seg: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0000";  
BEGIN  
IF rising_edge(clk) THEN
  IF Reset = '1' THEN var_cnt := 0;
    var_Seg := "0000";
  ELSE
    IF ENABLE = '1' THEN 
      IF var_cnt = 49999999 THEN var_cnt := 0;
      var_Seg := var_seg + 1;
      ELSE  var_cnt := var_cnt + 1;
        IF var_Seg = "1001" THEN var_Seg := "0000";
        END IF;
              
          END IF;
        END IF;
      END IF;
    END IF;
    sig_Seg <= var_Seg;
END PROCESS;



With sig_Seg SELECT

Segment <= "1111110" WHEN "0000",
        "0110000" WHEN "0001",
        "1100100" WHEN "0010",
        "1100100" WHEN "0011",
        "1100100" WHEN "0100",
        "1100100" WHEN "0101",
        "1100100" WHEN "0110",
        "1100100" WHEN "0111",
        "1100100" WHEN "1000",
        "1100100" WHEN "1001",
        "0000000" WHEN OTHERS;

                  
end Behavioral;

[Fpgakuechle K. (Gast)]

Kodi schrieb:
> Hallo,
>
> ich habe ein Problem mit meinem VHDL-Code. Der Code ist dazu da, um ein
> Sieben-Segment von 0 bis 9 hochzuzählen (Code siehe unten). Der Compiler
> meckert ständig bei der Zeile:
> var_Seg := var_seg + 1;
>
> Dort kommt die Fehlermeldung: + can not have such operands in this
> context.

Das heist die typen passen nicht.
var_seg ist std_logic_veector und 1 ist integer. deklarier var_temp als 
Unsigned und convertiere wo nötig auf std_logic_vector und es passt.


Bsp 
http://www.mikrocontroller.net/svnbrowser/pibla/00_hw/src/pibla.vhd?revision=2&view=markup
nx_address (Zeilen 36/170)

MFG,

[Kodi (Gast)]

Hallo,

danke für die Antwort.

Denke habe es jetzt richtig gemacht. Laut Simulation kommt auf jeden 
Fall schonmal das richtige Ergebnis heraus.

Deine Antwort hat mich auf dem richtigen Weg gebracht, aber musste echt 
noch bisschen überlegen.

Zur Kontrolle nochmal der Kode

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Sieben_Segment is
    Port ( Enable : in  STD_LOGIC;
           Reset : in  STD_LOGIC;
     clk: in STD_LOGIC;
           Segment : out  STD_LOGIC_VECTOR (6 downto 0);
--     CNT : out STD_LOGIC_VECTOR (3 DOWNTO 0));
end Sieben_Segment;

architecture Behavioral of Sieben_Segment is
SIGNAL sig_Seg: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0000";
begin
PROCESS(clk)
VARIABLE var_cnt: INTEGER RANGE 0 TO 49999999 := 0;
VARIABLE var_hochzaehler: UNSIGNED(3 DOWNTO 0) := "0000";
VARIABLE var_Seg: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0000";  
BEGIN  
IF rising_edge(clk) THEN
  IF Reset = '1' THEN var_cnt := 0;
    var_Seg := "0000";
  ELSE
    IF ENABLE = '1' THEN 
      IF var_cnt = 49999999 THEN var_cnt := 0;              -- Simulation: 49 1sec. Takt: 49999999
        IF var_Seg = "1001" THEN var_Seg := "0000";
        ELSE var_hochzaehler := var_hochzaehler + 1;
        var_seg := std_logic_vector(var_hochzaehler);
        END IF;
      ELSE var_cnt := var_cnt + 1;        
      END IF;
    END IF;
  END IF;
END IF;
sig_Seg <= var_Seg;
END PROCESS;



With sig_Seg SELECT

Segment <= "1111110" WHEN "0000",
        "0110000" WHEN "0001",
        "1100100" WHEN "0010",
        "1111001" WHEN "0011",
        "0110011" WHEN "0100",
        "1011101" WHEN "0101",
        "1011111" WHEN "0110",
        "1110000" WHEN "0111",
        "1111111" WHEN "1000",
        "1110011" WHEN "1001",
        "0000000" WHEN OTHERS;

--CNT <= sig_Seg;                
end Behavioral;

[berndl (Gast)]

... und wenn du jetzt noch eine Erklaerung liefern kannst, warum du die 
VARIABLE var_seg und var_cnt eigentlich brauchst und das nicht mit einem 
SIGNAL sig_cnt machst, tja, dann kannst du noch ein virtuelles 
Ueberraschungsei gewinnen...

[Kodi (Gast)]

Ich benutze in Prozessen immer Variablen. Diese nehmen so unmittelbar 
den Zustand ein und nicht erst wenn der Prozess beendet wird. Außerdem 
gelten die so nur für diesem Prozess. Mit Signalen verknüpfe ich die 
Prozesse und Strukturen miteinander.
Sehe ich etwas falsch oder warum so eine Anmerkung? Das Ei kannst du 
gerne behalten.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Kodi schrieb:
> Ich benutze in Prozessen immer Variablen. Diese nehmen so unmittelbar
> den Zustand ein und nicht erst wenn der Prozess beendet wird.
Ich sehe das eher so: du hast vorher Software gemacht. Und möchtest den 
Coding-Style beibehalten. Man kann auch in C mit "Goto" programmieren. 
Warum tut man das nicht?

> Außerdem gelten die so nur für diesem Prozess. Mit Signalen verknüpfe
> ich die Prozesse und Strukturen miteinander.
> Sehe ich etwas falsch
Ja.

> warum so eine Anmerkung?
Lies mal den Thread ganz genau durch: 
Beitrag "Variable vs Signal"

[Kodi (Gast)]

Danke, habe es mir durchgelesen. Ist auch sehr Informativ. Verstehe nur 
eins nicht, dieser negative "Ton". Muss ich erst meine 
Programmiergeschichte zuschreiben? Ihr habt die Erfahrung, die ich nicht 
habe und vielleicht auch nie haben werde, aber deshalb schreibt man hier 
doch und wenn jemanden was anderes auffällt, dann kann man doch mal Nett 
darauf hinweisen.

Naja, unterm Strich sage ich danke, aber werde euch auch nicht weiter 
"belästigen".

[berndl (Gast)]

Kodi schrieb:
> Danke, habe es mir durchgelesen. Ist auch sehr Informativ. Verstehe nur
> eins nicht, dieser negative "Ton". Muss ich erst meine
> Programmiergeschichte zuschreiben? Ihr habt die Erfahrung, die ich nicht
> habe und vielleicht auch nie haben werde, aber deshalb schreibt man hier
> doch und wenn jemanden was anderes auffällt, dann kann man doch mal Nett
> darauf hinweisen.
>
> Naja, unterm Strich sage ich danke, aber werde euch auch nicht weiter
> "belästigen".

Sorry wenn ich dir auf den Schlips getreten bin, aber: Weisst du, was 
eine Variable in einem getakteten Prozess eigentlich ist? Wenn ja, dann 
gilt immer noch das Angebot mit dem virtuellen Ueberraschungsei, dann 
hast du HDL (egal ob VHDL oder Verilog) verstanden.

Falls nein, du bist dann nicht der erste, der hier mit Variablen um sich 
schmeisst und eigentlich gar nicht weiss, was das in dem konkreten Fall 
bedeutet.
Und es hat nix mit Variablen wie man sie vom Programmieren her kennt zu 
tun...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Kodi schrieb:
> Naja, unterm Strich sage ich danke,
Wenn wenigstens die Gesamtbilanz positiv war...

> aber werde euch auch nicht weiter "belästigen".
Eine Frage hätte ich noch: stimmt das mit meiner Annahme, dass du bisher 
vorrangig Software programmiert hast?

Denn gerade wenn jemand von C herkommt, dann gefällt ihm das "sofortige 
Übernehmen" des neuen Wertes (genauso wie derjenige dann Prozesse als 
Funktionsersatz sieht).

Mir gefällt aber wesentlich besser, dass Signale ihren Wert erst am Ende 
des Prozesses ändern. Das erleichtert das Design von synchronen 
Schaltungen/Zustandsautomaten mit dem Ein-Prozess Modell ganz ungemein, 
weil die Signal dort ihren Wert auch erst beim nächsten Takt ändern...

[Fpgakuechle K. (Gast)]

Soweit ich es überblicke ist hier die Verwendung von Variable korrekt 
und damit nicht zu beanstanden.

Habs extra nochmal in lehrbuch nachgeschlagen (ISBN 0-9651934-3-8) dort 
werden auch Zähler auf diese Weise (mit variable) synthetisierbar 
beschrieben.
Ferner wird in dem Buch empfohlen, wo möglich variable statt signal zu 
verwenden da dies die Geschwindigkeit der Simu verbessert (weniger 
simulation overhead). Auch stehen bei dieser Variante Deklaration und 
verwendung nah beeinander, man hat also gleich im Blick welchen typ etc. 
die Variable hat. Signaldeklarationen dagegen stehen z(|m)eilenweit weg, 
da verliert man eher den Überblick. Auch "kapselt" hier eine variable 
das in einen process ein was nicht nür den Überblick verbessert sondern 
auch verhindert, das an einer anderer Stelle versehentlich das falsche 
Signal benutzt wird.

Also wenn es das synthesetool versteht (XST tut es und xilinx gestattet 
die Verwendung von variables in process 
http://www.cis.upenn.edu/~milom/cse372-Spring06/xilinx/xst.pdf S. 470) 
und man kontrolliert sein design auf ungewollte latches (synthese report 
lesen) dann sind variables genau richtig.

MfG,

[peter (Gast)]

----------------------------------
aber werde euch auch nicht weiter "belästigen".
---------------------------------

Die Hunde beissen hier nicht, sind zwar ein bisschen unwirsch und 
kurzatmig.
Mich scheissen die auch ab und zu an....damit kann ich leben als 
Pensionär.

Man kann auch davon lernen, das man Fragende nicht so behandelt wie hier 
manchmal, sondern immer gelassen bleibt, weil es ein Hobby ist.

Es stärkt den eigenen Charakter weil man dann der Bessere ist.

Gruss

[peter (Gast)]

IF var_cnt = 49999999 THEN var_cnt := 0;

Muss er hier auf "0" setzen wenn das Range bis 49999999 läuft?
Gruss

[Duke Scarring (Gast)]

peter schrieb:
> Muss er hier auf "0" setzen wenn das Range bis 49999999 läuft?
Ja. Zumindest der Xilinx-Synthesizer baut nicht automatisch einen 
begrenzten Zähler, nur weil man den integer-Range begrenzt.

Im Klartext: In der Simulation wird ein Fehler ausgegeben, wenn man aus 
dem range rauskommt, aber die Synthese wird im FPGA trotzdem 26 Bit zum 
Speichern reservieren.

Duke

[peter (Gast)]

Hm..bei meinem QuartusII Version 13 funktioniert es, es fängt dann bei 
"0" wieder an. So stelle ich mir auch das Range vor, nicht nur für eine 
schnellere Verarbeitung ,sondern auch als Entlatsung.

Gruss

[Duke Scarring (Gast)]

Fpga Kuechle schrieb:
> Soweit ich es überblicke ist hier die Verwendung von Variable
> korrekt
> und damit nicht zu beanstanden.
Im Prinzip ja, aber :-)

> Habs extra nochmal in lehrbuch nachgeschlagen (ISBN 0-9651934-3-8)
Doone Publications 1999
Ist auch nicht mehr das Jüngste. Ich habe schon einige VHDL-Bücher 
gelesen (dieses noch nicht) und festgestellt, das Perfekte gibt es 
nicht. Leider.


> Ferner wird in dem Buch empfohlen, wo möglich variable statt signal zu
> verwenden da dies die Geschwindigkeit der Simu verbessert (weniger
> simulation overhead).
Simulationsgewschwindigkeit ist in den allermeisten Design nicht 
relevant und sollte für VHDL-Anfänger kein Grund sein, Variablen zu 
verwenden. (Wenn das Argument bei heutigen Simulatoren überhaupt noch 
stimmt.)

> Auch stehen bei dieser Variante Deklaration und
> verwendung nah beeinander, man hat also gleich im Blick welchen typ etc.
> die Variable hat. Signaldeklarationen dagegen stehen z(|m)eilenweit weg,
> da verliert man eher den Überblick.
Da muß ich Dir leider recht geben. Aber wenn der Editor mehrere Panels/ 
Fenster öffnen kann, ist es bei heutigen Displaygrößen kein Problem sich 
beides auf den Schirm zu zaubern.
Außerdem müßte man mit Deinem Argument bei C/C++ die Variablen auch eine 
Zeile über der ersten Verwendung deklarieren.

> und man kontrolliert sein design auf ungewollte latches (synthese report
> lesen)
Das fällt gerade bei Xilinx nicht ganz leicht, da dort sehr viele (oft 
irrelevante) Warnungen auftauchen.

> dann sind variables genau richtig.
Ich kann Variablen erst empfehlen, wenn der geneigte Anfänger genau 
den Unterschied zu Signalen verstanden hat.
Und damit meine ich nicht den Unterschied zwischen <= und :=
:-)

Duke

[Fpgakuechle K. (Gast)]

Duke Scarring schrieb:
> Fpga Kuechle schrieb:

>> Habs extra nochmal in lehrbuch nachgeschlagen (ISBN 0-9651934-3-8)
> Doone Publications 1999
> Ist auch nicht mehr das Jüngste.

Erscheinungsjahr ist nun wirklich nicht ein Qualitätskriterium für 
Lehrbücher.

>> Auch stehen bei dieser Variante Deklaration und
>> verwendung nah beeinander, man hat also gleich im Blick welchen typ etc.
>> die Variable hat. Signaldeklarationen dagegen stehen z(|m)eilenweit weg,
>> da verliert man eher den Überblick.
> Da muß ich Dir leider recht geben. Aber wenn der Editor mehrere Panels/
> Fenster öffnen kann, ist es bei heutigen Displaygrößen kein Problem sich
> beides auf den Schirm zu zaubern.

Dann muss man den Überblick waren, welche Panels gerade offen sind und 
welchen codebereich zeigen. Und irgendwann ist vor lauter Monitoren kein 
Platz für die Tastatur mehr ;-). Und bei Code-reviews oder Durchsicht im 
stillen Kämmerlein wird gern mit ausgedruckten listings gearbeitet. Oder 
das pad/ebok-reader/smartphone hat keine multifenster-Editor oder ist 
umständlich damit zu bedienen

> Außerdem müßte man mit Deinem Argument bei C/C++ die Variablen auch eine
> Zeile über der ersten Verwendung deklarieren.

Hm in C bin ich nicht wirklich zu hause, aber man kann doch in C 
tatsächlich variablen deklarieren wo man sie gerade braucht, hauptsache 
vor einem Block . 
http://stackoverflow.com/questions/1287863/c-for-loop-int-initial-declaration

main()
{
    for(int i = 0; i <= 300; i += 20)
    {
      printf("F=%d C=%d\n",i, (i-32) / 9);    
    }
}

man werfe einfache ein {} paar in den code und kann dort die variablen 
deklarieren die man braucht.

Ich seh es so wo man die Möglichkeit der übersichtlichen Form 
(Deklaration und Verwendung nah beieinander) hat sollte man diese und 
nicht den workaround (multi-fenster editor) nutzen. Das ist auch besser 
für Dritte
die nicht mit dem Editor arbeiten wollen/können den sich der 
Code-ersteller gerade wünscht.

MfG

[berndl (Gast)]

also koennte ich sowas schreiben:

process (clk)
  signal hugo, sepp: std_logic;
begin
...
end process;

dann waere ich ja auch froh. 'Lokale' Typdeklarationen waeren toll, das 
gibt es aber in VHDL nicht. Variablen sind dagegen etwas ganz anderes! 
Je nach Kontext koennen das 'Signale die in ein FF muenden' sein oder 
auch 'fliegende Logiksignale'. Und das stoert mich an Variablen. Und bei 
entsprechender Verwendung macht es den Code in einem sequentiellen 
Prozess schlicht und einfach unlesbar und nahezu unwartbar!

[peter (Gast)]

Im Prinzip ja, aber :-)...

sprach Radio Eriwan...

Gruss

[peter (Gast)]

------------------------------------
.....dann kann man doch mal Nett darauf hinweisen....
------------------------------------

Da kannst du hier lange warten.
Sind einige Bauernlümmel hier runter...schlechte Ehe...von der Frau 
ausgeschlossen(kein Geschlechtsverkehr)... Alkohol...... usw. das formt 
einen Menschen und macht ihn schlecht.

Ich habe noch nie so viele missmutige im Leben stehende Menschen erlebt 
wie in diesem speziellen FPGA_Forum.

Gruss

[berndl (Gast)]

peter schrieb:
> ------------------------------------
> .....dann kann man doch mal Nett darauf hinweisen....
> ------------------------------------
>
> Da kannst du hier lange warten.
> Sind einige Bauernlümmel hier runter...schlechte Ehe...von der Frau
> ausgeschlossen(kein Geschlechtsverkehr)... Alkohol...... usw. das formt
> einen Menschen und macht ihn schlecht.
>
> Ich habe noch nie so viele missmutige im Leben stehende Menschen erlebt
> wie in diesem speziellen FPGA_Forum.
>
> Gruss

Komisch, dass du hier in den letzten paar Wochen aber gefueht eine 
Million Threads aufgemacht hast...

Und, komischerweise, du auf keine Antwort jemals mit etwas 
'substantiellem' geantwortet hast und trotzdem die 'Bauernluemmel' dir 
immer noch irgendwie helfen wollen...

[Fpgakuechle K. (Gast)]

berndl schrieb:
> peter schrieb:

>> Da kannst du hier lange warten.
>> Sind einige Bauernlümmel hier runter...schlechte Ehe...von der Frau
>> ausgeschlossen(kein Geschlechtsverkehr)... Alkohol...... usw. das formt
>> einen Menschen und macht ihn schlecht.
>>
>> Ich habe noch nie so viele missmutige im Leben stehende Menschen erlebt
>> wie in diesem speziellen FPGA_Forum.

> Komisch, dass du hier in den letzten paar Wochen aber gefueht eine
> Million Threads aufgemacht hast...
>
> Und, komischerweise, du auf keine Antwort jemals mit etwas
> 'substantiellem' geantwortet hast und trotzdem die 'Bauernluemmel' dir
> immer noch irgendwie helfen wollen...

Achtung Verwechslungsgefahr: viele Anfragen gestellt hat ein 
angemeldeter Peter, von Bauernlümmel schwadroniert hier ein "Peter 
(Gast)".

MfG

[Fpgakuechle K. (Gast)]

berndl schrieb:
> Variablen sind dagegen etwas ganz anderes!
> Je nach Kontext koennen das 'Signale die in ein FF muenden' sein oder
> auch 'fliegende Logiksignale'.
> Und das stoert mich an Variablen.

Man weiß jetzt nicht genaus was für dich 'fliegende Logiksignale' sind,
aber  signals werden ebenfalls je nach context (bspw. senseliste 
process) in FF münden, zu latches oder kombinatorischen Ausgängen.

Die Vermeidung von variables erspart Dir das Wissen um den richtigen 
Gebrauch derselben. Es führt aber nicht zwangsläufig zu fehlerfreien und 
effizienten VHDL-Code.

> Und bei
> entsprechender Verwendung macht es den Code in einem sequentiellen
> Prozess schlicht und einfach unlesbar und nahezu unwartbar!

Nee unlesbar oder unwartbar ist was anderes als nicht synthetisierbarer 
Code oder ungewollte Latches.


> also koennte ich sowas schreiben:
>

> process (clk)
>   signal hugo, sepp: std_logic;
> begin
> ...
> end process;
>

> dann waere ich ja auch froh. 'Lokale' Typdeklarationen waeren toll, das
> gibt es aber in VHDL nicht.

Pack um den process einen block dann kannst du quasi lokale Signale 
deklarieren

B_exa1: block
   signal hugo, sepp: std_logic;
begin
 process (clk)
 begin
-- ...
 end process;

end block b_exa1;

MfG,

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fpga Kuechle schrieb:
> Achtung Verwechslungsgefahr: viele Anfragen gestellt hat ein
> angemeldeter Peter, von Bauernlümmel schwadroniert hier ein "Peter
> (Gast)".
Aus dem Nähkästchen: es ist (leider oder zum Glück) der selbe Peter.

Und er bessert sich. Nur das Zitieren von Beiträgen klappt noch nicht so 
richtig...

[Duke Scarring (Gast)]

Fpga Kuechle schrieb:
> Erscheinungsjahr ist nun wirklich nicht ein Qualitätskriterium für
> Lehrbücher.
Leider doch. Die älteren Werke beziehen sich oft nur auf den 
simulationsfähigen Teil von VHDL.
Wenn doch explizit der synhtetisierbare Teil erwähnt wird, dann 
bestenfalls das, was die Tools zu diesem Zeitpunkt konnten. Und das ist 
leider nicht so berauschend viel gewesen. Oft wird dann noch nichtmal 
ein rising_edge verwendet. Oder es erfolgt der großflächige Einsatz der 
ollen std_logic_arith zum Rechnen :-(

Gefühlt 1/4 der Beiträge hier im Forum, wären nicht nötig, wenn es 
gescheite VHDL Bücher gäbe.

Duke

[Christoph Z. (christophz)]

berndl schrieb:
> also koennte ich sowas schreiben:

 process (clk)
  signal hugo, sepp: std_logic;
begin
...
end process;

> dann waere ich ja auch froh.

Ja, ich fände es auch schön, wenn ich das gleich so schreiben könnte. 
Das mit dem Block geht natürlich, aber ich fände es übersichtlicher und 
kompakter wenn ich es direkt im Prozess definieren könnte.

[Fpgakuechle K. (Gast)]

Duke Scarring schrieb:
> Fpga Kuechle schrieb:
>> Erscheinungsjahr ist nun wirklich nicht ein Qualitätskriterium für
>> Lehrbücher.
> Leider doch.

?? Das meinst Du wirklich ernst? Dieses "Ich kenn dieses Lehruch zwar 
nicht, aber ich ziehe es anhand seines Erscheinungsjahr in Zweifel"?

Meinst Du nicht man sollte wenigstens einen Blick hinein werfen bevor 
man versucht seine inhaltlichen Stärken und Schwächen abzuschätzen? Hier 
mal 'ne Beispielseite:

http://www.mikrocontroller.net/attachment/199654/20131109_HDL_Design_Muxk.jpg

MfG,

[Duke Scarring (Gast)]

Fpga Kuechle schrieb:
> Meinst Du nicht man sollte wenigstens einen Blick hinein werfen bevor
> man versucht seine inhaltlichen Stärken und Schwächen abzuschätzen?
Ok. Kritik angenommen.

Ersteinmal die positiven Aspekte:
+ dieses Buch verwendet durchgängig ieee.numeric_std
+ enthält viele (relativ) praktische Beispiele, die gleich zum 
Ausprobieren locken
+ ist für Umsteiger geeignet, weil Verilog und VHDL parallel behandelt 
werden
+ hat eine gute Erklärung warum man rising_edge verwenden sollte (S. 
172)
+ enthält einen schönen Überblick, über Generatoren für Testsignal (Kap. 
11)


Jetzt die Punkte, die mir negativ aufgefallen sind:
- Behauptung, daß eine Variable nicht zu einem FF synthetisiert werden 
kann (S. 229 im Beispiel)
- Empfehlung zur Mischung von kominatorischer und sequentieller Logik in 
einem Prozess (S. 78 und S. 274)
- Verwendung von internen Tristate-Bussen (Kap. 10, Kap. 12 Beispiel 1)
- Multiplikation und Division werden nicht zur Synthese empfohlen (S. 
63)
- Empfehlung Signale durch Variablen zu ersetzten um schneller zu 
simulieren (S. 78)
- umfangreiche Erklärung zu Latches (S. 164), teilweise mit mehrphasigen 
Enable-Signalen trotz Hinweis, das eine Timing-Analyse nicht möglich ist
- Einsatz von asynchronen Zählern (Beispiele 7.14 und 7.15)
- Verwendung von Taktteiler, statt clk_enable (Beispiel 7.13)
- numeric_std wird of eingebunden, obwohl die Funktionalität gar nicht 
gebraucht wird (Kap. 3)
- nicht zeitgemäßer Hinweis, das 'initial' nicht synthetisiert werden 
kann (Bild 3.4 und Anhang B)


Und noch drei 'optische' Mängel:
- genrell sind alle if-Ausdrücke geklammert, obwohl das bei VHDL nicht 
nötig ist
- im FSM-Kapitel (Kap. 8) wird viel zu oft ein else-Zweig verwendet, 
obwohl man auch schön vor dem case einen Default zuweisen kann
- gelegentlich werden Namen für States verwendet, die nicht in ein 
Lehrbuch gehören: ST1, ST2, ST3, ST4, ST5, ...


Insgesamt gesehen ist das Buch nicht schlecht, aber auch nicht wirklich 
gut.
Viele Dinge sind unzeitgemäß (initial-Zuweisung, Multiplikation), bzw. 
haben nur noch informativen Charakten (Kapitel 9, Interna zu Addierern 
und Multiplizierern).
Positiv ist wirklich hervorzuheben, daß hier durchgängig 
ieee.numeric_std verwendet wird. Auch der Einsatz von rising_edge 
gefällt mir. Der Autor verwendet auch gelegentlich das 'wait until 
...'-Konstrukt, auch wenn ich seine Begrüdung zu dessen Nachteilen nicht 
teilen kann. Das Buch könnte eine Überarbeitung gebrauchen (ich beziehe 
mich auf die Ausgabe von 1997) und bei einigen Dingen, die zwar zu 
synthetisieren gehen, aber definitiv nichts für Einsteiger sind, die 
Fallstricke deutlich herausstellen (u.a. Variablen als FF, Latches, 
asynchrone Zähler, FSM mit kombinatorischen Pfaden, interne Tri-States).

Duke