Synchrones Programmieren

[Sebastian (Gast)]

Hallo zusammen,

in VHDL beschriebene Schaltungen ist ratsam sich an einen Takt zu
synchronisieren. Ich frage mich ob der folgende Codesnippet
richtig/professionell ist (evtl. falsche Semantik übersehen sind nur
zusammen kopierte Auszüge):

UART_SYNC_CNT: process (sUART_AllReset, sDCM_FX_25MHz) 
begin
  if rising_edge (sDCM_FX_25MHz) then
    --Reset Registers 
  else 
    if sUART_SyncCnt >= 2080 then
      sUART_SyncCnt <= 0;
      sUART_SyncCntOverflowTick <= '1';  -- Erzeuge Flanke
    else
      sUART_SyncCnt <= sUART_SyncCnt + 1;
      sUART_SyncCntOverflowTick <= '0';  -- "Lösche" Flanke
    end if; 
  end if;   
end process;


UART_DATA_BIT_CNT: process (sUART_AllReset, sDCM_FX_25MHz)
begin
  if rising_edge (sDCM_FX_25MHz) then
    --Reset Registers
  else
    if sUART_SyncCntOverflowTick = '1' then  
      -- Ein Bit sampeln (Ins Schieberegister klopfen)
      -- BitCnt eins hochzählen...
     else
       null;
     end if;
   end if
end process;

Meine Frage funktioniert (in der Simulation schon) zuverlässig die
Sache mit dem sUART_SyncCntOverflowTick = '1'??? Ich meine der Tick
ist nur für eine halbe Periode da. Aber alles müßte synchron sein. Ich
als C-Progammierer habe aber da ein paar bedenken....

MfG Sebastian

[Sebastian (Gast)]

kleine Verbesserung im Code, sorry. Die Resetabfrage nachkopiert.

UART_SYNC_CNT: process (sUART_AllReset, sDCM_FX_25MHz) 
begin
  if rising_edge (sDCM_FX_25MHz) then
  if sreset = '1';
    --Reset Registers 
  else 
    if sUART_SyncCnt >= 2080 then
      sUART_SyncCnt <= 0;
      sUART_SyncCntOverflowTick <= '1';  -- Erzeuge Flanke
    else
      sUART_SyncCnt <= sUART_SyncCnt + 1;
      sUART_SyncCntOverflowTick <= '0';  -- "Lösche" Flanke
    end if; 
  end if;   
end process;


UART_DATA_BIT_CNT: process (sUART_AllReset, sDCM_FX_25MHz)
begin
  if rising_edge (sDCM_FX_25MHz) then
  if sreset = '1';
  --Reset Registers
  else
    if sUART_SyncCntOverflowTick = '1' then  
      -- Ein Bit sampeln (Ins Schieberegister klopfen)
      -- BitCnt eins hochzählen...
     else
       null;
     end if;
   end if
end process;

[Xenu (Gast)]

>Ich meine der Tick ist nur für eine halbe Periode da.

Das Signal ist nicht eine halbe, sondern ein ganze Periode 1.
Und ja, das funktioniert.

>Ich als C-Progammierer habe aber da ein paar bedenken....

Wieso? Welche? Und was hat C mit VHDL zu tun?

[FPGAküchle (Gast)]

paar Kleinigkeiten:

da synchrone reset braucht nur der takt in die Sens. list

UART_SYNC_CNT: process (sDCM_FX_25MHz)

gleich größer statt gleich kostet nur Hardware

if sUART_SyncCnt = 2080 then

Hm wass soll das null da, lass den else zweig weg.

 else       null;     end if;

[Sebastian (Gast)]

hui, das geht aber schnell... :-)

@FPGAküchle
Hast mit allem Recht ( natürlich ;-) ).

else null; end if;

Ich hab' da im orginal Code noch ein paar Kleinigkeiten drin
stehen...

@Xenu
Stimmt das Signal ist ein ganze Periode. Peinlich... von rising to
rising ist eine ganze.....

