Bin VHDL Anfänger, im Anhang mein VHDL-Code für den LTC2624 auf dem Spartan3E Board. Ich habe dieses Modul hinter einen BlockRAM gehangen und bekomme das Ausgangssignal welches ich erwarte - funktioniert also! :) Es sollen mit einer Sample-Clock (liegt bei 300 kHz) zwei neue Kanäle geladen werden und dann ziemlich zügig an den DAC geschickt werden (dafür verwende ich direkt die 50 MHz vom Oszillator). Das laden erfolgt sequentiell (da die Signale bis zur nächsten steigenden Flanke der Sample-Clock gültig sein sollten). Das DAC-Update erfolgt mit Ende des Transfer des zweiten Kanals. Da die beiden Kanäle hintereinander an den DAC geschickt werden müssen, habe ich mich für eine State-Machine entschieden. Generell würde ich gerne wissen, wie man das besser machen kann (ohne die Funktion grundlegend zu verändern :)). Dann finde ich diese selbst gestrickte Flankenerkennung für SampleClk irgendwie Murks - wie kann man das besser lösen? Ich möchte die neuen Samples halt mit der steigenden Flanke von SampleClk ausgeben, damit ich eine möglichst hohe Sample-Clock erreichen kann. Ich hatte erst versucht in einen separaten Prozess, asynchron zum eigentlichen CLK auf SampleClk zu reagieren und die Werte zu laden. Aber ich wüsste nicht, wie ich die beiden Prozesse dann vernünftig synchronisieren könnte. Habe auch festgestellt, dass WHEN-Anweisungen anscheinend nicht in Prozessen funktionieren :) Gibt es dafür eine alternative Kurzschreibform anstatt jedes mal "IF"/"ELSE"/"END IF"?
Marius S. schrieb: > Habe auch festgestellt, dass WHEN-Anweisungen anscheinend nicht in > Prozessen funktionieren :) > Gibt es dafür eine alternative Kurzschreibform anstatt jedes mal > "IF"/"ELSE"/"END IF"? Nein. Aber dafür funktioniert if-then-else nicht ausserhalb von Prozessen. Ja, das ist VHDL: unterschiedliche Syntaxelemente für Prozesse und nebenläufige Anweisungen... Marius S. schrieb: > Generell würde ich gerne wissen, wie man das besser machen kann (ohne > die Funktion grundlegend zu verändern :)). Hmmm, wie willst du was verbessern, wenn du nichts ändern willst? Das gibt mir zu denken: DAC_CLK <= CLK; Woher kommt denn dieser CLK? Welche Frequenz hat der? Das gibt mir auch zu denken: USE IEEE.NUMERIC_STD.ALL; USE IEEE.STD_LOGIC_UNSIGNED.ALL; Die STD_LOGIC_UNSIGNED ohne die STD_LOGIC_ARITH nützt kaum was. Und die beiden zusammen darfst du nie mit der NUMERIC_STD verwenden. Seltsame Fehler können und werden die Folge sein. Lies mal den Beitrag "Änderung des Gehäuses erzeugt Compilation Fehler"
Lothar Miller schrieb: > Hmmm, wie willst du was verbessern, wenn du nichts ändern willst? Naja, es gibt ja mehrere Arten das ganze zu beschreiben. Vielleicht hätte man das auch ohne State-Machine beschreiben können. Lothar Miller schrieb: > Das gibt mir zu denken: > DAC_CLK <= CLK; > Woher kommt denn dieser CLK? Welche Frequenz hat der? An CLK habe ich den 50 MHz Oszillator direkt verbunden. Ich könnte das Signal noch irgendwie "Gaten", so dass es nur durchgeschaltet wird, wenn tatsächlich ein Wert übertragen wird. Lothar Miller schrieb: > Das gibt mir auch zu denken: > USE IEEE.NUMERIC_STD.ALL; > USE IEEE.STD_LOGIC_UNSIGNED.ALL; Habe dazu auch deine Seite gefunden, sehr schön... muss ich mir mal genauer anschauen :) http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html In einem anderen Modul habe ich folgendes: SIGNAL addr : STD_LOGIC_VECTOR(7 downto 0) := "00000000"; ..... addr <= addr + 1; Ohne Einbindung der STD_LOGIC_UNSIGNED kann er keine Arithmetik auf logik-Vektoren anwenden. Wenn ich STD_LOGIC_UNSIGNED nicht verwenden "darf", wie würde man das dann elegant lösen? Muss ich wirklich erst in einen unsigned casten, addieren und wieder zurück casten?
Noch eine Frage zu deiner Seite: http://www.lothar-miller.de/s9y/archives/20-RAM.html#extended Ich wusste gar nicht, dass die Xilinx-tools automatisch BlockRAM zuweisen. Ich dachte das BlockRAM lässt sich nur über die Xilinx Library verwenden. Deshalb habe ich für meinen BlockRAM den CoreGenerator verwendet. ABER: Auf deinen Screenshots ist überall der gleiche Block zu sehen! Jede deiner Implementationen sieht so aus als ob ein BRAM verwendet wird!?
Zum Rechnen mit Logik-Vektoren braucht man wohl die Konvertierungs-Funktionen. Ist ja auch irgendwie besser als über die Library, dann kann man immer explizit fest legen ob signed/unsigned gerechnet werden soll. Wie kann ich einen signed/unsigned Wert initialisieren? Habe das zur Zeit so: SIGNAL ctr : unsigned(4 downto 0) := to_unsigned(0,5); Hätte es aber gerne so, damit ich bei Änderung der Länge nicht gleich zwei Werte ändern muss (geht nicht): SIGNAL ctr : unsigned(4 downto 0) := to_unsigned(0,ctr'length); Zum Umstellen zwischen BlockRAM/Distributed RAM habe ich folgendes gefunden: ATTRIBUTE ram_style : string; ATTRIBUTE ram_style OF ram : SIGNAL IS "block"; Alternativ halt "distributed".
Marius S. schrieb: > In einem anderen Modul habe ich folgendes: > SIGNAL addr : STD_LOGIC_VECTOR(7 downto 0) := "00000000"; > ..... > addr <= addr + 1; > > Ohne Einbindung der STD_LOGIC_UNSIGNED kann er keine Arithmetik auf > logik-Vektoren anwenden. Wenn ich STD_LOGIC_UNSIGNED nicht verwenden > "darf", wie würde man das dann elegant lösen? Muss ich wirklich erst in > einen unsigned casten, addieren und wieder zurück casten? Elegant wäre es, addr als unsigned (aus der numeric_std) zu definieren. Casten oder konvertieren würde ich nur, wenn ein Untermodul den Wert z.B. als std_logic_vector benötigt. Duke
Thread beobachten
Seitenaufteilung abschaltenBitte 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.