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?
@ 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
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.
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?
@ 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
@ 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.
Noch was vergessen: Das 3-Draht-Interface funktioniert in allen Fällen!
@ 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
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 ?
@ 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
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 ?
@ 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
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
@ 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.
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.
>> 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.