Qam-16 encoder / decoder Projekt

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
>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 ;-)

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

>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

1

:

2

signal div1M  : integer;

3

signal div10M : integer;

4

signal ce1M   : std_logic;

5

signal ce10M  : std_logic;

6

:

7

:

8

   process (clk100M) -- z.B. 100MHz-Takt 

9

      if rising_edge(clk100M) then

10

         ce1M   <='0';

11

         ce10M  <='0';

12

         div10M <=div10M+1;

13

         if (div10M=9) then

14

            div10M <=0;

15

            div1M  <=div1M+1;

16

            ce10M  <='1';       -- 10 MHz clock-enable

17

         end if;

18

         if (div1M=9) then

19

            div1M  <=0;

20

            ce1M   <='1';       -- 1 MHz clock-enable

21

         end if;

22

      end if;

23

   end process;

24

25

   process (clk100M) -- 100MHz-Takt 

26

      if rising_edge(clk100M) then

27

         if (ce10M='1') then -- Arbeit für 10 MHz

28

            :

29

            mach was...

30

            :

31

         end if;

32

      end if;

33

   end process;

34

35

   process (clk100M) -- 100MHz-Takt 

36

      if rising_edge(clk100M) then

37

         if (ce1M='1') then -- Arbeit für 1 MHz

38

            :

39

            mach was...

40

            :

41

         end if;

42

      end if;

43

   end process;

44

:

45

:

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.

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