Hallo,
kurze Einleitung:
Wir müssen für einen Beleg im Fach Schaltkreisentwurf eine digitale
Schaltung entwerfen. Von einem Mitarbeiter des Institutes haben wir
erfahren, dass für einen Praktikumsaufbau eine Motoransteuerung für
einen DC Motor überarbeitet werden soll. Die Steuerung soll an einen
ASI-Bus angeschlossen werden.
Wir haben schon ein Grobkonzept erarbeitet und müssen uns jetzt in das
Thema VHDL einarbeiten, da wir das ganze gern in einem FPGA mit ein paar
zusätzlichen Bauelementen umsetzten wollen.
Zum Konzept:
Ein ASI-ASIC dient als Anbindung an den BUS. Dieser hat 4 A/E-Pins,
welche frei verwendet werden können. Das FPGA soll die PWM generieren
und Werte von einem ADC auswerten, bzw. als ADC dienen(keine Ahnung, ob
das geht). Weiterhin soll noch eine Drehrichtungsumkehr möglich sein.
Um z.B. ein Relais anzusteuern sind dann noch weitere Bauelemente nötig.
Da die Aufgabe nur lautet etwas mit FPGA theoretisch umzusetzen, steht
es uns frei eigenen Code zu schreiben, oder fertige Bausteine zu
verwenden. Als Programmiersystem Soll die ISE von Xilinx zum Einsatz
kommen. Ein physischer Aufbau der Schaltung ist nicht notwendig.
Fragen:
1. Gibt es für VHDL sowas wie Bibliotheken von Bausteinen, wo bestimmte
Aufgaben, z.B. PWM Generierung schon fertig beschrieben sind?
2. Ist das Konzept so erstmal anwendbar, oder haben wir da in die
Falsche Richtung gedacht?
3. Welcher FPGA bietet sich für das Vorhaben vom Leistungsvermögen her
an?
Ich hoffe Ihr können mir da ein bissel mit euren Hinweisen unter die
Arme greifen.
Alex
Alex schrieb:> 1. Gibt es für VHDL sowas wie Bibliotheken von Bausteinen, wo bestimmte> Aufgaben, z.B. PWM Generierung schon fertig beschrieben sind?
Ja, sowas nennt man IP Core. Sowas lohnt sich aber nur für richtig
aufwändige Komponenten.
> 2. Ist das Konzept so erstmal anwendbar, oder haben wir da in die> Falsche Richtung gedacht?
Passt erst mal schön.
> 3. Welcher FPGA bietet sich für das Vorhaben vom Leistungsvermögen her> an?
Das kann jeder der aktuellen FPGAs. Aber das ist auch komplett
uninteressant, weil ihr die Hardware nie aufbauen werdet...
Alex schrieb:> Da die Aufgabe nur lautet etwas mit FPGA theoretisch umzusetzen, steht> es uns frei eigenen Code zu schreiben, oder fertige Bausteine zu> verwenden
Diese Aufgabe ist abschreckend! Für mich ist das wie Autofahren am
Küchentisch zu üben: kurz interessant, aber man lernt eigentlich
nichts dabei...
Das was du beschreibst, ist eigentlich eher die Aufgabe eines µC als
eines FPGAs.
Ein µC hat in der Regel bereits ADC und PWM-Einheiten fix fertig auf dem
Chip. Bei einem FPGA hingegen musst du die PWM-Einheit erst einmal
beschreiben (quasi bauen) und dann noch bedienen.
Ob es einen FPGA mit ADC gibt, weiss ich nicht. Hierbei handelt es sich
um einen analogen Schaltungsteil und das ist etwas, wofür FPGAs
eigentlich grundsätzlich nicht gemacht sind.
Sprich, es würde darauf hinauslaufen, dass ihr einen extrenen ADC
benötigt und diesen dann vom FPGA aus z.B. per SPI ansprecht. Wobei ihr
dann natürlich auch das SPI erstmal im FPGA "bauen" müsst.
Also wie du sieht: Alles viel viel umständlicher, als wenn man es mit
einem µC erschlagen würde.
Habt ihr euch die Aufgabenstellung selbst ausgesucht oder war exakt
diese als FPGA-Projekt vorgegeben?
Schlumpf schrieb:> Das was du beschreibst, ist eigentlich eher die Aufgabe eines µC als> eines FPGAs.Alex schrieb:> Wir müssen für einen Beleg im Fach Schaltkreisentwurf eine digitale> Schaltung entwerfen.
Er muss eine digitale Schaltung entwerfen, also kann man auch was
machen, mit realem bezug. Scheint von daher schon OK.
Er kann ja dann in einem anderen Semester im Fach Embeddedsystems oder
Softwaredesign die gleiche Aufgabenstellung für eine pratische Arbeit
mit µC eingeben, dann hat er beide Varianten geübt ;-)
Hallo,
ja, die Belege sind Abschreckend. Wir werden das auch nur für einen FPGA
theoretisch beschreiben, sollte der Aufbau dann doch mal umgesetzt
werden, wird es ein µC, da geht das mit weniger Aufwand einher. Embedded
Systems mit Programmierung haben wir schon gemacht, da wars eine
Wetterstation ;).
Wir haben einfach mal angefangen und bisher haben wir das fabriziert. Im
ISIM funktioniert es auch so wie es soll, die andere Frage ist, ob das
noch besser geht.
Ich könnte den Teil mit dem Counter auch weglassen, und bis zum Wert von
CLK zählen. So weit wie ich das mitbekommen habe, wird der Clock bei
FPGA von außen an den Chip gelegt und nicht wie bei µC, dass da einer
schon vorhanden ist.
Ist bei dem Aufbau ein RESET notwenig, oder geht das auch ohne?
Für den theoretischen Aufbau haben wir uns überlegt, einen ADC mit
Parallelausgang zu nehmen, einen Port zu machen und dann darüber die am
Shunt gemessene Spannung auszuwerten.
Wenn der Wert vom ADC dann länger als eine bestimmte Zeit größer als der
normale Motorstrom ist, wird ein Bit gesetzt, dass dann auf den ASI-Bus
geht.
Habt ihr noch Hinweise, worauf ich achten muss?
Alex
Alex schrieb:> Habt ihr noch Hinweise, worauf ich achten muss?
Dass du die Hardwarebeschreibung an dem orientierst, was dein
Synthesizer kann. Damit gibt es Probleme:
1
signalcounter:integer:=0;-- keine uneingeschränkten Integer verwenden, sondern immmer einen range angeben!
2
signalduty_cycle:integer:=0;
3
4
caseduty_cycleis
5
when33|66=>
6
ifrising_edge(CLK)orfalling_edge(CLK)then-- HOPPLA: mitten im asnychronen Prozess ein Takt
7
counter<=counter+1;
8
endif;
9
ifcounter>=10000then--- wieder asynchron, aber counter fehlt in der Sensitivliste --> Simulation falsch!!!
10
--- zudem: asynchroner kombinatorischer Reset --> Glitches setzen den gesamten oder Teile vom Zähler zurück
11
counter<=0;
12
endif;
13
14
ifcounter>=duty_cycle*100then--- hier wird ein Multiplizierer verbraucht. Davon gibt es gar nicht allzuviele...
1. die Beschreibung einen getakteten Prozesses sieht anders aus.
2. die Simulation ist falsch, weil counter und duty_cycle in der
Sensitivliste fehlen.
3. die Sache mit dem Multiplizierer solltest du besser so lösen:
4. keine uneingeschränkten Integer verwenden, denn sonst kann dir der
Simulator bei einem Fehler nicht auf die Finger klopfen!
> wird der Clock bei FPGA von außen an den Chip gelegt und nicht wie bei> µC, dass da einer schon vorhanden ist.
Beim uC wird der Takt idR. auch von aussen angelegt. Nur manchmal ist
auch ein verwertberer Taktgenerator eingebaut.
> Im ISIM funktioniert es auch so wie es soll,
Du kannst 100% von VHDL simulieren, aber bestenfalls 95% synthetisieren.
> die andere Frage ist, ob das noch besser geht.
Sieh dir ein Buch an, wie ein getakteter Prozess aussieht: anders als
deiner...
> einen FPGA
Es ist einFPGA, weil es ein Array ist...
> Ist bei dem Aufbau ein RESET notwenig, oder geht das auch ohne?
Wozu sollte hier ein Reset nötig sein? Es ist alles zyklisch und
passiert gleich darauf wieder...
Wenn ich die ISE das ganze Syntetisieren lasse und dann das Design
implementiere, zeigt es mir keine Fehler an. Kann ich dann davon
ausgehen, dass alles so jetzt IO ist?
Eine Frage habe ich aber noch, warum ist der Takt darin so schlimm?
Alex
Alex schrieb:> Eine Frage habe ich aber noch, warum ist der Takt darin so schlimm?
Gegenfragen: was hast du da beschrieben? Wie sieht das mit Flipflops und
Gattern aus? Warum beschreibt ausser dir niemand auf der Welt auf diese
Art einen Zähler? Und was steht im Handbuch zum Synthesizer?
Alex schrieb:> ich hab jetzt die von dir aufgezeigten Fehler versucht zu beseitigen.
Dein Zähler wird immer noch ganz beliebig zurückgesetzt, weil der
asynchrone kombinatorische Reset immer noch drin ist! Das ist das
eigentliche übel.
Es bringt nichts, an dem Design an Kleinigkeiten herumzubasteln, denn es
ist grundlegend vermurkst.
Grundlegend gilt: Du machst entweder einen getakteten Prozess oder du
machst einen kombinatorischen Prozess. Aber niemals so ein Mischmasch...
Peter, bitte sag, dass das nicht dein Arsch auf dem Bild ist.
Vielleicht solltest du jetzt einfach deine Tabletten nehmen, die du
heute abend vergessen hast, und dich dann schleunigst ins Bett
verkriechen.
So, ich hoffe es ist jetzt besser geworden.
Sind P1 und P3 jetzt rein Kombinatorische Prozesse?
P2 sollte jetzt rein getaktet sein. Aber wo muss ich nun den counter
resetten? wenn ich jetzt wieder in P2 ein If einfüge wird es ja dann
wieder eine Mischung.
Wenn ich das Richtig verstanden habe, werden die Prozesse auch nur
abgearbeitet, wenn sich bei dem Item(s) in der Sensivity List etwas
ändert. D.h. P1 wird nur ausgeführt, wenn von Außen auf den
Signalleitungen des ASI-ASICs was passiert?
Und gibt es Probleme, da die Prozesse zeitgleich ablaufen?
Alex schrieb:> Wenn ich das Richtig verstanden habe, werden die Prozesse auch nur> abgearbeitet, wenn sich bei dem Item(s) in der Sensivity List etwas> ändert. D.h. P1 wird nur ausgeführt, wenn von Außen auf den> Signalleitungen des ASI-ASICs was passiert?> Und gibt es Probleme, da die Prozesse zeitgleich ablaufen?
Falsche Denkweise! Das was da in den Prozessen beschrieben ist, ist
'immer da' und laeuft demnach immer ab. Das ist einfach Hardware, die so
vor sich hin klappert.
In deinem Prozess P2 fehlt noch der Reset des counters, sollte also in
etwa so aussehen:
1
P2:process(CLK)
2
begin
3
ifrising_edge(CLK)then
4
ifcounter>=10000then
5
counter<=0;
6
else
7
counter<=counter+1;
8
endif;
9
endif;
10
endprocessP2;
Den Prozess P1 sowie P3 koenntest du auch in sogenannter 'concurrent'
Schreibweise realisieren, also z.B.:
1
withASI_ASIC_IN_DUTYselect
2
duty_cycle<=3300when"01",
3
6600when"10",
4
10000when"11",
5
0whenothers;
oder auch
1
duty_cycle<=3300whenASI_ASIC_IN_DUTY="01"else
2
6600whenASI_ASIC_IN_DUTY="10"else
3
10000whenASI_ASIC_IN_DUTY="11"else
4
0;
In VHDL fuehren manchmal viele Wege nach Rom...
Du sparst dir dann die ganzen statements mit process und der
sensitivity-Liste (die uebrigens nur fuer die Simulation relevant ist).
Und weil Lothar oben schon was zu Peters Kommentaren gesagt hat:
Ignoriere den Peter, das ist ein VOLLHONK!
Alex schrieb:> Sind P1 und P3 jetzt rein Kombinatorische Prozesse?
ja
Alex schrieb:> P2 sollte jetzt rein getaktet sein.
ja
Alex schrieb:> Aber wo muss ich nun den counter> resetten?
du musst den Counter gar nicht reseten, er ist auf 0 initialisiert und
wird von dort loslaufen. Du kannst aber in p2 die Abfrage machen, ob der
Counter seinen Maximalwert erreicht hat. Falls ja, weißt du ihm wieder
den Wert Null zu statt ihn weiter hochzählen zu lassen.
Alex schrieb:> Wenn ich das Richtig verstanden habe, werden die Prozesse auch nur> abgearbeitet, wenn sich bei dem Item(s) in der Sensivity List etwas> ändert
In der Simulation "eigentlich" ja (muss nicht streng für alle
Simulatoren gelten, einige ergänzen wohl z.B. auch unvollständige
Sensitivity-Listen.) In der FPGA-Hardware existieren keine "Prozesse,
die abgearbeitet werden". Dort ist die Fragestellung also sinnlos.
Alex schrieb:> Und gibt es Probleme, da die Prozesse zeitgleich ablaufen?
Nein: der Simulator kommt damit klar, die Hardware im FPGA ist ohnehin
"parallel" für alle beschriebenen Funktionalitäten vorhanden.
Siehst du einen Vorteil darin, in der Case-Struktur von p3 das Signal
duty_cycle abzufragen statt den Einang ASI_ASIC_IN_DUTY? Mich hat das
verwirrt. Ich wollte dir zuerst schreiben, dass MOSFET "fast immer" auf
Null stehen wird, weil nur für bestimmte Werte des Duty-Cycle MOSFET mal
auf Eins gehen kann. Erst später habe ich erkannt, dass Duty-Cycle ja
tatsächlich nur diese 4 konkreten Werte annehmen kann.
Hallo,
wir haben weiter an unserem Projekt gearbeitet und die Zustandsmaschine
für die Ansteuerung des ADC eingefügt. Wir haben uns als ADc einen
TLV571 genommen.
Datasheet: http://www.ti.com/lit/ds/symlink/tlv571.pdf
Wir haben die ZSM entsprechend aufgebaut und hätten gern noch einmal
Feedback von euch, ob das so richtig ist.
Wir sind uns nur nicht sicher, wegen der Schaltzeiten, im Datenblatt
sind ja nach den Flanken jeweils die Zeiten angegeben, z.B. tsu(CSL_WRL)
Setup time, CS to WR. So weit, wie wir das verstanden haben, muss 5ns
nachdem CS auf low geschalten wurde WR auch auf low geschalten werden,
damit die Operation erfolgreich ist. Ist das bei einem FPGA gegeben,
wenn beie Signale im gleichen Knoten der ZSm geschalten werden?
2.
Wir haben den Chip des ADC jetzt so parametriert, dass die internal
Clock benutzt wird. Ist es jetzt vllt besser, die gleiche clock wie im
FPGA zu benutzen, also eine external Clock an den ADC zu legen? Wenn
beide mit 20MHz getaktet sind, sollte das doch eig keinen
unterschiedmachem, ob ich bei einem den interen und beim anderen den
externen Clock benutze.
Alex
Alex schrieb:>> Wir sind uns nur nicht sicher, wegen der Schaltzeiten, im Datenblatt> sind ja nach den Flanken jeweils die Zeiten angegeben, z.B. tsu(CSL_WRL)> Setup time, CS to WR. So weit, wie wir das verstanden haben, muss 5ns> nachdem CS auf low geschalten wurde WR auch auf low geschalten werden,> damit die Operation erfolgreich ist.
Das habt ihr falsch verstanden. Im Datenblatt steht >= 5 ns, d.h. es
darf auch später sein.
> Ist das bei einem FPGA gegeben,> wenn beie Signale im gleichen Knoten der ZSm geschalten werden?>
Nein, man kann zwar versuchen es mit Constraints zu erzwingen, das ist
aber ein endloser Kampf und lohnt sich hier nicht. Einfach zusätzliche
States und höhere Taktfrequenz benutzen.
>> 2.>> Wir haben den Chip des ADC jetzt so parametriert, dass die internal> Clock benutzt wird. Ist es jetzt vllt besser, die gleiche clock wie im> FPGA zu benutzen, also eine external Clock an den ADC zu legen? Wenn> beide mit 20MHz getaktet sind, sollte das doch eig keinen> unterschiedmachem, ob ich bei einem den interen und beim anderen den> externen Clock benutze.
Externe Clock für den ADC aus dem FPGA ist sinnvoller, Die FPGA Clock
sollte dann sinnvollerweise das doppelte der ADC Clock haben. Die ADC
Clock aber nicht etwa als CLK für einen Prozess verwenden.