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
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
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?
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
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?
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.
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.
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
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.
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.
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.
> 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
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.
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
> Test Driven Development for Embedded C von James W. Greening
Jep! Danke, genau das meinte ich.
Nick
Vancouver schrieb: > Teilmodelle in einer Nicht-HDL-Sprache Dies klingt aber eher nach "model based development", oder?
Vancouver schrieb: > 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. Guter Punkt! Leider sind manche von Schnellbastlern umgeben, die sich beharrlich weigern, mit Modellen zu arbeiten und überhaupt zu simulieren.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.