Hallo Zusammen,
vor einiger Zeit habe ich ein Projekt weiter führen "dürfen", bei dem
ein Blackfin-548 mit 133 MHz Bustakt über sein asynchrones Bus Interface
(EBU, Details ab Seite 318 hier:
www.analog.com/media/en/dsp-documentation/processor-manuals/ADSP-BF54x_h
wr_rev1.2.pdf) mit einem Spartan 3E verbunden ist. Der Spartan läuft
mit 25MHz und über die Schnittstelle werden diverse Wishbone Register
vom DSP gelesen und geschrieben.
Ursprünglich war der Wrapper von EBU zu Wishbone mit diesem unsäglichen
Xilinx StateCad gemacht. Es gab damit ab und an fehlerhafte Bits in der
Übertragung und weil ich beim besten Willen nicht verstanden habe, was
dieser StateCad Code treibt (hatte die Sourcen nicht mehr, nur den VHD
Output), habe ich den Wrapper neu geschrieben. Der hat jetzt lange Zeit
problemlos gearbeitet, jedoch tauchen, nachdem ich an anderer Stelle im
FPGA diverse Änderungen und mehr Logik reingesteckt habe, vereinzelt
Fehler beim Lesen (DSP liest Register vom FPGA) auf - bspw. Messwert
plötzlich x2 weil eine 1 als MSB dazu gekommen ist.
Ich vermute ein Problem beim Timing, zumal ich bisher keine Constraints
auf das Interface gelegt habe. Ich habe leider auch keine Idee, wie das
in dem Fall richtig gemacht wird, da ich ja praktisch keine Referenz
habe, auf die ich mich bei z.B. Offset Constraints beziehen kann.
Hat jemand von Euch vielleicht einen Hinweis, wie ich das Thema in dem
Fall angehen sollte?
Danke und viele Grüße
Achim
Achim schrieb:> Ich vermute ein Problem beim Timing, zumal ich bisher keine Constraints> auf das Interface gelegt habe.
Den leisten Verdacht habe ich auch :-)
"keine Constraints" anzugeben, ist die Beste Methode, an
Überraschungsergebnisse zu kommen.
> Ich habe leider auch keine Idee, wie das> in dem Fall richtig gemacht wird, da ich ja praktisch keine Referenz> habe, auf die ich mich bei z.B. Offset Constraints beziehen kann.
Auf einen virtuellen Zeitpunkt, sinnvollerweise den des eingehenden
strobes. Da das Lesen das Hauptproblem ist, vermutlich ein output
enable.
Die alles entscheidende Frage ist, mit welchen effektiven Zeiten das
Interface arbeitet?
"Asynchron" ist das ja nur im Bezug auf den FPGA. Das reale timing ist
meistens ein Teiler des Taktes des Prozzis, bei Dir 133 MHz. Wenn Da ein
schnelles Bustiming verwendet wird, a la, SETUP, STROBE, READ, dann sind
das maximal 22ns, bzw bei 4 Takten 30ns.
Wishbone ist aber synchron und damit wird das für 25 MHz zu eng. Da
darfst Du intern nicht einmal takten, um an die Daten zu kommen.
Problematisch wird es mitunter auch, zu schnell zu lesen, nachdem
geschrieben wurde, wenn die state machine noch nicht fertig ist.
Du wirst also die Taktfrequenz erhöhen - oder das Bustiming des blackfin
verlangsamen müssen.
Ich würde dir auch die Post Route simulation nahelegen, dann siehst du
auch mit fehlenden Constraints das Resultat.
Natürlich ist das nicht die Lösung, spart dir aber Kopfzerbrechen am
Oszilloskop, wenn man mit der STA noch nicht so vertraut ist.
Ich denke die Lösung sind input output Constraints mit virtual clock bzw
ein Strobe als clock definieren (schlechtere Variante).
Eigentlich braucht es nur die virtual clock. Die Bezugnahme auf den
strobe ist lediglich gedanklich zu sehen, weil dessen Auftreten ja nicht
bekannt ist. Es ist aber wichtig, daß die timings so sind, dass der FPGA
alles innerhalb einer Datenperiode packt. Dazu braucht es ein timing,
das sich am Takt der Quelle orientiert. Also wie lange liegen Addressen
an, wann kommt das OE und wann geht es wieder weg.
Jürgen S. schrieb:> "keine Constraints" anzugeben, ist die Beste Methode, an> Überraschungsergebnisse zu kommen.
Wahnsinns Spruch, am besten gleich mal auf Teppich
drucken und dann in die Eingangshalle legen :)
Hallo,
vielen Dank für eure Antworten!
>"keine Constraints" anzugeben, ist die Beste Methode, an
Überraschungsergebnisse zu kommen.
Kein Widerspruch ;)
>Wishbone ist aber synchron und damit wird das für 25 MHz zu eng. Da
darfst Du intern nicht einmal takten, um an die Daten zu kommen.
Problematisch wird es mitunter auch, zu schnell zu lesen, nachdem
geschrieben wurde, wenn die state machine noch nicht fertig ist.
Du wirst also die Taktfrequenz erhöhen - oder das Bustiming des blackfin
verlangsamen müssen.
Das Gute am EBU des Blackfins ist, dass man es relativ einfach in seinen
Timings konfigurieren kann. Zurzeit ist das Read- und Write-Enable
Signal auf eine Länge von 6 Takten gestellt (so dass der FPGA die sicher
sampeln kann) und der komplette Buszugriff ist erst abgeschlossen, wenn
das ARDY Signal valide Daten bestätigt.
Da im Moment aber z.B. beim Lesen vom DSP das ARDY zeitgleich mit den
Daten gesetzt wird, muss es Probleme geben, wenn ein Bit des Datenbus
>7,5ns nach ARDY am Pin steht.
Also wäre die einfachste Lösung, eine virtual clock zu erzeugen, auf die
sich meine Offset Constraints beziehen. Sind die Gedanken bis dahin
richtig?
Viele Grüße
Achim
Moin,
den Blackfin kenne ich in der Tat recht gut (danke an den Unbekannten
für das Echo), aber das Problem liegt wohl am FPGA-Design und ist nicht
CPU-spezifisch. Über die EBIU-Register kannst du recht relaxte
Setup/Hold-Timings einstellen, aber wenns prinzipiell damit nicht geht,
musst du an dein Design ran. Abgesehen davon schafft der Spartan3E das
Timing locker.
Auch wenn es ein asynchrones Interface ist, den Bustakt von an die 33MHz
(oder ähnlich) musst du auf jeden Fall mit in deine Constraint-Sim
reinnehmen.
Schadet auch nicht, die Post-Map-Simulation durchzuspielen.
Wichtig ist einfach, dass dein EBIU-Clock das Gegenstück (Bus-Decoder)
am FPGA treibt. Ansonsten hast du die klassischen Probleme mit dem
Eintakten asynchroner Logik. Für die Register in der 25MHz
(FPGA-Clock)-Domäne musst du dann halt eine Einsynchronisation machen,
um Lesen falscher Werte (während eines Bit-Flips) zu verhindern.
Gruss,
- Strubi
