Ich habe im Rahmen eines Kundenprojektes einige FPGA-Designs, die von
Zulieferern entworfen wurden, in ein System zu überführen und wir (der
Kunde und Ich, sowie die Entwickler) fragen uns, ob man das auf dem
Stand belassen kann und mit welcher Methodik man arbeiten sollte.
Die Projekte sind für sich gesehen eigentlich eher geringer Komplexität,
aber mit ziemlichem Umfang und wurden von Studenten, normalen
Entwicklern und externen Dienstleistern produziert und für Prototypen
gemacht, die auch überwiegend funktionieren und nun in Serienprodukte
einfließen sollen.
Die betreffende Abteilung wird aber zum 30.6. augelöst und
umstrukturiert daher werden die Projekte an einen anderen Standort
verschoben. Diese Aufage ist nun bei meinem Kunden "aufgeschlagen", wie
er es nennt und man hat eine Anzahl unterschiedlicher Beschreibungen mit
unterschiedlichen Strategien zusammenzubringen, wofür man mich als
Selbständigen mit ins Boot geholt hat. Wie üblich haben die lieben
Zulieferer so gut wie nichts an Doku gemacht, weswegen mein Kunden nun
ein wenig "aufgeschmissen" ist!
Ich habe mir nun (zum wiederholten male) die Methodik des Blockdesigns
"reingezogen" und musste feststellten, dass man da zwar sehr schnell was
zusammemklicken kann, aber dann immer wieder mit Macken und Defiziten
des Systems zu kämpfen hat, die mehr Zeit kosten, als sie sparen.
Daher meine Frage an die Erfahrenen:
Blockdesign als Management für FPGA-Projekte benutzten, Ja oder Nein?
Ich selber plädiere sehr für glattes VHDL, weil ich es so gelernt habe,
nicht so arg viel mit FPGAs mache und das ganze mehr aus der
Projektleitersicht sehe, da dies auch meine Rolle im Projekt ist.
A.X. schrieb:> Blockdesign als Management für FPGA-Projekte benutzten, Ja oder Nein?
Nein.
Ist letztlich für die Tonne, spätestens wenns auf ein neues FPGA oder
gar einen anderen Hersteller geht.
> Ist letztlich für die Tonne, spätestens wenns auf ein neues FPGA oder> gar einen anderen Hersteller geht.
Nicht erst dann. Es reicht schon irgendwas an den Ports oder
Wesentliches an der Funktion zu ändern und man muss den Block neu bauen.
Leider erweist sich der alte als Datenmüll, weil das eigentlich mögliche
update nicht funktioniert. Da ging schon mal wesentlich flüssiger zu
ISE-Zeiten. Das Ärgerliche ist, daß das Blockdesign als Grafik das, was
es dem Text vorraus hat, nämlich eine Farbgebung nicht leistet, weil es
die Farben wieder vergisst, wie auch schon bei ISE.
> Ich selber plädiere sehr für glattes VHDL, weil ich es so gelernt habe
Ich habe es nicht so gelernt, plädiere aber trotzdem dafür, weil nach
all meinen Erfahrungen in all den Jahren das zutrifft, was Du ja selber
schon hast anklingen lassen (Macken und Defizite).
Außerdem sehe ich, daß manche Entwickler, die mit dem Gemale arbeiten,
dazu neigen, sich doku zu sparen, weil sie argumentieren, dass die Doku
mit der Zeichnung ja schon da sei (was sie definitiv nicht ist).
Jürgen S. schrieb:> Außerdem sehe ich, daß manche Entwickler, die mit dem Gemale arbeiten,> dazu neigen, sich doku zu sparen, weil sie argumentieren, dass die Doku> mit der Zeichnung ja schon da sei (was sie definitiv nicht ist).
Als Doku sind die Dinger wirklich so unübersichtlich, da gebe ich recht.
Ich finde dieses Designs, jedoch trotzdem erstaunlich gut für einen
schnellen Prototypenentwurf auf Busebene. Das ganze Handling mit den
Bussen, Bridgen und Standard-IPs (Datamover, FIFO, Reset,..) entspannt
sich sehr.
Nachteilig finde ich das Handling von BD mit svn.
Nase schrieb:> A.X. schrieb:>> Blockdesign als Management für FPGA-Projekte benutzten, Ja oder Nein?> Nein.> Ist letztlich für die Tonne, spätestens wenns auf ein neues FPGA oder> gar einen anderen Hersteller geht.
Ach das Argument gibt's immer. Am Ende schrenkt man sich zu sehr ein.
Einen FIFO tausch ich auch aus. Ohne einen FIFO kommen die krudesten
Entwürfe raus. Sicher für Leute die zwischen ASIC und FPGA hin- und
herspringen ist das Blockdesign wegen der Portierung nichts.
Das Block-IP Zeugs nutzen wir nur soweit wie nötig. AXI-Verdrahtung und
Busse aber dann rasch in einen VHDL Wrapper, um es mit funktionsfähigen
Simulatoren nutzen zu können, und nicht auf Wivado angewiesen zu sein.
Nur so ist man auch davor gefeit, ständig neue Designs bauen zu müssen,
weil sich irgendwo was ändert.
Und alles, was nicht von Vivado erzeugt werden muss, wird manuell in
VHDL gemacht.
Portverwaltung kann Mentor HDL-Designer besser.
> Die betreffende Abteilung wird aber zum 30.6. augelöst und> umstrukturiert daher werden die Projekte an einen anderen Standort> verschoben. Diese Aufage ist nun bei meinem Kunden "aufgeschlagen", wie> er es nennt und man hat eine Anzahl unterschiedlicher Beschreibungen mit> unterschiedlichen Strategien zusammenzubringen, wofür man mich als> Selbständigen mit ins Boot geholt hat. Wie üblich haben die lieben> Zulieferer so gut wie nichts an Doku gemacht, weswegen mein Kunden nun> ein wenig "aufgeschmissen" ist!
Als Info. Ich habe mit Doxygen mir einen Überblick in fremde Designs
verschafft, so als Schnellschuß. Damit erhält man ein
Bockschaltbildstruktur. Damit kann man nicht arbeiten, nur für
Dokumentationszwecke geeignet aber mächtig wenn man es durchzieht.
> Die Projekte sind für sich gesehen eigentlich eher geringer Komplexität,> aber mit ziemlichem Umfang und wurden von Studenten, normalen> Entwicklern und externen Dienstleistern produziert und für Prototypen> gemacht, die auch überwiegend funktionieren und nun in Serienprodukte> einfließen sollen.
Ich kann nur sagen Simulation ist sehr wichtig in VHDL. Und diese sollte
man mit Einzelkomponenten und auch mit dem Gesamtpaket machen. Die
Warnungen sollte man auch mal durchschauen, da schlägt auch immer mal
was wichtiges mit auf.
Ich habe mir nun (zum wiederholten male) die Methodik des Blockdesigns
"reingezogen" und musste feststellten, dass man da zwar sehr schnell was
zusammemklicken kann, aber dann immer wieder mit Macken und Defiziten
des Systems zu kämpfen hat, die mehr Zeit kosten, als sie sparen.
Ich habe mit Record gut Erfahrung gemacht. Ein Record für Input und ein
Record für Output. Das sind nur zwei Zeilen und du bist genauso schnell.