zusätzliche Arbeit

Meine Frage war eher ob FPGA zusätzliche Arbeit durch diese Zeilen 
bekommt.

Denn daraus werden ja physikalische schaltungen gemacht, und wenn ich 
meine egal ob ich 1 mal oder 100000000000000000000 mal die "tick <= 
'0';" zuweisung mache - die Leitung ist vorhanden, FPGA lässt da einfach 
strom durch und entscheidet nicht jedes mal neu ob er das macht oder 
nicht (verrichtet also keine zusätzliche Arbeit im Vergleich z.B. zu 
einem mikrokontroller, der jedes mal an der Stelle '0' in den Register 
schreiben würde).

Zumindest sehe ich die Sache so, und wollte wissen ob meine Sicht 
richtig ist.

p.s. Die Idee mit dem Vergleich gegen 0 ist meiner ansicht nach richtig, 
nur habe ich so viel platz, dass es mir egal ist; FPGA macht ja beides 
in einem Takt und wird deswegen nicht langsamer

@  Dima Schmitt (onkelbenz)

>Meine Frage war eher ob FPGA zusätzliche Arbeit durch diese Zeilen
>bekommt.

Dort nicht.

>Denn daraus werden ja physikalische schaltungen gemacht, und wenn ich
>meine egal ob ich 1 mal oder 100000000000000000000 mal die "tick <=
>'0';" zuweisung mache - die Leitung ist vorhanden, FPGA lässt da einfach
>strom durch und entscheidet nicht jedes mal neu ob er das macht oder
>nicht (verrichtet also keine zusätzliche Arbeit im Vergleich z.B. zu
>einem mikrokontroller, der jedes mal an der Stelle '0' in den Register
>schreiben würde).

Richtig.

>p.s. Die Idee mit dem Vergleich gegen 0 ist meiner ansicht nach richtig,
>nur habe ich so viel platz, dass es mir egal ist; FPGA macht ja beides
>in einem Takt und wird deswegen nicht langsamer

Ich dachte du wolltest dem FPGA "Arbeit" sparen? Klar, bei 50 MHz und 
den heutigen FPGAs ist das erstmal egal. Aber wenn man effiziente und 
schnelle Schaltungen bauen will, gelten viele der alten Reglen immer 
noch, nur bei höheren Frequenzen ;-)

MfG
Falk

Dima Schmitt schrieb:
> case cur_state is
> ...
>           when count =>
>             if ( i >= 100000 ) then -- i ist die Zählvariable
>               cur_state <= pulse;
>               i := 0;
>             else
>               i := i + 1;
Das ist vermutlich die Zwei-Prozess-Schreibweise (wegen 
cur(rent)_state). Und damit ist der Zähler mit i eine (versteckte) 
kombinatorische Schleife.... :-o

http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife

Dima Schmitt schrieb:
> Ein Beispiel - ich will 20 ms abwarten, dazu zähle ich 100000 cycles ab
> (ist die Zahl übrigens richtig bei 50MHz Takt?). Also schreibe ich
> folgendes:
>           when count =>
>             if ( i >= 100000 ) then -- i ist die Zählvariable
>               cur_state <= pulse;
>               i := 0;
>             else
>               i := i + 1;
>             end if;
Nur am Rande: 0...10000 sind 10001 Zählschritte. Der Zähler wird also 
systematisch um 0,1 Promille falsch gehen....

Fetz schrieb:
> Wenn du soviel Platz hast, dann kann es dir doch egal sein, ob da noch
> ein Slice mehr oder weniger benötigt wird ...
Es geht eher darum, dass der eine zusätzliche Slice evtl. hinter den 
anderen sitzt und so die max. Taktfrequenz reduziert...

Man kann tun&lassen, was man will, aber wenn man seinen Baustein kennt, 
kann man besser bewerten, was die Konsequenzen draus sind.

Fetz schrieb:
>> Das spart dann wirklich Logik
> Mooooment ... das ist nicht ganz richtig ...
Doch, das stimmt. Leider ist dein Beispiel am Thema vorbei.

Beschreib den Enable mal so wie hier:

1

signal cnt: unsigned (7 downto 0);

2

3

  process (clk) begin -- Pulserzeugung

4

    if cnt(7)='1' then

5

        pulse <= '1';

6

        cnt   <= to_unsigned(1,8);

7

    else

8

        pulse <= '0';

9

        cnt   <= cnt+1;

10

    end if;

11

  end process;

12

13

  process (clk) begin -- Pulsauswertung

14

    if pulse='1' then

15

      ...

16

    end if;

17

  end process;

berndl schrieb:
> Eine weitere Frage ist auch, ob das 'zuruecksetzen' eines counters auf
> einen krummen Wert mehr Resourcen verbraucht als ein 'reset' auf 0
Nein, tut es nicht, solange nicht ein zusätzlicher "globaler" Reset 
definiert ist. Das hier ist schlecht:

1

  process begin -- Pulserzeugung

2

    wait until rising_edge(clk);

3

    if reset='1' then              -- synchroner Zählerreset Nummer 1 --> alle Bits auf '0'

4

      cnt <= (others=>'0');

5

    else

6

      if cnt(7)='1' then

7

        pulse <= '1';

8

        cnt   <= to_unsigned(1,8); -- synchroner Zählerreset Nummer 2 --> cnt(0) wird anders behandelt...

9

      else

10

        pulse <= '0';

11

        cnt   <= cnt+1;

12

      end if;

13

    end if;

14

  end process;

Wenn es nur 1 Reset/Preset gibt, dann kann das 1:1 auf diese Eingänge am 
Flipflop abgebildet werden. Wenn aber beim 1. Reset das FF zurückgesetzt 
und beim 2. Reset gesetzt werden soll, dann braucht das zusätzliche 
Logik.

Hallo,
was halten die Spezialisten eigentlich davon das Signal pulse 
kombinatorisch zu erzeugen?

Ich glaub zwar daß das den Pulse einen Clock nach vorn zieht, aber es 
spart ein Register?

Ciao, Günter

1

process (clk) begin -- Pulserzeugung

2

   cnt   <= cnt+1;

3

   if cnt(7)='1' then

4

      cnt   <= to_unsigned(1,8);

5

   end if;

6

end process;

7

8

pulse <= '1' when cnt(7)='1' else '0';

oder gleich

1

process (clk) begin -- Pulserzeugung

2

   cnt   <= cnt+1;

3

   if cnt(7)='1' then

4

      cnt   <= to_unsigned(1,8);

5

   end if;

6

end process;

7

8

pulse <= cnt(7);