Forum: FPGA, VHDL & Co. Cyclone Treiberleistung zu schwach


von Johnsn (Gast)


Lesenswert?

Hab nen Cyclone EP1C6 und es läuft ein Design ansich recht gut drauf. 
Allerdings, wenn ich dann zusätzliche Peripherie ansteuern will, dann 
funktioniert das Design nicht mehr! Die zusätzliche Peripherie steuere 
ich mit 3 Leitungen an (Clock, Send, Return) und das ganze 11 Mal. 
Sprich: ich gebe 11 Mal einen Takt von 24 MHz auf globale IO-Pins aus. 
Könnte dies dazu führen, dass die gesamte Treiberleistung des FPGAs zu 
schwach wird und deshalb nichts mehr funktioniert?

von Falk B. (falk)


Lesenswert?

@ Johnsn (Gast)

>ich mit 3 Leitungen an (Clock, Send, Return) und das ganze 11 Mal.
>Sprich: ich gebe 11 Mal einen Takt von 24 MHz auf globale IO-Pins aus.
>Könnte dies dazu führen, dass die gesamte Treiberleistung des FPGAs zu
>schwach wird und deshalb nichts mehr funktioniert?

Kaum. Die FPGAs von heute haben schon ordentlich Dampf. Es kann jedoch 
sein, dass die Treiberstärke standardmaässig auf ein Minimum eingestellt 
ist. Schau mal in das Toll zur Pinzuweisung.

MfG
Falk

von Johnsn (Gast)


Lesenswert?

Im Assignment-Editor als auch im QSF finde ich keine Hinweise auf 
constraints. Es ist auch schon komisch, wenn ich nur versuche 4 
zusätzliche Testpins hinzuzufügen. Sobald ich zusätzliche Logik 
raufpacken will, geht die ursprüngliche nicht mehr.

von Johnsn (Gast)


Lesenswert?

Hab das Problem immer noch nicht gelöst.

Woran könnte es liegen, dass plötzlich ein FPGA-Design nicht mehr 
funktioniert, wenn man nur zusätzliche Logik verwendet?

von high_speed (Gast)


Lesenswert?

Wurde schon mal das Timing überprüft?

Worin liegt denn die Fehlfunktion?

VHDL - Code ?

MfG
Holger

von Falk B. (falk)


Lesenswert?

@ Johnsn (Gast)

>Woran könnte es liegen, dass plötzlich ein FPGA-Design nicht mehr
>funktioniert, wenn man nur zusätzliche Logik verwendet?

Ja du bist ein Scherzkeks.  Wie kommt man aud die komische Idee, dass 
die Treiberleistung der IOs zu schwach ist, wenn ein FPGA-Design nicht 
mehr funktioniert? Zu 99% ist es ein Programmierfehler. Deine These mit 
zu schwachen IOs kann man leicht mit einem Oszi prüfen. Tu das.

MfG
Falk

von Johnsn (Gast)


Lesenswert?

@ high_speed
Es geht um einen USB-Core. Den Code darf ich nicht posten, würde auch 
das überschaubare Maß überschreiten. Timing hab ich mit Oszi gemessen 
und passt.

@ Falk
Ich mach keine Scherze! Der USB-Core funktioniert ohne Peripherie ohne 
Probleme (Enumeration und Datenaustausch). Ich will damit die Daten, die 
ich über das im ersten Beitrag erwähnt 3-Draht-Interface (eigenes 
Protokoll) bekomme über USB verschicken. Die beiden Units sind über ein 
RAM abgekoppelt und haben sozusagen nicht direkt miteinander zu tun.

Das 3-Draht-IF hab ich 11 Mal und jetzt kommt das komische (wo ich auch 
vorher dachte es wäre ein Scherz): Wenn ich die Taktversorgung zum 
3-Draht-IF abschalte, gibts nach wie vor keine Probleme. Schalte ich die 
Takte zu, dann schepperts bereits bei der USB-Enumeration. Hänge ich 
hingegen nur die ersten 5 Takte an, geht wieder alles. Hänge ich mehr 
als 5 Takte an zB 8, dann gehts wieder nicht. Darum habe ich an einen 
Leistungseinbruch des Cyclones gedacht.

