Wie konstruiert man strukturiertes VHDL?

Berater schrieb:
> Problem: Der Code funktioniert nicht richtig in der realen Umgebung.
> Irgendwas passt mit dem Timing nicht.
Das ist der übliche ausgangspunkt für eine wochenlange Fehlersuche... 
;-)

> Wie erklärt man dem Auftraggeber, dass dieser tolle, intelligente Code
> nicht zu debuggen ist, jedenfalls nicht in vertretbaren Zeiträumen.(?)
Wurden mehrere Takte verwendet?
Wurden asynchronen Resets verwendet?
Kommen evtl. sogar kombinatorische asynchrone Resets vor?
Wenn sowas auftaucht, dann stelle ich SOFORT jede Lobhudelei in Frage, 
und kann mit simpelsten Beispielen die Qualifiktaion des Lobgehuldeten 
zunichte machen.
Und ab diesem Zeitpunkt ist das nicht eine Fehlersuche, sondern ein 
grundlegendes Redesign.

> Warum ist es immer noch so, dass immer wieder Wert auf die Sprache VHDL,
> nicht aber auf das Designen gelegt wird?
Weil viel Know-How zu FPGAs erst in den letzten Jahren aufgebaut wurde, 
die Bücher aber schon lange vorher verfasst wurden. Und für viele 
Faustregeln gibt es noch keine ausreichend dokumentierte Mathematik, so 
dass lieber die alte abstrakte Automatentheorie gelehrt wird, als die 
praktische Umsetzung eines Zählers in Hardware...

> - der Topmann ist wech
Das war offenbar genu der richtige Zeitpunkt zum Absprung... ;-)

> - der Topmann ist wech
> Wie kommt man dem bei?
Vermisstenmeldung an die Polizei?  ;-)

> Sicher ist es nicht so toll erst ein Designdocument zu schreiben,
> Testbenches aufzuziehen und DANN erst anzufangen zu programmieren,
> aber es spart am Ende einen Haufen Zeit
Exakt meine Haltung. Ich gehe sogar noch einen Schritt weiter und leite 
die Funktionalität, die man für die Tests und Validierungen in den SPECs 
definiert, direkt in Punkt-für-Punkt Abläufe in Exceltabellen. Aus denen 
kann man dann nicht nur den Datenstom für Modelsim-Filereader sondern 
auch den Ablauf von pipes und statemachines rausziehen und automatisch 
generieren lassen - inklusive Timing.

Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule 
gelernt hat, wie man:

- wann und wie (nicht) einsynchronsiert
- physische von logischen "sets" und "resets" trennt
- asynchron rettet und wann man es bleiben lässt
- eine pipeline entwirft und dokumentiert
- serielle ind parallere Strukturen umdesiged
- die Balance zwischen serial und parallel ermittelt
- mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert
- eine Iteration über Zeit-Flächen-Struktur realisiert
- eine Rekursion implementiert
- eine Formel so umstellt, dass sie VHDL-tauglich wird
- einen Algo so zerlegt, dass er parallelisierbar wird
- synthetisierbarer testcode implementiert und wann
- testbenches optimieren und automatisieren kann
- eine Resource in verschiedenen Zeitebenen mehrfach nutzt

Es geht also nicht um das VHDL, sondern grundsätzlich darum, wie man 
eine digitale Schaltung optimal aufteilt und aufbaut, dass das 
Gesamtergebnis passt und zwar letztlich auch noch unter Berücksichtigung 
von:

- Designaufwand am Arbeitsplatz + Abstimmungsbedarf im Team
- Verifikations- und Validierungsaufwand während Design
- Implementierungsaufwand im FPGA oder später mal ASIC oder anderes FPGA
- Integrationsaufwand des FPGA-Systems in der Umgebung / im System
- Test- und Inbetriebnahmeaufwand des Systems im Feld

Je nachdem, ob man einen Prototypen baut oder einen Kleinserie, eine 
Komponente o.ä. gibt es hier doch recht starke Verschiebungen.

Das alles kommt natürlich erst mit der Erfahrung, aber Digitaldesign im 
eigentlichen Sinne, scheinen die Wenigsten systematisch wirklich erlernt 
zu haben.

Juergen S. schrieb:
>> Sicher ist es nicht so toll erst ein Designdocument zu schreiben,
>> Testbenches aufzuziehen und DANN erst anzufangen zu programmieren,
>> aber es spart am Ende einen Haufen Zeit
> Exakt meine Haltung. Ich gehe sogar noch einen Schritt weiter und leite
> die Funktionalität, die man für die Tests und Validierungen in den SPECs
> definiert, direkt in Punkt-für-Punkt Abläufe in Exceltabellen. Aus denen
> kann man dann nicht nur den Datenstom für Modelsim-Filereader sondern
> auch den Ablauf von pipes und statemachines rausziehen und automatisch
> generieren lassen - inklusive Timing.

