Forum: FPGA, VHDL & Co. HMCAD1520 FMC Eval Board


von Hans-Georg L. (h-g-l)


Lesenswert?

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 ?

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>
> 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

von René D. (Firma: www.dossmatik.de) (dose)


Angehängte Dateien:

Lesenswert?

Ich glaube du suchst diese Geschichte. Diese habe ich von Verilog nach 
VHDL von Hand rübergehoben.

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ;)

von Hans-Georg L. (h-g-l)


Lesenswert?

Hans-Georg L. schrieb:

> Der HMCAD1520 schickt die Daten aber nicht als DDR sondern SDR ...

Das war falsch, es ist doch DDR.

von Hans-Georg L. (h-g-l)


Lesenswert?

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
von Bernd (Gast)


Lesenswert?

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

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ;).

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

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?

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

>
> 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)

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

Vielleicht konzentrierst Du Dich auch erstmal auf einen 
Übertragungsmodus. Wenn der geht kann man das immer noch aufbohren...

von Stefan Kung (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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
von Gustl B. (-gb-)


Lesenswert?

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
von Gustl B. (-gb-)


Lesenswert?

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 ...

von Duke Scarring (Gast)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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
Noch kein Account? Hier anmelden.