FPGA Grundlagen : Lattice Diamond Schematic

chris schrieb:
> Der Diamond Schematic Editor scheint mir extrem unausgereift zu sein.
Für diesen Editor gilt dann eben auch das im 
Beitrag "Re: kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)" 
Geschriebene.
Oder andersrum: warum proprietäre Zeichenprogramme, wenn man VHDL kann?

chris schrieb:
> Weiß jemand, ob die graphischen Editoren bei Altera oder Xilinx besser
> sind?
Die Frage ist, ob sie so gut sind, dass man sie verwenden kann. Einen 
Teil der Antwort findest du im verlinkten Thread.

Ich würde in allen Fällen VHDL bevorzugen.

Lothar M. schrieb:
> Die Frage ist, ob sie so gut sind, dass man sie verwenden kann. Einen
> Teil der Antwort findest du im verlinkten Thread.

Was dort fehlt, ist der Hinweis auf die nicht vorhandene Fähigkeit, 
sinnvoll mit einer Versionsverwaltung (VCS) zusammenzuarbeiten.

Selbst wenn mal alle anderen Macken ausgemerzt sein sollten (sehr 
unwahrscheinlich) - das ist nicht hinzubekommen. Und für mich eine 
Grundvoraussetzung für irgendeine Art von vernünftiger 
Softwareentwicklung.

Moin,

einigermassen brauchbar und wiederverwertbar (!) ist der kactus2-Ansatz. 
Aber um von da wieder zur VHDL-Netzliste für sein Lieblingstool zu 
gelangen, ist etwas Aufwand nötig.
Ich bin mal noch den Weg gegangen: VHDL->XML->Kicad schematic symbol. 
Aber da muss man sich mit XSLT gehörig beschäftigen, das ist eher 'fun 
stuff' als früh amortisierend.
Der XSLT-Prozessor macht aus dem 'XHDL' eine Grafik und einen DRC, siehe 
auch hier: https://section5.ch/dclib/xhdl/. Die einzelnen Module muss 
man dann manuell im Schaltplaneditor verkabeln.
Auch hier ist wieder etwas Aufwand für Netzliste->HDL nötig.

Von allen rein grafischen Ansätzen kann man aber eigentlich in Bezug auf 
Nachhaltigkeit&Teamwork nur abraten, sofern nicht irgend ein 
'diff'-bares Format zugrunde liegt, was sich vernünftig per 
Revisionskontrolle verwalten lässt.

Markus F. schrieb:
> Was dort fehlt, ist der Hinweis auf die nicht vorhandene Fähigkeit,
> sinnvoll mit einer Versionsverwaltung (VCS) zusammenzuarbeiten.
Ich hoffe, das ist jedem klar.

> sofern nicht irgend ein 'diff'-bares Format zugrunde liegt
Und natürlich fehlt auch der Hinweis, dass (auch wenn das 
"Schaltplan-Format" eine les- und versionierbare Textdatei wäre) sich 
der interne Aufbau eines Schaltplans mit jeder Version des 
Zeichenprogramms unangekündigt ändern oder auch komplett umgestellt 
werden kann.

Und spätestens, wenn man ein Design auf zwei Plattformen laufen hat, ist 
mit "Vergleichen von Schaltplänen" absolut Schluss.

chris schrieb:
> Der Schaltplaneditor in Quartus von Altera scheint tatsächlich deutlich
> ausgereifter als der von Lattice Diamond.
Ja, dann musst du jetzt einfach die Lattice-Pläne mit dem Altera-Tool 
zeichnen...  ;-)

Lothar M. schrieb:
> Und natürlich fehlt auch der Hinweis, dass (auch wenn das
> "Schaltplan-Format" eine les- und versionierbare Textdatei wäre) sich
> der interne Aufbau eines Schaltplans mit jeder Version des
> Zeichenprogramms unangekündigt ändern oder auch komplett umgestellt
> werden kann.

Oder das Programm die Entities bei jedem Abspeichern beliebig 
umsortiert...dann ist ein diff völlig unbrauchbar, wie bei 
EDIF-Netzlisten.

>
> Und spätestens, wenn man ein Design auf zwei Plattformen laufen hat, ist
> mit "Vergleichen von Schaltplänen" absolut Schluss.

Naja, das könnte man mit etwas Disziplin noch hinkriegen.
Z.B. ein generisches PLL-Modul basteln, was in den Innereien die 
arch-spezifischen Sachen verarztet.
Und fürs Top-Level-Design macht der Revisions-Server ein diff-pdf.

Es gäbe schon eine Rechtfertigung für grafische Eingabe, wenn:

- Das Quellformat eine sauber sortierte HDL ist
- man sich ausschliesslich auf standardisierte 
Interfaces/pipelines/Busse im Toplevel oder einem Framework beschränkt

Bisher habe ich sowas bei den $-$$ Vendor-Tools nicht wahrgenommen. Qsys 
und Derivate machen teils eine heillose Sauerei...

chris schrieb:
> Gerade mal kurz probiert:
> Der Schaltplaneditor in Quartus von Altera scheint tatsächlich deutlich
> ausgereifter als der von Lattice Diamond.

Letztendlich ist aber auch der weit entfernt von perfekt.

Schau' mal in das .bdf-Format rein (ja, das ist ASCII).

Ich betrachte schon das Format als Murks.

Nach meiner Interprätation steht da noch nicht mal drin, dass "A" mit 
"B" verbunden ist, sondern die Information ist in der Tatsache 
versteckt, dass beide Signale an der selben Bildschirmkoordinate enden. 
Das bedeutet 1., dass sich beim Verschieben eines Elementes alles 
mögliche ändert, obwohl es noch dieselbe Schaltung ist, und 2., dass je 
nach Zoomstufe ein simples "Verzittern" mit der Maus plötzlich Mist 
produziert, der noch nicht mal gleich sichtbar wird.

Vielleicht ganz nett, um eben schnell was auszuprobieren (aber das geht 
mit VHDL genausoschnell, wenn man einigermassen tippen kann), aber sonst 
zu nix zu gebrauchen.

Das Einzige, was ich anfangs tatsächlich per Schematic gemacht habe, war 
die Verdrahtung der Module. Daraus wurde dann VHDL erzeugt und das dann 
weitergepflegt.
Irgendwann war mir das Gehampel mit dem Schaltplaneditor aber zu blöd 
und ich bin komplett auf direkten Quelltext umgestiegen. Und jetzt sind 
sogar die Verdrahtungslisten leserlich und übersichtlich (weil nicht 
jedes einzelne Signal eines 32 Bit Vektor mitsamt Index in einer eigenen 
Zeile aufgeführt wird).

chris schrieb:
> Soll man sonst jedesmal die Portlisten kopieren und
> in "components" umwandeln,

Suche: "{entity|direct} instantiation".

chris schrieb:
> Da kann man schön Retrocomputing betreiben.
Ja, so mit lokalen getakteten Takten und ebensolchen lokalen asynchronen 
kombinatorischen Resets. So wie man das damals halt auch hingeklatscht 
hat.
Allerdings ist ein FPGA da die vollkommen falsche Zielarchitektur....