Vorgehen zum Hardware entwurf

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

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...

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:
> 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,

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,

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