Hallo, Ich habe zwei Fragen zu denen ich gerne eine Antwort wüsste, vielleicht kann mir ja jemand weiterhelfen!? Auf meinem FPGA-Board ist der FPGA mit dem Memory-Bus eines CYPRESS EZUSB-Mikrocontrollers (AN2131) verbunden. Auf dem Board ist ein User-Programmable-Clock-Generator. Dieser liefert 2 Takte: Der erste sind konstante 12Mhz, die der EZUSB in 24Mhz wandelt und intern verwendet. Zu diesen 24Mhz ist der externe Memory-Bus des EZUSB synchron. Der zweite Takt ist User-Programmable, kann also in gewissen Grenzen beliebig gesetzt werden. Zu dem Board werden einige Beispiel-Designs mitgeliefert, unter anderem ein einfaches Beispiel zum Datenaustausch. Der FPGA verhält sich hier wie asynchroner Speicher. Siehe http://calypso.inesc-id.pt/FCUL/inst/docs/X2SUSB.pdf - Seite 24 1.Frage: Ich dachte immer, externe Signale müssen zuerst einsynchronisiert werden. Hier wird WR# mit den Clock-Eingängen der FF's verbunden. Können hier keine Glitches auftreten? Ist doch Gated-Clock! Angenommen mein Design verwendet den User-Programmable-Clock-Generator mit einem beliebigen Takt, habe also 2 Clock-Domänen. Ich brauche eine bidirektionale Verbindung zwischen dem FPGA und dem EZUSB. Dazu habe ich mir folgendes Design überlegt: In habe in meinem Design eine Reihe von FF's, die als Bus-Register fungieren. Die Eingänge der FF's sind mit dem EZUSB-Datenbus verbunden. Die WR#-Leitung des EZUSB ist in meinem Design mit den Clock-Eingängen der FF's verbunden. Der Adress-Bus des EZUSB ist mit einem Adress-Dekoder verbunden, der genau ein Signal auf 1 setzt wenn eine bestimmte Adresse anliegt. Dieses Signal wird als Clock-Enable für die FF's verwendet. Jetzt habe ich ein memory-mapped Write-Register für den EZUSB. Die Ausgänge der FF's sind mit Eingängen weiterer FF's verbunden, zum Zwecke der Einsynchronisierung in die FPGA-Clock-Domäne. Als Clock für die FF's wird dann der FPGA-Design-Takt verwendet. Die Ausgänge der Synchronisierungs-FF's werden dann über eine MUX auf die DATABUS-Eingänge eines CPU-Cores, der in meinem Design existiert, geführt. Ein Adress-Dekoder am Ausgang des CPU-Cores erzeugt das passende MUX-SEL-Signal. Jetzt kann der EZUSB auf eine Adresse schreiben und der CPU-Core von einer Addresse die Daten lesen! Zusätzlich existiert ein zweites Bus-Register, analog zum ersten, aber genau umgekehrt. Also: FPGA-CPU-Core schreibt auf Adresse, EZUSB kann dann diese Daten mit einer Adresse innherhalb seines Adressraums lesen. Auf Basis dieser Zwei-Kommunikationskanäle kann dann ein asynchronenes Handshaking-basiertes Protokoll zur bidirektionalen Kommunikation implementiert werden. Zu meiner zweiten Frage: Ist diese Logik zum Datenaustausch zwischen zwei Clock-Domänen geeignet oder können Probleme auftreten? Wenn ja, welche? Vielen Dank. P.S. Sorry, wenn ich mein Problem etwas umständlich und verwirrend rübergebracht habe! ;-)
> P.S. Sorry, wenn ich mein Problem etwas umständlich und verwirrend > rübergebracht habe! ;-) Hmmm... Hast du mal eine Skizze zu deiner Beschreibung, die ist tatsächlich etwas länglich. Aber ich habe den Verdacht dass es hier scheppern könnte: > Die Ausgänge der FF's sind mit Eingängen weiterer FF's verbunden, zum > Zwecke der Einsynchronisierung in die FPGA-Clock-Domäne. Als Clock > für die FF's wird dann der FPGA-Design-Takt verwendet.
Prinzipiell geht das. Allerdings ist bei den Cypress-Dingern die synchrone Anbindung meiner Meinung nach besser. Lässt sich auch im FPGA besser machen. Dann sind alle Steuersignale synchron zum IFCLK des Cypress Controllers. Vielleicht kannst du das nutzen, muss nur im Firmware-Register des Cypress eingestellt werden. Wir benutzen hier den Nachfolger, den FX2 mit synchronem Slave-FIFO Interface, das geht sehr einfach und extrem zuverlässig.
IFCLK - Interface-Clock?? Dann läuft der EZUSB-Memory-Bus in einer anderen Takt-Domäne als der Rest des Chips?? Und in der gleichen wie mein FPGA-Design. Meinst du das? Soweit ich weiß, hat mein Cypress (AN2131) sowas nicht? Noch eine Idee: Pro Kommunikationskanal ein kleines Distributed-DualPort-RAM verwenden, von einer Seite reinschreiben, dann einen Takt später ein durch ein MultiFlop-Synchronizer synchronisiertes VALID-Signal an die Gegenseite senden. Nachdem die andere Seite dieses erkannt hat, kann es die Daten abholen. Müsste doch ganz gut klappen!? Kann vielleicht jemand noch was zu meiner ersten Frage sagen? Danke
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.