Forum: FPGA, VHDL & Co. Herangehensweise an ein VHDL Projekt


von Andreas B. (loopy83)


Lesenswert?

Hallo,

ich bin VHDL Anfänger und suche nun einen geeigneten Einstieg in die 
Thematik. Dazu habe ich hier schon gesucht und nachgefragt. Ich habe mir 
das Buch "VHDL-Synthese" gekauft und angefangen, damit zu arbeiten und 
die Beispiele nachzuvollziehen. Das klappt bis auf die Testbenches schon 
ganz gut und es ist sehr verständlich erklärt und aufgebaut.

Nun habe ich aber ein konkretes Projekt und wollte fragen, wie man an 
eine solche komplexere Aufgabe rangeht.

Ich habe einen Ziel-FPGA-Typ den ich verwenden möchte. Aber um die 
Ressourcen genau abschätzen zu können, muss ja das Design fertig sein.

Herangehensweise:
- Funktionsbeschreibung (was soll der FPGA im Detail können, Konzept)
- welche Ein- und Ausgänge benötige ich hierfür

So und nun hört es schon wieder auf bei mir. Der FPGA miuss ja mit einem 
"Bitstream" (heißt das so?) konfiguriert werden. Dazu brauche ich einen 
Flash EEPROM.

Beginne ich nun mit dem Schaltungsentwurf, also wie wird der Flash an 
den FPGA angeschlossen, damit ich weiß welche Pins ich benötige?
Die zu ladene Grundkonfiguration ist ja mein VHDL-Design... also muss 
ich mir um den Flash und die BEschaltung erstmal gar keine Sorgen 
machen?

Wie gehe ich dann weiter vor, wenn ich meine Ein- und Ausgänge definiert 
habe?

Wie z.B. gebe ich ein, dass Pin XY der Takteingang ist und dann das 
signal XY in der architecture diesen Takt hat, damit ich damit arbeiten 
kann? (meinetwegen den Takt teilen und auf einen Ausgang legen)
Im Testbench simuliere ich dann einfach den Takt vom Oszilator mit
1
GEN_CLK : process --für einen 40MHz Takt
2
   begin
3
      while true loop
4
         clk <= '0';
5
         wait for 25 ns;
6
         clk <= '1';
7
         wait for 25 ns;
8
      end loop;
9
   end process;

Ich habe auch schon überlegt, einen Lehrgang zu besuchen, nur leider 
sind die Termine dieser Lehrgänge so ungünstig, dass bis dahin mein 
Teilprojekt fast abgeschlossen sein sollte. Also bin ich auf das 
Selbststudium angewiesen...

Ich würde mich über Meinungen und Hilfestellungen sehr freuen.

MfG Andreas

von Sebb (Gast)


Lesenswert?

Wa soll denn dein FPGA können ?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> Aber um die Ressourcen genau abschätzen zu können
Eine Schätzung ist per Definition ungenau  :-/

> Ich habe einen Ziel-FPGA-Typ den ich verwenden möchte.
Lege das Gehäuse fest, und nimm ein recht großes FPGA in diesem 
Gehäuse. Du kannst hinterher immer noch einen kleineren einsetzen.

> Beginne ich nun mit dem Schaltungsentwurf, also wie wird der Flash an
> den FPGA angeschlossen, damit ich weiß welche Pins ich benötige?
Kauf dir ein EVAL-Board und sieh dir die Schaltpläne dazu an. Sieh dir 
auch Schaltpläne von anderen EVAL-Boards an. Das ist eine gute 
Ausgangsbasis.

> dass Pin XY der Takteingang ist
Ein FPGA hat üblicherweise bevorzugte Pins für die Takte. Dort sind die 
Timings am besten definiert. Aber auch das siehst du im Plan der 
EVAL-Boards. Wo du die Signale angeschlossen hast, gibst du in 
Constraint-Files an.
Constraints sind Einschränkungen, die du den Design-Tools mitgibst. Wenn 
du nichts angibst, werden die Signale auf irgendwelche Pins mit 
irgendwelchen Laufzeiten gelegt, und diese Belegung kann sich natürlich 
beliebig ändern. Das ist i.A. nicht das was du willst, deshalb gibst du 
in einer Constraint-Datei deine Wünsche an.

> Also bin ich auf das Selbststudium angewiesen...
Nimm ein EVAL-Board...


BTW:
Einen Takt in einer TB mache ich so:
1
signal clk : std_logic := '0';
2
:
3
   clk <= not clk after 25 ns;


Verwende nicht die alten Libs
1
use IEEE.STD_LOGIC_ARITH.ALL;
2
use IEEE.STD_LOGIC_UNSIGNED.ALL;
sondern nur noch die herstellerunabhängige
1
use IEEE.NUMERIC_STD.ALL;

