Altera Timequest signal als clock identifiziert

[MALGUCKEN (Gast)]

Hallo anbei ein kleine Ausschnitt aus meine versuch eine rs232 
Schnittstelle zu erzeugen. Sie geht auch das ist nicht das Problem. 
Erstmal der Code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity RS232_RX is
  generic(  CLK_MUL: natural := 6;
      BITS: natural := 8;
      STOPBIT: natural range 0 to 1 := 0);
  port(    RESET: in bit;
      NDATA: in bit; -- new data
      READY: out bit; -- ready for new data
      BCLK: in bit;
      databit: in bit_vector(BITS-1 downto 0);
      DO: out bit);
end RS232_RX;

architecture STRUCT of RS232_RX is
  type state is (IDLE, START, SEND, STOP);
  signal l_databit: bit_vector(BITS-1 downto 0);
  signal iclk: bit := '0';
  signal l_mstate: state;
  signal l_obit: bit := '1'; --idle bit
  signal l_ready: bit := '0';

begin


P1:   process(BCLK,RESET,databit,NDATA,l_ready) 
  variable v_counter: integer range 0 to CLK_MUL := 0; --integer
  variable v_bcnt: integer range 0 to BITS-1 := 0; --integer rang 0 bis BITS; 
  variable vcnt_stbbit: integer range 0 to 1 := STOPBIT; --anzahl der stopbits
  begin
    if RESET='1' then
      l_mstate <= IDLE; --set the machine to start.
      v_counter := 0; -- reset v_counter
      l_ready <= '1'; --set ready to not ready for new data i am in the process.
    elsif NDATA = '1' and l_ready = '1' then --new data? 
        l_databit <= databit; --nur bei reset zuweisen
        l_mstate <= START;
        l_ready <= '0';
    elsif BCLK'event and BCLK='0' then
      if v_counter=0 then
        v_counter := CLK_MUL-1;
        case l_mstate is
          when IDLE => null;            
            l_mstate <= IDLE; --set the machine to start.
          when START =>          
            l_obit <= '0';
            l_mstate <= SEND;
            v_bcnt := BITS-1;
            vcnt_stbbit := STOPBIT;
          when SEND =>  
            l_obit <= l_databit(0);
            l_databit <= '0' & l_databit(BITS-1 downto 1);
            if v_bcnt = 0 then
              l_mstate <= STOP;
            else
              v_bcnt := v_bcnt -1;
            end if;
          when STOP =>  
            l_obit <= '1';
            if vcnt_stbbit = 0 then
              l_mstate <= IDLE;
              l_ready <= '1'; --ready for new data
            else
              vcnt_stbbit := vcnt_stbbit-1;
            end if;
        end case;
      else
        v_counter := v_counter - 1;
      end if;
    end if;  
  end process P1;

PO:   process(l_obit,l_ready)
  begin
    READY <= l_ready;
    DO <= l_obit;
  end process PO;
end STRUCT;

So die Entwicklungsumgebung erzählt mir in der Timequest Analyzer, dass 
das Signal "CONTROL:RS232CNT|RS232_RX:RS232RX|l_mstate.IDLE~1" eine 
clock ist. Jetzt meine Frage warum sollte das eine Clock sein? Den 
Zusammenhang verstehe ich nicht.

Bitte helft mir fürs Verständnis!
Vielen Dank

[Duke Scarring (Gast)]

Uiuiui, hier sind ja gleich mehrere Sachen:

1.

       when IDLE => null;            
          l_mstate <= IDLE; --set the machine to start.

Ein von beiden Anweisung ist definitiv überflüssig.
Ich würde die Zuweisung an l_mstate weglassen.

2.

process(BCLK,RESET,databit,NDATA,l_ready)

Deine Sensitivity-Liste ist genauso unübersichtlich, wie Dein Code.
Ich versuche in meinen Designs (zu 98% gelingt das auch) nur mit CLK zu 
arbeiten. Das sind sogenannte synchrone Designs.
In Einzelfällen kommt dann noch ein (asynchroner) Reset dazu.