Das klingt interessant. Doch Excel finde ich mittlerweile grausam, da 
ich alles unter Excel gesehen habe, was nicht in Excel sollte.



> Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule
> gelernt hat, wie man:
>
> - wann und wie (nicht) einsynchronsiert
> - physische von logischen "sets" und "resets" trennt
> - asynchron rettet und wann man es bleiben lässt
> - eine pipeline entwirft und dokumentiert
> - serielle ind parallere Strukturen umdesiged
> - die Balance zwischen serial und parallel ermittelt
> - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert
> - eine Iteration über Zeit-Flächen-Struktur realisiert
> - eine Rekursion implementiert
> - eine Formel so umstellt, dass sie VHDL-tauglich wird
> - einen Algo so zerlegt, dass er parallelisierbar wird
> - synthetisierbarer testcode implementiert und wann
> - testbenches optimieren und automatisieren kann
> - eine Resource in verschiedenen Zeitebenen mehrfach nutzt

fast null. Alles selbst erlernt.

was meinst du eigentlich mit den Punkten?
> - physische von logischen "sets" und "resets" trennt
> - eine Iteration über Zeit-Flächen-Struktur realisiert
da muss ich passen, oder es läuft unter einem anderen Begriff bei mir



> Es geht also nicht um das VHDL, sondern grundsätzlich darum, wie man
> eine digitale Schaltung optimal aufteilt und aufbaut, dass das
> Gesamtergebnis passt und zwar letztlich auch noch unter Berücksichtigung
> von:
>
> - Designaufwand am Arbeitsplatz + Abstimmungsbedarf im Team
> - Verifikations- und Validierungsaufwand während Design
> - Implementierungsaufwand im FPGA oder später mal ASIC oder anderes FPGA
> - Integrationsaufwand des FPGA-Systems in der Umgebung / im System
> - Test- und Inbetriebnahmeaufwand des Systems im Feld
>

Das sind alles Fragen nach der Wirtschaftlichkeit. Ich würde die Aussage 
etwas unterteilen. VHDL st keine Programmierung für eine CPU, sonder es 
wird Hardware geschaffen. Das ist Digitaltechnik!!
Auf der geschaffenen Hardware kann unter Umständen auch Software laufen. 
Wie der Schnitt Software Hardware gehalten werden sollte ist eine ganz 
schwierige Frage und beeinflusst das Design gewaltig.

 Die Algorithmen passen nicht 1:1 mehr, weil Prozesse synchronisiert 
werden müssen und Daten noch eine Gültigkeitsdauer haben.
VHDL wird of als Nebenfach angeboten. Mal bei den Informatikern und mal 
bei den Elektrotechnikern und alles bleibt in den Grundlagen stecken.
Die Dokumentation ist dann immer noch weit entfernt. Auch mathlab ist 
keine Dokumentationsebene.
Am besten wäre UML als Dokumentionsgrundlage -

René D. schrieb:
>> Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule
>> gelernt hat, wie man:
>>
>> - wann und wie (nicht) einsynchronsiert
>> - physische von logischen "sets" und "resets" trennt
>> - asynchron rettet und wann man es bleiben lässt
>> - eine pipeline entwirft und dokumentiert
>> - serielle ind parallere Strukturen umdesiged
>> - die Balance zwischen serial und parallel ermittelt
>> - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert
>> - eine Iteration über Zeit-Flächen-Struktur realisiert
>> - eine Rekursion implementiert
>> - eine Formel so umstellt, dass sie VHDL-tauglich wird
>> - einen Algo so zerlegt, dass er parallelisierbar wird
>> - synthetisierbarer testcode implementiert und wann
>> - testbenches optimieren und automatisieren kann
>> - eine Resource in verschiedenen Zeitebenen mehrfach nutzt
>
> fast null. Alles selbst erlernt.

So ist es. Dafür werden noch massiv Logikminimierungsverfahren gelehrt.

Tom

Thomas Reinemann schrieb:
> So ist es. Dafür werden noch massiv Logikminimierungsverfahren gelehrt.
Und Halbaddierer auf RTL-Ebene beschrieben und zu Volladdierern 
verknotet. Dabei wird dann aber nicht auf die Wichtigkeit der 
Carry-Chain, deren geschwindigkeitslimitierende Funktion und die 
Umsetzung der Kette in FPGAs eingegangen...

Georg A. schrieb:
> Naja, so ein bisschen Rumspielen mit boolscher Algebra, KV und
> Quine-McCluskey sollte man in 1-2 Vorlesungsstunden schon machen, damit
> man mal gesehen hat, was das Zeug kann und wo die Limits liegen.
Es sollte aber abschliessend der Hinweis kommen, dass diese ganze 
Optimiererei bei bis zu 4 (bzw. 6) Eingängen in FPGAs unnötig ist, weil 
die LUT (oder neu: der Funktionsgenerator) das sowieso direkt abbilden 
kann...

Das klingt als bräuchten wir eine Selbsthilfegruppe.

