Qam-16 encoder / decoder Projekt

[Richard K. (richardk)]

Hallo Liebe Leute

Zuerst, stelle ich mich kurz vor, da ich neu bei euch im Forum bin.
Heisse Richard K., komme aus der Schweiz und werde in ein paar Tagen 
26ig.
Beruflich als Elektroniker tätig, im Bereich Power DC/DC, Umrichter F&E. 
usw.
Nebenberuflich zur Zeit am Abendstudium zum Elektrotechniker HF.

Hobby's, Hauptsächlich Elektronik und Laser.

Neu, erkunde ich die Welt der FPGA's. Dazu kam ich, nach dem ich dem
Aufwand für mein neustes Hobby Projekt abzuschätzen begann.

Entschieden habe ich mich für die Altera Produkte. Folgende Beweggründe,
die mich dazu führten:
- Der Workflow von Quartus sagt mir mehr zu als der der ISE von Xilinx.
- Deutlich mehr Verfügbarkeit vor allem in Gehäusen mit Beinchen bei 
Distributoren ala Farnell.
- Ansprechendes Preis- / Leistungs- Verhältnis des DE1 Boards.

Nun zu meinem Projekt:

100Base-T -> MII -> Qam-16 I & Q -> Optisch ->I & Q  Qam-16 -> MII -> 
100Base-T

Okay, wohl nicht das optimale Einsteiger Projekt.

Geplante Hardware:
FPGA -> EP2C5T144C8N
PHY   -> DP83848C
ADC  -> AD9218
DAC  -> DAC2900

In einem ersten Schritt, möchte ich nur die Umsetzung von dem MII 
Interface
auf die I & Q Signale vom Qam-16 mit dem FPGA realisieren.
Falls, das Ganze je einmal läuft, könnte man auf der bestehenden
Hardware mit Software Filterung usw. weiter optimieren.
In einem weiteren Schritt die Qam HF direkt aus einem schnellen DAC 
prügeln.

Nun als Fazit, an VHDL werde ich nicht vorbeikommen..  und, ja ich bin
damit schon auf die Schnauze geflogen :-)

Nun, zu meinen Fragen:

- Wie ich bisher mich belesen habe, scheint mein bisheriges Design wohl 
Asynchron zu sein.
  Wenn ich mir das Timing ansehe, dann ist das schlecht für mein 
Vorhaben.
  Ausserdem wird vielerorts von D-flipflop & Ansyncron abgeraten.
  Wo, gibt es Literatur, wie man sinvoll, ein synchrones Projekt planet?
  z.B. ein vorbildliches Beispielprojekt.

- Bisher dachte ich, 25Mhz sind für einen FPGA eine eher einfachere 
Übung.
   Okay, wohl einfacher zu beherrschen als ein  74X Gatter Haufen 
welcher
   8 digitale Fensterkomperatoren repräsentiert.
   Bin ich einfach noch so was von unfähig, oder sind die Glitches 
welche man
   in meiner Simulation sieht doch so normal das man damit leben muss?

Pahh..  weitere Frage traue ich mich zur Zeit gar nicht zu formulieren.
Sehr mein Projekt resp. mein VHDL Desaster an, und helft mir auf den 
richtigen
Weg zu kommen.

Siehe Anhang.

Danke, für jede kleinste Unterstützung Richard K.

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

Fang nicht so was Komplexes als allererstes an. Das frustriert.

Kauf dir ein EVAL-Board und programmier selber eine Runde Pong oder 
Space-Invaders drauf. Richtig: die Spiele aus den 80ern.
Eingabe: PS2-Tastatur oder RS232
Ausgabe: Lautsprecher und VGA-Monitor
Vorteil: Man sieht und hört, was man programmiert hat

Wenn das geht, hast du mal die Grundlagen zum Thema VHDL bestanden.
dann kommt sowas wie in deinem Anhang nicht mehr vor.
z.B: viermal hintereinander:
PROCESS(Dbuff(0), Clk) BEGIN
   IF(Clk = '1') THEN
  Dout(0) <= Dbuff(0);
   END IF;