3.

  variable v_counter: integer range 0 to CLK_MUL := 0; --integer
  variable v_bcnt: integer range 0 to BITS-1 := 0; --integer rang 0 bis BITS; 
  variable vcnt_stbbit: integer range 0 to 1 := STOPBIT; --anzahl der stopbits

Für die gestellte Aufgabe sind das definitiv zu viele Variablen.

Hier nochmal kurz und prägnant von Lothar postuliert:
Beitrag "Re: VHDL - For-Schleife"

Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, 
der immer auf dieselbe Flanke aktiv ist. 
Es gibt keinen (und schon gar keinen asynchronen) Reset.
Externe Signale werden über 2 Flipflops einsynchronisiert.
Jede Abweichung von diesen Regeln muß fundiert begründet werden können.

Versuch mal Deinen Code dahingehend umzuschreiben...

Duke

[Freshman goes on air (Gast)]

MALGUCKEN schrieb:
> Erstmal der Code:library ieee;


>
> P1:   process(BCLK,RESET,databit,NDATA,l_ready)
>   variable v_counter: integer range 0 to CLK_MUL := 0; --integer
>   variable v_bcnt: integer range 0 to BITS-1 := 0; --integer rang 0 bis
> BITS;
>   variable vcnt_stbbit: integer range 0 to 1 := STOPBIT; --anzahl der
> stopbits
>   begin
>     if RESET='1' then
>       l_mstate <= IDLE; --set the machine to start.
>       v_counter := 0; -- reset v_counter
>       l_ready <= '1'; --set ready to not ready for new data i am in the
> process.
>     elsif NDATA = '1' and l_ready = '1' then --new data?
>         l_databit <= databit; --nur bei reset zuweisen
>         l_mstate <= START;
>         l_ready <= '0';
>     elsif BCLK'event and BCLK='0' then
>       if v_counter=0 then
>         v_counter := CLK_MUL-1;
>         case l_mstate is
>           when IDLE => null;
>             l_mstate <= IDLE; --set the machine to start.

            ...schnipp
>       else
>         v_counter := v_counter - 1;
>       end if;
>     end if;
>   end process P1;


Dein process ist sehr eigenwillig beschrieben. in eine sebsitixity list 
gehört nur Takt und asynchroner reset, das elsif twischen reset und takt 
ist auch nicht schön.
Vorschlag: Zeichne ein Blockbild es uarts aus shift Register, 
Steuerung-fsm, bitzähler. für jede der drei Komponenten schreibst du 
einen eigenen process.

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

    if RESET='1' then                        -- asynchroner Reset muss Taktsynchron inaktiv werden!
      ....
    elsif NDATA = '1' and l_ready = '1' then -- NIEMALS Kombinatorik im Reset!!!
      ....
    elsif BCLK'event and BCLK='0' then

Ganz, ganz böse Sache: asynchroner und kombinatorischer Reset. Das 
Design wird niemals stabil laufen: ein einziger Glitch und ein paar FF 
der SIO werden zurückgesetzt. Und zwar jedesmal irgendwelche Anderen...

BTW:

    elsif BCLK'event and BCLK='0' then

Wie viele Takte hat dein Design?

[MALGUCKEN (Gast)]

Hi danke für eure Anregung.

Ich habe bezüglich eurer Antworten ein paar Fragen um als Anfänger etwas 
Wissen ab zu stauben ;)

1. Ihr meint in der senstiv liste des Prozessen gehören nur CLK und 
RESET.
   Ist es nicht so, dass der Compiler (Syntesewerkzeug) eh alle 
gelesenen Signal nachträglich in diese Liste einfügt?

2. Ihr fragt nach den CLKs
Ich erzeuge eine BCLK aus dem CLK in Form eines Zählers, welche mir dann 
einen CLK erzeugt, welche ca. 12mal Schneller als die Baud rate ist.

