Verschiedene Clock-Domains mit VIVADO 2015.2 und HLS

[Andy N. (jtani)]

Hallo Zusammen,
ich habe gerade ein Projekt mit verschiedenen Clock-Domains unter VIVADO 
2015.2 und HLS mit einem ZYNQ.
Ich suche gerade nach dem richtigen Lösungsansatz für dieses Problem.

Bei früheren Projekten unter ISE14.2 habe ich dies mit einem 
dualport_blockram gelöst. Das hat ganz gut funktioniert - war aber schon 
recht aufwendig (finde ich...).

Im Internet habe ich leider kein konkretes Beispiel gefunden, wie man 
das heute unter VIVADO möglichst "elegant" lösen kann.
Mein jetziger Ansatz:
- eine HLS-IP für Clockdomain1. Diese Domain hat ein BRAM-Interface 
(write only)
- eine weitere HLS-IP für Clockdomain2. Diese Domain hat auch ein 
BRAM-Interface (read only) und ein AXI_LITE interface.
- unter VIVADO erzeuge ich ein dualport blockram mit dem Block Memory 
Generator
- nun kann ich die zwei HLS-IPs über das BRAM miteinander verbinden - 
und über das AXI-Interface darauf zugreifen (muss natürlich in HLS 
programmiert werden)

Ich denke, das sollte funktionieren --> ist aber meiner Meinung nach 
sehr umständlich. Ich hätte unter HLS eine viel einfachere Möglichkeit 
erwartet.
Kann jemand von Euch helfen?
Wie würdet Ihr das machen?

Viele Grüße,

Andy

[Antti L. (xilant)]

hast mal nach gedacht warum CLK port NICHT in AXI bus drin ist?

wegen clock domain crossing!

wenn du mit axi interconnect sachen zusammenbaust, dann werden ip 
dazwischen gescmugelt die den clock domain crossing FÜR DICH machen!

musst nur richtig zusammenstellen und clk input zu richtigen clocks 
verbinden.

[Andy N. (jtani)]

Hallo Antti,
vielen Dank für Deine Antwort. Das war mir in dieser Form nicht 
bewusst... Ist aber eigentlich logisch.

Eine Frage hätte ich aber noch:
Wie sieht es mit dem Reset ap_rst_n aus --> müssen ap_rst_n und ap_clk 
in irgend einer Form synchron sein. Gibt es irgendwelche Timings, die 
eingehalten werden müssen? Eigentlich dürfte es nicht nötig sein - bei 
einer FSM in VHDL sind Reset und Clock auch nicht zwingend synchron...



Viele Grüße,

Andy

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andy N. schrieb:
> bei einer FSM in VHDL sind Reset und Clock auch nicht zwingend synchron...
Das sollte aber geändert werden.
Der Reset darf gern asynchron aktiv werden. Er MUSS aber immer 
synchron inaktiv werden. Sonst läuft mit ein wenig Pech das halbe FPGA 
los und die andere Hälfte startet einen Takt später. Und das kann 
durchaus auch Flipflops der selben FSM oder des selben Zählers 
betreffen.

Man erkennt diese Designs, wenn der Entwickler sagt:
"... aber wenn es anläuft, dann läuft es tagelang fehlerfrei!"

[Andy N. (jtani)]

Hallo Lothar,
da bin ich aber froh, dass es bei meinen Designs so ist :-)
Und sie laufen auch schon seit vielen Jahren (bei 100% Einschaltdauer) 
stabil.

Für mein konkretes Problem fehlt mir jetzt aber trotzdem der Ansatz. 
Vielleicht kannst Du weiter helfen (wäre super!):

Über einen 24-Bit Datenbus stehen die Daten bei jeder positiven Flanke 
des Clocks an. Der Clock hat 40MHz.
Ich habe schon über SERDES nachgedacht - diese gehen aber anscheinend 
nur bis maximal 16-Bit Breite. Schade.
Ein Reset kommt nicht mit.
Alternativ könnte ich eine FSM mit 250MHz betreiben und so den Datenbus 
abtasten. Ich bin mir aber sicher, dass es da eine sinnvollere 
Möglichkeit gibt...

Hast Du für mich eine Idee, wie ich diesen Datenbus am Besten auslesen 
und die Daten ins PS bringen kann?

Viele Grüße,

Andy

[Antti L. (xilant)]

wenn die reset und assotiated clock nicht syncron sind sollte Vivado 
auch meckern, und bei auto connect macht der selber den RESET sync stuff 
da rein für dich :)

[Andy N. (jtani)]

Antti L. schrieb:
> wenn die reset und assotiated clock nicht syncron sind sollte Vivado
> auch meckern, und bei auto connect macht der selber den RESET sync stuff
> da rein für dich :)

Hallo Antti,
ich habe es ausprobiert. Er hat den Reset-sync-Kram automatisch 
erstellt. Er hat eine "Processor System Reset IP" hinzugefügt und einen 
zusätzlichen Port im AXI-Interconnect. Wenn man das AXI-Interconnect 
erweitert, dann bei dem coupler auch einen "AXI Clock Converter".
Den Eingang des "Processor System Reset" hat er nicht automatisch 
belegt. Ich habe diesen auf FCLK_REESET0_N des ZYNQ gelegt.

PROBLEM:
Aus irgend welchen Gründen scheint die HLS-Custom-IP keinen Clock zu 
bekommen - oder im Reset-Zustand zu hängen.
Wenn ich im ZYNQ die IP starten will, dann bleibt das Programm bei 
XJt_framegrabber_EnableAutoRestart hängen (das sehe ich an den 
Debug-Ausgaben auf der Konsole):

  _status = XJt_framegrabber_Initialize(&Jt_framegrabber, XPAR_JT_FRAMEGRABBER_0_DEVICE_ID);
  if (_status != XST_SUCCESS) {
    xil_printf("-- No XJt_framegrabber_Initialize --\r\n");
    while(1)
      ;
  }
  xil_printf("Framegrabber init 1\r\n");
  // IP starten
  XJt_framegrabber_EnableAutoRestart(&Jt_framegrabber);
  xil_printf("Framegrabber init 2\r\n");
  XJt_framegrabber_Start(&Jt_framegrabber);
  xil_printf("Framegrabber init 3\r\n");

Im Constraint-File habe ich dieses Constraint hinzugefügt - weil ich 
sonst eine "Critical Warning" bekomme:

create_clock -period 23.52941176 [get_ports p_pin_framegrabber_ap_clk]

Vielleicht habe ich auch beim Auto connect einen Fehler gemacht:
Ich habe die HLS-Custom-IP reingeholt. Dann habe ich ap_clock external 
gemacht. Und dann habe ich erst autoconnect ausgeführt. Eigentlich 
sollte es passen - oder?

Es wäre schön, wenn mir jemand einen Hinweis geben könnte.

Viele Grüße,

Andy

[Andy N. (jtani)]

Hallo,
kleines Update:
Ich habe mit der Reset- und der Clockleitung herumprobiert.
Soweit ich das sehe, ist die Reset-Leitung OK.
Es scheint an der Clock-Leitung zu liegen. Bleibt nur die Frage, wie man 
das weiter debuggen kann.

Hat jemand eine Idee?

Viele Grüße,

Andy