Ich gebe auch  Georg A. recht, es gibt auch überzogene Hardware 
Ausführungen, was besser in eine CPU gepasst hätte.

Hier ist es wichtig eine Projektleitung zu haben, da die Sachen von 
mehreren Kollegen entwickelt werden. Wie kann projektübergreifend 
diskutiert werden?
Daran krankt es.
Das sind Diagramme und als Schiedsrichter Testbenches. Eine Testbench in 
einem zu frühen Stadium ist etwas überzogen.

Ob da der Projektleiter der Richtige ist, weiss ich nicht. Es muss 
jemand sein, der breit und tief ausgebildet und lange Erfahrung in allen 
Bereichen hat. Typisch macht das ein Senior System Engineer:

Wenn man solche Systeme hinstellen und partitionieren will, dann gelangt 
man nur zu einer klugen Aufteilung von HW und SW, bzw HW-Abläufen und 
SW-Abläufen, zu Schnittstellen und Interaktionen, wenn man beide Welten 
sehr gut kennt.

Und ja, er muss sie studiert haben!

Denn, wenn ich eins in all den Jahren gelernt und gesehen habe, dann 
das, dass es in der Softwarelandschaft (C, Algorithmik und VHDL-basierte 
Abläufe) ein großer Haufen an Mist zusammengeschustert wird. Da gibt es 
die abenteuerlichsten Konstrukte mit tollen Tricks und "Realisationen", 
für die es längst schlüsselfertige, intelligente Lösungen in der 
Schublade gibt, von denen man unbedingt profitieren und Gebrauch machen 
muss, wenn man einfach, effektiv und stabil entwickeln will.

Das kann man sich nicht alles selber beibringen, weil man das meiste 
nicht irgendwo in der Anschauung sieht oder sich selber ausdenken kann. 
Man muss es gesehen haben, BEVOR man es braucht. Man muss wissen, dass 
es das gibt und ungefähr sehen und schätzen, was es an Zeit und Aufwand 
kostet und was damit möglich ist.

Ich habe immer wieder Leute gesehen, die aus fremden Bereichen der 
Wissenschaft in die Programmierung einsteigen und dann schnell an limits 
kommen. Umgekehrt bekommen selbst eingeschleischte Softwareentwickler es 
einfach nicht hin, in die strukturelle Ebene hineinzudenken.

Wenn man 5 Jahre Maschinenbau studiert hat, kennt man keine 
Digitalschaltungen und deren Eigenheiten und Details bleiben einem 
verborgen. Typische Synch-, Phasen- und Taktprobleme hat man auch nur 
verinnerlicht, wenn man reale Chips vor Augen hat, denn Abstraktheit hin 
oder her: Am Ende klickern da drinnen analoge Transistoren, die nur in 
der vereinfachten Betrachtung diskrete Funktionen aus LUTs darstellen.

Und genau dieses Wissen sorgt dafür, dass man manche Sachen u.U. eben 
nicht in SW nachbilden kann, ein FPGA im Einzelfall nicht taugt oder 
umgekehrt aus technischen Gründen ein "langsamer" DSP verwendet werden 
muss.

>Excel
Ich benutze das als schlaues Karopapier. Andere malen sich was auf den 
Zettel- ich zeichne Wiederverwendbares. Das gemeinsame Editieren von 
Varianten, Abläufen und Verzweigungen für physische oder virtuelle 
Derivate und Versionen geht mit COPY&PASTE schneller, als das Malen von 
Bäumchen in Visio :-)

Und Planen und Automatisieren geht auch simpel und einfach, weil man 
leicht Umkopieren, Löschen und Duplizieren kann. Und: Man kann Dinge, 
mit miteinander verknüpft sind, als harte oder weiche Verknüpfung 
belassen und sich eine Alternativversion auf Nachbarblättern 
durchrechnen lassen, bzw Änderungen in der V1-Version automatisiert 
weitergeben, um Konsistenz aufrecht zu erhalten, wo sie nötig ist.

Ein Beispiel aus dem FPGA-Bereich wäre das Halten und Planen der 
Verdrahtungstruktur von Bussen über Platinen und FPGA-Grenzen hinweg, 
inklusive der Namen der Signale an den Stecker, Ports, Entities etc. 
sowie die Versionsplanung für verschiedene Ausbaustufen oder die 
Migrationsplanung unter Nutzung von Chips unterschiedlicher Hersteller.

Ein reales Beispiel mit geänderten Zahlen:

Man denke sich mal eine Struktur aus z.B. 3 x 4 FPGAs, wo sich 10 davon 
50 ähnliche Funktionen teilen, 5 davon weitere 200 
Leitungstreiberfunktionen, wobei jeweils 40 dieser Leitungen durch 
jeweis andere FPGAs redundant getrieben werden können müssen, wegen 
Minderbestückung und alle 12 zusammen auch 1 bestimmte Funktion verteilt 
leisten, manche FPGAs aber auch nur eine einzige Funktion leisten, die 
nur sie beherrschen.