Angenommen dies ist falsch und ich benutze nur die CLK dann muss ich ja 
in dem RS Block selber immer mit zählen was die Variablenanzahl noch 
erhöht und zum andern  den Code noch unübersichtlicher gestaltet.
Die einzige Lösung die mir in den Sinn kommt (keine Erfahrung) ist 
dieser schritt wie er in einigen Diskussionsthreads angesprochen wird.

....
begin process(CLK)
variable v_ch_bclk: bit := '1';
begin
if CLK'event and CLK='1' then
   if v_ch_blk /= BCLK and BCLK='1' then
     ......
     v_ch_blk := BCLK;
   else
     v_ch_blk := BCLK;
   end if;
end if;
end process;

Vormal ist das eine Flanken wechsle Erkennung welche synchron mit dem 
TAKT läuft.

Vielen Dank :)

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

MALGUCKEN schrieb:
> 1. Ihr meint in der senstiv liste des Prozessen gehören nur CLK und
> RESET.   Ist es nicht so, dass der Compiler (Syntesewerkzeug) eh alle
> gelesenen Signal nachträglich in diese Liste einfügt?
Nein. Er ignoriert die Sensitivliste komplett und meldet bestenfalls 
mit einer Info, dass die Simulation nicht merh zur generierten Hardware 
passt und somit falsch ist.


> 2. Ihr fragt nach den CLKs Ich erzeuge eine BCLK aus dem CLK in Form
> eines Zählers, welche mir dann einen CLK erzeugt, welche ca. 12mal
> Schneller als die Baud rate ist.
Dacht ichs mir doch...
So werden keine Takte erzeugt. Arbeite mit 1 einzigen Takt im 
gesamten Design. Und wenn du langsamere "Untertakte" brauchst, dann 
arbeitest du ausschließlich mit Clock-Enables. So wie dort der "Takt" 
für das Lauflicht erzeugt und über clken weitergegeben wird:
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html

[MALGUCKEN (Gast)]

Hallo Lothar Miller,

danke für deine Antworten. Ich habe es jetzt zu einer Takt enable 
Schaltung umgestellt. In der tat taucht jetzt in den Timings das Problem 
nicht mehr auf. Eine frage habe ich noch. ich frage jetzt den Reset nach 
dem clk event ab. Als der Code sieht nun wie folgt aus. (Immer noch 
etwas chaotisch)

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity RS232_RX is
  generic(  CLK_MUL: natural := 6;
      BITS: natural := 8;
      STOPBIT: natural range 0 to 1 := 0);
  port(    
      CLK: in std_logic;
      RESET: in bit;
      NDATA: in bit; -- new data
      READY: out bit; -- ready for new data
      BCLK: in bit;
      databit: in bit_vector(BITS-1 downto 0);
      DO: out bit);
end RS232_RX;

architecture STRUCT of RS232_RX is
  type state is (IDLE, START, SEND, STOP);
  signal l_databit: bit_vector(BITS-1 downto 0);
  signal iclk: bit := '0';
  signal l_mstate: state := IDLE;
  signal l_obit: bit := '1'; --idle bit
  signal l_ready: bit := '0';

begin