END PROCESS;

schreibt man eher so:
PROCESS(Dbuff, Clk) BEGIN
   IF(Clk = '1') THEN
  Dout <= Dbuff;
   END IF;
END PROCESS;

oder concurrent (also ohne process):
Dout <= Dbuff when Clk='1' else Dout;

Aber eigentlich sollte man sich ohne Not (und vielleicht sogar, ohne 
dass man weiß was man da tut) keine Latches auf den Clock bauen.


Synchrones Design heisst etwas vereinfacht: NUR 1 TAKT
Im ganzen Design. Klappt erstaunlich oft.


Die Glitches in deinem Design kommen von Übergängen zwischen den 
Taktdomänen, das bringt dein Design im Real-Life um. Denn da sind dann 
die Takte ein bischen unabhängiger, und du kriegst ab+an mal eine Setup- 
oder Hold-Zeit-Verletzung an einem FF mit anschliessenden eigenartigem 
Verhalten. Garantiert.


Literatur
Jürgen Reichardt, Bernd Schwarz: VHDL-Synthese


>Der Workflow von Quartus sagt mir mehr zu als der der ISE von Xilinx...
Der Workflow ist bei allen (SRAM-)FPGAs annähernd gleich, und eine IDE 
darf niemals (oder erst ganz am Schluss) ein Entscheidungskriterium 
sein.
Mehr Unterstützung wirst du hier mit der Zielplattform Xilinx 
erhalten.

[Gast (Gast)]

schreibt man eher so:
PROCESS(Dbuff, Clk) BEGIN
   IF(Clk = '1') THEN
  Dout <= Dbuff;
   END IF;
END PROCESS;

Dbuff muss nicht in die Sensitivity list ...

oder concurrent (also ohne process):

Dout <= Dbuff when Clk='1' else Dout;

Uff ... was gibst denn du für Tipps??? Richard sollte das so schnell wie 
möglich wieder vergessen ...

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

@Gast
>Uff ... was gibst denn du für Tipps??? Richard sollte das so schnell wie
>möglich wieder vergessen ...
den da:
>Aber eigentlich sollte man sich ohne Not (und vielleicht sogar, ohne
>dass man weiß was man da tut) keine Latches auf den Clock bauen.

Sieh dir den Original-Quelltext genau an:
>>PROCESS(Dbuff, Clk) BEGIN
>>   IF(Clk = '1') THEN         <-------------  hier passierts
>>      Dout <= Dbuff;
>>   END IF;
>>END PROCESS;
>:
>Dbuff muss nicht in die Sensitivity list ...
Oh doch, der Clk trägt seinen Namen ganz zu Unrecht: das ist ein 
high-aktives transparentes Latch, kein D-Latch (da fehlt Clk'event). 
Solange Clk='1' ist, ist Dout nur von Dbuff abhängig. Deshalb muss Dbuff 
in der Sens-List (Die Original-Idee kommt nicht von mir, die kommt von 
Richard).


Das Kind liegt schon im Brunnen (Designwunsch, Zielhardware, IDE...), 
ich gebe ihm nur etwas Wasser, damit es nicht verdurstet. Sieh dir 
meinen 2. Abschnitt an ;-)

[Richard K. (richardk)]

Hallo Leute

Vielen Dank für eure Antworten.
Ich sehe schon, dass das keine einfache Geburt wird.

Dem Literatur Tipp, werde ich nachgehen.
"Jürgen Reichardt, Bernd Schwarz: VHDL-Synthese"

Das DE1 Demobord habe ich mir bereits bestellt.
Zum rumspielen und üben.

Jedoch möchte ich, wenn möglich paralell dazu
an meinem Projekt basteln. Da steht noch so viel
Detail Arbeit an, Schema, Layout mit
allen Impedanz Geschichten usw..
das ich mir erhoffe, nebenbei mir VHDL Kentnisse
aneignen zu können.

Lieber sehe ich einen gewissen Fortschrit des Projektes
am Logicanalyzer als Pong oder so zu programieren.