von Johnsn (Gast)


Lesenswert?

Noch was vergessen: Das 3-Draht-Interface funktioniert in allen Fällen!

von Falk B. (falk)


Lesenswert?

@ Johnsn (Gast)

>Takte zu, dann schepperts bereits bei der USB-Enumeration. Hänge ich
>hingegen nur die ersten 5 Takte an, geht wieder alles. Hänge ich mehr
>als 5 Takte an zB 8, dann gehts wieder nicht. Darum habe ich an einen
>Leistungseinbruch des Cyclones gedacht.

Dann schau dir die Signale mit nem gescheiten Oszi an. Vielleicht hat 
der FPGA ungenügend Enkopplungskondensatoren, wenn gleich das 
unwahrscheinlich ist. Oder es gibt Übersprechen. Oder ein Kurzschluss. 
Oder Treiber von aussen treiben gegen Ausgänge vom Cyclone (Pins falsch 
zugeordnet). Oder, oder, oder.

MFG
Falk

von J. S. (engineer) Benutzerseite


Lesenswert?

Dieser Takt ist aber nicht zufällig der Systemtakt des FPGAs, denn Du 
hart herausgeführt hast? Das könnte ein Grund für solche 
Belastungs-Zeit-Probleme sein.

Andere Möglichkeit : Wenn Sich beim C1 die Treiberstärke (output 
current) wirklich nicht einstellen lässt (ich kenne die Tyen nicht), 
dann lassen sich zwei Ausgänge über 10 Ohn zusammenschalten, wenn man 
sie voll synchron betreibt ?

von Falk B. (falk)


Lesenswert?

@ Jürgen ... (engineer)

>Dieser Takt ist aber nicht zufällig der Systemtakt des FPGAs, denn Du
>hart herausgeführt hast? Das könnte ein Grund für solche
>Belastungs-Zeit-Probleme sein.

Wie?

>Andere Möglichkeit : Wenn Sich beim C1 die Treiberstärke (output
>current) wirklich nicht einstellen lässt (ich kenne die Tyen nicht),
>dann lassen sich zwei Ausgänge über 10 Ohn zusammenschalten, wenn man
>sie voll synchron betreibt ?

Wozu soll DAS gut sein? Die FPGA Ausgänge haben mehr als genug Dampf.

MFg
Falk

von J. S. (engineer) Benutzerseite


Lesenswert?

Zu 1) Wenn der Systemtakt direkt nach Aussen geführt wird, kann das 
Probleme mit dem Delay geben. Besser ist eine DDR-Zelle, oder eben ein 
Taktwechsel zu jeder Flanke mit intern doppelt so hohem Takt.

Bei manchen Xilinx-Bausteinen ist es so, daß die Synthese das garnicht 
hinbekommt, sondern für diesen nach aussen geführten Takt gar kein 
CLK-Netz mehr verwendet.

Zu 2) "Genug" ist immer relativ, oder? Wenn 20mA gefordert sind, stimmt 
das sicher, aber was machst Du bei einigen 100? Extra Treiber 
eindesignen ?

von Falk B. (falk)


Lesenswert?

@ Jürgen ... (engineer)

>Zu 1) Wenn der Systemtakt direkt nach Aussen geführt wird, kann das
>Probleme mit dem Delay geben.

Solche Algemeinplätze sind nicht sonderlich nützlich.

> Besser ist eine DDR-Zelle, oder eben ein
>Taktwechsel zu jeder Flanke mit intern doppelt so hohem Takt.

Und ohne Fehleranalyse sowas vorzuschlagen ist ebenfalls "very 
non-engineer".

>Bei manchen Xilinx-Bausteinen ist es so, daß die Synthese das garnicht
>hinbekommt, sondern für diesen nach aussen geführten Takt gar kein
>CLK-Netz mehr verwendet.

