Warum klappt seriell zu parallel mit FF

[CheckNix (Gast)]

Hallo,

mal eine Frage wegen Timing beim seriell zu parallel.

Ich  möchte über ein Shiftregister Daten von seriell nach parallel 
konvertieren. Dazu verwende ich ein Schiftregister und einen Counter der 
entscheidet wann die daten parallel ausgelesen werden können.

------------------------------------------------------------------------ 
--

vereinfachtes Beispiel: seriel zu 4bit parallel

counter: process(clk)
if reset = '1'then
counter = 4;
else if rising_edge(clk) then
  counter <= counter - 1;
  if counter = 0 then
  data_bereit <= '1';
  else
  data_bereit <= '0';
  end if;
end if;
end process;

FF_Shift: process(clk)
begin
if rising_edge(clk) then
  FF(3 downto 0) <= FF(2 downto 0) & Data_Seriell; -- shift nach links
end if;
end process

process(clk)
begin
if rising_edge(clk) then
  if data_bereit = 1 then
    data_parallel(3 downto 0) <= FF(3 downto 0);
  end if;
end if;
end process;

------------------------------------------------------------------------ 
--

Laut Simulation funktioniert das auch sehr gut. Aber ich frage mich nun 
ob das auch immer auf der Hardware gut geht. Was wenn das Shiftregister 
früher schiftet als die Zuweisung an data_parallel erfolgt. Dann hätte 
ich ja entweder einen metastabilen Zustand bei dem alles sein kann oder 
ich hab bekomme eben den Zustand der erst ein clk später im FF stehen 
dürfte.

Kann mir jemand erklären ob und wen ja warum das immer funktioniert.
Gibt es bessere alternativen um von seriell zu parallel zu kommen?

Vielen Dank

[voodoofrei (Gast)]

CheckNix schrieb:
> Kann mir jemand erklären ob und wen ja warum das immer funktioniert.

deshalb:

if rising_edge(clk) then

ohne den Takt hättest du recht.

Der Wert steht erst einen Takt später am Ausgang.

[Entwickler12345 (Gast)]

Hallo,

Du solltest aber auch ein Timing Constraint(Period bei Xilinx) 
verwenden, damit du auch sicher sein kannst, dass du dein Timing 
schaffst.
Aber die Simulation sollte bei dir nicht richtig funktionieren, weil du 
ein AR verwendest und dieses in deiner Sensitivity Liste fehlt.

Gruß

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

Entwickler12345 schrieb:
> Aber die Simulation sollte bei dir nicht richtig funktionieren, weil du
> ein AR verwendest und dieses in deiner Sensitivity Liste fehlt.
Siehe zu diesem Thema den Beitrag "Detailfrage Reset"

[Klaus F. (kfalser)]

CheckNix schrieb:
> Kann mir jemand erklären ob und wen ja warum das immer funktioniert.

In der Simulation funktioniert das immer richtig, weil die Prozesse alle 
"gleichzeitig" auf rising_edge() reagieren.
Die Prozesse werden natürlich vom Computer hintereinander berechnet, 
aber alle Eingangssignale aller Prozesse bleiben stabil auf dem alten 
Wert, bis alle Prozesse durchgerechnet sind.
Dann erst werden den Signalen die neu berechntet Werte zugewiesen, die 
Signale ändern sich also erst danach.

In der Hardware funktioniert dies ebenfalls immer richtig, weil alle 
FF's mehr oder weniger gleichzeitig schalten, es aber eine gewisse Zeit 
braucht, bis die Ausgangsignale am Ausgang erscheinen.
Der Hersteller des FPGA garantiert, dass die Signale an den Ausgängen 
der FFs "langsam" genug zu den Eingängen der nächsten FFs kommen und 
diese garantiert erst an der nächsten Taktflanke das geänderte Signal 
sehen.

> Gibt es bessere alternativen um von seriell zu parallel zu kommen?
Nicht dass ich wüsste.

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

Klaus Falser schrieb:
> aber alle Eingangssignale aller Prozesse bleiben stabil auf dem alten
> Wert, bis alle Prozesse durchgerechnet sind.
Kurz: während dieser Berechnung bleibt die Simulationsuhr stehen. Die 
nacheinander berechneten Ergebnisse sind also alle für den selben 
Simulationszeitpunkt gültig.