mikrocontroller.net

Forum: FPGA, VHDL & Co. Tools zur FPGA Konzeptionierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde gerne wissen, welche Werkzeuge ihr verwendet um einen Entwurf 
auf einen FPGA zu bringen. Ich meine hier nicht Verilog oder VHDL, 
sondern Werkzeuge in der Entwurfsphase. Wie welche Blöcke miteinander 
verbunden werden, wie das Timing aussehen soll/muss.

* Einfach nur Papier und Bleistift?
* Pure Erfahrung und Inuition!
* Top-Down-Design gleich mit der HDLder Wahl?
* Gleich losfrickeln und dann nachher ordentlich dokumentieren?
* Sowieso weder bezahlbar noch sinnvoll.

Gruß,
Nick

Autor: Bildverarbeiter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das wichtigste Tool ist das Meeting, um abzufragen, was überhaupt 
erzeugt werden soll.

Das zweitwichtigste ist des REQ-tools, um festzuzurren, was gemacht 
werden soll

wenn die zwei Instrumente unzureichend eingesetzt wurden, ist es fast 
wurscht, wie einer später vorgeht - es wird:

Nick M. schrieb:
> * Sowieso weder bezahlbar noch sinnvoll.

Oft ist es daher besser:

Nick M. schrieb:
> * Gleich losfrickeln und dann nachher ordentlich dokumentieren?

... und irgendwie zu schauen, wie man es hinkriegt, dass das eigene 
Vorgehen doch irgendwie in die Prozesse passen

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist wieder so eine "it depends"-Geschichte.
Du muesstest etwas konkreter fragen.
Beispielszenarien:
- DSP-Rechenwerk (die man auch mit HLS abhaken kann)
- Neuartige Logik, eigenentwickelt
- grobe Systemarchitektur, SoC, usw.

Das geht dann von Papier/Bleistift bis zu irgendwelchen 
Rapid-Prototyping-Ansätzen, die hier schon des öfteren durchgekaut 
wurden. Sobald es ins Team geht, lässt sich die Frage schlicht nicht 
mehr generell beantworten. Dito bei grösseren Komplexitäten, da sind die 
Philosophien des Rapid Prototyping arg unterschiedlich. Und die Frage: 
Wer ist der Kunde und was will er.
Also: Worauf zielst du ab?

Autor: NichtWichtig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht könnte Kactus2 helfen.

http://funbase.cs.tut.fi/

Autor: Nick M. (muellernick)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Geh einfach davon aus, dass ich keine Ahnung hab. Was für mich komplex 
ist, ist für dich Kindergarten.
Wenn ich mir Software überleg, dann schnier ich maximal paar grobe 
Skitzen aufs Blatt und mach danach eine Doku. Und die ist dann so, wie 
ich sie zu Anfang im Kopf hatte.
Nur bei Datenbanken mal ich mir ein ERD auf, weils für mich 
übersichtlicher wird.
Also wenig komplexe Aufgabe, nichts sensationelles oder innovatives, ich 
will eher Methoden sehen wie das die Profis machen, machen würden, 
machen sollten oder auch machen müssen.

Und damit für euch die Schreiberei sich in Grenzen hält, genügen mir 
Produktnamen oder Methodennamen. Die kann ich dann schon googeln. ;-)

Edit:
Nein, ich will kein Clickibunti das mir dann aus Kästchen Verilog 
zusammenstöpselt.


Gruß,
Nick

: Bearbeitet durch User
Autor: Bildverarbeiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NichtWichtig schrieb:
> Vielleicht könnte Kactus2 helfen.

Das habe ich schon zweimal runtergeladen und im Abstand von >1 Jahr mal 
ins Laufen zu kriegen, aber nichts wirklich hinbekommen. Entweder zu 
ungebildet, oder das Zeug ist zu kompliziert.

Hat es jemand im Gebrauch?

