Ich möchte eine LVDS Verbindung etablieren, bei der Daten und Taktsignale all per LVDS ankommen werden. In einem Demo-Design funtioniert es schon. Das Testboard, das ich verwende, benutzt Stecker, die jeweils mit komplementären Paaren geroutet sind (p/n). Diese werden aber im UCF überraschenderweise mit "LVCMOS25" deklariert, was auch funktioniert, während ich üblicherweise LVDS_25 deklariert hätte und auch schon erfolgreich habe. Aus der Dokumentation des Chips entnehme ich, dass in verschiedenen Bänken nur jeweils einer der Standards zur Verfügung ist, in komlementären Bänken der andere! Wenn ich versuche, ein Design für das Demoboard zu machen, geht es folgerichtig nicht mit LVDS_25. Ich muss mich nun entscheiden, welche Bank ich für das Design nehme und aus Platzgründen hätte ich gerne eine andere, als im Demoboard. Was müsste ich da sicherheitshalber nehmen, bzw. welcher Standard wäre das "Richtige"? Es geht jetzt hauptsächlich um die Eingänge. Bei den Ausgängen bin ich nämlich festgelegt, da der Chip nur in manchen Bänken einen 2,5 LV ausgang hat.
LVCMOS_25 ist nicht differentiell. Da müsste der Mapper eigentlich meckern, wenn du da einen OBUFDS beispielsweise dran hast. Oder der korrigiert das automatisch, dann gibts sicher eine entsprechende Warnung. Ich nehme mal an das ist Xilinx, di LVCMOS_25 Schreibweise und die Bankbeschränkung könnte passen.
Es ist ein XA6SLX45T. Von den Pegeln her sehe ich keinen (grossen) Unterschied. Wie gesagt, klappt es, das Design fürs Demoboard mit den existenen Constraints zu bauen, aber ich bin jetzt unsicher, wegen der Pegel und der Signaltechnik. Die Signale selber kenne ich leider noch nicht und kann sie auch nicht vermessen, da bis auf Weiteres keine weiteren Infos habe, ausser, dass es LVDS-Signale sein werden. Konkret geht es um die Verschaltung von Modulen mit speziellen ADCs, die eine eigene PLL, einen eigenen Takt, einen Datentrigger und parallele Datenleitungen ausgeben. Der Takt kann mit bis zu 500 MHz laufen, dann kommen 125MHz LVDS in double data rate. Benutzt werden aber nur 62,5MHz in SDR, d.h. mit jedem zweiten Takt kommen 2x16 Signale parallel rein. Ich sehe dann in jedem Takt einen Datenwechsel. Ob die Signale aus einem Chip kommen, noch über ein PLD laufen oder gar Treiber dazwischen sitzen, ist nicht bekannt.
Christian R. schrieb: > LVCMOS_25 ist nicht differentiell. Da müsste der Mapper eigentlich > meckern, wenn du da einen OBUFDS beispielsweise dran hast. Hm, es könnte sein, dass ich mich durch die Deklaration der Ports habe täuschen lassen. Die sind BUS-weise verdrahtet und haben 32 Signale, von denen es jeweils ein p und ein n gibt. Dazu stehen auch noch CC Pins (clock capable) zur Verfügung. Einige davon sind outputs, andere inputs. Alle stehen auf LVCMOS25. Möglicherweise sind im UCF alle standardmäßig auf single ended verbaut und müssen je nach Verwendung erst passend geschaltet werden oder man hat sich wie bei Xilinx üblich, um manche Port-Deklarationen nicht intensiv genug gekümmert. Ich habe nun das design angegangen und einige inputs verdrahtet, scheitere aber in der Tat am Mapper. Irgendwie will er die LOCs nicht obwohl die definitiv zu einem pn-Paar gehören. Vielleicht liegt es an der Beschreibung: Ich habe die IO-Deklarion nicht im UCF, sondern wie im XI-Beispiel im VHDL beim Buffer direkt:
1 | IBUFDS_1 : IBUFDS |
2 | generic map (DIFF_TERM => FALSE, IBUF_LOW_PWR => TRUE, IOSTANDARD => "LVDS_25") |
3 | port map (O => Pclk, I => Pclk_p, IB => Pclk_n); |
Ich halte nicht viel von der VHDL-Deklaration, eben weil man da die Übersicht verlieren kann. Lieber ins UCF. LVDs muss natürlich korrekt verschaltet werden und benötigt ggf. auch eine Terminierung. Beim Spartan 6 geht das intern zu erledigen. Ein Haken beim Spartan 6 ist, dass er nur in 2 der Bänke LVDS Ausgänge mappen kann, Eingänge gehen auf allen Bänken. Wenn im UCF tatsächlich LVCMOS steht und evtl. auch nur der p verdrahtet ist, kann der Mapper natürlich meckern. Sinnvoll wäre mal, die Meldung zu posten. LVCMOS und LVDS sind natürlich nicht kompatibel. Mach am besten die Pin-zuordnung über PlanAhead das geht ziemlich gut und der warnt auch gleich, wenn was nicht passt.
Momentan reduziert sich das Problem auf einen Port der nicht mit einem Buffer versehen werden kann. "LVDS_25" funktioniert aber. Momentan mache ich es noch im VHDL, aber das mit dem UCf sehe ich genau so.
R. K. schrieb: > "LVDS_25" funktioniert aber. Mit welchen Pegeln arbeitest Du? Die Optionen für die Ports müssten im Datenblatt zu finden sein. Die sind aber nicht bei allen FPGA-Familien gleich.
ING-O schrieb: > Mit welchen Pegeln arbeitest Du? Angeblich LVDS. Zu messen habe ich noch nichts vorliegen.
R. K. schrieb: > Wie gesagt, klappt es, das Design fürs Demoboard mit den > existenen Constraints zu bauen, aber ich bin jetzt unsicher, wegen der > Pegel und der Signaltechnik. D.h. Du hast das Design theoretisch fertig, weil es simuliert? Du hast es aber noch nicht getestet? Schon mal in den FPGA geladen?
Weltbester FPGA-Pongo schrieb im Beitrag #2756444: > D.h. Du hast das Design theoretisch fertig, weil es simuliert? Ja > Du hast es aber noch nicht getestet? So ist es > Schon mal in den FPGA geladen? nein, keine Hardware da Ich hätte noch eine Frage zu den differentiellen Eingängen bei Xilinx: Soweit ich sehe, müssen die Abschlusswiderstände selbst instanziert werden. Gibt es da Alternativen? Bzw, ab wann kann man die weglassen?
Angehängte Dateien:
R. K. schrieb: > Soweit ich sehe, müssen die Abschlusswiderstände selbst instanziert > werden. Wo werden die Widerstände instanziiert? Im HDL-Code oder Im UCF? > Gibt es da Alternativen? > > Bzw, ab wann kann man die weglassen? Wenn man externe Widerstände dran hat. Schau mal in den SelectIO User Guide (UG381). Duke
Externe Widerstände habe ich keine, daher mache ich es im UCF:
1 | NET "adc_in_p(4)" LOC = "D5" | IOSTANDARD = LVDS_25 | DIFF_TERM = TRUE; |
u.s.w Das wird auch erkannt und abgearbeitet - im MAP-report stehen sie allesamt drin. Komisch ist nun, dass einige der Ports (wie gewünscht) registriert sind, während andere unregistriert bleiben. Dies betrifft sowohl inputs, als auch outputs. Vor allem bei den Datenleitungen der ADCs sind die meisten *_p ohne IO-Register, wärend einige FF im IO-register sitzen. (Bei den *_n sind nie IO-Register angegeben). Ich habe das im MAP global vorgegeben und im VHDL werden alle Busse mit ihrem abgelieferten Takt 2x einsynchronisiert, um genügend FFs und routing resourcen (timingtechnisch gesehen) zu haben. Kann ich das irgendwie ausdrücklich erzwingen, dass er IO-Register für die FFs nimmt? Beim Altera gibt es dafür in der IDE eine constrain Möglichkeit "fast io, fast output enable" ... Normalerweise hatte ich auch beim Xilinx noch nie Probleme, ging immer automatisch. Hat das was mit den diff-ins zu tun? Haben da manche keine FFs? An einer Mehrfachbelegung mit DQS (Ram-CTRL) oder einen CCIO (clock Eingang) kann es nicht liegen, da einige Pins, die nur simpler IO sind, ebenfalls nicht registriert sind.
Just as a discussion starter: LVCMOS Low Voltage Complementary Metal Oxide Substrate LVDS Low Voltage DIFFERENTIAL Signalling pick one ... ... wisely
Robert K. schrieb: > Komisch ist nun, dass einige der Ports (wie gewünscht) registriert sind, > > während andere unregistriert bleiben. Dies betrifft sowohl inputs, als > > auch outputs. Diesbezüglich bin ich nun etwas weiter gekommen. Die Synthes hat sich nun - wie auch immer - dazu bequemt, alle IO-Pins auch in Register zu mappen, kann sein, dass es an der neuern Version von ISE liegt. Bei den DIFF-IOs ist es so, dass der "p" immer ein FF hat, während der "n" nie eins hat, was laut Xilnx FAE so i.O. ist.
FFs nur am p-Eingang sind richtig so. Der n-Eingang geht erst auf einen Buffer und hat kein eigenes FF. Robert K. schrieb: > dass es an der neuern Version von ISE liegt. Ich habe auch so ein Wackeldesign! Manchmal schafft er es trotz ausdrücklicher Deklaration als IO-Block, nicht, die FlipFlops in die Zellen zu routen. Der Grund ist unklar. Wie könnte man da vorgehen?
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.