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?
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.
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.
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
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.
Gibt man mit solchen Vorgaben nicht Knowhow über seine Produkte und deren Möglichkeiten preis?
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?
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!
Angehängte Dateien:
-
vivado.png
79 KB
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.
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.
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.
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.
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)
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.