von Andreas B. (loopy83)


Lesenswert?

Sebb wrote:
> Wa soll denn dein FPGA können ?

Ich zitiere mich mal aus einem anderen Thread, in dem ich die Funktion 
schon erklärt habe:

Meiner Meinung sollte es so ablaufen:
- der FPGA/CPLD bootet nach zuschalten der Vcc. Entweder hat er seine
eigene Konfiguration behalten, oder holt sie sich erneut aus einem
externen, nicht flüchtigen Speicher.

- dann beginnt er drei externe Devices (SPI Slaves, also keine weiteren 
FPGAs)der Reihe nach zu konfigurieren. Dazu verwendet er 5 Siganle 
(SCLOCK, SDATA, SLOAD_1, SLOAD_2, SLOAD_3).

- SLOAD_1 wird auf LOW gelegt und danach wird begonnen, zuerst die
Adressdaten des entsprechenden Registers auf den SDATA Kanal zu legen
und dann die entsprechenden Datenbits.

- die übermittelten Adress- und Datenbits sind konstant, sie werden also 
nur im Entwicklungsprozess abgeändert. Sind passende Werte gefunden, 
sind diese fix und werden bei jedem Starten erneut in die Register der 
Slaves geschrieben.

- Danach wird SLOAD_1 wieder High gesetzt und SLOAD_2 wird aktiviert
(low aktiv) und das Spiel mit Adress- und Datenbits beginnt von Neuen.

- So geschieht es dann auch beim dritten zu konfigurierenden 
Schaltkreis.

- So bekommen nach und nach (serial) alle drei Teilnehmer ihre
Konfigurationsdaten zugesendet und können dann anhand der Inhalte in
ihren Registern anfangen zu arbeiten.

- nach abgeschlossender Grundkonfiguration werden die 5 
Konfigurationskanäle/-signale mit 5 Eingängen verknüpft und
das serielle Interface wird von einem weiteren FPGA gesteuert bzw. mit
Adress- und Datenbits versorgt. Das Serielle Interface wird quasi durch 
den FPGA duirchgeschleift, also eine direkte Verbdingung von Ein- und 
Ausgängen.

DANKE !

von Karl (Gast)


Lesenswert?

Und wozu braucht man da ein FPGA??

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

> Wie z.B. gebe ich ein, dass Pin XY der Takteingang ist und dann das
> signal XY in der architecture diesen Takt hat, damit ich damit arbeiten
> kann? (meinetwegen den Takt teilen und auf einen Ausgang legen)
Beitrag "Re: Spartan 3 AN Pins ?" (Zuordnung 
VHDL-Signale mit physikalischen Pins)
> - dann beginnt er drei externe Devices (SPI Slaves, also keine weiteren
> FPGAs)der Reihe nach zu konfigurieren. Dazu verwendet er 5 Siganle
> (SCLOCK, SDATA, SLOAD_1, SLOAD_2, SLOAD_3).
Das würde ich nicht mit einem FPGA machen. Wenn das nicht gerade in 
wenigen Mikrosekunden ablaufen muss, sollte das mit jedem 
ATmega-Mikrocontroller gehen. Die sind wesentlich billiger, einfacher zu 
verbauen (auch von Hand.) und die Programmierung dürfte auch einfacher 
sein.
> - nach abgeschlossender Grundkonfiguration werden die 5
> Konfigurationskanäle/-signale mit 5 Eingängen verknüpft und
> das serielle Interface wird von einem weiteren FPGA gesteuert bzw. mit
> Adress- und Datenbits versorgt. Das Serielle Interface wird quasi durch
> den FPGA duirchgeschleift, also eine direkte Verbdingung von Ein- und
> Ausgängen.
Ist das festgelegt, dass da noch ein FPGA sein muss? Und ist das, was 
dieser 2. FPGA tun soll, eine komplexe rechenintensive Aufgabe? Weil 
falls nicht, würde ich dir auch hier raten, lieber einen Mikrocontroller 
zu verwenden bzw. beide Aufgaben auf einem Mikrocontroller zusammen zu 
fassen, dann sparst du dir das durchschleifen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> SPI Slaves...
> Dazu verwendet er 5 Siganle (SCLOCK, SDATA, SLOAD_1, SLOAD_2, SLOAD_3)
Warum benennst du die SPI-Signale so anders als der Rest der Welt?
Geläufig sind:
SCLK, MOSI, MISO, SS# (alternativ CS#)

