Hallo Community,
ich habe sei kurzem ein merkwürdiges Problem. Ich habe ein größeres
Design auf einem Xilinx Zynq gebaut. Daten werden über CSI2 empfangen
und an einen DMA weitergeleitet. Jetzt ist es so das das Design auf der
Hardware funktioniert wenn ich Debugsignale drin habe. Wenn ich diese
rausnehme funktioniert es nicht mehr. Dann steht alles. Der DMA lässt
nichts mehr rein (tready down). Im Prinzip ist das ja kein großes
Problem weil es ja funktioniert wenn ich die Debugsignale drin habe,
aber ich würde gerne wissen warum das so ist. Und vor allem wie bekomme
ich das in den Griff. Ich hab auch schon die Schematic mit und ohne
Debugsignalen angeschaut und sehe keinen Unterschied. Vielleicht muss
ich nochmal genauer nachsehen. Ich hätte vermutet das irgendwas
wegoptimiert wird bei der Implementierung wenn ich die Debugsignale
nicht drin habe. Aber das sehe ich so nicht...
Vielleicht könnt ihr mir Tipps geben woran es liegen könnte.
Danke sehr
Gruß
Peter
Ich nehme an, mit debug-Signalen meinst Du solche, die auf eine
Steckerleiste gelegt werden, um sie z.B. mit einem Analyzer anzuschauen?
Alles Ausgänge?
Das hört sich ganz stark danach an, dass etwas wegoptimiert wird. Hast
Du mal die Slice-Auslastung mit und ohne Debug-Signale verglichen? Wenn
die unterschiedlich sind, musst Du als nächstes mal den Synthesereport
durchgehen. Da steht sehr ausführlich drin, was alles wegoptimiert
wurde. Ich glaube, im Schematic kann man das nicht erkennen.
Sind die Debug-Signale voll nebenläufig? Hatte schon ab und zu den Fall,
dass eine (nicht nebenläufige) Debug-UART durch ihre relative
Langsamkeit das Timing so verändert, dass es ohne sie zu race conditions
kam.
Hast Du vielleicht mal in den Warnmeldungen geschaut? Der (vermutlich
noch immer) beliebteste Fehler ist, ein einkommendes Signal nicht zu
synchronisieren. Das Verhalten solcher Fehler wird natürlich auch durch
das aktuelle Routing bestimmt, was wiederum von der Gesamtschaltung
abhängt.
Rein Stochermäßig kannst Du Dein Debug-Design auch soweit reduzieren,
dass der Fehler gerade noch nicht auftritt, würde in dem Fall aber
nichts (an Erkentnis) bringen.
Vancouver schrieb:> Ich nehme an, mit debug-Signalen meinst Du solche, die auf eine> Steckerleiste gelegt werden, um sie z.B. mit einem Analyzer anzuschauen?> Alles Ausgänge?> Das hört sich ganz stark danach an, dass etwas wegoptimiert wird. Hast> Du mal die Slice-Auslastung mit und ohne Debug-Signale verglichen? Wenn> die unterschiedlich sind, musst Du als nächstes mal den Synthesereport> durchgehen. Da steht sehr ausführlich drin, was alles wegoptimiert> wurde. Ich glaube, im Schematic kann man das nicht erkennen.
Ne ich meine gewöhnliche ila Signale die ich in mein Design einbaue und
dann im Xilinx Vivado Hardware Manager anschauen kann.
DieSlice-Auslastung werde ich mir mal genauer ansehen, danke.
VHDL hotline schrieb im Beitrag #4869643:
> Sind die Debug-Signale voll nebenläufig? Hatte schon ab und zu den> Fall,> dass eine (nicht nebenläufige) Debug-UART durch ihre relative> Langsamkeit das Timing so verändert, dass es ohne sie zu race conditions> kam.
Ich nehme an das sie nebenläufig sind. Habe sie ganz normal mit Vivado
unter "Set Up Debug" ausgewählt.
Achim S. schrieb:> Hast Du vielleicht mal in den Warnmeldungen geschaut? Der> (vermutlich> noch immer) beliebteste Fehler ist, ein einkommendes Signal nicht zu> synchronisieren. Das Verhalten solcher Fehler wird natürlich auch durch> das aktuelle Routing bestimmt, was wiederum von der Gesamtschaltung> abhängt.>> Rein Stochermäßig kannst Du Dein Debug-Design auch soweit reduzieren,> dass der Fehler gerade noch nicht auftritt, würde in dem Fall aber> nichts (an Erkentnis) bringen.
Das kann ich eigentlich ausschließen, denn alle Eingangssignale gehen
direkt in fertige IPs rein. Ich hoffe das dort schon synchronisiert
wird. Es gibt auch keine Timing Verletzung.
VHDL hotline schrieb im Beitrag #4869643:
> Sind die Debug-Signale voll nebenläufig?
Da wird jetzt aber Kruat&Rüben heftig vermischt.
Eine nebenläufige Anweisung in VHDL (aka. Concurrent Assignment) ist
nichts anderes als ein auf eine einzige Anweisung reduzierter Prozess.
Und nattürlich kommt dann auch das Selbe dabei heraus. Diese
nebenläufige Beschreibung:
1
a<=candb;
ergibt natürlich exakt das selbe Syntheseresultat und die selbe Harware
wie der Prozess hier:
1
process(c,b)begin
2
a<=candb;
3
endprocess;
Peter schrieb:> Es gibt auch keine Timing Verletzung.
Das ist nicht sicher. Wenn kein Timing-Fehler im Report steht, dann ist
nur sicher, dass die Toolchain keinen sieht...
Achim S. schrieb:> Hast Du vielleicht mal in den Warnmeldungen geschaut?
Und auch die Infos. Manchmal steht dort ganz nebenbei der Hinweis, dass
das Design so nicht funktionieren wird...
Peter schrieb:> Das kann ich eigentlich ausschließen, denn alle Eingangssignale gehen> direkt in fertige IPs rein. Ich hoffe das dort schon synchronisiert
Da wäre ich vorsichtig.
Im Zweifel eine FF-Stufe einbauen. Wenn die Signale vom IO-Pin kommen
dann zwei FF-Stufen.
> wird. Es gibt auch keine Timing Verletzung.
Ohne timing constraints gibt es auch keine Warnungen...
Duke
Wenn es ein Problem des Einsynchronierens wäre, sollte das Vorhandensein
von DebugPins weiter hinten im Design nichts ändern. Ich gehe eher davon
aus, dass was komplett wegoptimiert wird. Allerdings wird nur
wegoptimiert, was im design nirgends abgefragt und verwendet wird.
Wahrscheinlich ist das design instabil und wird MIT debug anders gebaut.
Zufallsverhalten.
Ich würde da mal ChipScopeSigs einbauen und schauen, wo das
funktioniert.
(wahrscheinlich hat man dann aber auch denselben Effekt, dass es mit
CHipScope geht)
Lothar M. schrieb:> Da wird jetzt aber Kruat&Rüben heftig vermischt.> Eine nebenläufige Anweisung in VHDL (aka. Concurrent Assignment) ist
Nein, da vermische ich nix sondern meine es anders. Nebenläufig heißt
einfach, dass etwas "parallel" geschieht (auch Prozesse sind zueinander
concurrent) und somit im Fall der Debugsignale nicht den zeitlichen
Ablauf beeinflusst, wenn es aktiv ist oder nicht. Da er von einem Zynq
spricht, kann es durchaus sein, dass er in Software eine UART drin hat,
die dann eben nicht nebenläufig ist und den zeitlichen Ablauf der
Software beeinflusst.
VHDL hotline schrieb im Beitrag #4870062:
> Nein, da vermische ich nix sondern meine es anders.
Dann sollte man aber einen anderen Begriff verwenden, oder nicht.
In der Software ist der Begriff "nebenläufig" (noch) nicht bekannt, weil
dort eigentlich erst mal nichts "nebenläufig", sondern (zumindest pro
Kern) streng sequentiell ist.
> im Fall der Debugsignale nicht den zeitlichen Ablauf beeinflusst
Diese Signale sind doch (hoffentlich) nur Leitungen, die an den
virtuellen Logicanalyzer angeschlossen werden,
denn Peter schrieb:> ich meine gewöhnliche ila Signale
Denn wenn der Debugger Abläufe im System ändert (z.B. weil das Sytem auf
den Debugger warten muss), dann gehört er zum System und muss mit
betrachtet werden...
Lothar M. schrieb:> Dann sollte man aber einen anderen Begriff verwenden, oder nicht.> In der Software ist der Begriff "nebenläufig" (noch) nicht bekannt, ...
Ich kenne "nebenläufig" eher als Synonym zu "multithreaded", also für
Abläufe, die voneinander unabhängig sind und daher gleichzeitig
geschehen können. Zumindest in meinem Studium galt das sowohl für die
Steuerungstechnik, als auch in der Informatik.
Was du meinst, also die garantierte Gleichzeitigkeit verschiedener
Abläufe, kenne ich eher unter dem Begriff "echt parallel".
