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.
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.
1 | schreibt man eher so: |
2 | PROCESS(Dbuff, Clk) BEGIN |
3 | IF(Clk = '1') THEN |
4 | Dout <= Dbuff; |
5 | END IF; |
6 | END PROCESS; |
Dbuff muss nicht in die Sensitivity list ... oder concurrent (also ohne process):
1 | 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 ...
@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
>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 ...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.