> dann beginnt er drei externe Devices (SPI Slaves, also keine weiteren
> FPGAs)der Reihe nach zu konfigurieren.
Woher nimmt er die Daten?
Wieviele Bytes Config-Daten (für die SPI Slaves) sind das?

> Und wozu braucht man da ein FPGA??
Frage ich mich auch. Ich würde da ein SPI-EEPROM oder -Flash (abhängig 
von der Datenmenge) und einen 8-Pin uC nehmen.

von Christian R. (supachris)


Lesenswert?

Eine Frage hab ich da immer noch. Wieso ist es erforderlich zwischen 
deinen eigentlichen großen FPGA und die SPI Slaves noch ein kleines FPGA 
zu setzen? Die Grundeinstellung der SPI Slaves kann der große Spartan 
DSP doch genauso gut machen? Das hätte ja höchstens Sinn, wenn du vor 
bzw. während des bootens des großen FPGA unbedingt aus Sicherheits- 
oder schaltungstechnischen gründen eine Grundeinstellung der SPI Slaves 
sicherstellen musst, damit nix durchbrennt oder sowas. Nimmst du 
allerdings einen kleinen FPGA der die Grundeinstellung vornimmt, so muss 
auch der booten, und das geht nicht viel schneller als der große. Also 
sinnlos. Wäre höchstens bei einem CPLD sinnvoll, da der viel schneller 
bootet.
Das Konzept ist irgendwie unsinnig, finde ich. Außerdem kann ich mir 
schwer vorstellen, dass das unbedingt nötig ist. Den Spartan kann man 
zum beispiel so beschalten, dass er während der Konfig alle Pins auf 
Pull-Down oder Pull-Up macht. Eingänge sind es sowieso, also können 
schon mal während der Konfig keine Ausgänge aufeinander arbeiten. Der 
Rest ist eine Frage geschickter Platzierung von Pull-Up bzw. Pull-Down 
Wiederständen an den Pins.

Ich bin mir langsam zu 80% sicher, dass du den Konfig-FPGA gar nicht 
brauchst.

von Andreas B. (loopy83)


Lesenswert?

Auch ein CPLD wäre denkbar...
Ich bin der Meinung, dass ein uC zwar schon die Aufgabe erledigen kann, 
nur kann er dann nicht umschalten, dass der große FPGA dann die 
Konfiguration (Feinanpassung der Konfig.) übernehmen kann. Dieser FPGA 
ist Pflicht, da er neben dem Ändern der Konfig-register auch noch 
weitere Aufgaben zu erfüllen hat. Der SCLK liegt im Bereich von 5MHz, 
die Konfiguration sollte also schon recht schnell geschehen.

Die drei zu konfigurierenden Devices haben je 4bit Adressen und dann 
unterschiedlich große Register, das geht hinauf bis zu 200bits. In Summe 
sollte ich aber mit 1024bit hinkommen, also für Adressen und Daten.

Ein Gedankenspiel:
Könnte denn ein uC die komplette Standardkonfiguration übernehmen und 
nach Fertigstellung seine Ausgänge hochohmig schalten? Dann könnte man 
den uC und den FPGA parallel an das serielle Interface anschließen. So 
wäre auch die Konfigurationsgeschichte gelöst. Erst konfiguriert der uC 
und dann übernimmt der FPGA.... so bräuchte ich das Serielle Interface 
nirgends durchschleifen.

DANKE!

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Andreas B. wrote:
> Ein Gedankenspiel:
> Könnte denn ein uC die komplette Standardkonfiguration übernehmen und
> nach Fertigstellung seine Ausgänge hochohmig schalten?
Ja.
> Dann könnte man
> den uC und den FPGA parallel an das serielle Interface anschließen. So
> wäre auch die Konfigurationsgeschichte gelöst. Erst konfiguriert der uC
> und dann übernimmt der FPGA.... so bräuchte ich das Serielle Interface
> nirgends durchschleifen.
Gute Idee.

von Andreas B. (loopy83)


Lesenswert?

