Hallo zusammen,
ich habe zwei Eingangssignale Data0 + Data1, die ich bei gedrücktem
Taster einfach kopieren und als Ausgangssignal wieder ausgeben möchte.
Die Eingangsignale laufen synchron zu einem Taktsignal (ca. 100 MHz,
stabiler Pegel bei steigender Flanke).
Mein Design sieht im Kern wie folgt aus:
Wenn ich mit Chipscope messe, stelle ich leider fest, dass einzelne
Pulse verschluckt werden. Siehe Anhang.
Was mache ich falsch? Kann mir bitte jemand helfen?
Grüße
Steffen
Moin,
ich verstehe nicht wieso du
attribute box_type: string;
attribute box_type of IBUFDS: component is "black_box";
attribute box_type of IBUFGDS: component is "black_box";
attribute box_type of OBUFDS: component is "black_box";
attribute keep: string;
attribute keep of IN_CLK: signal is "true";
aber nicht
--library UNISIM;
--use UNISIM.VComponents.all;
nutzt. IBUFDS, IBUFGDS, OBUFDS und noch viele Weitere sind dort
definiert.
Ausserdem sind OUT_CLK und IN_CLK nicht verbunden.
Ich habe die .vhd mal so geschrieben wie ich das machen würde und durch
Vivado geschickt. ISE habe ich nicht. Das hat wunderbar gebaut und
sollte genau so funktionieren.
Steffen H. schrieb:> Wenn ich mit Chipscope messe
Wenn ich da so diese kurzen Peaks so ansehe: mit welchem Takt läuft dein
Chipscope? Und woraus wird das getaktet?
Was kannst du mit einem externen Oszilloskop an den FPGA-Pins messen?
Lothar M. schrieb:> mit welchem Takt läuft dein Chipscope? Und woraus wird das getaktet?
Sehr gut!
Und was sagt die Simulation?
Duke Scarring schrieb:> Ist denn Dein Taster auch einsynchronisiert und entprellt?
Im Screenshot ist der dauerhaft low. Könnten natürlich kurze high Pulse
drinnen sein die das Chipscope nicht anzeigt.
Gustl, der Echte! schrieb:> ich verstehe nicht wieso du> [...]> aber nicht>> --library UNISIM;> --use UNISIM.VComponents.all;>> nutzt.
Anfängerfehler! Danke für den Hinweis, es funktioniert wunderbar.
Gustl, der Echte! schrieb:> Ausserdem sind OUT_CLK und IN_CLK nicht verbunden.
Ebenfalls korrigiert, aber die Pulse werden weiter verschluckt.
Gustl, der Echte! schrieb:> Ich habe die .vhd mal so geschrieben wie ich das machen würde und durch> Vivado geschickt. ISE habe ich nicht. Das hat wunderbar gebaut und> sollte genau so funktionieren.
Das ist nett, danke! Leider funktioniert es auch damit nicht. Es treten
weiterhin sporadisch Pulse am Ausgang auf, wo am Eingang keine gemessen
werden. Meine RTL sieht übrigens nun genauso aus, siehe Anhang.
.
Lothar M. schrieb:> Wenn ich da so diese kurzen Peaks so ansehe: mit welchem Takt läuft dein> Chipscope? Und woraus wird das getaktet?
Der Takteingang ist mit IN_CLK verbunden. Siehe Anhang. IN_CLK ist der
Bustakt (ca. 100 MHz). Data 0 und Data 1 sind stabil auf der steigenden
Flanke.
Lothar M. schrieb:> Was kannst du mit einem externen Oszilloskop an den FPGA-Pins messen?
Mein Oszilloskop ist leider zu langsam. Außerdem habe ich leider keinen
Differenztastkopf bzw. zu wenig Kanäle für Einzelmessungen. Heißt: Ich
kann keine Messung durchführen :-(
.
Gustl B. schrieb:> Duke Scarring schrieb:>> Ist denn Dein Taster auch einsynchronisiert und entprellt?>> Im Screenshot ist der dauerhaft low. Könnten natürlich kurze high Pulse> drinnen sein die das Chipscope nicht anzeigt.
Der Taster ist nur dafür da, dass die Verbindung IN -> OUT nicht
wegoptimiert wird. Der Eingang ist hardwareseitig offen und per
Constraint auf "PULLDOWN" gesetzt.
Gustl B. schrieb:> Sehr gut!> Und was sagt die Simulation?
Meinst Du die Simulation von Chipscope? Kann ich Chipscope simulieren?!
Eine Sache hatte ich noch erwähnt, um die Diskussion nicht in die
falsche Richtung zu lenken: ISE wirft Warnungen, auch solche, die auf
Probleme mit dem Takt hinweisen. Allerdings darf ich, soweit ich es im
Netz gelesen habe, diese Warnungen ignorieren.
Hier die Liste aller Warnungen:
1
WARNING:ConstraintSystem:56 - Constraint <TIMESPEC TS_J_CLK = PERIOD "J_CLK"
2
30000.000000000 pS HIGH 50.000000000 %;>: Unable to find an active 'TNM' or
3
'TimeGrp' constraint named 'J_CLK'.
4
5
WARNING:ConstraintSystem:56 - Constraint <TIMESPEC TS_U_TO_J = FROM "U_CLK" TO
6
"J_CLK" 15000.000000000 pS;>: Unable to find an active 'TimeGrp' or 'TNM' or
7
'TPSync' constraint named 'J_CLK'.
8
9
WARNING:ConstraintSystem:56 - Constraint <TIMESPEC TS_J_TO_D = FROM "J_CLK" TO
10
"D_CLK" TIG;>: Unable to find an active 'TimeGrp' or 'TNM' or 'TPSync'
11
constraint named 'J_CLK'.
12
13
WARNING:ConstraintSystem:56 - Constraint <TIMESPEC TS_D_TO_J = FROM "D_CLK" TO
14
"J_CLK" TIG;>: Unable to find an active 'TimeGrp' or 'TNM' or 'TPSync'
15
constraint named 'J_CLK'.
16
17
WARNING:PhysDesignRules:372 - Gated clock. Clock net icon_control0<13> is
18
sourced by a combinatorial pin. This is not good design practice. Use the CE
19
pin to control the loading of data into the flip-flop.
20
21
WARNING:Place:414 - The input design contains local clock signal(s). To get a better result, we recommend users run map
22
with the "-timing" option set before starting the placement.
23
24
WARNING:Route:455 - CLK Net:IN_CLK may have excessive skew because
25
4 CLK pins and 1 NON_CLK pins failed to route using a CLK template.
26
27
WARNING:Route:455 - CLK Net:icon_control0<13> may have excessive skew because
28
1 CLK pins and 3 NON_CLK pins failed to route using a CLK template.
29
30
WARNING:PhysDesignRules:372 - Gated clock. Clock net icon_control0<13> is
31
sourced by a combinatorial pin. This is not good design practice. Use the CE
32
pin to control the loading of data into the flip-flop.
Steffen H. schrieb:> Leider funktioniert es auch damit nicht.
Irgendwie schon klar, weil das SIM un UNISIM darauf hindeutet, dass das
Bibliotheken für die SIMulation sind. Du willst aber gar nicht
simulieren.
> ISE wirft Warnungen, auch solche, die auf Probleme mit dem Takt hinweisen.
Dein Design hat eigetnlich keinen Takt. Deshalb deuten diese Warnungen
eher auf ein Problem mit dem Chipscope Takt hin.
> Außerdem habe ich leider keinen Differenztastkopf bzw. zu wenig Kanäle> für Einzelmessungen. Heißt: Ich kann keine Messung durchführen :-(
Dir ist aber schon klar, dass du so ein LVDS-Signal auch unipolar
ansehen und messen kannst.
> Mein Oszilloskop ist leider zu langsam.
In Zahlen? Man kann auch mit einem Oszilloskop mit einer analogen
Bandbreite von 50MHz erkennen, ob die Impulse durchgehen.
BTW: ich würde da erstmal ein besser definiertes Eingangssignal
reingeben. Eines, das z.B. 10 Takte lang stabil ist. Und dann mal
schauen, was dabei herauskommt.
> Der Takteingang ist mit IN_CLK verbunden.
Lass mal auf diesen Takt einen Zähler laufen und schau, ob der sauber
hochzählt, nicht dass der Takt noch dumm tut.
Lothar M. schrieb:> Dein Design hat eigetnlich keinen Takt. Deshalb deuten diese Warnungen> eher auf ein Problem mit dem Chipscope Takt hin.
Darauf wollte ich hinaus: wenn ich die Chipscope Instanz wegnehme,
fallen sämtliche Warnungen weg.
Lothar M. schrieb:> In Zahlen? Man kann auch mit einem Oszilloskop mit einer analogen> Bandbreite von 50MHz erkennen, ob die Impulse durchgehen.
HP54200A -> 2 Kanal DSO mit 200MHz Abtastrate. Das geht schon irgendwie,
aber wirklich Klarheit bekomme ich nicht. Es sind halt Pegeländerungen
von 350 mV für 10 ns.
Ich hatte es auch erfolglos mit einem LVDS Pegelwandler im fliegenden
Aufbau probiert. Also ohne da Aufwand reinzustecken (zeitlich und
finanziell) bekomme ich die externe Hardware nicht ausgemessen.
Lothar M. schrieb:> BTW: ich würde da erstmal ein besser definiertes Eingangssignal> reingeben. Eines, das z.B. 10 Takte lang stabil ist. Und dann mal> schauen, was dabei herauskommt.
Nachdem das Signal den IBuf passiert hat, ist es doch in der FPGA Logik
angekommen. Wie kann es sein, dass Chipscope am Eingang keine Pulse
findet, aber am Ausgang schon? Kann das denn wirklich von "außen"
kommen?
Anders formuliert: Gibt es überhaupt eine bestimmte Signalform, die
Chipscope veranlasst, soetwas auszugeben? Denn wenn nicht, liegt der
Fehler ausschließlich innerhalb meines FPGA-Designs.
Einen Funktionsgenerator besitze ich übrigens leider nicht.
Lothar M. schrieb:> Lass mal auf diesen Takt einen Zähler laufen und schau, ob der sauber> hochzählt, nicht dass der Takt noch dumm tut.
Prima, das probiere ich aus!
Steffen H. schrieb:> HP54200A
Du hast aber viel Platz auf dem Schreibtisch...
> das probiere ich aus!
Und dann toggle mit dem Takt einen Ausgangspin einfach immmer nach 8
oder 16 Bit und mach ein "Augendiagramm" auf deinem Oszi (Trigger auf
Flanke, Nachleuchtzeit auf ewig).
Wenn der Takt ordentlich ist, siehst du da nur 1 Kurve, die nicht
"ausfranst".
Im Anhang die Chipscope Messung mit dem vorgeschlagenem Zähler. Was
hältst Du / was haltet ihr davon?
.
Lothar M. schrieb:> Und dann toggle mit dem Takt einen Ausgangspin einfach immmer nach 8> oder 16 Bit und mach ein "Augendiagramm" auf deinem Oszi (Trigger auf> Flanke, Nachleuchtzeit auf ewig).
Mein HP54200 kann leider kein Augendiagramm darstellen. Es ist ein DSO
aus Mitte der 80er Jahre.
Lothar M. schrieb:> Du hast aber viel Platz auf dem Schreibtisch...
Wie mans nimmt: Jetzt nicht mehr ;-)
Steffen H. schrieb:> Meinst Du die Simulation von Chipscope? Kann ich Chipscope simulieren?!
Nein, die VHDL Simulation. Du schreibst eine Testbench in VHDL in der du
deine vorhandene Beschreibung instantiierst. Und das simulierst du dann
mit Modelsim oder iSim von ISE.
Steffen H. schrieb:> Im Anhang die Chipscope Messung mit dem vorgeschlagenem Zähler. Was> hältst Du / was haltet ihr davon?
Wer misst misst Mist.
Das sieht für mich so aus, als ob der Zähler schnurgerade durchläuft und
sich das Chipscope verstoplert.
Steffen H. schrieb:> Mein HP54200 kann leider kein Augendiagramm darstellen.
Trigger auf steigende oder fallende Flanke und dann Nachleuchtdauer auf
"ewig".
Wenn das dann so aussieht, dann jittert da nichts:
1
_________________ ________
2
| | |
3
| | |
4
| | |
5
| | |
6
___| |_______________|
7
^
8
T
Wenn es aber so aussieht, dann passt was mit dem Zähler nicht:
Gustl B. schrieb:> Nein, die VHDL Simulation. Du schreibst eine Testbench in VHDL in der du> deine vorhandene Beschreibung instantiierst. Und das simulierst du dann> mit Modelsim oder iSim von ISE.
In der Simulation werden keine Pulse verschluckt. Dort funktioniert
alles einwandfrei.
Lothar M. schrieb:> Trigger auf steigende oder fallende Flanke und dann Nachleuchtdauer auf> "ewig".
Danke für die Beschreibung. Leider kann ich bei meinem Oszilloskop keine
Nachleuchtdauer einstellen. Es kann leider auch nicht mehrere Sample
übereinander legen, was ja sonst den gleichen Effekt hätte.
Ich bin ratlos, was ich nun tun soll. Ich möchte sehr gerne mit
Chipscope messen, aber ich muss der Messung vertrauen können. Sonst
nützt es mir nichts.
Macht es Sinn, auf eine andere Version von Chipscope zu wechseln?
Steffen H. schrieb:> In der Simulation werden keine Pulse verschluckt. Dort funktioniert> alles einwandfrei.
Wenn die Simulation anders ist, als die Realität, dann fehl noch was im
Simulationsmodell.
> Leider kann ich bei meinem Oszilloskop keine> Nachleuchtdauer einstellen. Es kann leider auch nicht mehrere Sample> übereinander legen, was ja sonst den gleichen Effekt hätte.
Bei manchen Jitter-Messungen hilft es, den Triggerzeitpunkt weit vor die
eigentliche Darstellung zu legen.
> Ich möchte sehr gerne mit> Chipscope messen, aber ich muss der Messung vertrauen können. Sonst> nützt es mir nichts.>> Macht es Sinn, auf eine andere Version von Chipscope zu wechseln?
Nein. Chipscope ist ausentwicklet. Da gibt es nach meiner Erfahrung
keine signifikaten Vesionsunterschiede.
Ich würde mir noch mal ganz genau die Pinzuordnung anschauen. Nicht das
Du um einen Pin daneben liegst und der Eingang nur durch die
Koppelkapazität angeregt wird.
> Ich bin ratlos, was ich nun tun soll.
Vereinfache das Design weiter, um weitere Ursachen auszuschließen.
Duke
Steffen H. schrieb:> Meine Constraints im Kern so:
Hast du die Clock Constraints auch auf 100 MHz ??? .
BuffG -- Buf Buf .... .....
Das muss mal so intern getrimmt werden.
Die Hardware & die Simu sind nicht gleich.
Such dir ein RefDesign das geht und mit 100 MHz geht.
Und analysiere das genau. Clock Constraints
Viel Erfolg.
Thread beobachten
Seitenaufteilung abschalten