Hallo Community, wir machen für die Uni ein Projekt und möchten gerne einen CAN Controller auf dem Altera DE1-SOC Board implementieren. Um uns das Leben einfacher zu machen, da wir absolute anfänger sind, haben wir den Verilog IP-Core (OpenCores can_top.v) benutzt. Um das Interface zu vereinfachen haben wir die can_controller.vhd geschrieben. Allerdings bekommen wir den im Betreff erwähnten Fehler und wissen langsam nicht mehr weiter. Könnte jemand vielleicht mal über unseren Code schauen und uns einen Hinweis geben. Auch über semtliche Kritik zu Do's and Dont's sind wir sehr dankbar. Die relvanten Dateien findet ihr im Anhang. Dankeschön
:
Verschoben durch Moderator
Nachtrag: Der Fehler tritt auf wenn wir das erste mal die Procedure CAN_REG_WRITE() benutzen.
TwoBit schrieb: > da wir absolute anfänger sind, Ja, das sieht man. Und diese Multisource-Fehler sind nur die oberste Spitze des Eisbergs... Euch muss erst mal klar sein, dass alle Zustände der FSM gleichzeitig im FPGA existieren. Es ist nur jeweils 1 davon aktiv. Oder andersrum: VHDL ist keine Programmiersprache, sonst hieße es VHPL.z Du musst also ein Bild oder einen (Schalt-)Plan haben (auf Papier oder im Kopf). Den kannst du anschliessend mit der Beschreibungssprache VHDL beschreiben. Das bedeutet andererseits, dass jegliche "Softwaredenkweise" falsch ist. > da wir absolute anfänger sind Habt ihr wenigstens solche simplen Sachen wie ein Lauflicht oder eine RS232-Schnittstelle gemacht, bevor ihr euch in die Königsklasse wagt? TwoBit schrieb: > Auch über semtliche Kritik zu Do's and Dont's sind wir sehr dankbar. Zum Thema "Eisberg": diese beiden Prozesse config und can_read haben eine komplett falsche Sensitivliste. Dadurch wird 1.) die Simulation nicht mehr zur Realität passen und 2.) nur wirres Zeug passieren. Die Sensitivliste wird nur vom Simulator beachtet. Sowas ähnliches ist auch im Thread https://embdev.net/topic/386459#4419332 das Problem...
:
Bearbeitet durch Moderator
Hi Lothar, hatte gehofft das es nicht so schlimm ist. Also wir haben tatsächlich mal mit einfachen Sachen angefangen und uns einige Tutorials vorher angeschaut. Allerdings mit einer RS232 Schnittstelle haben wir uns vorher nicht auseinander gesetzt. Was würdest du den uns empfehlen? Kann man wirklich alles in die Tone kloppen? Der Ansatz stammt eigentlich von unserem Assi der uns betreut und sagte das wir das mit Statemachines hinkriegen können. Was uns dann nur schwer gefallen ist, also auch von der Denkweise her, wie wir Prozeduren wie CAN_REG_READ oder CAN_REG_WRITE wiederverwendbar machen können. Oder müssen wir uns die mühe machen und überall wo die Prozeduren auftauchen den code immer wieder einfügen. Gruß der ratlose Robert
TwoBit schrieb: > Was uns dann nur schwer gefallen ist, also auch von der Denkweise her, > wie wir Prozeduren wie CAN_REG_READ oder CAN_REG_WRITE wiederverwendbar > machen können. Vergiss "procedure" und "function" in diesem Projekt. Oder andersrum: die einzige Prozedur, die du hier verwendest ist rising_edge(). Wiederverwendung von Hardware erfolgt über Komponenten. Aber es kann eben schon mal nicht mehrere Komponenten mit einer Funktionalität eines "Lese_Register" geben. Sondern es gibt nur 1 Hardware, die auf dieses Register zugreifen kann. Und diese 1 Hardware muss nacheinander mit passenden Werten gefüttert werden. Un alles, was in ein FPGA einen zeitlichen Ablauf hat ("nacheinander") braucht eine FSM. Die tut im einen Takt irgendwas, und evtl. im nächsten Takt was Anderes (kleine Anmerkung: schon ein simpler Zähler ist eine FSM). TwoBit schrieb: > Also wir haben tatsächlich mal mit einfachen Sachen angefangen Welches Niveau? > und uns einige Tutorials vorher angeschaut. "Anschauen" hilft da wenig. Fehler muss man selber machen... ;-) > Allerdings mit einer RS232 > Schnittstelle haben wir uns vorher nicht auseinander gesetzt. Bei so einer seriellen Schnittstelle wäre genau sowas mit der Weiterverwendung der empfangenen Daten auch aufgetreten. Nur nicht ganz so geballt... Mein Vorschlag: beschreibt erst mal 1 Zugriff auf 1 Byte. Wenn der klappt (in Simulation und Realität), dann überlegt eine Schaltung, die die Werte für diesen Zugriff ändern könnte. Und diese Schaltung beschreibt ihr dann mit VHDL. Seht euch mal den Beitrag "Re: EA DOG-M initialisieren" an. Die Komponente LCD_CTRL entpricht hier etwa eurem Verilog CAN Controller. Und dieser LCD Controller wird als Komponente im Toplevel top_LCD instantiiert und bon dort aus auch aus "angesprochen"...
:
Bearbeitet durch Moderator
Hey Lothar, dann machen wir uns an die Arbeit. Vielen Dank fuer deine Tipps und deinen Rat! Gruß Robert
Lothar M. schrieb: > die einzige Prozedur, die du hier verwendest ist rising_edge() Mensch Loddar, das ist eine Funktion und keine Prozedur ;-)
Lothar M. schrieb: > Euch muss erst mal klar sein, dass alle Zustände der FSM gleichzeitig > im FPGA existieren. Wieso das denn? Es gibt doch immer nur einen Zustand in einer FSM. Wir erbitten Aufklärung?
Manni schrieb: > Es gibt doch immer nur einen Zustand in einer FSM. Nehmen wir mal an, die FSM sei "One-Hot" ausgeführt und hätte 10 Zustände. Dann ist das im FPGA mit 10 Flipflops als Zustandsspeicher mit jeweiliger Weiterschaltlogik implementiert. Es sind damit also im FPGA alle 10 Zustände vorhanden, ABER es ist jeweils nur 1 davon AKTIV. Das ist der wichtige Unterschied zur sequentiellen Software, wo tatsächlich im Ablauf entschieden wird, welcher Zustand gerade "aktiv" ist... Dieses gleichzeitige Vorhandensein kann dann bei ungeschickter Ansteuerung zu eigenartigen Effekten führen: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
:
Bearbeitet durch Moderator
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.