P1:   process(CLK) 
  variable v_counter: integer range 0 to CLK_MUL := 0; --integer
  variable v_bcnt: integer range 0 to BITS-1 := 0; --integer rang 0 bis BITS; 
  variable vcnt_stbbit: integer range 0 to 1 := STOPBIT; --anzahl der stopbits
  begin
    if CLK'event and CLK='1' then
      if RESET='1' then
         v_counter := 0; -- reset v_counter
         l_ready <= '1'; --set ready to not ready for new data i am in the process.
       elsif NDATA = '1' and l_ready = '1' then --new data? 
         l_databit <= databit; 
         l_mstate <= START;
         l_ready <= '0';
      elsif BCLK='1' then
        if v_counter=0 then
          v_counter := CLK_MUL-1;
          case l_mstate is
            when IDLE => null;            
              l_mstate <= IDLE; --set the machine to start.
            when START =>          
              l_obit <= '0';
              l_mstate <= SEND;
              v_bcnt := BITS-1;
              vcnt_stbbit := STOPBIT;
            when SEND =>  
              l_obit <= l_databit(0);
              l_databit <= '0' & l_databit(BITS-1 downto 1);
              if v_bcnt = 0 then
                l_mstate <= STOP;
              else
                v_bcnt := v_bcnt -1;
              end if;
            when STOP =>  
              l_obit <= '1';
              if vcnt_stbbit = 0 then
                l_mstate <= IDLE;
                l_ready <= '1'; --ready for new data
              else
                vcnt_stbbit := vcnt_stbbit-1;
              end if;
            when others => l_mstate <= IDLE;
          end case;
        else
          v_counter := v_counter - 1;
        end if;
      end if;  
    end if;
  end process P1;
PO:   process(l_obit,l_ready)
  begin
    READY <= l_ready;
    DO <= l_obit;
  end process PO;
end STRUCT;

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

MALGUCKEN schrieb:
> ich frage jetzt den Reset nach dem clk event ab.
Ein synchroner Reset, ok.
Aber: jetzt muss(!) dieser Reset auf jeden Fall auch noch synchron 
inaktiv werden. Denn sonst passiert das da:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Sieh dir auch das und die verlinkten Posts dazu an:
http://www.lothar-miller.de/s9y/categories/34-Getakteter-Prozess

Und wenn NDATA ein externer (und damit meist asynchroner) Eingang ist, 
dann muss der natürlich auch einsynchronisiert werden.

Übrigens: nur Schulen arbeiten mit "bit". Der Rest der Welt nimmt 
std_logic...

[MALGUCKEN (Gast)]

Lothar M. schrieb:
> Übrigens: nur Schulen arbeiten mit "bit". Der Rest der Welt nimmt
> std_logic...

:D ja und in dem Buch wird ein ganzes Kapitel über Vor- und Nachteile 
von std_logic und bit verschwendet. Die Grundaussage war, das man bit 
verwenden soll wenn man std_logic nicht benötigt. Wo und Nachteile?

Lothar M. schrieb:
> Und wenn NDATA ein externer (und damit meist asynchroner) Eingang ist,
> dann muss der natürlich auch einsynchronisiert werden.

Tut mir leid da komme ich nicht mit. Ich habe deinen Beitrag gelesen und 
die Links dazu. Dort steht nur, das die reset nach dem clk event folgen 
soll. Meinst du mit "einsynchronisiert", dass das Signal extern auch mit 
clk event erzeugt werden soll? Oder soetwas:

architecture bla of blbla is
signal l_reset:bit := '1';
begin
SYNC: process(CLK)
 begin
  if CLK'event and CLK='1' then
    l_reset <= RESET;
  end if;
 end process SYNC;
....

[berndl (Gast)]

MALGUCKEN schrieb:
> Lothar M. schrieb:
>> Übrigens: nur Schulen arbeiten mit "bit". Der Rest der Welt nimmt
>> std_logic...
>
> :D ja und in dem Buch wird ein ganzes Kapitel über Vor- und Nachteile
> von std_logic und bit verschwendet. Die Grundaussage war, das man bit
> verwenden soll wenn man std_logic nicht benötigt. Wo und Nachteile?

Falls du jemals auf die Idee kommen solltest, einen VHDL Simulator zu 
verwenden, dann wuerde der dir mit 'std_logic(_vector)' wunderschoen 
Konflikte und nicht initialisierte Signale anzeigen. Und das ist beim 
entwickeln ein Riesenvorteil. Frueher hat man mal wegen der 
Laufzeit/Rechenleistung darueber rumdiskutiert, ist aber heute kein 
Thema mehr...

