Forum: FPGA, VHDL & Co. Chipscope beeinflusst Datentransfer von FX2


von Otto N. (gelenkeharald)


Lesenswert?

Hallo Leute,

Ich habe ein Problem und komm einfach nicht weiter.

Ich benutze ein gekauftes FPGA Board (Trentz eletronic TE0300-01BM) auf
dem ein Spartan 3E und der geläufige Cypress FX2 USB2.0
CY7C68013A-56LFXC drauf sind.

Was ich mach will ist vom FPGA aus alle 50µs ein Datenpaket an den FX2
schicken zu lassen und diese dann am PC zu loggen. Ich benutze ein
fertiges VHDL-Modul zur Anbindung des FX2. In der Simulation
funktioniert das Senden der Daten einwandfrei. Ebenfalls wenn ich mir
die Signale im Chipscope ansehe.

Da das natürlich für einen Anwender nicht sonderlich komfortabel ist,
habe ich ein C++ Programm geschrieben, welches die Daten vom FX2 in
500Byte großen Paketen abholt und in eine Datei schreibt.

Und jetzt kommt mein eigentliches Problem:
Der Datentransfer mit dem C++ Programm funktioniert einwandfrei, wenn
ich Chipscope nebenbei triggern lasse. Bsp nach jedem Paket. Das
funktioniert auch mehrmals hintereinander.

Jedoch funktioniert der Datentransfer nie, wenn ich Chipscope nicht
triggern lasse oder die Chipscope-Blöcke garnicht erst mit
synthetisiere. Das ist doch verrückt?!

Kennt jemand solch ein Verhalten und weis am besten noch was man dagegen
tun kann? Gerne gebe ich auch weitere Informationen oder Quelltext
weiter.

Grüße GH

von hjk (Gast)


Lesenswert?

Entweder was sehr komisch gebaut oder, was warscheinlicher ist, keine 
Timing constraints(erfüllt).

von Otto N. (gelenkeharald)


Lesenswert?

alle Timing constraints sind erfüllt!

ich frag mich halt, wie die beeinflussung zustande kommt?
bis auf das benötigte control signal sind am chipscope_core keine 
ausgänge vorhanden, die irgendwas beeinflussen könnten

ist das komisch gebaut? die trigger eingänge sind ja immer vom typ 
std_logic_vector auch wenn nur 1 bit beobachtet werden soll
1
USB_SLWR_pin <= USB_SLWR(0);
2
USB_FLAGB(0) <= USB_FLAGB_pin;
3
USB_FLAGD(0) <= USB_FLAGD_pin;
4
detect3_dbg(0) <= detect3;
5
USB_PKTEND_pin <= USB_PKTEND(0);
6
USB_FIFOADR_pin <= USB_FIFOADR;
7
USB_CLK(0) <= USB_IFCLK;
8
sample_en_dbg(0) <= sample_en;
9
10
inst_chipscope : chipscope_core
11
  port map (
12
    CONTROL => scontrol,
13
    CLK => SYS_Clk,
14
    TRIG0 => USB_CLK,
15
    TRIG1 => USB_SLWR,
16
    TRIG2 => USB_FLAGB,
17
    TRIG3 => USB_FLAGD,
18
    TRIG4 => detect3_dbg,
19
    TRIG5 => USB_PKTEND,
20
    TRIG6 => USB_FIFOADR,
21
    TRIG7 => USB_FD_O,
22
    TRIG8 => sample_en_dbg);
23
   
24
inst_icon : icon_core
25
  port map (
26
    CONTROL0 => scontrol);

von Christian R. (supachris)


Lesenswert?

Sowas kann eigentlich nur passieren, wenn das Timing so knapp ist, dass 
das Hinzufügen/Entfernen einer Komponente was durcheinanderbringt. Schau 
nochmal genau die FX2 Timings an, der ist da ziemlich anspruchsvoll. Mit 
welcher Frequenz lässt du denn den IFCLK laufen? Läuft denn die 
Simulation ohne ChipScope?

von Rudolph (Gast)


Lesenswert?

Otto Normalverbraucher schrieb:
> alle Timing constraints sind erfüllt!

Welche Constraints sind denn gesetzt? Reichen die aus? Das Fehlerbild 
weisst stark auf Timingprobleme hin, in dieser Richtung würde ich weiter 
suchen, gucken, ob alle Pfade mit Constraints abgedeckt sind usw. Wenn 
sich ISE die Timings selber suchen muss, kann er sie auch erfüllen ohne 
das was sinnvolles rauskommt.

von Otto N. (gelenkeharald)


Lesenswert?