Werd nun mal mein D-Latch Problem versuchen zu lösen.
Mühsam ernährt sich das Eichhörnchen.


Gibt es hier in der Schweiz, am liebsten im Raum
St.Gallen einen FPGA Jünger, der sich
zu einer Tasse Kaffe bereit erklären würde
um mir die brennensten Fragen / Wegleitungen
zu beantworten, resp. nahelegen könnte?

Dann könnte ich wohl auch gezieltere Fragen stellen,
resp. wüsste wo ich zuerst selber gezielt nachlesen könnte.

Gruss RichardK

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

>Mühsam ernährt sich das Eichhörnchen.
Und Einsicht ist der beste Weg zur Besserung ;-)

Ein synchrones Design in der einfachsten Form ist eines mit nur 1 
Taktquelle.
Dieser Takt geht an alle FFs. Alle langsameren Komponenten werden nur 
über einen entsprechenden Clock-Enable aktiviert.

z.B. so
Grundfrequenz 100MHz
abgeleitete clock-enables 10 MHz und 1 MHz

:
signal div1M  : integer;
signal div10M : integer;
signal ce1M   : std_logic;
signal ce10M  : std_logic;
:
:
   process (clk100M) -- z.B. 100MHz-Takt 
      if rising_edge(clk100M) then
         ce1M   <='0';
         ce10M  <='0';
         div10M <=div10M+1;
         if (div10M=9) then
            div10M <=0;
            div1M  <=div1M+1;
            ce10M  <='1';       -- 10 MHz clock-enable
         end if;
         if (div1M=9) then
            div1M  <=0;
            ce1M   <='1';       -- 1 MHz clock-enable
         end if;
      end if;
   end process;
       
   process (clk100M) -- 100MHz-Takt 
      if rising_edge(clk100M) then
         if (ce10M='1') then -- Arbeit für 10 MHz
            :
            mach was...
            :
         end if;
      end if;
   end process;

   process (clk100M) -- 100MHz-Takt 
      if rising_edge(clk100M) then
         if (ce1M='1') then -- Arbeit für 1 MHz
            :
            mach was...
            :
         end if;
      end if;
   end process;
:
:

Das könnte man noch anders und kompakter schreiben, aber die Idee dürfte 
klar sein: Es gibt nur 1 Takt (100MHz), der in alle getakteten Prozesse 
eingeht. Langsamere Teile des FPGAs werden mit clock-enables gesteuert.

[Richard K. (richardk)]

Vielen Dank für das anschauliche Beispiel.

Ich habe nun meinen Qam 16 encoder / decoder überarbeitet
und bin nun schon weit eher mit dem Ergebnis zufrieden.

Nach Anpassung des D-Latch Problems sehen
meine Signale schon deutlich besser aus.
Nun frage ich mich, geht es noch perfekter oder
sind diese übrig gebliebenen Gliches "normal"?
(siehe Anhang)

Jedoch muss irgend ein Fehler noch drin stecken.
Wenn ich mir im Timing TXD_MII..  ansehe, sollte dort
das selbe herauskommen wie bei RXD_MII.. reingeht.
TXA_ADC.. -> I & TXB_ADC -> Q scheinen zu stimmen.

Gruss Richard

[Gast (Gast)]

>Sieh dir den Original-Quelltext genau an:
>>>PROCESS(Dbuff, Clk) BEGIN
>>>   IF(Clk = '1') THEN         <-------------  hier passierts
>>>      Dout <= Dbuff;
>>>   END IF;
>>>END PROCESS;
>>:
>>Dbuff muss nicht in die Sensitivity list ...
>Oh doch, der Clk trägt seinen Namen ganz zu Unrecht: das ist ein
>high-aktives transparentes Latch, kein D-Latch (da fehlt Clk'event).

Ohoh ... Ja, du hast recht ... Ich hab das clk'event implizit 
dazugedichtet ... Das kommt davon, wenn man an sowas einfach nicht mehr 
denkt, weil es zu unsauber ist g

Sorry für meinen Kommentar, du hast natürlich recht ...