Designabhängigkeit von Debugsignalen

[Peter (Gast)]

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

[Vancouver (Gast)]

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.

[VHDL hotline (Gast)]

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.

[A. S. (Gast)]

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.

[Peter (Gast)]

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.

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

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:

   a <= c and b;

ergibt natürlich exakt das selbe Syntheseresultat und die selbe Harware 
wie der Prozess hier:

   process (c,b) begin
     a <= c and b;
   end process;

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

[Duke Scarring (Gast)]

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

[J. S. (engineer)]

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)

[VHDL hotline (Gast)]

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.

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

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

[S. R. (svenska)]

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