Das Ganze dann für 2 verschiedene Versionen von Boards, wo sich die 
Zuordnungen der Pins teilweise physisch ändern und 2 verschiedene 
Prozessoren / Ansteuerungen, wo sich die Busse und die Timings ändern = 
4 Versionen! Man darf aber nur 3 verschiedene, jeweils unterschiedliche 
FPGA-images verwenden, weil das Flash auf den alten board-Versionen zu 
klein ist und die boards plug-and-meassure fähig sein müssen, alles 
selber erkennen müssen und überall passen sollen.

Das gibt eine Matrix mit wenigstens 4 Dimensionen mit divergenten und 
konvergenten Überlappungen, deren Funktionsvielfalt genau so auf 
virtuelle FPGA-Funktionen gemappt werden muss, dass am Ende jedes FPGA 
eines von 3 images bekommt, welche in Summe die Vereinigungsmenge aller 
Funktionen können, aber pro FPGA jeweils nur die Teile funktionieren, 
die in diesem FPGA benötigt werden, die Summe der so zusammenarbeitenden 
FPGAs aber die gesamt Teilfunktion kann. Das kompliziertes FPGA nutzt 
dann aus seinem Image, welche z.B. 40 Teilfunktionen könnte, z.B. 13, 
dessen Nachbar nur 7. Macht in Summe 20 Funktionsteile (4 
unterschiedliche) von insgesamt >70 insgesamt auf dem board.

Und dann bitte bis Ende der folgenden Woche eine Planungsmethode 
entwickeln, wo alle Funktionen enthalten-, übersichtlich geordnet-, und 
so gruppiert sind, dass die daraus notwendigen virtuellen 
Verdrahtungsoptionen ersichtlich sind und die Vollständigkeit 
sichergestellt werden kann. Ok, hab' ich gemacht.

Ergebnis: Mehrere Designingenieure inkl Projektleiter mit Kinnlade 
unten, automatisch erzeugte "set_location's" für's UCF ohne Tippfehler, 
automatische Summierung der Funktionen, Teilfunktionen, Pins je FPGA, 
Busbreitenwerte für Derivateoption und Darstellung der Zuordnung der 
realen physischen Pins zu virtuellen Kanälen der Software -> 
Programmiertabelle ausleitbar

... und ein Dr. der Mathematik, der sich ein halbes Jahr lang bereits 
mit der Planung des Systems befasst hatte und zu dem Schluss gekommen 
war, man brauche mindestens 2 verschiedene boards mit insgesamt 5 
verschiedenen images.

Meine reale Aufgabe war im Ürigen noch etwas komplexer.

Wenn ich mir überlege, was man davon in den heutigen 
SOC-builder-Systemen und System-Generator-blocksets oder HDL-Designer 
abbilden kann, dann happy digit!

Juergen S. schrieb:
> Man denke sich mal eine Struktur aus z.B. 3 x 4 FPGAs,
> wo sich 10 davon 50 ähnliche Funktionen teilen, 5 davon weitere 200
> Leitungstreiberfunktionen, wobei jeweils 40 dieser Leitungen durch
> jeweis andere FPGAs redundant getrieben werden können müssen, wegen
> Minderbestückung und alle 12 zusammen auch 1 bestimmte Funktion verteilt
> leisten, manche FPGAs aber auch nur eine einzige Funktion leisten, die
> nur sie beherrschen.
Zum Glück habe ich solche Probleme nicht (und ich vermute: auch die 
wenigsten anderen)... ;-)
Aber ich möchte auch behaupten, dass man da einfach auch mal Glück haben 
darf und zum richtigen Zeitpunkt die zündende Idee. Nur: DAS zu lehren 
kann man jetzt wirklich nicht von den Schulen verlangen...  :-o

> Zum Glück habe ich solche Probleme nicht (und ich vermute: auch die
> wenigsten anderen)... ;-)
Schon richtig, es ging mir nur darum, einmal zu zeigen, dass man mit 
Excel durchaus einiges machen kann. War vielleicht ein wenig zu 
ausführlich.

Es ging mir aber auch darum, zu verdeutlichen, dass die Komplexität bei 
Entwicklungen mehr in der Planung und im Denkansatz liegt und es nicht 
reicht, einfach nur irgendeine wissenschafliche Ausbildung zu haben und 
sich das Programmieren angeeignet zu haben. Der Hase ganz woanders im 
Pfeffer.

> Juergen S., so gut wie du möchte ich auch gerne mal werden...
Ja, ja ich weiss schon, wenn man D Fakten auspricht, fühlen sich einige 
gleich wieder angegriffen. Nur: ständig auf understatement machen, 
bringt nichts voran. Manchmal muss man auch mal ein wenig Tacheles reden 
und wo sollte man das, wenn nicht in einem Forum? Im direkten Umgang mit 
Kollegen kann man schlecht auf den Putz hauen und der Threadersteller 
ist gut beraten, vorsichtig mit Kritik an Kollegen zu sein.