Christian R. wrote:
> Eine Frage hab ich da immer noch. Wieso ist es erforderlich zwischen
> deinen eigentlichen großen FPGA und die SPI Slaves noch ein kleines FPGA
> zu setzen? Die Grundeinstellung der SPI Slaves kann der große Spartan
> DSP doch genauso gut machen? Das hätte ja höchstens Sinn, wenn du *vor*
> bzw. während des bootens des großen FPGA unbedingt aus Sicherheits-
> oder schaltungstechnischen gründen eine Grundeinstellung der SPI Slaves
> sicherstellen musst, damit nix durchbrennt oder sowas. Nimmst du
> allerdings einen kleinen FPGA der die Grundeinstellung vornimmt, so muss
> auch der booten, und das geht nicht viel schneller als der große. Also
> sinnlos. Wäre höchstens bei einem CPLD sinnvoll, da der viel schneller
> bootet.
> Das Konzept ist irgendwie unsinnig, finde ich. Außerdem kann ich mir
> schwer vorstellen, dass das unbedingt nötig ist. Den Spartan kann man
> zum beispiel so beschalten, dass er während der Konfig alle Pins auf
> Pull-Down oder Pull-Up macht. Eingänge sind es sowieso, also können
> schon mal während der Konfig keine Ausgänge aufeinander arbeiten. Der
> Rest ist eine Frage geschickter Platzierung von Pull-Up bzw. Pull-Down
> Wiederständen an den Pins.
>
> Ich bin mir langsam zu 80% sicher, dass du den Konfig-FPGA gar nicht
> brauchst.

Der Hintergrund ist folgender:
Der kleine FPGA und der große FPGA sitzen auf zwei getrennten Platinen. 
Das Bestreben geht dahin, dass man beide Platinen getrennt in Betrieb 
nehmen kann. Das bedeutet, dass die drei Devices auch ohne großen FPGA 
konfiguriert werden und somit auch ohne extra Platine ihre Arbeit 
aufnehmen können. Im finalen Design wird dann höchstwahrscheinlich, aus 
Platz und Kostengründen, der kleine FPGA wegrationalisiert. Aber für 
einen Prototypen war das erstmal der einzig sinnvolle Ansatz. Denn eine 
extra Konfigurationsplatine incl. geeignetem Steckverbinder zu fertigen 
würde mehr kosten, als einen weiteren kleinen CPLD/FPGA zu verwenden.

DANKE

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

> Aber für
> einen Prototypen war das erstmal der einzig sinnvolle Ansatz. Denn eine
> extra Konfigurationsplatine incl. geeignetem Steckverbinder zu fertigen
> würde mehr kosten, als einen weiteren kleinen CPLD/FPGA zu verwenden.
Eine Platine mit einem Mikrocontroller zu fertigen kostet dich höchstens 
zweistellig. Und man kann auch fertige Platinen kaufen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> Könnte denn ein uC die komplette Standardkonfiguration übernehmen und
> nach Fertigstellung seine Ausgänge hochohmig schalten?
Ja.

> 1024bit
Das passt noch locker in den Programmspeicher eines kleinen uC.

> Erst konfiguriert der uC und dann übernimmt der FPGA.
Wenn das Feldprogrammierbare Gate-Array (also nicht der FPGA) 
solange stillhät und während der Konfiguration hochohmig ist, dann geht 
das. SPI ist an sich kein Multimaster-Bus, du mußt den Zugriff der 
beiden Master (FPGA und uC) also selber verwalten.
Wenn das nicht geht, kannst du mit einem Tristate-Treiber das FPGA 
abhängen, solange du auf den Bus willst.

> Der SCLK ...
Na bitte, geht doch ;-)
> ... liegt im Bereich von 5MHz
Das ist recht gemächlich.

von Christian R. (supachris)


Lesenswert?

Achso. Sag das doch gleich. Machen wir doch genauso. Quasi eine Test- 
und Inbetriebnahme-Geschichte. Sowas haben wir auch auf Test-Platinen. 
Mal als µC, oder als CPLD, der einen FPGA auf einer Einsteckkarte mit 
Kommandos füttert, die sonst ein FPGA auf der Backplane ausspuckt. Das 
CPLD hat für uns den weiteren Vorteil, dass die Einsteckkarte auch ohne 
die große Backplane komplett per Boundary-Scan testbar ist. Aber für 
deinen Fall ist der µC wahrscheinlich die einfachere Lösung.

von Andreas B. (loopy83)


Lesenswert?

Ok, dann werde ich die Lösung mit einer Ansteckplatine für 
Inbetriebnahme und Tests weiterverfolgen, die dann den uC beherbergt und 
somit die Controllerplatine mit dem großen FPGA simuliert.

Als Variante habe ich mir jetzt erstmal den ATtiny24 ATmel ausgesucht. 
Aber durch die jetzt nicht mehr geforderten räumlichen Grenzen kann ich 
auch einen ATmega nehmen, ein großes package und dann hab ich genug 
Freiheiten bei der Programmierung und beim Messen.

Und dann kann ich parallel die VHDL und FPGA Geschichte angehen. Ich 
habe das Gefühl, dass ich fast froh bin, dass ich dieses Kapitel wieder 
etwas nach hinten schieben kann :D

DANKE an alle Beteiligten :)

Bitte 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
Noch kein Account? Hier anmelden.