So, wie es im Titel schon steht, möchte, bzw muss, ich einen Wishbone Master implementieren. Das hat folgende Vorgeschichte: Ich versuche ein RFM12 Funk-Modul an ein Spartan 3E-FPGA zu betreiben, und das benötigt SPI. Nun habe ich erst versucht, ein SPI modul selber zu schreiben, was in der Simulation auch wunderbar Funktioniert, nur in der Praxis funktioniert es nicht und ich habe nicht die Zeit/Lust das in der Emulation zu Debuggen. Daher habe ich mich dafür entschieden, ein fertig getestetes Modul zu verwenden, um Fehlerquellen auszuschließen. Als von OpenCores diesen Core geholt: http://opencores.org/project,spi Nun sind wir beim Problem, zum Simulieren habe ich ein task verwendet um das zu testen, was aber natürlich auf die in der Simulation möglichen Verzögerungen zurückgreift, die natürlich nicht Synthetisierbar sind. Daher stehe ich nun vor dem Problem, eben das Verhaltend es WB-Masters zu implementieren und da ich noch ein Neuling in sachen Verilog/FPGA bin, würde das sehr umständlich und viel werden. Daher meine Frage: Gibt es Quellen von WB-Master Modulen, die Synthetisierbar sind und wo ich mir etwas anschauen kann und gibt es vlt Implementationen, die "Realtiv einfach" in der Nutzung sind? MfG J.Hebeler
Hallo, wenn du noch nicht mal so etwas einfaches wie ein SPI hin bekommst, warum versuchst du dich dann an noch komplizierteren Dingen, hier Wishbone Master? Selbst wenn du einen WB-Master bekommst, dann musst du den Master mit Daten versorgen. Quelle => WB-Master => WB-Slave => SPI Warum entfernst du von dem SPI mit WB-Slave nicht einfach den WB-Slave und speist den SPI aus deiner Logik? Tom
>>wenn du noch nicht mal so etwas einfaches wie ein SPI hin bekommst, >>warum versuchst du dich dann an noch komplizierteren Dingen, hier >>Wishbone Master? Mein Problem ist es nicht, dass ich nicht verstehe wie SPI funktioniert, schließlich habe ich ein Modul, dass in der Simulation funktioniert. Nur besteht das Problem, dass in der Emulation NICHT funktioniert und das wrsl an Timing Problemen im Zuge der Synthetisierung handelt und ich, um das zu testen, einiges an zeit aufwenden müsste, die ich so nicht aufwenden wollte. >>Warum entfernst du von dem SPI mit WB-Slave nicht einfach den WB-Slave >>und speist den SPI aus deiner Logik? Weil ich dann in Fremden-Modulen rumspiele und das Definitiv Probleme erzeugen wird. Dann kann ich auch mein Modul weiter testen. Aber wie gesagt, ich habe egt auf eine einfachere, sprich Zeitsparende Methode gehofft. >>Selbst wenn du einen WB-Master bekommst, dann musst du den Master mit >>Daten versorgen. >> >>Quelle => WB-Master => WB-Slave => SPI Das ist mir bewusst, aber wenn ich den Master in mein Modul integriere, sollte das meiner Auffassung nach möglich sein. Gut, da es bisher keinen Ausblick auf irgendwelche WB-Master-Referenzimplementatione gibt, werde ich mich nochmal mit eigenem Code beschäftigen und schauen, was ich selber auf die reihe bekomme, da ja Wishbone noch schwerer als SPI zu sein scheint. MfG J.Hebeler
J.Hebeler schrieb: > was in der Simulation auch > wunderbar Funktioniert, nur in der Praxis funktioniert es nicht und ich > habe nicht die Zeit/Lust das in der Emulation zu Debuggen. Was ist bei Dir die Emualtion? Vielleicht kannst Du uns Deine Simulation mal zeigen. Fast immer wenn es bei mir in der Simualtion ging und in der Hardware nicht, habe ich mein System nur unzureichend simuliert gehabt. J.Hebeler schrieb: > Wishbone noch schwerer als SPI zu sein scheint. Ja, dafür ist Wishbone ja auch wesentlich universeller. Üblicherweise ist z.B. ein Prozessor ein Whishbone-Master. Und der kann dann ähnlich wie ein Mikrocontroller programmiert werden. Wo werden denn Deine Funkdaten generiert bzw. gebraucht? Duke
> Fast immer wenn es bei mir in der Simualtion ging und in der Hardware nicht, > habe ich mein System nur unzureichend simuliert gehabt. Von nicht einsynchonisierten Eingängen mal abgesehen... @ J.Hebeler Du könntest einfach mal deinen SPI Code zeigen...
>>Du könntest einfach mal deinen SPI Code zeigen... Und so paradox wie es ist, das im Anhang ist neuer Code mit anderem Konzept, den ich aber zu verwenden gedenke. Ist noch recht unkommentiert, aber ich hoffe man findet sich zurecht. Es gibt neben den SPI Signalen (MISO, MOSI, SCK, SS) noch die Signale {rx_data, tx_data, clock, reset(active low), start, ack} clock und reset kommen vom übergeordneten Modul. rx_data ist was Empfangen wurde, tx_data ist was gesendet wurde. "Start" startet eine Übertragung/Empfang. ack ist das Acknowledgement für ein erfolgreiches Übertragen/empfangen. Die Signale start, reset und !ack werden UND-Verknüpft für das allgemeine Start(run)-Signal Clock geht auf einen Clock_divider, der durch 8 teilt und das ganze auf SCK legt. tx_data geht in ein Shift-register und rx_data kommt von einem Shift Register, die von SCK getaktet werden(jeweils posedge und negedge) und mit run aktiviert. SS ist !run. Gleichzeitig zählt ein Counter die negativen Taktflanken und legt ack nach 8 Taktflanken auf 1 und damit run auf 0, was so lange bleibt bis man start wieder auf 0 setzt. Folglich muss man von außen tx_data setzten, start auf 1 ziehen, auf ack warten, rx_data auslesen, wenn man möchte, start auf 0 ziehen, kurz warten und dann die nächste Übertragung/Empfang starten. Den alten Quellcode habe ich wegen unnötiger Komplexität und recht unsinnigen Konstrukten verworfen. Da war ich zu schnell und hab zu wenig nachgedacht. >>Wo werden denn Deine Funkdaten generiert bzw. gebraucht? Generiert werden sie auf einem RFM02, angeschlossen an einen Atmega48, das funktioniert, denn ein Roboter mit Atmega8 und RFM01 empfängt das problemlos. Die Daten sollen empfangen werden, ausgewertet und dann als PWM an eine KSQ weitergereicht werden. Die KSQ funktioniert an sich schon recht problemlos. >>Was ist bei Dir die Emualtion? Bisher bestand sie daraus, die Signale auf LEDs zu legen und das Funkmodul anzusteuern, zusätzlich werden einige Signale mit einem OSZI überwacht. Ich könnte egt mal versuchen, den Takt auf wenige Herz herunter zu drücken um dann die Signale Genauer zu analysieren, oder gibt es da Probleme?
J.Hebeler schrieb: > Den alten Quellcode habe ich wegen unnötiger Komplexität und recht > unsinnigen Konstrukten verworfen. Mir wäre auch der "neue" Quellcode unnötig komplex. Wenn man bedenkt, dass SPI nur ein Schieberegister ist, dann erschließt sich mir nicht, warum man dafür 4 Untermodule braucht... http://www.lothar-miller.de/s9y/categories/17-SPI Und das hier ist sehr bedenklich und wird dir in der Praxis auch noch Kopfzerbrechen bereiten:
1 | SCK <= prescaler[4]; |
2 | ....
|
3 | shift_tx_register tx_reg_inst(.clock(~SCK), //Reakt to negedge |
So werden in FPGAs keine Takte erzeugt. Überhaupt gibt es in einem Anfängerdesign nur 1 Takt. Das ist der, der vom Quarzoszillator kommt. Und das sieht mir wie eine "Multiple Source" aus:
1 | always @(posedge clock) |
2 | begin
|
3 | :
|
4 | iData <= iData >> 1'b1; |
5 | :
|
6 | end
|
7 | |
8 | always @(posedge start) |
9 | begin
|
10 | iData <= data; |
11 | end
|
Zuweisung auf iData abhängig von 2 "Takten"? In VHDL ginge das nicht...
>>Zuweisung auf iData abhängig von 2 "Takten"? In VHDL ginge das nicht... Das stimmt, es funktioniert nicht. Ich habe es in der Synthese geändert, das data im Sequentiellen übernommen wird, wenn Start ungleich 1 ist und nicht mehr mit posedge start. >>So werden in FPGAs keine Takte erzeugt. Überhaupt gibt es in einem >>Anfängerdesign nur 1 Takt. Das ist der, der vom Quarzoszillator kommt Das würde ich auch so machen, wenn das RFM12 Modul 10Mhz SPI-Clock vertragen, sprich auswerten könnte. Das kann es aber nicht, von daher benötige ich einen verringerten Takt. Diese Umsetzung hat auf dem Oszi in der Emulation für mich aber funktionsfähig ausgesehen, sprich richtig. Wie wäre denn eine Korrekte Takterzeugung? >>Mir wäre auch der "neue" Quellcode unnötig komplex. Wenn man bedenkt, >>dass SPI nur ein Schieberegister ist, dann erschließt sich mir nicht, >>warum man dafür 4 Untermodule braucht... Ich bin ein Anfänger, ich habe es so realisiert wie ich es für richtig erachtet habe. Wenn ich nochmal darüber nachdenke, kann man versuchen den Counter und den Prescaler in ein Modul unter zu bringen, dass einfach den Notwendigen SCK Takt erzeugt. MfG J.Hebeler
Die Multiple-Source ist in Verilog unsynthetizierbar... Ich würde die fpga4fun website, es hat extrem einfache implementierungen, die auch funktionieren ! :)
Der SCLK ist kein Takt, sondern nur ein stinknormales Signal, das zufällig irgendwas mit "clock" in seinem Namen trägt. Du musst SCLK aber wie ein Signal erzeugen, behandeln und ausgeben. Und dann kennt dieses Signal im FPGA nur noch high- und low-Zustände, aber keine Flanken! Die SPI Implementierung von fpga4fun verwendet auch SCLK als Takt. Das wurde ich mit gerade noch in einem CPLD erlauben (wegen der sehr eingeschränkten Ressourcen), aber niemals in einem FPGA.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.