Und uebrigens: Warum diese komplett unnoetigen Variablen? Die 
Nebeneffekte von Variablen ggue. Signalen sind dir hoffentlich bekannt?

[berndl (Gast)]

MALGUCKEN schrieb:
> Lothar M. schrieb:
>> Und wenn NDATA ein externer (und damit meist asynchroner) Eingang ist,
>> dann muss der natürlich auch einsynchronisiert werden.
>
> Tut mir leid da komme ich nicht mit. Ich habe deinen Beitrag gelesen und
> die Links dazu. Dort steht nur, das die reset nach dem clk event folgen
> soll. Meinst du mit "einsynchronisiert", dass das Signal extern auch mit
> clk event erzeugt werden soll?

Ein in VHDL beschriebener asynchroner Reset ist jetzt erstmal nix 
verwerfliches, der mag ja in deiner Chiparchitektur besser implementiert 
sein als ein synchroner. Ausserdem sichert er dich gegen Fehlfunktion 
ab, falls mal der Takt gar nicht loslaeuft (Quartz kaputt, PLL laeuft 
nicht an, ...)

ABER: Wenn du den Reset 'deaktivierst', dann must du auch dafuer sorgen, 
dass innerhalb eines Taktes ALLE daran haengenden Flipflops das 
deaktivieren 'sehen'. Sonst laeuft evtl. ein Zaehler falsch los (z.B. 
Bit(0) sieht den weggehenden Reset erst einen Takt spaeter) oder eine 
State-Machine steht im Wald...
Und deine Toolchain kann dir in diesem Fall nur helfen, wenn der Reset 
'synchron' weggenommen wird, ansonsten ist raten angesagt...

[MALGUCKEN (Gast)]

berndl schrieb:
> Und uebrigens: Warum diese komplett unnoetigen Variablen? Die
> Nebeneffekte von Variablen ggue. Signalen sind dir hoffentlich bekannt?

Die Nebeneffekte von Variablen sind mir leider nicht bekannt. und ja 
signal verwende ich auch. Bitte erklären

Danke

[berndl (Gast)]

MALGUCKEN schrieb:
> Die Nebeneffekte von Variablen sind mir leider nicht bekannt. und ja
> signal verwende ich auch. Bitte erklären

Eine Variable kannst du ja nur in einem sequenziellen, getakteten 
'process' verwenden. Sie nimmt einen ihr zugewiesenen Wert sofort an. 
Falls du aber diese Variable 'vorher' im Prozess schon abfragst, dann 
ist das der Ausgang eines Flipflops, also einen Takt spaeter. Und das 
kann ganz schoen verwirrend sein...

Ein Signal, das in einem 'process' verwendet wird, aendert seinen Wert 
erst, wenn du am 'end process;' ankommst, d.h. im ganzen Prozess hat das 
Signal den gleichen Wert. De facto also immer ein Flipflop.

Falls du sowas wie eine Variable brauchst (Zwischenergebnis einer 
Berechnung oder sowas), dann kannst du das auch als Signal ausserhalb 
eines Prozesses mit sogenannten 'concurrent' Anweisungen machen, also 
z.B. "a <= '1' when xy = '0' else '0';" Das wirkt dann wie eine Variable 
in einem Prozess sofort. Die Gefahr bei Variablen ist dann noch 
zusaetzlich, dass sie laufzeitkritische Berechnungen gut verschleiern. 
All das hat mich dazu gefuehrt, Variablen nur fuer ganz bestimmte Zwecke 
zu benutzen und ansonsten auf 'concurrent' Anweisungen zu setzen. Dein 
Code wird dadurch eindeutiger weil klar ist: Isses ein FF oder isses ein 
Netz irgendwo in der Logik.

[berndl (Gast)]

