Wishbone Master implementieren

>>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

>>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?

>>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 ! :)

... empfehlen :)