Hallo alle zusammen,
ICh arbeite gerade an einem interface eines AD7980 mittels VHDL und habe
ein problem von dem ich die ursache nicht kenne.
Im Anhang sind einmal das AD7980 interface, die Topl Level entity, die
Testbench und ein Modell des AD7980 zu finden. Das modell habe ich zum
simulieren gemacht und ist eigentlich in diesem Fall egal. Es taktet
einfach immer nur 16 bit auf anfrage raus.
Das eigentlich Problem ist die AD7980interface.vhd. im aquisition
zustand sollen die über die Miso Line empfangenen bits mit der fallenden
Taktflanke des Clken signals eingelesen werden, aber in der simulation
werden die Bits bei steigender Taktflanke des Clken eingelesen.
zwar tut die simulation was sie soll, aber es steckt ja eindeutig ein
fehler dahinter.
ich hoffe mein Problem habe ich verständlich dargelegt und ihr könnt mir
helfen
Deine Flankenerkennung macht schon das was sie soll, aber so eine
Erkennung hat nun mal einen Takt Delay und da deine SCLK sehr hoch ist
geht das in die Hose.
Du willst eine SCLK Frequenz von 66 MHz hast aber eine 100 MHz
Systemclock, das geht nicht. Aktuell ist deine SCLK nur 50 MHz (zu wenig
um mit dem AD780 1 MSPS zu erreichen).
Ich würde eine Systemtakt von 66 MHz benutzen, und die IOs zum ADC als
IDDR und ODDR realisieren.
Wie schon erwähnt: wenn du mit deinen internen Datenraten dicht an die
Takfrequenz rankomst, dann ist es nicht mehr mit pauschalen Berechnungen
wie 100000000/66000000 getan. Sondern du musst jeden einzelnen Takt per
Handschlag verabscheiden und dir bewusst sein, dass die Granularität
dort recht groß ist. Du kannst dir also nicht 62MHz erzeugen, denn es
gibt nur Verzögerungszeiten von 10ns, 20ns, 30ns, 40ns... ergo 100MHz,
50MHz, 33MHz, 25MHZ...
Versuche mal, das Design so umzustellen, dass Du den ADC die Daten
selbst eintakten lässt, z.B. mit einem asynchronen Fifo.
Ansonsten musst Du wie erwähnt überabtasten. Du könntest auch mit einem
DDR-FF arbeiten und parallel mit einfacher Frequenz weitergehen.
Danke für eure Antworten, es wurde natürlich punkte angesprochen die ich
noch nicht bedacht habe.
@lothar
Du hast natürlich recht mit den 100mhz/62,5mhz. Ich hab da ein wenig
rumprobiert und vergessen es zu ändern. Mein derzeitiges enable Signal
läuft mit 50mhz und ist für 1MSPS wie lattice_user bereits gesagt hat.
Mit den 720ns Wartezeit habe ich dich auch verwirrt, es ist natürlich
730ns und auch so gewollt. Die Convention dauert max 720ns und danach
muss noch 10ns-15ns gewartet werden bis die Daten auf der Miso Leitung
anliegen.
Da 50mhz Etwas zu langsam sind muss ich jetzt erstmal alternativen
betrachten. Ich benutze einen spartan6 und muss erstmal gucken welche
Möglichkeiten mir der DCM bietet.
Ich glaube du solltest erstmal dein Fehler rausfinden (auf welche Flanke
die bits rein/rausgetaktet werden) und dann erst den Clock anpassen.
Der ADC kannst du auch mit eine niedrigere Rate erstmal ansteuern. Somit
kannst du die MISO Leitung mit Systemtakt überabtasten und einfach über
einen Schieberegister eintakten.
Gruss
experte schrieb:> S.G schrieb:>> Ich benutze einen spartan6 und muss erstmal gucken welche>> Möglichkeiten mir der DCM bietet.> 1050 MHz !>> 50 x 21 -> 1050 -> /8 -> 132 MHz
Danke, aber könntest du mir diese Rechnung ein wenig erläutern?
Mein Fpga board bekommt hat einen Takt von 50mhz. im moment sieht mein
Lösungsansatz so aus, dass ich mithilfe der SPartan6 PLL komponentne
einen SPi Takt von 62,5 und einen Systemtakt von 125Mhz generiere. mit
den 62,5 erreiche ich die 1MSPS des ADc und die 125 werde ich dann zum
verarbeiten der Daten verwenden.
Würde eurer meinung etwas gegen diese Idee sprechen?
S.G schrieb:> Mein Fpga board bekommt hat einen Takt von 50mhz. im moment sieht mein> Lösungsansatz so aus, dass ich mithilfe der SPartan6 PLL komponentne> einen SPi Takt von 62,5 und einen Systemtakt von 125Mhz generiere. mit> den 62,5 erreiche ich die 1MSPS des ADc und die 125 werde ich dann zum> verarbeiten der Daten verwenden.> Würde eurer meinung etwas gegen diese Idee sprechen?
Solgange bei einem SPI Master der Systemtakt ein ganzzahliges Vielfaches
des SPI Taktes ist, brauchst du diesen nicht extra mit einer PLL
erzeugen.
Betrachte einfach den SPI Takt als zusätzliches Signal, das in deiner
Statemachine erzeugt wird. Wichtiger ist dass man darauf achtet IO FFs
zu verwenden, sonst wird es bei höheren Gechwindigkeiten schwierig bis
unmöglich die Setup und Holdzeiten einzuhalten
In Verilog könnte ich es dir schnell hinschreiben, aber in VHDL bin ich
nicht fit genug.
S.G schrieb:> Würde eurer meinung etwas gegen diese Idee sprechen?
Dass du unnötigerweise zwei Taktdomänen aufmachst. Uin diesem Fall hier
ist das "nur" die Hälfte, das kann dir die Toolchain noch aufrechnen,
aber wehe, du machst unbedarft ("das hat das letzte Mal auch schon so
toll geklappt!") einen "krummen" Takt auf. Dann hast du auf einmal zwei
asynchrone Takte in deinem Design und damit all die Probleme an der
Backe, die ein solches asynchrones Design mit sich bringt (Stichworte:
Eintakten, Fifo, Synchronisieren, Handshake)...
Lattice User schrieb:> Betrachte einfach den SPI Takt als zusätzliches Signal, das in deiner> Statemachine erzeugt wird.
Es gibt nämlich nur einen Takt: der, der vom Quarzoszillator kommt
(meinetwegen noch durch eine PLL aufgehübscht). Aber ein SPI-Takt ist
KEIN Takt, sondern nur ein Symbol, das die Buchstabenfolge t, a, k und t
(von mir aus auch c, l, o, c und k) in seinem Namen trägt.