Was ich zu dem Thema Studium geschrieben habe, sehen viele meiner 
Kollegen aber genau so, besonders, wenn sie sich mit der mittelmäßigen 
Qualität von Zulieferern herumärgen müssen. Heute kommt doch jeder 
zweite Computerbediener auf die Idee, er sei ein guter 
Softwareentwickler, weil er eine Programmiersprache gelernt hat. Seien 
wir mal ehrlich: C-Programmieren könnte so ziemlich jeder, wenn er sich 
damit befasst. Mit Jedermann-Qualität kann man aber keine Systeme in den 
Markt bringen, die um soviel besser sind, als das, was anderorts gemacht 
wird, dass man gut verkaufen kann.

> Doch nicht der tolle Hecht oder keine Eier?
Nein, sozialkompatibel, freundlich und nett zu Kollegen. Mit Eiern hat 
das nichts zu tun. Wir sind nicht im Rabaukenland.

> Konstruktiv darf und soll man das.
Tue ich, keine Sorge. Ich tue es aber durchs Vorleben, weniger durch 
Diskutieren, weil ich gelernt habe, dass keiner gerne auf die Füsse 
getreten bekommt und es geht auch nur peu a peu voran.

In den harten Fällen, wo man wirklich den Hebel ansetzen müsste und 
nicht drüber hinwegsehen dürfte, ist eh nichts zu machen, weil man 
niemandem im Nachinein eine andere Ausbildung, ein anderes Wissen und 
nicht einmal mehr eine andere Programmier- oder Arbeitstechnik 
beibringen oder auferlegen kann. Man muss dann mit denen klarkommen, die 
man nebenbei hat :-)

Die Kritik setzt weiter vorne an, z.B. bei denjenigen, die immer weniger 
auf Ausbildung schauen, Studienzeiten verkürzen oder "verbatcheln" und 
bei Einstellungen den billigen Jakob bevorzugen.

Ich beziehe mich dabei in jüngster Zeit immer öfters auf Beauftragungen 
an Dienstleister und Drittanbieter, wo man gezwungen ist, den Billigsten 
zu nehmen, der dann seinerseits nur noch leben kann, indem er die 
billigen Quereinsteiger und Anfänger beschäftigt, während andere gut 
ausgebildete Ingenieure und Softwareexperten, (die ich auch zuhauf 
kennengelernt habe) aufgrund ihrer angeblich hohen Gehaltsforderungen 
nichts bekommen und zu ebensolchen Billigtarifen anbieten müssen.

Dies leistet dann somit der allgemeinen Verbilligung Vorschub und es 
lohnt sich immer weniger, eine fundierte Ausbildung anzustreben. Ich 
kenne in der Tat viele sehr gute Entwickler, die sich genau aus diesen 
Gründen aus diesem Bereich abseilen. Qualität ist nicht mehr gefragt in 
diesen Tagen.

Du scheinst ja wirklich etwas "selbstreflektiert" zu sein, wenn Du in 
Betracht ziehst, vorschnell geurteilt haben zu können :-)

Ich halte mich durchaus nicht für omnipotent. Schwächen habe auch ich 
auch genug, aber dort präsentiere ich mich nicht als Experte oder 
Ideengeber und überlasse die Führung anderen. Dies tue ich genau weil 
ich gesehen haben, dass ich mir das eine oder andere zwar locker zutraue 
und auch leisten könnte, aber eben nur "auch" und nicht "en top".

Mithin ist das Beispiel des "Dr." genau das Passende, den ihm oblag die 
Führung und Planung im Projekt, weil man dachte, die Promotion macht es 
schon. Denken können reicht.


Nochmal eines zu den Überfliegern:

Sicher ist es richtig, dass es besser läuft, man von einem homogenen 
Team ausgeht. Das Team muss aber hohes Niveu und nicht Mittelmäßigkeit 
darstellen. Daher halte ich den link von oben für äusserst unstimmig.


> Beim Intelligenzquotienten zum Beispiel wird der Mittelwert als 100 definiert.
> Die große Mehrheit der Menschen weist einen IQ zwischen 85 und 115 auf.
Das sind ALLE Menschen, aber nicht alle Fachkräfte. Bei MINT-Studenten 
finden sich sehr wohl Mittelwerte um die 115 - bei manchen Fachbereichen 
auch noch mehr.

> Genies .. gibt es nur sehr wenige; Experten schätzen den Anteil auf jeweils 
zwischen zwei und fünf Prozent.
5% heisst immerhin jeder 20., also einer pro Schulklasse. In der 
Bevölkerung wären es 400.000 Personen. Das würde ich noch nicht "Genie" 
nennen.

Angeblich sind 2% aller Menschen "Hochbegabt", haben also einen IQ von 
>130. Das klingt schon eher nach Genie, heisst aber auch nur wieder 
"jeder 50te".

Jetzt rechnen wir mal:

