Hallo, gibt es gute Literatur zum allgemein Entwurf von Hardware(damit ist hier gemeint: ein Problem auf ein FPGA (durch VHDL) zu bringen). Möglichst mit Diskussion von verschiedenen Möglichkeiten zu - Prozess Modelle(wie V-Modell) - Entwurf auf Systemebene Danke
uivhdl schrieb: > - Prozess Modelle(wie V-Modell) Was ist ein V-Modell? Eine Verhaltensbeschreibung? Ein Vorgehensmodell? > ein Problem auf ein FPGA (durch VHDL) zu bringen Also die VHDL-Synthese. Da solltest du dir Bücher von Peter Ashenden ansehen (Designers Guide to VHDL). Und "VHDL-Synthese" auch mal ansehen.
:
Bearbeitet durch Moderator
hmm ok. Die Bücher hab ich schon gesehen. Was ist von "Entwicklung eingebetteter Systeme" zu halten? P.S. gibts auch gute Bücher vom Springer Verlag(oder Springer Vieweg). Da kann ich die Bücher am einfachsten Online ziehen
Lothar M. schrieb: > uivhdl schrieb: >> - Prozess Modelle(wie V-Modell) > Was ist ein V-Modell? Eine Verhaltensbeschreibung? Ein Vorgehensmodell? https://de.wikipedia.org/wiki/V-Modell
> gemeint: ein Problem auf ein FPGA (durch VHDL) zu bringen). Ein FPGA macht schon genug Probleme, da muss man nicht extra noch eins draufbringen ;-). Baul Paumann
V-Gast schrieb: > https://de.wikipedia.org/wiki/V-Modell VHDL spielt da bestenfalls unten im Knick des V eine Rolle. Alles darüber ist zu abstrakt...
Lothar M. schrieb: > V-Gast schrieb: >> https://de.wikipedia.org/wiki/V-Modell > VHDL spielt da bestenfalls unten im Knick des V eine Rolle. Alles > darüber ist zu abstrakt... Hä? Das ist doch schmarn was du sagst... Wenn du einen Hardwareentwurf auf einem FPGA machst: - machst du dann keine Anforderungsanalyse? - machst du dann keine Architektur? (VHDL gibt das doch quasi durch entitys(also abstrakten Entwurf, die Implementierung wird versteckt)vor) - machst du keinen Unit-Test?(perfekt via Testbenches in VHDL möglich!) - machst du dann keinen System-Test? Also ich denke schon das du das machst, wenn ich mir deine Website so anschaue... Man kann natürlich auch hergehen und sagen, ich programmier einfach mal. Allerdings: - wird das dann entweder unwartbar - oder geht in die Hose...
> Man kann natürlich auch hergehen und sagen, ich programmier einfach mal. > Allerdings: > - wird das dann entweder unwartbar > - oder geht in die Hose... Nicht beim Chuck Norris der HDL-Schule. ...(den konnte ich mir jetzt nicht verkneifen).
V-Modell ist schon einer der richtigen Wege. Nur erwarte es nicht so vollautomatisch wie in der Software-Entwicklung. Bei unseren Projekten mit größerer Komplexität werden auch erst mal Papiertiger gestartet. (=Anforderungsanalyse) Dann kann man das in erste Blöcke runterbrechen, woraufhin man danach die Interfaces zusammenstellt (=Architektur-Ebene). Hier wirst du an einigen Stellen merken, dass Erfahrung einen voranbringt bzw. man ohne strauchelt. Ziel ist es erst mal viele Randbedingungen rauszuklopfen. Hängt man an einer Stelle, müssen Teilprobleme auf niedrigerer/tieferer Abstraktion angegangen werden und Erkenntnisse wieder auf Konzeptebene nachgezogen werden. Irgendwann hat man das Problem soweit erfasst, dass man ganz unten anfangen kann den Datenpfad zu designen. Dabei gibt es testbenches für Module (ähnlich Unittest-Ebene) und später abstraktere testbenches für abstraktere Module (die mehrere Submodule zusammenfassen). Das endet in der Simulation des Top-Levels bzw. auf dem realen Test auf dem Board. Man wandert ab dieser Stelle quasi das V-Modell wieder hoch.
uivhdl schrieb: > Wenn du einen Hardwareentwurf auf einem FPGA machst: > - machst du dann keine Anforderungsanalyse? > - machst du dann keine Architektur? > - machst du keinen Unit-Test? > - machst du dann keinen System-Test? Naja, vielleicht doch. Manchmal, automatisch... ;o) Aber dann ist natürlich dieses Modell genauso beliebig skalierbar. Wenn ich einen Prozessor auf dem FPGA designe, dann verwende ich dieses V-Modell. Wenn einer diesen Prozessor zur Steuerung programmiert, dann nimmt er genau dieses V-Modell, allerdings auf einer anderen Abstraktionsebene. Und wenn mir einer ein neues FPGA entwickelt, dann nimmt er ebenfalls dieses V-Modell, nur eben wieder auf einer anderen Abstraktionsebene.
Lothar M. schrieb: > Was ist ein V-Modell? Das haut mich aber jetzt weg, Lothar, dass ausgerechnet der König der FPGA-Entwickler diesen in der Industrie weit verbreiteten Begriff des strukturierten Entwicklungsmodells nicht kennt. :D Naja, kommt halt auch aus der Softwareecke (und deckt das FPGA-Thema auch nicht komplett ab!). Zudem ist es mehr für die Projektsicht relevant und nicht die reine Entwicklungssicht, denn dort werden ja die Entwicklungsebenen mit den Verifikationsebenen und Testebenen korreliert und das ist mehr ein Projektleiter- und QM-Thema.
:
Bearbeitet durch User
uivhdl schrieb: > Hallo, > > gibt es gute Literatur zum allgemein Entwurf von Hardware(damit ist hier > gemeint: ein Problem auf ein FPGA (durch VHDL) zu bringen). > Möglichst mit Diskussion von verschiedenen Möglichkeiten zu > - Prozess Modelle(wie V-Modell) V-Modell ist für Software das nützt dir beim Hardwareentwurf nix. Die Stichworte nach denen du suchst ist design verification und hardware/firmware design. Buchempfehlungen: 978-1-85617-605-7 0-12-751803-7 MfG,
Fpga K. schrieb: > V-Modell ist für Software das nützt dir beim Hardwareentwurf nix. Man kann es sich schon so hinbiegen, dass es passt. Klar stimmen dann die Namen für die Begriffe nicht mehr. Das Wichtigste ist hier wie immer, dass man sich vorher Gedanken zum Design macht... ;-)
Es ging mir eigentlich auch nicht um die Diskussion ob das V-Modell sinnvoll ist oder nicht ;)(meine Meinung: kann man, wenn auch etwas skaliert bzw. abgeändert) immer verwenden! Ausser vielleicht bei XP, aber das macht bei festen requirements eh keinen sinn.) Es ging mir eher darum: - V-Modell skaliert auf Hardwaredesign via HDL auf einem FPGA(was sind logische, gute Schritte) - Vorgehen auf System-Ebene - Vorgehen auf Architektur-Ebene
Lothar M. schrieb: > Fpga K. schrieb: >> V-Modell ist für Software das nützt dir beim Hardwareentwurf nix. > Man kann es sich schon so hinbiegen, dass es passt. Klar stimmen dann > die Namen für die Begriffe nicht mehr. Das Wichtigste ist hier wie > immer, dass man sich vorher Gedanken zum Design macht... ;-) Für Hardwareentwurf orientiert man sich besser am y-Chart nach Gajsky als am Wasserfallmodell der Softwerker: http://www.eetimes.com/document.asp?doc_id=1277691 Hardware hat den Vorteil das top-down und struktur physikalisch vorhanden und begreifbar sind: Gerät -> Platine -> FPGA da muss man keine Hierarchie (design -patterns|units|application|system dazudefinieren auch die Entwurfschritte (Planung|Konstruktionsunterlagen (Zeichnung)| Prototyp| Prüffeld|Serienüberleitung) sind seit beginn des Inginieurszeitalters gut etabliert. Software musste erst das Rad für sich selbst neu erfinden, in der Geräteentwicklung läuft es schon seit Erfindung der Dampfmaschine. uivhdl schrieb: > - Vorgehen auf System-Ebene > - Vorgehen auf Architektur-Ebene Das läuft unter Computerarchitektur, schau mal bei den Klassikern: Hennesy und Patterson http://www.amazon.de/Rechnerorganisation-entwurf-Arndt-Bode/dp/3827415950 Andrew s. Tanebaum http://www.amazon.de/Computerarchitektur-Strukturen-Grundlagen-Andrew-Tanenbaum/dp/3827371511 Prozessorentwurf ist auch ein passendes Stichwort, da sind mir aber keine empfehlsenwerte Bücher bekannt. MfG,
Fpga K. schrieb: > V-Modell ist für Software das nützt dir beim Hardwareentwurf nix. Da das Thema ja in der Rubrik "FPGA" erstellt wurde, unterstelle ich mal, dass FPGA-Entwürfe gemeint waren und die sind oftmals äusserst Software-lastig. Daher passt das schon. Nicht wenige Firmen lassen FPGAs unter dem Softwareschirm entwicklen und nutzen das V-Modell- z.B. in der MED. Aber wie schon gesagt: Da fehlt halt immer noch die Hälfte! Siehe auch hier: Beitrag "Re: Grundsatzfrage zu neuen Designstrategien (SoC/VHDL)"
Was bei uns in der Gruppe(Studienprojekte) sehr gut funktioniert hat, ist die Scrum - Methode. Viele FPGA-Projekte sind dafür auch sehr gut geeignet, da sie sich in viel kleine Arbeitspakete teilen lassen, die dann in den einzelnen Sprints abgearbeitet werden können. Diese Methode gehört jedoch zu den "agilen" Entwicklungsmethoden und steht damit etwas im Gegesatz zu anderen Vorgehensmodellen, wie dem V- oder Wasserfall-Modell. Gut dargestellt ist das ganze im Buch: Softwareentwicklung von Kopf bis Fuß By Dan Pilone, Russ Miles Deutsche Übersetzung von Jörg Beyer, Lars Schulten 1. Auflage Juli 2008 ISBN 978-3-89721-862-8 Jedoch geht es hier hauptsächlich um Softwareentwicklung, wobei sich relativ viel davon auf die digitale Hardwareentwicklung übertragen lässt.
ET'ler schrieb: > Was bei uns in der Gruppe(Studienprojekte) sehr gut funktioniert hat, > ist die Scrum - Methode. Viele FPGA-Projekte sind dafür auch sehr gut > geeignet, da sie sich in viel kleine Arbeitspakete teilen lassen, die > dann in den einzelnen Sprints abgearbeitet werden können. Bekanntlich lässt sich ja alles teilen ausser Primzahlen. Probleme in handlich/beherrschbare Pakete teilen kannten schon die Römer: "Divide et impera" Insofern ist Scrum nichts neues und so unstrukturiert wie hier beschrieben unbrauchbar für den modularen HW entwurf. Die Kunst ist es Schnittstellen resp. Busse/Protokolle zu definieren mittels derer getrennt entwickelte Module zusammenpassen. Wenn man das nicht kann ist jeder Sprint nutzlos. > Jedoch geht es hier hauptsächlich um Softwareentwicklung, wobei sich > relativ viel davon auf die digitale Hardwareentwicklung übertragen > lässt. Scrum ist eine Team-Organisationsform. Damit übertragt man kein KnowHow sondern zwingt anderen Fachgebieten nur ein Korsett auf. Kann Gut sein, muss aber nicht. MfG, PS: https://www.scrumalliance.org/community/articles/2011/march/why-agile-does-matter-in-an-embedded-development-e
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.