berndl schrieb:
> Eine Variable kannst du ja nur in einem sequenziellen, getakteten
> 'process' verwenden. Sie nimmt einen ihr zugewiesenen Wert sofort an.
> Falls du aber diese Variable 'vorher' im Prozess schon abfragst, dann
> ist das der Ausgang eines Flipflops, also einen Takt spaeter. Und das
> kann ganz schoen verwirrend sein...

Gmpf, Korrektur...

Eine Variable kannst du ja nur in einem sequenziellen 'process' 
verwenden. Sie nimmt einen ihr zugewiesenen Wert sofort an. Falls du 
aber diese Variable 'vorher' im Prozess schon abfragst, dann ist das der 
Ausgang eines Flipflops/Latches, also einen Takt/Zustand spaeter. Und 
das kann ganz schoen verwirrend sein...

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

MALGUCKEN schrieb:
> in dem Buch
In welchem?

MALGUCKEN schrieb:
> Die Nebeneffekte von Variablen sind mir leider nicht bekannt. und ja
> signal verwende ich auch. Bitte erklären
Siehe den Beitrag "Variable vs Signal"


berndl schrieb:
> Ein Signal, das in einem 'process' verwendet wird, aendert seinen Wert
> erst, wenn du am 'end process;' ankommst, d.h. im ganzen Prozess hat das
> Signal den gleichen Wert. De facto also immer ein Flipflop.
Das hat mit Flipflop aber nichts zu tun. Das Signal verhält sich auch in 
einem rein kombinatorischen Prozess so.
Ob Flipflops involviert sind, sieht man am 'event (gern auch versteckt 
im rising_edge() o.ä.).

[berndl (Gast)]

Lothar M. schrieb:
> Das hat mit Flipflop aber nichts zu tun.

joh, haette ich noch auf FF/Latch aendern muessen...

[berndl (Gast)]

Lothar M. schrieb:
> Siehe den Beitrag "Variable vs Signal"

Danke fuer den Link, den hatte ich gesucht, aber gerade nicht auf dem 
Radar...

