Forum: FPGA, VHDL & Co. PCB templates für FPGA selber erstellen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hans Kanns (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Beim Lesen des Themas rund um die PCB-Auswahl beim großen X, das 
parallel erörtert wird, kam mir gerade ein Gedanke:

Macht es Sinn, selbst erstellte PCBs ein solches template zu erstellen, 
um es in Folgeprojekten sozusagen als Test-System verwenden zu können?

Wie groß ist der Aufwand, um sagen wir ein System zu beschreiben, das 
aus 2 unterschiedlichen base baords und 4 Karten besteht?

Unsere Kundenplattformen können in einer kleinen und großen Version (und 
demnächst in einer ganz grossen) bestellt und bestückt werden. Die 
Plattformen haben Steckplätze für bis zu 8 Karten. Wir würden gerne dem 
Kunden ein System an die Hand geben, womit er sich seine eigenen 
Plattformen bauen und umbauen kann, z.B.

2 Karten TYP A Eingang
2 Karten TYP B Eingang
2 Karten TYP X Ausgang

Schon jemals einer gemacht?

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hans Kanns schrieb:
> womit er sich seine eigenen
> Plattformen bauen und umbauen kann, z.B.
>
> 2 Karten TYP A Eingang
> 2 Karten TYP B Eingang
> 2 Karten TYP X Ausgang
>
> Schon jemals einer gemacht?
Ja.

Wenn man FMC nimmt, findet man gleich ein paar passende Karten.

Irgendwann kommt dann die Frage nach dem Gehäuse auf und man landet 
schnell bei Sonderlocken.

von Hans Kanns (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Wenn man FMC nimmt, findet man gleich ein paar passende Karten.

Wir haben eigene Karten und Stecker, die keinem besonderen offiziellen 
Standard entsprechen. Das wird auch so bleiben. Die Karten werden in 
sicherheitskritischen Bereichen eingesetzt und sind was die 
Signalführung anbelangt, entsprechend gestaltet.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dann verstehe ich den Sinn Deiner Frage nicht.
Ich habe auch schon mit proprietären FPGA-Boards mit diversen ADC- bzw. 
DAC-Erweiterungskarten gearbeitet.

Wenn der Bedarf da und der Aufwand gerechtfertigt ist, gibt es keinen 
Grnud es nicht zu tun. Erfahrungsgemäß hält sich dann die Auswahl an 
Erweiterungskarten in Grenzen, es ist aber ein gutes Gefühl zu wissen, 
das man mit geringem Aufwang für neue Anforderungen gerüstet ist.
Bis zu dem Punkt, wo das Gesamtsystem die Grenzen setzt (max. Datenrate, 
max. IO-Zahl, FPGA-Fabric, Formfaktor, etc.)

Duke

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hans Kanns schrieb:
> Beim Lesen des Themas rund um die PCB-Auswahl beim großen X, das
> parallel erörtert wird, kam mir gerade ein Gedanke:
>
> Macht es Sinn, selbst erstellte PCBs ein solches template zu erstellen,
> um es in Folgeprojekten sozusagen als Test-System verwenden zu können?

Ich glaube der TO redet hier von board Templates, damit in Vivado beim 
erstellen eines neuen Projekts gleich ein board anstatt nur der FPGA typ 
ausgewählt werden kann.

Ja, so wie ich das verstanden habe, kann man diese Templates auch selber 
schreiben und an seine Kunden ausliefern. Für das MicroZed Board muss 
man die z. B. selber herunterladen und in den passenden Ordner kopieren.

von Signalverarbeiter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gibt man mit solchen Vorgaben nicht Knowhow über seine Produkte und 
deren Möglichkeiten preis?

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das sog. "board centric"-Entwicklungsmodell von Vivado ist in der Tat 
für genau solche Zwecke gedacht und für einen Anwender auch sehr 
komfortabel.

Leider gibt es aber von Xilinx keine brauchbaren Werkzeuge, um solche 
Konfigurationen zu erstellen. Stattdessen bastelt man händisch an ein 
paar XML-Dateien (board.xml, part0_pins.xml, preset.xml) herum und 
vergibt dort numerische Indices, usw.. Wenn sich dort ein Fehler 
einschleicht, wird es ganz schnell ziemlich übel, diesen zu finden. 
Außerdem eignet sich dieser Ansatz nur für eine einstufige Übersetzung 
von FPGA-Pins zu Gerätesignalen, d.h. es ist nicht möglich, Adapter oder 
weitergereichte Pins darzustellen.

Anbieter wie Trenz bieten auch Beispielprojekte auf Basis von derer 
recht proprietärer, aber sehr leistungsfähiger Buildumgebung an, die 
auch auf solchen Boardbeschreibungen basiert, z.B. für das TE0725:

https://shop.trenz-electronic.de/de/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/3.5x7.3/TE0725/Reference_Design/2018.2/test_board

Ich habe keine Ahnung, ob die sich einen eigenen Konfigurator gebastelt 
haben, der die o.a. XML-Dateien erzeugt. Man beachte, dass schon die 
Umsetzung vom FPGA auf das TE0725 die Boardbeschreibung "verbraucht" 
hat. Eigentlich würde man an dieser Stelle ja erst weitermachen wollen, 
und zwar mit der Signalumsetzung zwischen den Steckverbindern des 
FPGA-Moduls und der eigenen Elektronik. Und wenn es, wie beim TE, dann 
nochmals Aufsteckboards geben sollte, hätte man noch eine weitere 
Übersetzungsstufe.

Oder war ich nur zu blöd/faul, bei Xilinx das richtige Programm bzw. 
Funktionalität von Vivado zu finden?

von Hans Kanns (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Wenn der Bedarf da und der Aufwand gerechtfertigt ist, gibt es keinen
> Grnud es nicht zu tun.
Das ist eben die Frage. Mit welchen Aufwänden muss man da rechnen?

Christophz schrieb:
> Ich glaube der TO redet hier von board Templates, damit in Vivado beim
> erstellen eines neuen Projekts gleich ein board anstatt nur der FPGA typ
> ausgewählt werden kann.
Richtig, exakt dies war gemeint. Ich habe mich durch einige dieser 
Einführungsplattformen hindurchgeklickt und finde es spannend, auf diese 
Weise ein ganzes Paket an Infos zur Verfügung zu haben.

Andreas S. schrieb:
> Leider gibt es aber von Xilinx keine brauchbaren Werkzeuge, um solche
> Konfigurationen zu erstellen. Stattdessen bastelt man händisch an ein
> paar XML-Dateien (board.xml, part0_pins.xml, preset.xml) herum und
> vergibt dort numerische Indices, usw.. Wenn sich dort ein Fehler
> einschleicht, wird es ganz schnell ziemlich übel,
Das klingt mir jetzt nicht so berauschend!

Eine Dokumentation müsste es schon geben.

Wenn ich unseren Altherren so einen Vorschlag bringe und auf Erhören 
hoffe, dann erwarten die einen sicher betretbaren und begehbaren 
Designprozess, inklusive der Sicherstellung der Machbarkeit durch 
interne Entwickler. das heisst, alles, was gebraucht wird, muss 
erlernbar und reproduzierbar sein. Die Methodik wäre dann in eine 
Standardprozedur zu gießen und niederzulegen.

Dünne Doku ist da ein Totargument!

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Außerdem eignet sich dieser Ansatz nur für eine einstufige Übersetzung
> von FPGA-Pins zu Gerätesignalen, d.h. es ist nicht möglich, Adapter oder
> weitergereichte Pins darzustellen.

Zumindest fuer die FMC Schnitttellen gibt es da schon was Fertiges zur 
Auswahl, evtl. lassen sich auch andere Schnittstellen definieren.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hans Kanns schrieb:
> Richtig, exakt dies war gemeint. Ich habe mich durch einige dieser
> Einführungsplattformen hindurchgeklickt und finde es spannend, auf diese
> Weise ein ganzes Paket an Infos zur Verfügung zu haben.

Ja, wenn solche Board-Definitionen gut gemacht sind, freut sich der 
Anwender. Aber das bedeutet ggf. einen Haufen Arbeit für denjenigen, der 
solche Definitionen erstellen muss, insbesondere wenn hierbei 
verschiedene Konfigurationen unterstützt werden sollen.

> Eine Dokumentation müsste es schon geben.

Die Dokumentation befindet sich in UG895.

> Wenn ich unseren Altherren so einen Vorschlag bringe und auf Erhören
> hoffe, dann erwarten die einen sicher betretbaren und begehbaren
> Designprozess, inklusive der Sicherstellung der Machbarkeit durch
> interne Entwickler. das heisst, alles, was gebraucht wird, muss
> erlernbar und reproduzierbar sein. Die Methodik wäre dann in eine
> Standardprozedur zu gießen und niederzulegen.
>
> Dünne Doku ist da ein Totargument!

Und diese "Altherren" haben mit ihrer Sichtweise nicht ganz unrecht.

Meine Kritikpunkte sind:
- keine mehrstufigen Signaluebersetzungen moeglich
- sehr fehlertraechtiger Entwurfsprozess
- Board-Verbindungen sind nicht vollstaendig im Blockdesign sichtbar

Board-Definitionen muessen in Vivado "installiert" werden, wofür auf dem 
Entwicklungsrechner Administratorrechte benötigt werden. Dies kann auf 
zentral administrierten Rechnern eine massive Spaßbremse sein, denn das 
bedeutet im schlimmsten Fall, dass man für jede Änderung an den 
Board-Definitionen einen Änderungsantrag beim IT-Support einreichen 
muss.

Alternativ kann ein Systemverwalter die zur Vivado-Installation 
gehörende Vivado_init.tcl anpassen und dort mittels "set_param 
board.repoPaths" zulassen, dass auch Pfade im Arbeitsbereich des 
Benutzers zugelassen werden. Dies kann wiederum von der 
IT-Sicherheitsabteilung beanstandet werden. Und wenn die 
Softwareverteilung in dem Unternehmen nur durch entsprechende zentrale 
Werkzeuge erfolgt, die keine rechnerspezifischen Anpassungen zulassen, 
dann fällt das auch flach.

Als letzter Ausweg bliebe noch, bei jedem Start von Vivado erst einmal 
selbst händisch "board.repoPaths" zu verbiegen. Hmm.

von Signalverarbeiter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Board-Definitionen muessen in Vivado "installiert" werden, wofür auf dem
> Entwicklungsrechner Administratorrechte benötigt werden.
Das wundert mich nicht. Die Firma Xilinx nimmt generell wenig Rücksicht 
auf die Belange der IT-Sicherheit und konzeptioniert, was Zugriffe auf 
Platte und Verzeichnisse angeht, ihre Software immer noch wie in den 
90ern, als unter Win98 überall hingeschrieben werden durfte, wo der user 
wollte.

Andreas S. schrieb:
> Das sog. "board centric"-Entwicklungsmodell von Vivado ist in der Tat
> für genau solche Zwecke gedacht und für einen Anwender auch sehr
> komfortabel.
Warum macht man es nicht einfach modular, dass jedes board einen Satz an 
TCL-Befehlen mitbringt, mit dem die Einstellungen so gesetzt werden 
können, wie es nötig ist. Das muss nicht installiert werden, ist 
durchsichtig und beliebig ausbaubar.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Signalverarbeiter schrieb:
> Warum macht man es nicht einfach modular, dass jedes board einen Satz an
> TCL-Befehlen mitbringt, mit dem die Einstellungen so gesetzt werden
> können, wie es nötig ist. Das muss nicht installiert werden, ist
> durchsichtig und beliebig ausbaubar.

Es steht doch jedem frei, genau so vorzugehen.

Aber gibt es einen Xilinx-konformen Weg, mittels TCL ein hübsches 
Fenster mit entsprechenden Auswahlmöglichkeiten und Produktfoto 
darzustellen?

Das "board centric"-Entwicklungsmodell ist meines Erachtens 
hauptsächlich für schicke Präsentationen und den allerersten Einstieg 
auf Basis eine Entwicklungsboards geeignet. Das sind aber genau die 
beiden Wege, um Neukunden zu gewinnen. Der Vertriebler führt in einer 
Präsentation vor, wie einfach es doch sei, ein Projekt auf einer 
"komplett neuen" Hardware anzulegen.

Und der Entwickler, der anschließend seinen Senf dazu abgeben soll, 
bekommt von dem Vertriebler zufällig eines der Boards in die Hand 
gedrückt, die schon durch das Entwicklungsmodell unterstützt werden. 
Damit kann er dann sehr schnell bestätigen, dass das ganze wirklich so 
einfach sei wie behauptet.

Zu dem Zeitpunkt, an dem er dann eine Unterstützung für die eigene 
Hardware anlegen bzw. implementieren muss, ist die Entscheidung 
zugunsten Xilinx schon längst gefällt worden. Dann wird er eventuell die 
Pille schlucken oder zu einem konventionellen Entwicklungsmodell 
zurückkehren.

Fazit:
Das "board centric"-Entwicklungsmodell taugt als Marketinginstrument und 
Schnelleinstieg, aber nicht für den Dauergebrauch. Für einen 
Boardhersteller wie Digilent, Avnet, Trenz o.ä. kann es jedoch 
hochgradig wichtig sein, entsprechende Board-Definitionen 
bereitzustellen, um damit Vivado-Einsteiger bei Null abzuholen und sehr 
schnell Anfangserfolge zu erzielen.

von Signalverarbeiter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> zufällig eines der Boards in die Hand
> gedrückt, die schon durch das Entwicklungsmodell unterstützt werden.

Kann man Xilinx eigentlich beauftragen, für eigene Systeme so etws 
anzubieten?

Ich meine, vlt. haben sie da tatsächlich eine Software, die das 
automatisch packagen kann. (Wahrscheinlich macht es aber irgend ein 
9$-Inder aus Banaglore im Auftrag)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.