Hallo, ich beschäftige mich gerade mit Cypress PSoC Controllern und implementiere mein erstes größeres Hardware-Design. Kurze Erläuterung, die PSoC beinhalten neben dem Controllerkern sogenannte UDBs, das sind quasi Mini-Recheneinheiten, welche Grundfunktionen wie addieren, subtrahieren, shiften, etc. unterstützen. Drumrum sind noch ein paar Macrozellen. Verknubbelt wird das ganze per Verilog. In Verbindung mit den PLDs kann man sich somit seine Funktionen in Hardware gießen. Die UDBs können mit dem Controllerkern u.a. über FIFOs kommunizieren. In Richtung UDB<->PLD kann über jeweils sechs Ein- und Ausgänge kommuniziert werden, die PLDs kommunizieren mit dem Controllerkern über Status- bzw. Controlregister. Mein Problem ist nun folgendes: Ich benötige den FIFO, aber die Ausgänge sind schon voll belegt, d.h. ich kann die FIFO-Statussignale nicht abgreifen. Also muss ich das manuell abhandeln. Mein Ansatz ist nun folgender: Ich schreibe ein Byte in den FIFO. Über das Controlregister informiere ich die Hardware, dass ein Byte in den FIFO geschrieben wurde (geht wie oben beschrieben leider nicht anders). Die StateMachine hat vier Zustände, von denen einer Bytes aus dem FIFO liest, die restlichen Zustände sind entweder IDLE oder eben die Daten verarbeiten. Nennen wir die Zustände mal "Idle, Data0, Data1, ReadFifo". In jedem Zustand wird geprüft, ob ein Byte im FIFO gelandet ist. Wenn ja, wird in den Zuständen Idle, Data0/Data1 ein Bytezähler hochgesetzt. Im Zustand ReadFifo wird der Bytezähler dekrementiert und nur ein Merker für die anderen drei Zustände gesetzt, um den Bytezähler zu inkrementieren. --> Das hab ich deswegen gemacht, weil man ja ansonsten gleichzeitig dekrementieren und inkrementieren müsste. Die Frage ist nun, ist das korrekt so, oder soll ich es "umdrehen" und im Zustand ReadFifo, wenn ein Byte im FIFO gelandet ist, den Bytezähler einfach nicht ändern? In dem Fall bräuchte ich den Merker für die anderen Zustände nicht und könnte dann dort direkt immer inkrementieren. Ich frage deswegen, weil ich das "parallele Denken in Hardware" noch nicht verinnerlicht habe. Sieht jemand mit dem obigen Ansatz Probleme? Besten Dank für Tips und Vorschläge =) Ralf
Ralf schrieb: > Sieht jemand mit dem obigen Ansatz Probleme? Schweigen bedeuted: Zustimmung Probiere Deine Idee aus. Wenn sie fehlschlägt mußt Du die Ursache suchen (=debuggen) und ggf. einen neuen Ansatz wählen. Duke
Hi Duke, >> Sieht jemand mit dem obigen Ansatz Probleme? > Schweigen bedeuted: Zustimmung Njaaa, nicht immer ;) > Probiere Deine Idee aus. Wenn sie fehlschlägt mußt Du die Ursache suchen > (=debuggen) und ggf. einen neuen Ansatz wählen. Das ist noch etwas, was mir Kopfzerbrechen bereitet, da ich noch keinen Ansatz habe, wie man das geschickt und effektiv debuggen kann. Da muss ich noch n bisschen Hirnschmalz reinstecken... Ralf
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.