Hallo, ich habe mir gerade ein solches Board geschossen und möchte es an meinem Zedboard betreiben. Hittite gehört inzwischen zu Analog Devices und da gibt es Unterlagen zu dem Board und auch ganz versteckt die Quelltexte zur "EasyStack" Firmware für ein Spartan SP601. Dort sind die FMC Pins als LVDS_25 Deklariert und ich denke wenn ich an meinem Zedboard VADJ auf 2,5V setze geht da erstmal nichts kaputt. Hat schon Jemand dieses Board oder ein anderes aus der Familie eingesetzt und möchte darüber etwas erzählen ? Oder über eine Linux(ARM) Oszi-App die möglichst keinen kostbaren Messwertspeicher verbraucht und die Daten aus dem Ram anzeigen kann ?
Falls es jemand interessiert ;) Ich habe aus den EasyStack "Firmware" Verilog Quelltexten ein ISE 14.7 Projekt erstellt und nach ein bissel Fummelei ist die Synthese auch durchgelaufen. Im RTL Schematic View bekommt man jetzt erstmal den groben Überblick über die Modulstruktur. Im Projekt sind alle Möglichen Hittite Produkte enthalten, die bei den Evalboards über Widerstände codiert sind und über ein 8 Bit Port von der Fpga eingelesen werden. Dazu gibt es eine Java PC-Software, die man von AD auch, nach Anmeldung, bekommt und die mit der Firmware über RS232 kommuniziert. Die Firmware kann hier herunter laden: https://ez.analog.com/thread/51904?start=0&tstart=0 Das blöde ist nun, das ich zwar Spartan6 Boards besitze (ZTEX,und Gigabee) aber keines davon mit FMC Stecker und bei dem ZedBoard die DDR Speicher nicht an dem FPGA Teil hängen. Die Daten werden über 8 LVDS Kanäle übertragen, dazu noch ein Frame und ein Bit Clock. Die Übertragung läuft bei maximaler Samplingrate mit 125Mhz. Das ganze passiert über ein Verilog Modul das die Daten über ISERDES2 einliest und hinten parallel mit 128 Bit herauswirft. Die übertragene Datenlänge kann man dabei umschalten weil der HMCAD1520 8Bit,12Bit oder 14Bit Daten liefert, der HMCAD1511 kennt nur 8 Bit. Ein einzelnes Sample besteht dann aus einem 16Bit Wert oder 2x 8Bit gepackt. Dieses Modul und auch die Simulation des Eval Boards würde ich gerne verwenden aber in VHDL, weil ich von Verilog so gut wie keine Ahnung habe. Und nun meine Frage gibt es einen verilog2vhdl Konverter auf der mehr nützt als Probleme macht und auf den man sich verlassen kann ?. Ansonsten werde ich versuchen die xapp524 auf die Hittite ADCs umzuschreiben. Sonst noch Ideen ?
> > Und nun meine Frage gibt es einen verilog2vhdl Konverter auf der mehr > nützt als Probleme macht und auf den man sich verlassen kann ?. der Icarus simulator kann Verilog zu VHDL umwandeln. % iverilog -tvhdl -o my_design.vhd my_design.v Lange nicht mehr benutzt. Wie gut wie schlecht keine Ahnung
René D. schrieb: > Ich glaube du suchst diese Geschichte. Diese habe ich von Verilog nach > VHDL von Hand rübergehoben. Hallo Rene, danke für den Code :) Der HMCAD1520 schickt die Daten aber nicht als DDR sondern SDR mit zusätzlichem Frame und Bitclock auf die er sich einsynchronisiert. Die xapp524 ist wahrscheinlich der beste Ausgangspunkt und die ist bereits in vhdl geschrieben. Ich werde erstmal die ganze Umschalterei weglassen und nur den 4 Kanal 8Bit Betrieb mit 250Msps versuchen zu realisieren. Dann die Samples ins DDR Ram schaufeln und mit dem "iio-oscilloscope" versuchen anzuzeigen. https://github.com/analogdevicesinc/iio-oscilloscope Vielleicht gibt es 2017 die ersten Ergebnisse ;)
Hans-Georg L. schrieb: > Der HMCAD1520 schickt die Daten aber nicht als DDR sondern SDR ... Das war falsch, es ist doch DDR.
Nachdem ich jetzt 4 Verilog nach Vhdl Konverter ausprobiert habe und alle entweder nichts und ohne Rückmeldung gemacht haben und die anderen Syntaxfehler im Verilog Code reklamiert haben, natürlich ohne zu sagen wo, gebe ich an der Stelle auf. Nach lesen von: xapp1064, xapp866, xapp860, xapp585, xapp524, xapp523 und noch viel mehr hat sich herausgestellt, das es 2 Grund- und noch ein paar familienspezifische Varianten gibt. Die "classic" variante arbeitet mit einer PLL um aus den DDR Daten SDR Daten zu machen und die Phasenverschiebung zwischen Clock und Daten einzustellen und die Daten werden in CLB serialisiert. Diese wird auch im Hittite Verilog code benutzt. Die moderne Variante benutzt die IDELAY und ISERDES für die Phasenverschiebung und Serialisierung ich werde die xapp524, die sehr gut dokumentiert ist, als Ausgangspunk verwenden. Da Hittite, jetzt AD, den ADC nicht selbst entwickelt hat sondern auch von arctic silicon devices eingekauft hat, gibt es für den Chip 3 Bezeichnungen. ADS1520 -> HAD1520 -> HMCAD1520 und der kleinere Bruder ADS1510 -> HAD1511 -> HMCAD1511 Aber eine Frage habe ich doch noch ... Der 1520 kann 8,12,14,16 Bit serialisieren, daher wäre es für mich interessant die Serialisierung umschaltbar zu machen. Geht das überhaupt mit den ISERDES ohne neu oder partial Konfiguration?
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Der 1520 kann 8,12,14,16 Bit serialisieren, daher wäre es für mich > interessant die Serialisierung umschaltbar zu machen. Geht das überhaupt > mit den ISERDES ohne neu oder partial Konfiguration? Ich denke das geht nicht. Aber was funktionieren könnte: einen 1:4 Deserializer zu verwenden und anschließend den Rest mit eigener Logik zu bauen. Dann wäre zumindest 8, 12 und 16 Bit machbar. Knifflig wird es evtl. bei der Synchronisation (wo kommt das erste Bit vom Frame...?) Berndl
Hans-Georg L. schrieb: > Nachdem ich jetzt 4 Verilog nach Vhdl Konverter ausprobiert habe und > alle entweder nichts und ohne Rückmeldung gemacht haben und die anderen > Syntaxfehler im Verilog Code reklamiert haben, natürlich ohne zu sagen > wo, gebe ich an der Stelle auf. > > Nach lesen von: > xapp1064, xapp866, xapp860, xapp585, xapp524, xapp523 und noch viel mehr > hat sich herausgestellt, das es 2 Grund- und noch ein paar > familienspezifische Varianten gibt. Ich stehe nicht ganz im Thema gerade. Kenne nicht den Baustein und wollte mich gerade nicht austoben. Trotzdem würde ich dir gerne helfen. Zur Vereinfachung der Kommunikation. Hast du ein Blockschaltbild für den Datenstrom? Einmals als Überblick und daen die Knackstelle, an der du scheiterts.
René D. schrieb: > Zur Vereinfachung der Kommunikation. > Hast du ein Blockschaltbild für den Datenstrom? > > Einmals als Überblick und daen die Knackstelle, an der du scheiterts. Danke für dein Angebot :) Die Datenübertragung besteht aus folgenden LVDS Leitungen: a.) BitClock (max 500Mhz DDR) b.) FrameClock ( 125Mhz bei 8 Bit Daten) c.) 8 Datenleitungen (2 pro Analog Kanal). d.) ein Spi (Rück) Kanal zur Steuerung des ADC. Vereinfacht braucht man nur 1 seriellen Datenkanal zu betrachten, die Zugehörigkeit zu den Modi und Analog Kanälen kann ich nach der DeSerialisierung über Multiplexer zurechtfummeln. Die xapp524 beschreibt das für einen 14 Bit ADC und da muss ich mich einfach durchbeißen. Mein spezielles Problem ist, das mein ADC die Daten nicht nur als 14 Bit Daten übertrage kann, sondern auch noch als 12, 14, 16 oder Bit 2*8 seriell über die Datenleitungen. Das bedeutet ich brauche einen DeSerializer mit umschaltbarem Serialisierungs Faktor. (1:8, 1:12, 1:14). Realisieren möchte ich das auf einem ZedBoard, das einen Zynq 7020 von Xilinx enthält. Wenn ich die ug471_7Series_SelectIO richtig verstanden habe müsste das mit den ISERDES2 doch funktionieren. Meine Annahmen: a.) 2 ISERDES fest als 14 Bit Master/Slave konfigurieren. b.) Das Attribut DATA_WITH bestimmt nur die Datenbreite des Parallelausgang. c.) Der Serialisierungsfaktor ist nur von dem Verhältnis Clock/ ClockDiv abhängig und somit während der Laufzeit einstellbar. Und es ist ja nicht nur der Deserialisierungsfaktor für die Daten sondern die Trainingspattern für den BitClock und den FrameClock und somit die dazugehörigen State Machines der xapp524 werde ich auch anpassen müssen. Die 16 Bit serielle Datenübertragung brauch ich nicht, da werden nur zusätzliche Nullen in den unteren Bits übertragen und die kann ich im FPGA viel einfacher einfügen und werde daher für den HighRes Mode die 2*8 (je 8Bit über 2 Leitungen) Übertragung wählen. Die Arbeit, das alles in meinen schon etwas älteren Kopf zu bekommen kann mir keiner abnehmen aber es würde mir schon helfen wenn jemand das durchliest und sagt ... Halt, da bist du auf dem Holzweg oder könnte so gehen ;) ps. Ich habe nicht das Projekt aufgegeben, sondern nur mich mit dem Verilog Code von Hittite zu beschäftigen ;).
Hans-Georg L. schrieb: > René D. schrieb: > >> Zur Vereinfachung der Kommunikation. >> Hast du ein Blockschaltbild für den Datenstrom? > Mein spezielles Problem ist, das mein ADC die Daten nicht nur als 14 Bit > Daten übertrage kann, sondern auch noch als 12, 14, 16 oder Bit 2*8 > seriell über die Datenleitungen. > > Das bedeutet ich brauche einen DeSerializer mit umschaltbarem > Serialisierungs Faktor. (1:8, 1:12, 1:14). Wichtig ist, du bekommst den Datenstrom ersteinmal rein. Im FPGA kannst du die Bit auch neu sortieren. Re-odering Wie lange musst do synchron laufen können? Event-Trigger und ab dann Speicher füllen oder ein kontinuierlicher Datenstrom?
> > a.) BitClock (max 500Mhz DDR) > b.) FrameClock ( 125Mhz bei 8 Bit Daten) > c.) 8 Datenleitungen (2 pro Analog Kanal). > d.) ein Spi (Rück) Kanal zur Steuerung des ADC. Du kannst doch 1:4 Serialisieren. dann müsstes du bei 250Mhz Clock im FLGA sein. und dann mit Nachbehandlungslogik. Bernd hatte es auch schon vorgeschlagen. zwei x 4bits= 1:8 drei x 4bits= 1:12 vier x 4bits= 1:16 (das ist 14bit mit den aufgefüllten Null)
Das werde ich auch auf jeden Fall als Rückfallmöglichkeit im Auge behalten. Wenn es geht möchte ich aber die so oder so vorhandenen ISERDES Resourcen ausnutzen. Die 16Bit im HighPerformance Mode werde ich auf jeden Fall über 2 getrennte Leitungen (Low/High Byte) übertragen, da komme ich auf 125Mhz Samplefrequenz pro Analog-Kanal. Bei 16 Bit auf einer Leitung wäre der BitClock dann 1GHz und das kann der ADC und das FPGA nicht und ich müsste auf 62,5 MHz Sample Frequenz zurück. Ich werde jetzt erst einmal versuchen eine Testbench zu schreiben, die den ADC Simuliert und dann kann ich verschiedene Varianten in der Simulation ausprobieren.
Vielleicht konzentrierst Du Dich auch erstmal auf einen Übertragungsmodus. Wenn der geht kann man das immer noch aufbohren...
Hallo, Ich habe diesen Thread gefunden und ich bin momentan dabei ähnliche Dinge zu tun wie hier diskutiert wurden. Ich versuche einen HMCAD15xx (mit 7-family FPGA) mit Vivado zu verbinden und stoße dabei auf ähnliche Probleme. Hat es irgendjemand mittlerweile geschafft es zum Laufen zu bringen, in welchem Modus auch immer? Vielen Dank für eure Hilfe.
Stefan Kung schrieb: > Ich versuche einen HMCAD15xx > (mit 7-family FPGA) mit Vivado zu verbinden und stoße dabei auf ähnliche > Probleme. Das mache ich auch gerade. Aber aktuell noch in der Simulation. Stefan Kung schrieb: > Hat es irgendjemand mittlerweile geschafft es zum Laufen zu bringen, in > welchem Modus auch immer? Würde mich auch interessieren. Man bekommt aus dem ADC eine LCLK von 500 MHz und eine FCLK von 125 MHz. Meine Idee ist da jetzt einen SerDes zu verwenden.
1 | SerDes: HMCAD_SerDes |
2 | generic map( |
3 | SYS_W => 8, |
4 | DEV_W => 64) |
5 | port map( |
6 | data_in_from_pins_p => Data_LVDS_p, |
7 | data_in_from_pins_n => Data_LVDS_n, |
8 | data_in_to_device => Data, |
9 | bitslip => "00000000", |
10 | clk_in_p => CLK_LVDS_p, |
11 | clk_in_n => CLK_LVDS_n, |
12 | clk_div_out => CLK125_EXT, |
13 | clk_reset => clk_reset, |
14 | io_reset => io_reset); |
Mit einem Serialisierungsfaktor von 8 und DDR bekomme ich dann 64 Bit Data und eine clk_div_out von 125 MHz. Allerdings finde ich seltsam, dass der SerDes nicht noch die FCLK benötigt als externen Eingang um eben die richtigen 8 Bits je einem Sample zuzuordnen. Ja, es gibt Bitslip, aber das ist ein interner Eingang, also nicht extern LVDS. Sollte ich einfach Bitslip mit FCLK verbinden? Mein Problem ist, dass Data, also der Datenausgang des SerDes in der Simulation immer XXXXX... bleibt. clk_div_out passt und ich füttere auch korrekte Daten hinein über die Datenleitungen. Edit: Der andere Weg wäre eben zu Fuß für jeden Eingang IBUFDS zu setzen und für die Daten dann je ein IDDR. Da könnte ich dann mit der FCLK zur passenden Zeit die Werte übernehmen in die FPGA Logik. Der Nachteil ist, dass man da selbst mit 500 MHz LCLK zu tun hat. Ich kann das nicht abschätzen, würde aber vermuten, dass das mehr Ärger mit Timing macht als so ein SerDes Baustein der ja genau dafür gemacht ist. Edit2: So, jetzt habe ich Bitslip verstanden, das lässt quasi ein Bits aus wenn es aktiviert ist. Sehr fein. Also ist meine Strategie am ADC das pat_deskew solange zu verändern bis ich stabil die "01010101" (oder "10101010") empfange und dann pat_sync einstellen und bitslip so oft aktivieren bis ich "11110000" empfange. Klingt doch gut? Oder sollte ich den Weg über IBUFDS und IDDR gehen? Dann könnte ich mir das mit dem Bitslip sparen und FCLK verwenden. Vielen Dank!
:
Bearbeitet durch User
Hm ... das Timing wird doch echt schwer zu schaffen ohne SerDes. Ich habe jetzt
1 | IBUFDS_LCLK: IBUFDS |
2 | generic map( |
3 | DIFF_TERM => TRUE, |
4 | IBUF_LOW_PWR => FALSE, |
5 | IOSTANDARD => "LVDS_25") |
6 | port map( |
7 | O => LCLK, |
8 | I => LCLK_LVDS_p, |
9 | IB => LCLK_LVDS_n); |
10 | |
11 | IBUFDS_FCLK: IBUFDS |
12 | generic map( |
13 | DIFF_TERM => TRUE, |
14 | IBUF_LOW_PWR => FALSE, |
15 | IOSTANDARD => "LVDS_25") |
16 | port map( |
17 | O => FCLK, |
18 | I => FCLK_LVDS_p, |
19 | IB => FCLK_LVDS_n); |
20 | |
21 | GEN_Data: |
22 | for I in 0 to 7 generate |
23 | IBUFDS_inst: IBUFDS |
24 | generic map ( |
25 | DIFF_TERM => TRUE, |
26 | IBUF_LOW_PWR => FALSE, |
27 | IOSTANDARD => "LVDS_25") |
28 | port map |
29 | (O => Data_1Edge(I), |
30 | I => Data_LVDS_p(I), |
31 | IB => Data_LVDS_n(I)); |
32 | |
33 | IDDR_inst: IDDR |
34 | generic map ( |
35 | DDR_CLK_EDGE => "OPPOSITE_EDGE", |
36 | INIT_Q1 => '0', |
37 | INIT_Q2 => '0', |
38 | SRTYPE => "SYNC") |
39 | port map ( |
40 | Q1 => Data_1Clock(I), |
41 | Q2 => Data_1Clock(I+8), |
42 | C => LCLK, |
43 | CE => '1', |
44 | D => Data_1Edge(I), |
45 | R => '0', |
46 | S => '0'); |
47 | |
48 | end generate GEN_Data; |
49 | |
50 | process begin |
51 | wait until rising_edge(LCLK); |
52 | FCLK_buff <= FCLK; |
53 | Data_4Clocks <= Data_4Clocks(47 downto 0) & Data_1Clock; |
54 | if FCLK = '1' and FCLK_buff = '0' then |
55 | Data <= Data_4Clocks; |
56 | end if; |
57 | end process; |
Also erstmal zwei IBUFDS je für FCLK und LCLK. Dann im Generate wird für jede der 8 Datenleitungen ein IBUFDS und dahinter ein IDDR eingebaut. Damit bekomme ich also mit jedem Takt von LCLK einen neuen 16 Bit Wert Data_1Clock. Ausgeben möchte ich aber immer 8 ganze deserialisierte Werte. Dazu schiebe ich dann also mit LCLK immer Data_1Clock in Data_4Clocks hinein. Ausserdem muss noch FCLK ausgewertet werden. Wenn dann eine steigende Flanke von FCLK stattfindet, FCLK = '1' and FCLK_buff = '0', dann wird der 64 Bit vector ausgegeben. Vom Timing geht das aber nicht. Ich werde es also mit Serdes versuchen, habe aber ein Problem: Wenn ich mit Bitslip um 1 verschieben möchte, dann muss ich auch dieses Bitslip nur für einen Takt, bei 500 MHz, anlegen. Wie mache ich das? Zur Not würde ich die Logik selber schreiben um aus je mehreren 8 Bit Werten einer LVDS Lane ein Sample zu basteln. Dazu muss ich dann aber ein paar Werte speichern, klingt erstmal kompliziert, ist es aber vielleicht gar nicht wirklich.
:
Bearbeitet durch User
So, neuer Tag, neue Idee: Der SerDes bekommt einfach 9 Eingangsleitungen. Die 8 Datenleitungen und FCLK. FCLK ist synchron zu den Daten, bei den ersten 4 Bits sollte es 1 und bei den letzteren 4 Bits 0 sein. Also hat man schon wunderbar sein synchronisationspattern. Man muss das nicht über SPI einstellen. Funktioniert in der Simulation wunderprächtig und macht keine Timingprobleme. So, dann muss das nur noch auf die Hardware^^ muss mir noch die Konfiguration von dem HMCAD IC bauen ...
Gustl B. schrieb: > Der SerDes bekommt einfach 9 Eingangsleitungen. Die 8 Datenleitungen und > FCLK. FCLK ist synchron zu den Daten, bei den ersten 4 Bits sollte es 1 > und bei den letzteren 4 Bits 0 sein. Also hat man schon wunderbar sein > synchronisationspattern Bei einer ähnlichen Geschichte habe ich das auch so gemacht. Mit dem 11110000-Pattern von FCLK kann man einen Demultiplexer ansteuern, der dann aus den alten Samples und den aktuellen Samples die richtigen Daten rausfischt. Duke
Mittlerweile funktioniert alles fein. Aber ich verwende jetzt am SerDes Bitslip bis das Pattern von FCLK korrekt ist. Klar, ein Demultiplexer funktioniert anders als Bitslip, aber eigentlich sollte egal sein was ich verwende und trotzdem korrekte Daten herauskommen. Das konnte ich mit dem Demultiplexer aber nicht erreichen. Die Daten waren meistens korrekt aber nicht immer. Bei der Lösung mit Bitslip sind sie jetzt immer korrekt. Verstehe ich nicht aber werde ich mir für die Zukunft merken.
Bitte 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.