Hi, ich habe als FPGA-Hobbyist bis jetzt nur Erfahrung mit kleineren Projekten gemacht, z.B. LED/Taster IO, VGA,UART,Ethernet,Simulation uÄ. Da ich als Fachfremder keinerlei Kontakt zu Profis habe, möchte ich mal gerne wissen, wie ein grösseres Projekt (was man halt so in endlicher Hobbyzeit noch angehen kann) angegangen wird. Was mich in erster Linie interessiert: Werden meine Komponenten grösser oder werden Cores wie DSP48/TEMAC etc. eingebunden, entwickeln sich schnell Signalgräber (teils im Port-, teils auf Komponentenebene). Und dann einen TEMAC mit einer anderen Komponente auf der selben Ebene zu verbinden birgt immer das Risiko von Signal vertauscht/vergessen etc. Gibt's hier gute Ansätze, Ordnung in die Signalmenge zu bringen (z.B. Gruppieren mittels RECORDS etc.)? Gruss
Wichtig ist, Hierarchien einzufügen und Signale zu nutzen, die die Funktionen repräsentieren. Möglichst eine zentrale Verwaltung, die Untermodule eindeutig steuert. Das ist am einfachsten zu verifizieren und zu beweisen.
Ja, mit records und einheitlichen Bussystemen (AMBA, Avalon, Wishbone, OBP/PLB etc.) für die Funktionsblöcke ist sowas einigermaßen in Griff zu bekommen. Duke
Es hilft nur, teile deinen Code in mehrere Dateien auf. Dann musst du dir für deine Componenten eine Skizze zeichnen, was du in in welcher Datei codest. Diese Skizze muss während der Entwicklung aktuell gehalten werden. Für jede Datei eine viereckigen Kasten. Auf den Rand schreibst du die Schnittstellen und in den Kasten den was in der Datei berechnet wird.
Hi, nach einiger Erfahrung mit VHDL/FPGAs sollte es natürlich selbstverständlich sein, Projekte bzw. Komponenten auf mehrere Ebenen/Dateien zu unterteilen. Das hilft aber nur zu einem sehr kleinen Teil. Nur mal als "kleines" Beispiel: Ich habe eine einfache Verbindung zu PC mittels Ethernet/SimplesUDP relalisiert. Verwendet wird der Xilinx-Core TEMAC (Virtex4,ug074.pdf). Alleine schon die Signale des TEMACs implizieren auf Modulebene glaube ich 80-100 Signale/Signalvektoren. Die lassen sich aber relativ leicht in Gruppen unterteilen und an andere Module (z.B. Phy etc.) anbinden. Die vielen Signale auf einer Ebene bleiben trotzdem. Mein Ansatz wäre, den TEMAC in ein eigenes Modul auszulagern und je Gruppe RECORDs für je IN und OUT nach Aussen weiter zureichen (irgendwo hier im Forum wurde mal ein ähnlicher Ansatz vorgestellt). So hat man auf der nächsthöheren Ebene nur noch zwei RECORDs je Gruppe/Aufgabenteil. Dazu kommt, dass sich diese Ebene nicht mehr um Implementierungdetails kümmern muss. Gibt es in der Praxis vergleichbare Ansätze oder Standard? Oder gibt's im Internet gute Quellen, die Schnittstellen bzw. deren Implementierung beschreiben? Gruss
Duke Scarring schrieb: > Ja, mit records und einheitlichen Bussystemen (AMBA, Avalon, Wishbone, > OBP/PLB etc.) für die Funktionsblöcke ist sowas einigermaßen in Griff zu > bekommen. > > Duke Duke hast du eine Übersicht zu den Bussystemen? Ich habe mich noch nicht so richtig beschäftigt wie sich die Busse unterscheiden. Ich habe immer mir mein eigenes Bussystem geschnitten, was sicher nicht immer effektiv war. Ein vorhandener Standard hätte mir sicher schon Arbeit erspart.
René D. schrieb: > hast du eine Übersicht zu den Bussystemen? Nein, leider nicht. Mit Wishbone und OPB/PLB habe ich mal gearbeitet, Avalon kenne ich nur vom Namen her und AMBA (AHB/APB) verwende ich aktuell. Wishbone: Da hab ich den Eindruck, das er bei opencores einigermaßen verbreitet ist. Wirkt etwas angestaubt, ist auch relativ einfach zu verstehen, aber die opencores-Module sind nicht unbedingt vorbildlich dokumentiert, welche Bus-Features verwendet werden. Als Interconnect hatte ich ein Stück Code, welches von einem Perl-Skript generiert wurde. Für jeden neuen Busteilnehmer mußte das Perl-Skript aufgerufen werden, welches leider keine records für die Bussignale erzeugt hat. OPB/PLB: Das ist das, was Xilinx beim Microblaze und PPC verwendet. Da wird einem schon schlecht wenn man sich die entity eines Moduls anguckt. Man könnte da Wrapper schreiben um die vielen Signale mit records in den Griff zu bekommen. Das Zusammengeklicke im EDK ist auch ganz nett, aber man weiß nicht was er da wirklich tut. Arbeiten möchte ich damit nicht, nur wenn ich muß :-) AMBA: Gute Dokumentation (bei ARM) und coole Implementation in der grlib von Gaisler (open source). Die Busse sind als arrays von records definiert und ein neues Modul hänge ich einfach auf einen freien Platz im array. Portabel, keine Voodoo-GUI, gut dokumentierte fertige IP (grlib.pdf). Mein Eindruck ist, daß sich die Bussysteme von der Leistungsfähigkeit nicht großartig unterscheiden. Im Handling möchte ich records und den Verzicht auf "Drittprogramme" nicht mehr missen. Duke
> > Duke du meinst ich sollte mir mal die AMBA reinziehen?! Ich sitzte gerade an einem MIPS32 Softcore und muss mir langsam überlegen, wie die "externen" Module einbinde. Da werde ich nicht an einem Bus vorbeikommen.
René D. schrieb: > du meinst ich sollte mir mal die AMBA reinziehen?! Warum nicht ;-) Ich arbeite hier mit einer ZPU, die per Wrapper am AHB hängt... Duke
> Ich arbeite hier mit einer ZPU, die per Wrapper am AHB hängt... > > Duke Duke kannst du mich mal anmailen. Du bist nicht angemeldet.
Wenn Du mit Altera arbeitest, dann würde ich den Avalon-Bus bevorzugen. Der ist denkbar einfach und über den SOPC-Builder wird dir alles abgenommen was mit der Zusammenschaltung, Adressierung und Arbitrierung zu tun hat.
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.