>>Ich als C-Progammierer habe aber da ein paar bedenken....

>Wieso? Welche? Und was hat C mit VHDL zu tun?

Na der Process UART_SYNC_CNT setzt das Signal mit der steigenden Flake
von sDCM_FX_25MHz auf eins. Der Process UART_DATA_BIT_CNT überprüft mit
derselben Flanke den Pegel des Signals. Meine BEDENKEN: Ist den das
Signal schon auf eins eingeschwungen, wenn der Process
UART_DATA_BIT_CNT das Signal abfragt??????????????????????????

Danke für die Diskussion "BEDENKEN" (ist mir sehr wichtig),
Sebastian

[FPGAküchle (Gast)]

#Na der Process UART_SYNC_CNT setzt das Signal mit der steigenden
#Flake
#von sDCM_FX_25MHz auf eins. Der Process UART_DATA_BIT_CNT überprüft
#mit
#derselben Flanke den Pegel des Signals. Meine BEDENKEN: Ist den das
#Signal schon auf eins eingeschwungen, wenn der Process
#UART_DATA_BIT_CNT das Signal abfragt??????????????????????????


sDCM_FX_25MHz sieht die eins einen Takt später, also mit der folgenden
steigenden Flanke.
Das klappt natürlich nur wenn die taktfrequenz nicht höher ist als der
FPGA kann. Aber das sagen dir die tools.

Falls Dir das zu spät ist musst du den counter im anderen Prozess eins
weniger zählen lassen.

[Sebastian (Gast)]

Warum sieht der Process UART_DATA_BIT_CNT das Signal
sUART_SyncCntOverflowTick einen Takt später. Wegen des FlipFlop
verhaltens???

[FPGAküchle (Gast)]

Ja FF. Das setzen des FF braucht seine Zeit (clock to output Zeit)
In der simualtion einen delta cycle.

Da aber der andere Prozess auch zur Flanke das signal überprüft (und
nicht einen delta cycle oder clocktooutput Zeit + propagation delay,
sieht er noch den alten Wert. Im folgenden Takt sieht der zweite dann
die '1', während der erste Prozess das signal auf '0' setzt.

[Sebastian (Gast)]

Ok, danke. Das in der Simulation habe ich kapiert mit den
Delta-Zeiten.In der Simulation erfolgt die Signalzuweisung erst dann,
wenn alle im vorherigen Simulationszyklus aktivierten Prozesse
abgearbeitet wurden.Dann wird eine Delta-Zeit vorgerückt und die
Signale zugewiesen.....Das kann ich auch bei genauem hinsehen in der
Simulation erkennen.

Mit der Hardware habe ich noch ein paar Vorstellungsprobleme. Ich habe
mir das synthetisierte Schematic mal angesehen. Bitte korrigierts mich
wenn folgendes nicht stimmt.

Für ein Signal wird ein Speicherelement angelegt, im Schematic kann ich
nur FDEs finden.
Mein process beinhaltet eine Logikschaltung die auch Zeit (viel kleiner
als eine Periode) braucht.
So in ein FDE muss ich auch das angelegte Datum (Signal) einclocken.
Welche Flanke bleibt den da noch zum einclocken, die erste Flanke ist
ja schon vorbei. Die Fallende??? Kann ich aber im Schematic nicht
erkennen.

Mit einem Latch könnte ich mir das alles vorstellen, aber ein LATCH
taucht nicht auf im Schematic....

Vielen Dank mal wieder für Eure Geduld,
Sebastian.

[FPGAküchle (Gast)]

Sorry aus Zeitgründen kann ich hier erstmal nicht weitermachen. Morgen
gehts für 3 wochen nach Kalifornien.

[Klaus F. (kfalser)]

In Hardware ist es das selbe wie in der Simulation, sonst hätte die
Simulation ja keinen Sinn.

Dein Prozess UART_DATA_BIT_CNT erkennt sUART_SyncCntOverflowTick genau
eine Taktflanke später.
Ob die steigende oder fallende Flanke verwendet wird hängt von deinem
VHDL Programm ab. In Deinem Fall hast Du für die Abfrage von
sUART_SyncCntOverflowTick  im Prozess UART_DATA_BIT_CNT die steigende
Flanke verwendet, folglich wird an der nächsten steigenden Taktflanke
das Signal eingeclockt.
In der (funktionalen) Simulation ist die Verzögerung zwischen
steigender Taktflanke und dem Setzen von sUART_SyncCntOverflowTick
genau 1 Delta-Cycle, in Hardware ist es die Verzögerungszeit der ersten
Flip-Flops. In beiden Fällen bewirkt dies, daß im 2. Prozess das Signal
an der 1. Flanke noch nicht erkannt wird, an der nächsten Flanke jedoch
schon.
Grüße
Klaus

[Sebastian (Gast)]

Hallo,

danke für Eure Bemühungen ich glaub ich weiß' wie es in der Hardware
funktiniert. Ich werde aber nochmals genau recherchieren. Dann werde
ich natürlich posten...

@FPGAküchle
Schönen Urlaub :-), oder Arbeit...

