|
Anzeige
|
Chipscope Fragen
Gast
#1576399
Hallo @ all Ich möchte mit Chipscope eine Signale testen von meinem AD-Wandler überprüfen. Ich habe einen 14Bit AD-Wandler dieser liefert mir ein DataReady Signal und 14Bit Daten. Die Daten sind im DDR Format. Jetzt möchte ich prüfen wie hoch der Delay zwischen dem Data Ready Signal und den Datensignalen sind. Ist dies mit Chipscope möglich oder ist die Auflösung zu gering? Das Data Ready Signal kommt mit maximal 200MHz. Nein, das klappt nicht. ChipScope kann nur saktsynchron aufnehmen. Du müsstest einen viel höheren Takt anlegen. Aber dein BlockRAM, der dafür verwendet wird, geht "nur" bis 500MHz auf dem V5. Dieser Wert steht im Datenblatt des ADC. Ich glaube du hast immer noch eine völlig falsche Herangehensweise an dein Problem. Der ADC gibt das Ready Signal und die Daten mit einem zum CLK definiertem Timing aus, das steht im Datenblatt. Nun kannst du IDDRs für Daten und Ready benutzen und mit dem Constraints Editor die OFFSET IN BEFORE Constraints festlegen. Je nachdem mit System Sychronous oder Source Synchronous. Ist bei "Create Timing Constraints" recht gut bildlich erklärt.
Gast
#1577536
Ich habe halt ein Evaluation Board und weiß halt nicht ich wie weit die Realen Daten versetzt ankommen. Es kann ja sein das das Data Ready und die Datenleitungen unterschiedliche Laufzeiten bedinkt durch das Layout der Paltine besitzen. Deshalb kann man ja auf unbekannte Signale schlecht ein Offset geben. An den Pins kann man leider nicht messen da es eine 8 lagige Platine ist. Jetzt ist mir jedoch eine Idee gekommen. Ich lede an den AD-Wandler z.B. einen Takt von 10MHz an. Dann nehme ich den externen Quarz (50MHz) benutze dann einen DCM und erhöhe den Takt von 50MHz auf z.B. 400MHz. Diese 400MHz verwende ich dann für Chipscope. Damit erreich ich dann eine Auflösung von 2,5ns dies ist natürlich nicht sonderlich gut. Wie kann man denn sonst wissen wie unterschiedlich die Laufzeiten sind? Wenn das Board nicht gerade ein Anfänger oder Vollidiot geroutet hat, sind die Leitungen gleich lang. Gerade bei solchen Frequenzen ist das normal. Außerdem machen ein paar ps Abweichung nix aus. Gibts dazu kein Referenzdesign, in dem die Constraints schon stehen? Beim ML405 zum Beispiel sind die IDELAYs auch angegeben, ebenso die Constraints für die schnellen GbE Pfade und den DDR2 SDRAM. Da musst du mal bissl suchen....
Gast
#1578117
Das Bord wird von TI angeboten. Da habe ich halt nur den Schaltplan. Auf den externen Speicher war bereits ein Programm drauf, das automatisch beim Einschalten geladen wird, leider gibt es dazu keinen Quellcode oder Doku. Du hast sicherlich recht damit das alle Leitungen sicherlich gleich lang sind. Jedoch sollte man auch ab und zu mal prüfen. Ich werde noch mal in dem Constaint File nachlesen. Johann schrieb: > Du hast sicherlich recht damit das alle Leitungen sicherlich gleich lang > sind. Jedoch sollte man auch ab und zu mal prüfen. Bei so einem Board ist das nahezu unmöglich, denn die Leitungen liegen irgendwo in den Layern unterhalb des BGA Virtex.
Gast
#1578620
Genau das ist ja das Problem ^^. Bei dem AD-Wandler steht im Datenblatt das die Datenleitung bis zu +-0,5ns gegenüber den Datenleitungen verzögern können. Deshalb habe ich die DataReady Leitung über ein IDELAY um 0,75ns verzögert. Jetzt weiß ich bloß nicht ob ich mir dort Probleme einhandel, da die Data Ready Leitung auf einem ClockBuffer liegt. Erst wird die Data Ready Leitung durch den LVDSGDS (I/O Buffer) ja schon um 1,1ns (Laut Datenblatt) verzögert, dann gehe ich vom I/O Buffer auf den Delay und dann auf einen BUFG. Von den BUFG dann in das IDDR. Ich habe ja eine Netzlaufzeit vom I/O Buffer zum IDELAY und von dort dann zum BUFG. Leider kenne ich mich mit den Constraints noch nicht ganz so gut aus. Ich hatte halt gehoft das der AD-Wandler ein Test-Pin hat, so das dieser dann ein definiertes Signal erzeugt. Aber leider besitzt dieser AD-Wandler keinen Test-Pin. Hast du immer noch das Data Ready Signal am CLK der IDDR? Das gehört da meiner Meinung nach nicht hin, der CLK Eingang sollte vom CLK gespeist werden, der auch an den ADC geht. Und dann musst du im Timing Constraint Generator System Sychronous Constraints dafür anlegen. Die nötigen Setup-Zeiten stehen im Datenblatt. Zu den Constraints gibts auch viele Informationen im User Guide (zumindest beim Spartan 3 steht da einiges).
Gast
#1579916
Wieso willst Du immer den orginalen Clock an den FPGA legen? Ich habe noch mal auf dem Schaltlan des Evaluation Boards nachgeschaut. Der Clock für den AD-Wandler geht nur auf die beiden AD-Wandler und NICHT in den FPGA. Das Data Ready Signal ist doch mein Clock-Signal das der AD-Wandler erzuegt. Deshalb wurde es auch auf einen I/O Clock Buffer geroutet. Zudem ist dies doch auch genau das Signal um aus meinem DDR Daten wieder "normale" Daten zu bekommen. Oder habe ich einen Denkfehler und sehe den Wald vor lauter Bäumen nicht. Achso, wenn das so vorgesehen ist, gehts ja nicht anders. Soweit ich das Datenblatt des ADC verstehe ist DRY Signal ein Indikator, dass die Daten gültig sind. Klar, kann man auch als CLK nutzen. Dann musst du "source synchronous" Constraints anlegen für OFFSET IN BEFORE, damit es passt.
Gast
#1580282
Danke für den Hinweis. Dann habe ich ja schon mal ein Anhaltspunkt nachdem ich suchen kann.
Gast
#1580319
Denkst Du das die Variante mit dem IDELAY auf der Data Ready Leitung eine ungünstige Lösung ist? Ich habe gedacht ich verzöger einfach die Data Ready Leitung um 0,75ns somit liegen die Daten lange genug am IDDR an. Jedoch muß man natürlich bei diese Lösung berücksichtigen das die I-Buffer vom Clock und den Daten unterschiedlich lange Schaltzeiten besitzen.
Gast
#1580321
Wie erzeugt denn diese Constraint die einzuhaltenden Timings? Ich verwende keinen Quarz für den AD-Wandler sondern habe eine Gerät was mir einen Clock erzeugt. Dieser Clock enthält jedoch einen Jitter der deutlich größer ist als bei einem Quarz. Setz doch mit dem PlanAhead Tool mal die Constraints, und schau dir nach dem Routen die IOB Liste an. Eventuell taucht dann dort schon ein Delay auf, meines Wissens kann das automatisch anhand der Constraints eingestellt werden. Create Timing Contraints -> Inputs usw. Dann halt source synchronous, DDR und im nächsten Dialog den richtigen Clock auswählen, also den DRDY Signal und eventuell die vorgeschlagenen Werte noch anpassen, je nachdem, was im Datenblatt steht.
Gast
#1580399
Das werde ich mal machen. Leider werde ich heute nicht mehr dazu kommen da ich noch viele andere Dinge machen muß. Jedoch vielen Dank für diese Rat. Man lernt doch immer was dazu :-) Gibts denn eigentlich ein Problem, oder wieso machst du es für den Anfang so umständlich? Hast du falsche Daten?
Gast
#1580605
Bis jetzt habe ich die Datenübertragung zum PC programmiert. Jetzt bin ich dabei die Daten vom AD-Wandler in einem BlockRam zu schreiben und dann an den PC zu senden. Jedoch versuche ich die gröbsten Fehler gelich zu vermeiden. Genauso habe ich überlegt wie ich die Daten in den Block RAM bekomme. Mein IDDR liefert mir Daten, mit jeder ansteigenden DATA REDAY Flanke. Den Ausgang von dem IDDR Register verbinde ich dann mit dem DataIn vom BlockRam. Zudem erhöhe ich mit jeder ansteigenden Data Ready Flanke einen Adresszähler für den Block Ram. Nun müssen die Daten und die Adresse ja einige Zeit vor der ansteigenden Clock flanke stabil anliegen. Jetzt habe ich halt überlegt ob ich da auch ein Timing Constraint erzeugen muß. Oft arbeite ich in meiner Freizeit an diesem Projekt, da ich auf Arbeit halt momentan eine menge andere Projekte bearbeite. Dies macht die Sache nicht unbedingt einfacher. Auf meinem Spartan 3 habe ich bis jetzt immer eine große Sicherhetsreserve gelassen so das es nie Probleme gab. Dies ist jetzt bei den Geschwindigkeiten jedoch nicht mehr möglich. Wenn der BlockRAM mit dem gleichen Takt wie die davor liegenden FlipFlops laufen, dann meckert ISE schon rum, wenn das Timing nicht passt. Denn nur der PAR kennt die Laufzeiten innerhalb des FPGA. Beim schnellen V5 sehe ich da allerdings keine großen Schwierigkeiten, wenn keine Kombinatorik im Signalpfad ist. Die IDDR geben dir ja die Daten passend zur steigenden Flanke des Basistaks aus, so dass die schon synchronisiert sind, wenn du beim IDDR das Generic auf SAME_EDGE setzt. Dann hast du nur innerhalb des IOB die kritische Stelle, dass nur ein halber Takt Setup-Zeit ist. Aber auch darum kümmert sich ISE. Innerhalb des FPGA kannst du in erster Linie nur schwierigkeiten bekommen, wenn du zwischen 2 synchronen Elementen viel Kombinatorik (Adder, Muxer...) hast, aber dann bringt ISE die Meldung, dass das Timing nicht zu schaffen ist.
Gast
#1580795
Der Adresszähler wird etwas Kombinatorik enthalten.
Geplant ist es wie folgt.
Ich habe ein Signal nennen wir es mal Trigger ^^
Wenn der Trigger 1 ist dann, dann nehme x Datenpunkte auf
--> Dadurch benötigt man einen Counter und einen Comperator
Bis jetzt habe ich das so gemacht:
If ansteigende Flanke von Data Reday) then
If(Trigger = 0) then
--> ADDR_Counter <= "000000000";
end if;
else
if(Tigger < x)then
counter <= counter + 1;
end if;
end if;
Musst du sehen, was das Timing sagt, auf dem V5 sehe ich mit solchen einfachen Sachen keine Schwierigkeiten bei 400Mhz. Wenn´s nicht optimal umgesetzt wird, teste mal, ob es schneller wird, wenn du den Zähler herunter zählen lässt und auf 0 vergleichst. Kannst die Adress-Zählerei ja auch von einem Block-RAM-FIFO erledigen lassen. Ist weniger Schreibarbeit.
Gast
#1581427
Das mit dem Block Ram Fifo ist mir neu. Wie soll das gehen? Na wie ein FIFO halt funktioniert. Es gibt einen Dateneingang, einen Schreib-Takt und ein Write Enable. Solange WE High ist, wird bei jeder steigenden Flanke das Wort am Din eingeschrieben. Die Daten kannst du gleichzeitig oder später auslesen, denn es gibt einen Daten-Ausgang, einen Lese-Takt und ein Read-Enable, die unabhängig davon sind. So kannst du z.B, erst mal deine Anzahl Samples mit 400Mhz in den FIFO schreiben, und dann irgendwann gemütlich auslesen. Es gibt da noch Full und Empty Flags, die du beachten musst.
Gast
#1581543
Ich verwende lieber eine Simple Dual Port RAM da kann ich die Daten vom AD-Wandler reinschreiben und dann mit der PC-Übertragung beginnen. Da die PC-Übertragung momentan nur eine 3MBit RS232 Übertragung ist wird der RAM schnell voll sein. DAnn will ich warten bis alle Daten ausgelesen sind. Anschließend schreibe ich wieder neue Daten rein. Wenn alles funktioniert versuche ich die RS232 Schnittstelle durch eine schnellere zu ersetzen Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