Im Moment machen etwa 35% eines Jahrgangs Abitur und von denen schließen 
wiederum 30% ein Studium ab, also 10% der Bevölkerung. Damit wäre jeder 
5. Absolvent "hochbegabt". Bei den MINT dürfte der Anteil noch höher 
liegen, sagen wir 25%? - Da nur die oberen 3/4 der MINT-Absolventen in 
ihrem Job arbeiten, haben rund ein Drittel der Ingenieure einen IQ von 
>130.

Selbst wenn die geschätzten Zahlen nicht 100% stimmen, sollte der wahre 
Anteil nicht weit davon weg liegen. Also nix mit "Mittelmass = gut".

Trotzdem hin ich nach wie vor ein Fan einer umfangreichen und fundierten 
Ausbildung. Das Problem: Wer's nicht hat, kennt es nicht und weiss 
manchmal nicht, was ihm fehlt :-)

Juergen S. schrieb:
> Ich würde gerne die Frage stellen, ob jemand hier in der Hochschule
> gelernt hat, wie man:
>
> - eine pipeline entwirft und dokumentiert
> - serielle ind parallere Strukturen umdesiged
> - die Balance zwischen serial und parallel ermittelt
> - eine Formel so umstellt, dass sie VHDL-tauglich wird
> - einen Algo so zerlegt, dass er parallelisierbar wird

Das gab's bei mir Studium. Technische Informatik an einer TU, mit 
entsprechender Vertiefungsrichtung, noch nicht zu lange her. Aber 
natürlich lässt sich das theoretische Wissen nicht sofort in die Praxis 
übersetzen. Einem Absolventen fehlt einfach die Erfahrung, deswegen ist 
er ja auch günstiger als alte Hasen. Wer aber nach 5 Jahren immer noch 
keine Ahnung hat, muss sich schon fragen lassen, ob er seinen Job 
wirklich gut macht. (Und selbstkritischerweise muss ich auch sagen, dass 
ich mich intensiver mit Methodik und Strukturen beschäftigen könnte - es 
"läuft" halt im derzeitigen Job auch ohne).

> - wann und wie (nicht) einsynchronsiert
> - physische von logischen "sets" und "resets" trennt
> - asynchron rettet und wann man es bleiben lässt

Das wird verschiedentlich in aktuellen Lehrbüchern behandelt.

> - mit FiFos die Verarbeitungszeit komprimiert / dekomprimiert
> - eine Rekursion implementiert
> - synthetisierbarer testcode implementiert und wann
> - testbenches optimieren und automatisieren kann
> - eine Resource in verschiedenen Zeitebenen mehrfach nutzt

Das durfte man sich mit entsprechendem Engagement selbst in Praktika 
beibringen, oder man lernt es auf die harte Tour nach dem ersten 
fehlgeschlagenen Projekt. Es gibt auch ganz hervorragende VHDL-Kurse 
z.B. von Doulos, die gerade auf die Testbench-Geschichten eingehen. Und 
Testbenches stellen bekanntlich 90% des VHDL-Codes.

> - eine Iteration über Zeit-Flächen-Struktur realisiert
Meinst Du Design-Space-Exploration?

> Das alles kommt natürlich erst mit der Erfahrung, aber Digitaldesign im
> eigentlichen Sinne, scheinen die Wenigsten systematisch wirklich erlernt
> zu haben.

Auf jeden Fall muss da viel mehr passieren, vor allem seitdem FPGAs 
omnipräsent sind.

Ras Funk schrieb:
>> - wann und wie (nicht) einsynchronsiert
>> - physische von logischen "sets" und "resets" trennt
>> - asynchron rettet und wann man es bleiben lässt
> Das wird verschiedentlich in aktuellen Lehrbüchern behandelt.
Welche? Beispiele?
Solange da noch jeder Prozess so aufgebaut ist:

1

   if reset='1' then

2

      --

3

   elsif clk'event and clk='1' then

4

      --

5

   end if;

Dann ist da noch nichts von aktuellen FPGAs und deren internen 
Strukturen zu erkennen. Das geht sogar soweit, dass Synthesewerkzeuge 
solche Konstrukte von sich aus (per Schalter) in synchrone Resets 
umwandeln...  :-o

> Und Testbenches stellen bekanntlich 90% des VHDL-Codes.
Diese Zahl und ihre Bekanntheit wage ich anzuzweifeln...

> Und Testbenches stellen bekanntlich 90% des VHDL-Codes.
Wenn ich mir die allgemein gültige falsche Beschreibung eines Taktes 
ansehe, kann das so nicht stimmen. Wofür gibt es eine Funktion 
rising_edge(), die auch den Zustand vor der Pegeländerung 
berücksichtigt, wenn dann der obige Konstrukt mit 'event genommen wird? 
Mit (clk'event and clk='1') wird z.B. die Simulation bei einem Wechsel 
von 'H' nach '1' einen Takt ausführen. Die Hardware aber nicht...
Kurz: die Simulation entspricht nicht der Hardware und ist damit falsch.

Hallo Lothar,

ohne einen Reset-Streit vom Zaun brechen zu wollen ;-) aber Altera 
empfiehlt "synchronized asynchronous resets", und die würden in VHDL so 
aussehen wie Dein Beispiel. clk'event bzw. rising_edge mal aussen vor, 
ebenso low/high Aktivität.

