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
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.
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
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!"
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
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 :)
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):
1 | _status = XJt_framegrabber_Initialize(&Jt_framegrabber, XPAR_JT_FRAMEGRABBER_0_DEVICE_ID); |
2 | if (_status != XST_SUCCESS) { |
3 | xil_printf("-- No XJt_framegrabber_Initialize --\r\n"); |
4 | while(1) |
5 | ;
|
6 | }
|
7 | xil_printf("Framegrabber init 1\r\n"); |
8 | // IP starten
|
9 | XJt_framegrabber_EnableAutoRestart(&Jt_framegrabber); |
10 | xil_printf("Framegrabber init 2\r\n"); |
11 | XJt_framegrabber_Start(&Jt_framegrabber); |
12 | xil_printf("Framegrabber init 3\r\n"); |
Im Constraint-File habe ich dieses Constraint hinzugefügt - weil ich sonst eine "Critical Warning" bekomme:
1 | 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
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
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.