www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Chipscope Fragen


Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis. Dann habe ich ja schon mal ein Anhaltspunkt 
nachdem ich suchen kann.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts denn eigentlich ein Problem, oder wieso machst du es für den 
Anfang so umständlich? Hast du falsche Daten?

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Block Ram Fifo ist mir neu. Wie soll das gehen?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.