Siehe Seite 21 in
www.altera.com/literature/hb/qts/qts_qii51006.pdf

Wegen der Bücher schau ich heute abend nochmal in meine Bibliothek und 
sage Dir die genauen Titel und was empfohlen wird.

Herzliche Grüße!

Ras Funk schrieb:
> aber Altera empfiehlt "synchronized asynchronous resets",
Und genau DAS und der (mögliche) Unterschied zu anderen FPGA-Herstellern 
wird in keinem der Bücher (soweit mir bekannt) explizit dargestellt...

> aber Altera empfiehlt "synchronized asynchronous resets",
Ja, blöd nur, dass man sich das nicht unbedingt immer merkt und dann 
z.B. sowas schreiben könnte, weil die asynchronen Resets ja so schön 
sind:

1

   if reset='1' or cnt=17 then -- der ultimative Gipfel: ein asynchroner kombinatorischer Reset. Wehe, da kommt ein Glitch!

2

      cnt <= 0;

3

   elsif clk'event and clk='1' then

4

      cnt <= cnt+1;

5

   end if;

Wenn ich mir zudem die Übersicht zur ALM dort ansehe
http://www.altera.com/literature/hb/stratix-v/stx5_51002.pdf
dann erkenne ich nur, dass an den FFs zwar ein CLR angeschlossen ist, 
aber nicht, wie die Verteilung da aussieht, und mit welchem Slack ich 
rechnen muß. In das selbe Horn stossen auch die Altera-Gurus:
http://www.alterauserforums.net/forum/showthread.php?p=3802
http://alteraforum.org/forum/showthread.php?p=16965
Wenn das globale Reset-Netzwerk zu langsam ist, dann geht schon das 
Verlassen des Reset-Zustands schief.

Es ist ganz einfach so, dass der Reset z.B. eines Zählers/einer FSM und 
der Reset eines FPGAs nichts miteinander zu tun haben. Und auch dem 
verlinkten Dokument kann ich keinesfalls entnehmen, dass bei Altera ein 
Zähler asynchron zurückgesetzt werden sollte.
Ein FPGA braucht sowieso keinen Reset. Das hat nach Anlegen der Spannung 
loszulaufen und so lange seine Arbeit zu verrichten, bis die Spannung 
wieder weggenommen wird. Ein Reset kommt in dieser Aufgabenbeschreibung 
nicht vor.

> Wegen der Bücher schau ich heute abend nochmal in meine Bibliothek
> und sage Dir die genauen Titel und was empfohlen wird.
Ich bin gespannt... ;-)

Wenn dabei aber sowas rauskommt, wie in diesem speziell dem Spartan 3 
gewidmeten Buch im Beitrag "Re: Suche VHDL Buch", 
dann dankesehr... :-/

Hallo Lothar,

das Buch, das ich meinte, heisst "Advanced FPGA Design" von Steve Kilts. 
Da werden die Resets genau auseinandergenommen, mit Empfehlungen wie bei 
Altera. Na gut, der Author arbeitet auch bei denen...

Das zweite Buch such ich Dir auch noch raus.

Zum Thema "FPGA braucht kein Reset" - stimmt! Normalerweise braucht man 
das nicht. Sobald man aber mehrere Clock-Domains hat, und einzelne 
Clocks (z.B. zum Stromsparen) an- und abschalten will, dann sind Resets 
doch sehr lohnenswert. (bevor Diskussionen entstehen: ja, clock gating 
natürlich nur über CCB etc.)

Oder auch, wenn das Design später auf Asics laufen soll. Spätestens da 
kommt man um asynchrone Resets nicht herum.

Im Normal- und Regelfall bin ich völlig bei Dir.

Ras Funk schrieb:
> Oder auch, wenn das Design später auf Asics laufen soll. Spätestens da
> kommt man um asynchrone Resets nicht herum.
Zum Glück haben die wenigsten mit ASICs zu tun. Denn dort müsste ich dir 
mit den 90% Simulationsaufwand wieder recht geben.. ;-)

Lothar Miller schrieb:
> Ein FPGA braucht sowieso keinen Reset. Das hat nach Anlegen der Spannung
> loszulaufen und so lange seine Arbeit zu verrichten, bis die Spannung
> wieder weggenommen wird. Ein Reset kommt in dieser Aufgabenbeschreibung
> nicht vor.

Nicht immer von Xilinx auf alle anderen Hersteller schließen. Wenn ich 
zB einen PCI-Core im FPGA habe, wird der PCI-Reset natürlich verwendet. 
Außerdem gibt es auch Synthesewerkzeuge und FPGAs, denen man keinen 
Initialwert für Signale im Code mitgeben kann bei der Signaldefinition, 
die müssen dann quasi sowieso noch in einen definierten Zustand, also 
"resettet" werden.