MfG,
Sebastian

[BaldHabenWirTest (Gast)]

Hi

also ich hätte kein frage zum programmieren selbst sondern eher mehr
Theorie..

-Was passiert bei Synchronisation der Eingänge/Ausgänge ? Was passiert
da ? ..Wenn keine Synchronisation vorhanden ist, können Glitches
enstehen oder ?

- Was ist unterschied zwischen asynchronen reset und synchronen reset ?
und welche probleme können hier auftreten ?

- Was sind die Timinganforderungen ? - dass TimeVonEL + SetupTime +
TimeVonMetastabilität(was ist das bitte für eine Zeit..Metastabilität
das ja wenn sich 'D' bei einem FlipFlop genau zur Clockflanke ändert
und somit zufällig 'Q' '0' oder '1' wird) nicht größer sind als
eine Clockflanke ?

und zuletzt..

- Unterschied zwischen synchronen Handshake und asynchronen Handshake
!

wäre euch sehr dankbar dafür !

[FPGAküchle (Gast)]

zum synchronizer ein paar Folien von ner Ami-Uni:

http://www.stanford.edu/class/ee183/handouts_spr2003/synchronization_pres.pdf

Vorteile von synchronenen reset hängen auch von der Architektur ab.
Xilinx beschreibt das recht gut z.B. designs bei denen Reset nicht
erforderlich und wie man FF in VHDL zwecks kleinen Design beschreibt:

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset


http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=kc_priorities&iLanguageID=1&iCountryID=1

[Brielinger (Gast)]

>ich glaub ich weiß' wie es in der Hardware
>funktiniert.

Glaub ich nicht. Das wissen manchmal nichtmal die Vollprofis auf dieser
Page...

Das Prinzip ist einfach. Die Details wirst Du so nie erfahren...

[k.. (Gast)]

k..das is jetzt alles so ziemlich klar..nur..den UNterschied zwischen
synchronen handshake und asynchronen handshake kapier ich immer noch
nicht..kann mir vielleicht da einer das prinzip erklären? [was
allgemein ein handshake is weiß ich.. :D]

lG

[FPGAküchle (Gast)]

Hm, ich kenn nur handshake. Was meinst Du oder wo hast was gelesen von
synchron und asynchron Handshake.

(Hehe wir das wohl auf dt. heisst? Handschütteln mit Zeit und
Handschütteln ohne Zeit. Oder gehts um die Uhr, also schüttelt man die
Hand mit der Armbanduhr oder die ohne ... Gaga ich krieg noch die
Rechnerhacke hier ...)

[k.. (Gast)]

naja..synhronen und asynchronen handshake haben wir in der schule
"gelernt" ..haben darüber weder was aufgeschrieben noch
aufgezeichnet, jedoch kommt das morgen zum test und ich hab bis jetzt
kA was da der unterschied sein soll..^^