Wie grössere VHDL-Projekte angehen?

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

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

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

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