Hi, ich hätte mal kurz ein paar allgemeine Fragen. Es geht um folgendes: Ich habe hier Firmware für einen CPLD. Das Ganze ist in Abel geschrieben... nicht von mir. Nun muss dieser CPLD mit einem FPGA auf dem meine Firmware läuft (Verliog) kommunizieren und einfache Befehle umsetzen. Die Verbindung ist ein kleiner Bus mit ein paar Adresseleitungen, ein paar Datenleitungen und Steuersignalen. Die Aufgaben des CPLDs sind relativ primitiv. Mittels der Befehle/Daten vom FPGA ein paar Treiber enablen und ein paar Leds schalten. Soweit ich den Abel-Code von meinem Kollegen verstehe, werden diese Aufgaben im CPLD durch größtenteils statische und auch asynchrone Logik erledigt. Der Verfasser des Codes besitzt keine wirklichen Grundlagen im Digitaldesign. Da ich keine Lust habe jedesmal zu dem Kollegen zu rennen und ihn zu bitten sein Abel-Code zu verändern und an einem speziellen Rechner mit Ise 10.1 zu übersetzen, etc, habe ich mir überlegt das ganze neu zu machen und zwar in Verilog und entsprechend meiner eigenen Entwurfskonzepte: synchron, getakt und sequentiell mit Zustandsautomaten. Da ich selbst wenig Erfahrung mit CPLDs habe und deren Aufbau/Grundelemente nicht so gut kenne wie die Bausteine eines FPGAs, weiß ich nicht ob das ganze sinnvoll umsetzbar ist. Nun meine Frage an die von euch die mit beidem Arbeiten CPLDs und FPGAs: Geht ihr beim Entwurf bzw. Design mit unterschiedlichen Strategien ran?? Also beispielsweise, drauf achten weniger Register zu benutzen, mehr Logik pro Takt, kleinere FSMs, mehr statisch... so ne Sachen halt?? Ich weiß die Frage ist ziemlich allgemein gestellt. Es geht mir nur um ein paar grundsätzliche Tipps bevor ich jetzt los lege. Vielleicht fällt ja irgendjemanden was ein, was ich umbedingt beachten sollte beim CPLD-Entwurf. Vielen Dank im Voraus
Trundle Trollkönig schrieb: > Nun meine Frage an die von euch die mit beidem Arbeiten CPLDs und FPGAs: > Geht ihr beim Entwurf bzw. Design mit unterschiedlichen Strategien ran? Nicht wirklich. Aber prinzipiell muß man schon beachten, das die Register im CPLD viel schneller alle sind. Dafür sind die LUTs (=Produktterme) größer. Ansonsten einfach ausprobieren. Wenn es voll wird, kann man machmal durch den Tausch von Pins noch was rausholen. Das nützt aber nix, wenn das PCB-Layout schon fertig ist. Duke
Trundle Trollkönig schrieb: > CPLDs und FPGAs: Geht ihr beim Entwurf bzw. Design mit > unterschiedlichen Strategien ran?? Nicht vorsätzlich. Aber "natürlich" weiß man, dass das CPLD mächtige Logik kann, aber nur wenig Register hat und packt ein Problem entsprechend anders an (Multiplexer statt Schieberegister). Im FPGA ist das egal, da gibts von Allem genug. Und interessant wird es dort eigentlich erst, wenn das Design zu langsam wird...
Trundle Trollkönig schrieb: > Der Verfasser des Codes besitzt keine wirklichen Grundlagen im > Digitaldesign. > Da ich keine Lust habe jedesmal zu dem Kollegen zu rennen und ihn zu > bitten sein Abel-Code zu verändern Hmm.. aber du besitzt die wirklichen Grundlagen dafür, ja? Also, für ein gedeihliches Zusammenspiel zwischen deinem Chip und seinem Chip braucht es doch schlichtweg nur eines: ein tragfähiges Protokoll der Verbindung zwischen beiden Seiten. Das war's dann. Wenn du der zweite bist und dich an die Gegebenheiten des CPLD's halten mußt, dann laß dir von deinem Kollegen einfach die Beschreibung des Protokolls geben, nach dem dieser Chip behandelt sein will - oder du läßt dir den ABEL-Quellcode geben und liest dort nach. Da du die Fähigkeiten deines Kollegen beurteilen kannst, sollte dir dies nicht schwer fallen. W.S.
Das Protokoll an sich ist nicht das Problem. Das Problem ist das der ABEL-Code laut Aussagen meines Kollegen noch nicht fertig ausgereift ist. Und noch nicht getestet und verbessert werden müsste... da zwar der Abel-code nicht in meiner Verantwortung liegt, aber das Gesamtsystem einfach fertig werden muss, dachte ich mir ich übernehm jetzt auch die Firmware für den CPLD. Und wie bereits gesagt zum Übersetzen vom Abel-code müsste ich immer zu ihm rennen und auf einem speziellen XP-Rechner mit ISE 10.2 den Code implementieren lassen. Mit Verilog und aktuellen Entwicklungsumgebungen wäre ich halt unabhängig. Und da ich in deinem ganzen Text lese, das ich dir unsympathisch bin und du mich für arrogant hälst... ja ich nehme mir das Selbstbewusst sein und beurteile die Fähigkeiten meines Kollegen. Nenn es arrogant oder was auch immer... Wichtig für mich ist: das meine Frage geklärt wurde => Mit den gleichen Ansätzen wie beim FPGA-Design beginnen. Danke nochmal Thema kann geschlossen werden!!
Trundle Trollkönig schrieb: > Und noch nicht getestet und verbessert werden müsste. Dann ist es umso wichtiger, daß wirklich ZUALLERERST die Schnittstelle zwischen beiden Seiten wasserdicht und für beide (!!) verläßlich festgeschrieben ist. Sonst kommt nur Chaos heraus. W.S.
Trundle Trollkönig schrieb: > Da ich keine Lust habe jedesmal zu dem Kollegen zu rennen und ihn zu > bitten sein Abel-Code zu verändern Das verstehe ich nicht. Die Kommunikation zwischen euren Chips funktioniert, damit müsste es völlig wurscht sein welcher Code hinter der Kommunikation/dem Protokoll steht. Ich denke eher, das Problem ist, dass ihr das Protokoll zwischen den Chips nicht vollständig definiert habt. DA würde ich noch mal ansetzen statt selbst den CLPD zu programmieren. Es hat doch seinen Grund warum dein Kollege den CLPD programmieren soll und nicht du. Wieso willst du jetzt die Arbeit für zwei machen? Ich an deiner Stelle würde mich mit dem Kollegen unterhalten, getreu dem Motto: "Sprechenden Menschen kann geholfen werden." ;)
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.