Torsten M. schrieb:
> wird der PCI-Reset natürlich verwendet.
Latürnich wird er verwendet. Ohne jede Frage...  :-/
Nur: ist er auch nötig und wo ist er sinnvoll?

> Außerdem gibt es auch Synthesewerkzeuge und FPGAs, denen man keinen
> Initialwert für Signale im Code mitgeben kann bei der Signaldefinition,
Die sind aber schon älter oder von Actel...
> die müssen dann quasi sowieso noch in einen definierten Zustand, also
> "resettet" werden.
Auf jeden Fall wird bei jedem SRAM-basierten FPGA (und mittlerweile auch 
den meisten CPLDs) beim Laden jedes Flipflop per Handschlag auf einen 
definierten Wert gesetzt. Und alle aktuellen Synthesizer können diese 
Möglichkeit der Initialisierung verwenden (wenn die Hardware es 
hergibt). Diese Initialisierung ist ganz einfach eine Ressource auf dem 
FPGA wie z.B. ein Multiplizierer oder ein RAM. Und die verwendest du 
doch auch, wenn es dir Vorteile bringt. Oder nicht?

> Nicht immer von Xilinx auf alle anderen Hersteller schließen.
BTW: Lattice kann die Initialisierungswerte jetzt auch, seit sie den 
Synthesizer gewechselt haben.

Lothar Miller schrieb:
> Die sind aber schon älter oder von Actel...

Treffer (Actel) ;-)

Damit erübrigt sich auch die Verwendung von irgendwelchen HW-Einheiten 
(außer BRAMs), weil keine vorhanden sind, außer ein 1kbit User-Flash, 
den ich aber nicht benötige, weil er viel zu klein ist :-(

Wenn nur FPGAs eines einzigen Herstellers eingesetzt werden, ergibt sich 
nicht die Notwendigkeit, herstellerunabhängigen Code zu Schreiben. Was 
nichts daran ändert, dass, bis auf die BRAMs und die oben angesprochenen 
Resets, der von mir "verbrochene" Code auch auf FPGAs anderer Hersteller 
laufen dürfte.

Strukturiertes Design heißt für mich eher, dass man das Design zB in 
kleine, überschaubare Funktionseinheiten aufteilt, diese modular, lesbar 
und verständlich beschreibt und dann in überliegenden Einheiten 
miteinander verbindet. Dass man diese einzelnen Einheiten nach 
Möglichkeit ausgiebig mit jeweils einer eigenen Verifikationsumgebung im 
Simulator testet. Dass man die Einheiten alle mit einem gleichartigem 
Portprotokoll ausstattet, damit man sie schnell und unkompliziert 
zusammenstöpseln kann. Usw. usf ...

Torsten M. schrieb:
> Lothar Miller schrieb:
>> Die sind aber schon älter oder von Actel...
> Treffer (Actel) ;-)
Also Microsemi...
http://www.actel.com/company/acquisition/
Bin gespannt, was daraus noch wird.

Lothar Miller schrieb:
> Also Microsemi...
> http://www.actel.com/company/acquisition/
> Bin gespannt, was daraus noch wird.

Wir hatten letztens einen leitenden Ingenieur von Microsemi da, und was 
er vorgestellt hat, sah sehr vielversprechend aus. Vieles schon als HW 
integriert von dem, womit wir uns heute noch in VHDL und als Softcore 
herumschlagen müssen. Das ging viel weiter, als ich erwartet hatte :-)

Berater schrieb:
> Der Punkt ist nur der, dass man nie weiss, womit man in 3 Jahren
> arbeitet.

Und was, wenn man das schon weiß? Außerdem sind die Teile, die 
herstellerspezifisch sind, größtenteils IP-Cores und so nicht zu ändern, 
weil auf den FPGA angepasst ...

lotte schrieb:
> ich denke, es ist auch nicht die aufgabe der hochschule
Die der Baumschule vielleicht, oder der Fahrschule, oder wie oder was?
> das ist viel zu kompliziert, um es den studenten beizubringen
Ich hoffe zuversichtlich, das war ironisch gemeint!
Allerdings fehlt dann ein Augenzwinkern... :-/

Junge Leute, die voll "im Saft stehen" sollten so was eigentlich 
aufsaugen können wie ein Schwamm. Später im Berufsleben wird so ein 
Lernprozess mindestens um den Faktor 4 verlangsamt, weil man ja noch was 
anderes machen sollte...
Und wenn sie das schon als Student nicht kapieren, dann taugen sie auch 
nicht als Ingenieur (und da können einige wenige Ausnahmen bestenfalls 
die Regel bestätigen).

Was Hänschen nicht lernt, lernt Hans nimmermehr.
Stimmt zwar nicht ganz, aber Hans tut sich recht schwer.