Schoen waere ja, wenn VHDL 'lokale' Signaldefinitionen im Prozess 
unterstuetzen wuerde (also z.B.

hugo : process
    signal xy : std_logic := '0';
begin
    ....
end process;

Dann waere den 'lokale Variablen' Befuerwortern viel Wind aus den Segeln 
genommen...

[MALGUCKEN (Gast)]

Lothar M. schrieb:
> MALGUCKEN schrieb:
>> in dem Buch
> In welchem?

Das bleibe ich schuldig Sitz im Zug ISBN kommt später nach.

Zu den variablen. Sehe ich das richtig das ihr empfehlt das alle 
variablen als signale geschrieben werden sollten? Aber macht das den 
code nicht noch unübersichtlicher? Wenn ich neben den normalen Signalen 
Zähler Signale usw. Habe?

Meine andere Frage mit den ndata blieb offen zwecks Synchronisation.

berndl schrieb:
> ABER: Wenn du den Reset 'deaktivierst', dann must du auch dafuer sorgen,
> dass innerhalb eines Taktes ALLE daran haengenden Flipflops das
> deaktivieren 'sehen'. Sonst laeuft evtl. ein Zaehler falsch los (z.B.
> Bit(0) sieht den weggehenden Reset erst einen Takt spaeter) oder eine
> State-Machine steht im Wald...
> Und deine Toolchain kann dir in diesem Fall nur helfen, wenn der Reset
> 'synchron' weggenommen wird, ansonsten ist raten angesagt...

Aber wie soll ich das anstellen wenn reset auf der linken oberen Seite 
des FPGAs erzeugt wird und meine Schaltung rechts unten liegt, dann habe 
ich da kein Einfluss. Das muss doch das Synthese tool sicherstellen das 
meine Signale zum CLK event da sind.

[berndl (Gast)]

MALGUCKEN schrieb:
> Aber wie soll ich das anstellen wenn reset auf der linken oberen Seite
> des FPGAs erzeugt wird und meine Schaltung rechts unten liegt, dann habe
> ich da kein Einfluss. Das muss doch das Synthese tool sicherstellen das
> meine Signale zum CLK event da sind.

Wenn deine Reset Schaltung links/oben liegt, du aber das deaktivieren 
des Resets ueber mehrere getaktete Flipflops machst, dann kann dein Tool 
ueblicherweise diese 'mehrere getakteten FFs' duplizieren und mit ein 
paar Taktzyklen Latenz das auf jeden Ort auf dem Chip verteilen. Und 
zwischen zwei FFs kann deine Toolchain auch wunderbar berechnen, ob dein 
Timing noch zu halten ist.

Sollte also damit (Takte hinzufuegen, pipelineing, ...) kein Problem 
sein, weil: Wann die Schaltung aus dem Reset rauskommt, das kann ja wohl 
nicht an ein paar mal 10 Nanosekunden abhaengen...

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

MALGUCKEN schrieb:
> Das muss doch das Synthese tool sicherstellen das meine Signale zum CLK
> event da sind.
Du sagst der Toolchain, wie schnell du es haben willst. Und die probiert 
dann, deine Anforderungen zu erfüllen und sagt es, wenn es nicht 
klappt...

[MALGUCKEN (Gast)]

Guten Abend,

ich war noch das Buch schudig welches ich verwende:
VHDL-Synthese: Entwurf digitaler Schaltungen und Systeme.
ISBN:  978-3486716771

Lothar M. schrieb:
> Du sagst der Toolchain, wie schnell du es haben willst. Und die probiert
> dann, deine Anforderungen zu erfüllen und sagt es, wenn es nicht
> klappt..

OK so weit bin ich noch nicht vorgedrungen. Ich denke das ist der 
nächste Schritt.

Vielen Dank an alle für die sehr guten Anregungen.

[Michael W. (Gast)]

MALGUCKEN schrieb:
> Entwurf digitaler Schaltungen und Systeme

gibt es eigentlich jemanden, der NICHT dieses Buch benutzt?

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

MALGUCKEN schrieb:
> VHDL-Synthese: Entwurf digitaler Schaltungen und Systeme.
Sieh dir dazu mal den 
Beitrag "Re: Verständnisproblem Xilinx XC9572 CPLD" an.
Aber evtl. sind die dort aufgezeigten Punkte ja schon behoben...


BTW: Peter Ashendens "Designers Guide to VHDL" ist auch recht brauchbar.

[Duke Scarring (Gast)]

berndl schrieb:
> Schoen waere ja, wenn VHDL 'lokale' Signaldefinitionen im Prozess
> unterstuetzen wuerde (also z.B.hugo :
Signale können 'lokal' innerhalb eines block-Statements definiert 
werden:

myblock : block
    signal xy : std_logic := '0';
    
    process
    begin
        ....
    end process;
end block;

Duke

[berndl (Gast)]

Duke Scarring schrieb:
> Signale können 'lokal' innerhalb eines block-Statements definiert
> werden:

ups, danke! Das hab' ich in der freien Wildbahn noch nie gesehen und es 
waere schoener, wenn das zwischen process und begin ginge, aber besser 
als nix

[berndl (Gast)]

hmmmm, bei Google mit "vhdl block statement" finde ich immer nur 
Erwaehnungen von 'concurrent' statements...
Kann ich in ein "block" statement auch einen "process" reinpacken?

Muss ich bei Gelegenheit mal probieren...

[Duke Scarring (Gast)]

berndl schrieb:
> block-Statements [...] freien Wildbahn
In meinem aktuellen Projekt kommen ca. 50 entitys vor. Ein einer davon 
verwende ich 'block'.
In VHDL-Beispielen aus dem Netz und in Lehrbüchern wird oft die 
kritische Codegröße gar nicht erreicht, um ein block-Statement 
einzusetzen.

Duke