???
Das nach aussen führen von Takten ist sowieso nicht ganz ohne. Aber 
davon wird keine USB-Modul gestört, bestenfalls werden die Daten am 
seriellen Interface falsch übernommen.

>Zu 2) "Genug" ist immer relativ, oder? Wenn 20mA gefordert sind, stimmt
>das sicher, aber was machst Du bei einigen 100? Extra Treiber
>eindesignen ?

Wozu braucht ein LOGIKSIGNAL einige 100?. ? Und ja, in den allermeisten 
Fällen würde ich einen Treiber nehemen, wenn denn wirklich solche 
riesigen Ströme gebraucht würden.

MfG
Falk

von high_speed (Gast)


Lesenswert?

Hallo  Johnsn

Hast du dir auch schon mal den "Compilation Report" angeschaut?
Insbesondere unter "Timing Analyzer".

Bevor du dein Design Synthetisierst, sollte für alle Schnittstellen
(FPGA Anschlüssen) die nötigen Timing-Einstellungen getroffen werden.
Diese Einstellungen sind anschließend für den Fitter wichtig, damit
er für alle Signale die günstigsten Verbindungen erstellen kann.

Assignments -> Timing Analysis Settings...

Wie voll ist der FPGA?

MfG
Holger

von Johannes T. (johnsn)


Lesenswert?

@ high_speed:
Danke für deine Antwort. Der Timing Analyzer weißt keine Verletzungen 
auf. Die restlichen Reports schauen auch normal aus. Ich habe den 
Hauptclock von 24 MHz als Constraint definiert. Meist du das es auch 
sinnvoll wäre für alles restlichen Pins constraint zu vergeben?

Das FPGA ist nicht mal zu 1/3 voll (14% logik, 38% ram).

@ Jürgen ...:
Doch der Takt, den ich rausschicke ist auch der Systemtakt.


Verdächtig sind Warnings bei Synthese: "Fan-out 116 for net "BLABLA" 
exceeds default fan-out limit 32".

Und bei Fitter: Pin BLABLA has no specified output pin load capacitance.

von J. S. (engineer) Benutzerseite


Lesenswert?

Wenn die 24 MEg tatsächlich Systemtakt sind, ist das so 
schneckenlangsam, daß es klar ist, daß dort keine Syntheseprobleme 
auftreten. Beim 5-fach hättest Du dir wohl eher.

Ebenso sollte dann jede andere Taktproblematik passe sein. Kannst aber 
trotzdem nochmal versuchen, das alles auf dem Doppelten laufen zu lassen 
und so zu verfahren, wie ich beschrieb.

Die Warnings haben hier nicht viel zu sagen: default fan-out limit 32" 
ist eine der default Vorteinstellungen. Theoretisch liegt hier dein 
mögliches Problem da genau der steigender TReiberleistungsbedarf zu 
steigenden Verzögerungen führt. Aber das sind einige ns und bei deinem 
Takt ... naja..

Die capacitance dient dazu , die Delays zu berechnen. Dort solltest Du 
mal ein paar extreme Werte einstellen und dimulieren lassn, ob es dann 
noch schafft.

Hast Du ein constraint von pin to pad ?
Könnte sein, daß die Synthese bei den niedrigen Takt generell von einer 
Toleranz von 25ns ausgeht. Das könnte man enger fassen.

von weltbester FPGA-Pongo (Gast)


Lesenswert?

>> hinbekommt, sondern für diesen nach aussen geführten Takt gar kein
>> CLK-Netz mehr verwendet.

>???
>Das nach aussen führen von Takten ist sowieso nicht ganz ohne. Aber
>davon wird keine USB-Modul gestört, bestenfalls werden die Daten am
>seriellen Interface falsch übernommen.

Das können ja eigentlich nur Verzögerungen sein, die die Datenübernahme 
verunmöglichen. Aber bei dem Tempo scheint mir das eher 
unwahrscheinlich.
Ich würde mal die Treiberleistung mödifizieren und testen, um der Fehler 
genauso auftritt, um sicherzustellen, daß es wirklich der Knackpunkt 
ist.

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.