das sind die vorgegebenen contraints, die auch alle erfüllt werden
1
#================================================
2
# EZ-USB FX2 Interface
3
#================================================
4
Net USB_IFCLK_pin TNM_Net = USB_IFCLK_pin;
5
TIMESPEC TS_USB_IFCLK_pin = PERIOD USB_IFCLK_pin 20833 ps;
6
7
# FX2 timing constrains
8
NET "USB_FD_pin<*>"       OFFSET =  IN   9 ns BEFORE "USB_IFCLK_pin" RISING;
9
TIMESPEC TS_B2P = FROM RAMS TO PADS 10 ns;
10
NET "USB_FLAGB_pin"       OFFSET =  IN  10 ns BEFORE "USB_IFCLK_pin" RISING;
11
NET "USB_FLAGD_pin"       OFFSET =  IN  10 ns BEFORE "USB_IFCLK_pin" RISING;
12
NET "USB_SLWR_pin"         OFFSET = OUT   9 ns AFTER  "USB_IFCLK_pin" RISING;
13
# USB_SLRD_pin drived from flip-flop in OPAD, so there is maximum that you can get from this device
14
#NET "USB_SLRD_pin"       OFFSET = OUT 7.4 ns AFTER  "USB_IFCLK_pin" RISING;  # If you don't use DCM
15
NET "USB_SLRD_pin"         OFFSET = OUT 5.7 ns AFTER  "USB_IFCLK_pin" RISING;  # If you use DCM
16
NET "USB_SLOE_pin"         OFFSET = OUT   9 ns AFTER  "USB_IFCLK_pin" RISING;
17
NET "USB_PKTEND_pin"       OFFSET = OUT   9 ns AFTER  "USB_IFCLK_pin" RISING;
18
NET "USB_FIFOADR_pin<*>"   OFFSET = OUT   9.5 ns AFTER  "USB_IFCLK_pin" RISING;

mehr timing contraints habe ich nicht gesetzt

die simulation läuft ohne chipscope

usb_ifclk: 48 Mhz
sys_clk: 100 Mhz

von Christian R. (supachris)


Lesenswert?

Ohoh, 48MHz, ich habs fast vermutet. Bei 48 MHz ist das Timing kaum zu 
schaffen, vor allem, was die Flags angeht, wenn man im selben Takt noch 
reagieren und ggf. das Schreiben/Lesen stoppen muss. Da sind Setup- plus 
Delay größer als die 20,83ns. Wir haben den FX2 mit 48MHz nicht stabil 
zum Laufen bekommen. Nutzen daher einen externen IFCLK von 25MHz. Damit 
ist man im 16 Bit Modus immer noch um einiges schneller als der die 
Daten per USB wegschaufeln kann.

von Otto N. (gelenkeharald)


Lesenswert?

danke für den tip

hab jetzt usb_clk auf 24 MHz runtergesetzt und die Systemclock ebenfalls 
(auf 50 MHz), leider ändert, dass nichts an dem skurrilen Einfluss von 
Chipscope :-/

von Christian R. (supachris)


Lesenswert?

Tja, dann bleibt nur noch klassische Fehlersuche mit Simulator und 
externem Logic-Analyser. "Geht nicht" ist übrigens keine 
Fehlerbeschreibung. ;)

von Rudolph (Gast)


Lesenswert?

Otto Normalverbraucher schrieb:
> Net USB_IFCLK_pin TNM_Net = USB_IFCLK_pin;
> TIMESPEC TS_USB_IFCLK_pin = PERIOD USB_IFCLK_pin 20833 ps;
>
> mehr timing contraints habe ich nicht gesetzt
>
> usb_ifclk: 48 Mhz
> sys_clk: 100 Mhz

Kein Constraint für sys_clk?

von Christian R. (supachris)


Lesenswert?

Manchmal liegt der Fehler ganz wo anders. Wir haben auch mal ewig im 
Design gesucht, welches sporadisch einen externen FIFO nicht korrekt 
ausgelesen hatte. Mit ChipScope gings auch, aber ohne nicht. Grund war, 
dass der FIFO nach dem Power Up nochmal explizit ein Reset auf der 
TRST-Leitung oder einen TAP-Reset über JTAG haben möchte (IDT). Durch 
die ChipScope Verbindung hat der den JTAG-Reset korrekt bekommen, und 
dann liefs. Hat aber eine Weile gebraucht, bis wir die Fußnote im 
Datenblatt des FIFO gefunden und uns das rekonstruieren konnten.

von Otto N. (gelenkeharald)


Lesenswert?

ich wollte den thread nochmal hochholen und vermelden, dass es zum teil 
an den einhaltungen der contraints lag, was ich jetzt zum teil 
erfolgreich beheben konnte, hierzu habe ich nochmal eine frage

contraints mit AFTER, wie bspw.:
NET "USB_SLWR_pin" OFFSET = OUT   9 ns AFTER  "USB_IFCLK_pin" RISING;

habe ich über ein flipflop realisiert um das signal "auszuclocken" (sagt 
man das so?)

1
process(USB_IFCLK_pin)
2
  begin
3
    if(USB_IFCLK_pin'event and USB_IFCLK_pin = '1') then
4
      USB_SLWR_pin <= USB_SLWR;
5
    end if;
6
  end process;

wie mache ich das aber mit BEFORE ? für bspw.:
NET "USB_FLAGB_pin" OFFSET =  IN  10 ns BEFORE "USB_IFCLK_pin" RISING;

wie funktioniert, dass mit dem "einclocken"?
so geht es jedenfalls nicht, da sich bereits in der behavioral 
simulation ein fehlverhalten ergibt

1
process(USB_IFCLK_pin)
2
  begin
3
    if(USB_IFCLK_pin'event and USB_IFCLK_pin = '1') then
4
      USB_FLAGB <= USB_FLAGB_pin;
5
    end if;
6
  end process;

grüße GH

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
Noch kein Account? Hier anmelden.