Autor: Fitzebutze (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bildverarbeiter schrieb:
> Hat es jemand im Gebrauch?

Ich hatte. Es lohnt eigentlich nicht wirklich, wenn man Sachen 
automatisieren will. Der Overhead des IP-XACT-Ansatzes ist beträchtlich. 
Ansich eine schöne Sache, aber auf eine gewisse Art komplett 
over-engineert.
Geht auch in Richtung SoC, also eine Komplexität, ab der es sich 
irgendwann rechnen müsste. Wenn...

Nick M. schrieb:
> Wenn ich mir Software überleg, dann schnier ich maximal paar grobe
> Skitzen aufs Blatt und mach danach eine Doku. Und die ist dann so, wie
> ich sie zu Anfang im Kopf hatte.

Das ist wohl immer noch der beste Ansatz, um etwas darzustellen. Geht 
sogar soweit, dass die Handskizzen vom Kollegen im Handbuch landen.

Zumindest gilt das ab dem Punkt, an dem bereits definiert ist, was das 
Ding machen soll.

Wenn es das noch nicht ist, muss man allenfalls zusammen mit den 
Interface-beteiligten (SW <-> HW) Register, Eigenschaften, usw. 
definieren.
Das machen viele Hersteller ab gestiegener Komplexität in XML, siehe 
auch besagtes IP-XACT. Grosse SoC-Register-Decoder, Headerfiles und Doku 
werden dann per Knopfdruck generiert. Aber ob man's braucht ist eine 
Amortisationsfrage.

Autor: Robert P. (fpgazumspass) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenns hier verpöhnt ist: ich schreibe mittlerweile fast jedes VHDL 
Modul vorher in C#, natürlich im Blick was daraus später werden soll.
Aufwand schätze ich auf 10-20% der Zeit einer VHDL Implementierung.

Die Struktur entspricht dabei weitgehend dem wie ich mir zu dem 
Zeitpunkt(!) die spätere Hardware vorstelle: eine Entity wird zu einer 
Klasse usw.

Sind Konfigurations-Register beteiligt, dann schreibe ich die bereits in 
ein VHDL Package und exportiere sie per Script in eine C# 
Klassenbeschreibung.

Wenn es dann in Software funktioniert kann ich alles relativ komfortabel 
ausprobieren, auch wenn es natürlich langsamer abläuft als im FPGA 
später.

Automatische Regressiontests kommen danach. Die sollen hinterher 
identisch auf der C# Software, in der VHDL Simulation(Modelsim) und auf 
der Zielhardware laufen.
Für mich DER Zentrale Punkt. VHDL Code für den es bereits Tests gibt 
schreibt sich fast von alleine. Man kann sich voll auf die eigentliche 
Arbeit konzentrieren:

Denn jetzt weiß ich bereits was "gerechnet" werden muss und muss mir 
"nur noch" die Struktur in VHDL überlegen: Taktrate, Pipelining, FSMs, 
Blockrams usw.


Ja, für externe Komponenten geht das schlecht.
Ja, man muss dabei immer wieder im Kopf zwischen Hardware und Software 
umdenken.
Ja, es kostet initial mehr.

Hilft mir aber im Endeffekt viel mehr als nur drüber nachdenken oder nur 
auf Papier aufschreiben.
Und wenn ich mir schon Gedanken darüber mache, dann will ich später auch 
dauerhaft was davon haben.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert P. schrieb:
> Auch wenns hier verpöhnt ist: ich schreibe mittlerweile fast jedes VHDL
> Modul vorher in C#, natürlich im Blick was daraus später werden soll.

Ich wuerde empfehlen von C# nach Python zu wechseln. Das hat enorme 
Vorteile, weil man das ganze dann via VUnit super einfach automatisieren 
kann. Ebenso lassen sich fuer meinen Geschmack Python Container leichter 
als C# managen.

Ein kleines Beispiel wie soetwas aussehen kann findest du hier:

https://gitlab.com/Elpra/drever-framework/examples/rgb-swap

: Bearbeitet durch User
Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Ich wuerde empfehlen von C# nach Python zu wechseln. Das hat enorme

Man kann gleich die ganze HDL in Python machen und per MyHDL 
durchsimulieren, und in synthesefähiges VHDL/Verilog ausgeben.
Gibt da auch, neben VUnit für die automatisierten Regresstests ein paar 
nette andere Anwendungen um in HW gegossene Algorithmen gegen die 
Software zu verifizieren, siehe auch 'cocotb'. Auf VHDL-Seite kann man 
das mit GHDL und VHPI machen, in der Verilog-Welt gibt es das 
entsprechende VPI-Interface. Das alles ist aber auch eher wieder was für 
komplexere Projekte, wie Prozessordesigns wo eine Menge Tests 
durchgeführt werden müssen.
Beispielsweise lässt sich so eine Hardware-Implementierung eines Risc-V 
gegen einen (verifizierten) Software-Simulator testen. Mit dem qemu geht 
das recht gut - Opensource ist halt was schönes.

Der Ansatz, früh für jede Funktionalität Testszenarien zu entwickeln, 
zahlt sich spätestens dann aus, wenn Features hinzugebaut werden. Und 
gerade im Zusammenhang mit VUnit lassen sich wunderbare 
CI(Continuous-Integration) Konfigurationen erstellen, die für jeden 'git 
commit' den Regresstest abspulen und man schnell sieht, wo was (von wem) 
kaputtgemacht wurde.

Autor: Elbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fitzebutze schrieb:
> Der Ansatz, früh für jede Funktionalität Testszenarien zu entwickeln,
> zahlt sich spätestens dann aus, wenn Features hinzugebaut werden. Und
> gerade im Zusammenhang mit VUnit lassen sich wunderbare
> CI(Continuous-Integration) Konfigurationen erstellen,

Solche Dinge  sollten einmal hier in das Wiki, als Beispiel für eine 
solide Entwicklung und möglichst für C und VHDL getrennt.

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir machen üblicherweise eine Konzeptionsphase mit Papier und Bleistift 
(bzw. Whiteboard) und literweise Kaffee, die je nach Komplexität 1-2 
Wochen dauert. Danach fangen die ersten Entwickler an, HDL zu schreiben. 
Manchmal schreibt schon jemand während des Konzeptmeetings am Toplevel, 
sobald der sich herauskristallisiert. Nach einigen Jahren 
Berufserfahrung kommen die meisten auf den Trichter, dass es Gold wert 
ist, schon früh ein Simulationsmodell zu haben. Das darf gerne grob und 
unvollständig sein, aber man sieht dann schon in der Anfangsphase, dass 
bestimmte Konzepte nicht umsetzbar oder zu ineffizient/aufwändig/teuer 
sind, bzw. man bekommt Ideen, wie es besser geht. Zudem können die 
Softwareleute ihre Entwicklung gleich von Anfang an gegen das Modell 
testen.
Teilmodelle in einer Nicht-HDL-Sprache (typischerweise Matlab, Python 
oder C++) machen wir nur bei arithmetiklastigen Anwendungen, z.B. 
Signalverarbeitungspipelines. Steuerlogik und Infrastruktur werden 
sofort in SystemVerilog modelliert und verifiziert.
Spezielle Tools während der Konzeption verwenden wir keine. Wir haben 
vor einigen Jahren ein paar Tools mal probeweise verwendet (ich glaube 
auch Kaktus, war aber vor meiner Zeit), aber sie waren allesamt 
ungeeigent, zu umständlich, zu kompliziert zu erlernen oder schlicht zu 
teuer, Das Problem bei den Tools ist, dass man bei der Konzeptionsarbeit 
dem Workflow folgen muss, der vom Tool vorgegeben wird. Und das ist 
üblicherweise nicht der eigene Workflow. Genau wie Lernen findet 
Konzeptionsarbeit im Kopf statt, nicht in einem Werkzeug. Alle 
Hilfsmittel, die über Papier und Bleistift hinausgehen, machen die Sache 
komplizierter. Das ist zumindest die Erfahrung von vielen Kollegen und 
mir. Wir haben noch kein Konzeptionstool gefunden, dsas uns mehr Arbeit 
abnimmt als es zusätzlich erzeugt.

Autor: Nick M. (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Ansatz, früh für jede Funktionalität Testszenarien zu entwickeln,
> zahlt sich spätestens dann aus,

Ah, das klingt ja sehr nach TDD (test driven development).
Der Ansatz ist sehr interessant. Gibt auch ein schönes Buch dazu (Titel 
nicht im Kopf). Allerdings für Software.



Danke,
Nick

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> Teilmodelle in einer Nicht-HDL-Sprache (typischerweise Matlab, Python
> oder C++) machen wir nur bei arithmetiklastigen Anwendungen, z.B.
> Signalverarbeitungspipelines.

Sehe ich genau so. Es muss ja einen Vorteil geben, sich einen 
Zwischenschritt aufzuladen. Bei Strukturen erübrigt sich das meistens.

Vancouver schrieb:
> Hilfsmittel, die über Papier und Bleistift hinausgehen, machen die
> Sache komplizierter.

Ebenso, wobei mein Papier kariert ist und auf den Namen Excel hört.

Autor: Blechbieger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nick M. schrieb:
> Ah, das klingt ja sehr nach TDD (test driven development).
> Der Ansatz ist sehr interessant. Gibt auch ein schönes Buch dazu (Titel
> nicht im Kopf). Allerdings für Software.

Test Driven Development for Embedded C von James W. Greening

Autor: Nick M. (muellernick)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Test Driven Development for Embedded C von James W. Greening

Jep! Danke, genau das meinte ich.


Nick

Autor: Hans Kanns (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> Teilmodelle in einer Nicht-HDL-Sprache

Dies klingt aber eher nach "model based development", oder?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.