Hat hier schon mal jemand mit den Gatemates von CologneChip gespielt? Taugt Yosys etwas, bevorzugt im Zusammenspiel mit Modelsim/Questasim auf der snthetisierten Seite und VHDL als Quelle? Den thread, den Antti vor einem guten Jahr aufgemacht hat, den habe ich gesehen. Ich habe jetzt kein konkretes Projekt dafür, eher "Eigenforschung zur Sicherung des technisch-wissenschatlichen Niveaus", wie das früher bei Fraunhofers immer so schön hieß. Ich würde evtl. versuchen, meine triple module redundant library als Ersatz für standard_logic und standard_logic_vector in zeitgenössischer Sprache zu re-implementieren. Oder meinen DDS auf OpenCores... Mit Xilinx Virtex5 bin ich schon mal auf die Nase gefallen, als ich für die space/mil-Version wegen ITAR nicht mal die Löt- vorschriften bekomen habe, geschweige denn Chips. Und das für Zeugs, das auf die ISS sollte. Das war vor Trump; nicht auszu- denken, was passiert wenn der wieder mal hohldreht. Dann bauen wir eben Tamagotchis für die Kinder von Fukushima. 1/2 :-) Da kommt Design und Backen der Chips in Köln & Dresden gerade recht. Gruß, Gerhard
Gerhard H. schrieb: > Hat hier schon mal jemand mit den Gatemates von CologneChip gespielt? Ja, ausgiebig, aber nur im Trockendock ohne Hardware. Was ich soweit sagen kann: Bei den Primitiven habe ich zum jetzigen Stand keine Merkwuerdigkeiten festgestellt, aber TDP-Inferenz war lange ein Krampf, wie woanders schon gepostet. Lag an diversen Verschlimmbesserungen (so sagt der Schweizer) im Memory-Subsystem von yosys. Ob die LUT-Umsetzung inzwischen sparsam und timing-effizient geschieht, entzieht sich meiner Kenntnis, ich habe damals von einem produktiven Einsatz wieder Abstand genommen. > Taugt Yosys etwas, bevorzugt im Zusammenspiel mit Modelsim/Questasim > auf der snthetisierten Seite und VHDL als Quelle? Ich habe nur die GHDL-Seite (ghdl-yosys-plugin) unter die Lupe genommen. Portierbarkeit von Code ist eher mau, kann viel Arbeit in Anspruch nehmen. Ich arbeite inzwischen nur noch mit Verilog oder Direkt-Synthese aus Python HLS. Kommt ein bisschen draufan, was man machen will. Im Sinne von Weiterbildung macht es aber schon Sinn und auch Laune, sich mit einer neuen Architektur zu beschaeftigen. Gibt bei den CPE-Primitiven schon ein paar Extras, die klassische LUT4/LUT6-Gewebe nicht aufweisen.
Gerhard H. schrieb: > Hat hier schon mal jemand mit den Gatemates von CologneChip gespielt? Nein, aber ich habe mir das in Nürnberg etwas näher angeschaut. BGA-only hat mich etwas abgeschreckt, das kann man nicht mehr sicher in der Bastelbude zusammenlöten. > Taugt Yosys etwas, bevorzugt im Zusammenspiel mit Modelsim/Questasim > auf der snthetisierten Seite und VHDL als Quelle? Das (wenige), was ich bisher probiert habe, funktionierte.
> Ich würde evtl. versuchen, meine triple module redundant library > als Ersatz für standard_logic und standard_logic_vector in > zeitgenössischer Sprache zu re-implementieren. > Mit Xilinx Virtex5 bin ich schon mal auf die Nase gefallen, als > ich für die space/mil-Version wegen ITAR nicht mal die Löt- > vorschriften bekomen habe, geschweige denn Chips. Dann war deine Institution zu unfähig, die entsprechende Exportgenehmigung bei den Amis zu beantragen. Normalerweise ist das für ne etablierte Defense/Space-Firma kein Problem, ggf. muss man halt eine Kooperation mit amerikanischen (oder fränzosischen) Partnern eingehen. Hier hätte vielleicht schon der Wechsel von CGA auf BGA geholfen. Und für EGSE/Test-Boards tun es auch die "normale" Chip-Varianten. Vor ca. 4 Wochen beim Tag der Raumfahrt hat man bspw. bei Airbus in Taufkirchen boards mit Virtex-FPGA gezeigt, die für einen Standard-Satellitenbus waren. Da hies es lediglich, "Ist teuer" aber sonst keine unlösbaren Probleme damit: Beitrag "Veranstaltungstipp deutschlandweit: Tag der Raumfahrt 29.03.25" > Und das für > Zeugs, das auf die ISS sollte. > > Da kommt Design und Backen der Chips in Köln & Dresden gerade recht. Also es geht um space gehärtetes/taugliches PLD (Dreifach redundanz/ISS) ?! Da sollte man doch zuerst prüfen, ob die in der Fab verwendete Halbleitertechnologie dafür geeignet ist, auch hinsichtlich LatchUp-Gefahr etc.. Ich kann mich nicht erinnern, das Infineon in Dresden dergleichen im Angebot hat, vor 20 Jahren war das Actel? bei Stuttgart? und heute sind es einige PLD-Serien wie PolarFire von Mikrochip: https://www.microchip.com/en-us/products/fpgas-and-plds/radiation-tolerant-fpgas * https://www.st.com/en/space-products/rad-hard-asic-platforms.html Einige von denen haben dreifach-redundante FF gleich eingebaut. OK, bei der ISS unterhalb des Strahlungsgürtels weniger kritisch, aber wenn man gleich eine "Bibliothek" vorhat, sollte man das auch auf Anwendungen unter "ganz harten Bedingungen" auslegen. Als eine Hauptanwendung von GateMate nennen diese selbst Retro-Computing und verweisen auf dafür ausgelegte Boards, bspw. von olimex: https://www.olimex.com/Products/FPGA/GateMate/GateMateA1-EVB/open-source-hardware
:
Bearbeitet durch User
Ich hab mir das Teil mal ganz kurz angeschaut, aber die Alternativen sind für den Hobbybastler deutlich besser geeignet. Im Moment sind meine Favoriten die Gowin Reihe (Tang Nano 20k und 9k), Anlogic EF2M45 und der gute alte Cyclone I-IV. Die gibt es günstig in handlötbaren Gehäusen und die Software funktioniert soweit ohne Probleme. (Gowin EDA und TD funktionieren wirklich gut in einer VM )
Ich habe das Board rumliegen. Grundsätzlich ist es brauchbar, wenn es funktioniert. Allerdings habe ich damit nicht viel gemacht, weil es auf Linux und Windows Probleme gab. Auf Linux ist eines der Programme, ich glaube, das Place & Route, mit Speicherzugriffsfehler abgestürzt. Es war zwar eine nicht unterstützte Distribution, aber auch da sollte ein Programm nicht einfach abstürzen. Das Board benutzt zum Programmieren einen FTDI-Chip, wie viele andere Boards auch. Allerdings muss man für das GateMate-Board auf Windows einen anderen Treiber installieren. Dann funktionieren aber die anderen Boards nicht mehr, die auf den Standardtreiber angewiesen sind. Auf der Arbeit kann man bei einem administrierten Rechner nicht jedes Mal den Treiber wechseln, wenn man das Board wechselt. Beides relativ kleine Probleme, die mich aber trotzdem bisher davon abgehalten haben, da weiter einzusteigen.
> Das Board benutzt zum Programmieren einen FTDI-Chip, wie viele andere > Boards auch. Allerdings muss man für das GateMate-Board auf Windows > einen anderen Treiber installieren. Dann funktionieren aber die anderen > Boards nicht mehr, die auf den Standardtreiber angewiesen sind. Auf der > Arbeit kann man bei einem administrierten Rechner nicht jedes Mal den > Treiber wechseln, wenn man das Board wechselt. > > Beides relativ kleine Probleme, die mich aber trotzdem bisher davon > abgehalten haben, da weiter einzusteigen. Die Antwort darauf wäre eine virtuelle Maschine zu verwenden mit dem eigenen Treiber.
> Die Antwort darauf wäre eine virtuelle Maschine zu verwenden mit dem > eigenen Treiber. Wenn du schon Probleme mit der IT hast weil du keinen Admin hast, was glaubst du wohl wie die da hochdrehen? Vanye
Gerhard H. schrieb: > Taugt Yosys etwas, bevorzugt im Zusammenspiel mit Modelsim/Questasim > auf der snthetisierten Seite und VHDL als Quelle? Das open-source yosys kann von Haus aus leider nur Verilog. Mittles GHDL (dem freien VHDL Simulator), kann man aber über ein Plugin in Yosys auch VHDL einlesen. (Die kommerzielle Yoysys Version kann VHDL). Ich hab das bisher alles unter Linux gemacht. Könnte mir vorstellen, dass das unter Windows ein größerer Kampf ist, falls man da was selber kompilieren müsste. Questa / Modelsim sollte ja generell kein Problem sein für reines RTL. Viel IP gibt's in den FPGAs ja nicht, das man irgendwie als Simulationsmodell braucht. Ich habe mir so ein Gatemate Board von Olimex gekauft und damit herumgespielt. Das einzige Problem war, als ich das das letzte mal ausprobiert habe, das P&R tool von Cologne Chip, das man nur als Binary bekommt. Das Ding ist einfach widerlich. (No Offense. Ich find's cool, dass ihr die FPGAs gebaut habt! Aber ich habe wirklich fast gekotzt). Florian schrieb: > Auf Linux ist eines der Programme, ich glaube, das Place & Route, mit > Speicherzugriffsfehler abgestürzt. Es war zwar eine nicht unterstützte > Distribution, aber auch da sollte ein Programm nicht einfach abstürzen. Kann ich leider bestätigen. Für alle, die da mal Lust haben: ColgneChip hat die Debugsymbole nicht aus der Binary gestrippt. Da kann man mit GDB / r2 mal reinschauen. Das lohnt sich. Das ist sehr.... ähm... interessant. Danach wundern einen auf jeden Fall die Probleme nicht mehr. Ich hatte ursprünglich auf den nextpnr Support (opensource) gehofft. Der war / ist auch in Arbeit.Zumindest gibt es im nextpnr Repo einen gatemate Branch. Letztes Jahr auf der embedded hieß es, dass der Support kommt. Bisher ist aber glaube ich noch nichts released. Zumindest habe ich gerade nichts gefunden. Von der Performance der Chips bin ich persönlich "underwhelmed". Die 6 Input LUT ist bspw keine wirkliche 6er LUT, sondern, wenn man alle 6 Eingänge nutzt eine Kaskade aus kleineren Luts etc.. Zudem finde ich den maximalen Speed nicht so berauschend, vorallem mit dem Hintergrund, dass der Chip in GF 28 nm SLP gefertigt wurde. Ich habe schon mit einigen Technologien von GF beruflich gearbeitet (28nm, 22 FDX FDSoI etc...) und hätte dem Prozess da mehr zugetraut. Beitrag "RISC-V mit GateMate FPGA" Hier beschreibt der Autor eine Frequenz von +- 20 MHz für seinen picorv32. Ich Vergleich dazu: Ich habe ein privates Design mit enem Picorv32 und das läuft in einem alten Altera Max10 mit 100 MHz ohne Probleme.
M. N. schrieb: > Das open-source yosys kann von Haus aus leider nur Verilog. Das stimmt, aber die yosys-Toolchain von Cologne Chip kann VHDL von Haus aus. > Von der Performance der Chips bin ich persönlich "underwhelmed". Dem muss ich leider zustimmen, die Performance ist nicht besonders berauschend. > Die 6 Input LUT ist bspw keine wirkliche 6er LUT Es ist sogar eine 8er. Aber keine reine LUT, wie du auch schon bemerkt hast, sondern ein "8-Input-LUT tree", was bei genauerem Hinsehen ein "tree" aus kleineren LUTs ist. Wo der genaue Vorteil liegen soll, erschließt sich mir auch nicht wirklich. Florian schrieb: > Das Board benutzt zum Programmieren einen FTDI-Chip, wie viele andere > Boards auch. Allerdings muss man für das GateMate-Board auf Windows > einen anderen Treiber installieren. Dann funktionieren aber die anderen > Boards nicht mehr, die auf den Standardtreiber angewiesen sind. Stimmt, man muss mit Zadig einen libusb-Treiber installieren, aber bei mir haben alle anderen FTDI-Programmieradapter ihren Treiber behalten.
M. N. schrieb: > Ich habe schon mit einigen > Technologien von GF beruflich gearbeitet (28nm, 22 FDX FDSoI etc...) und > hätte dem Prozess da mehr zugetraut. Ist es nur der Prozess oder doch ein suboptimaler Mapping-Routing-Ansatz? Bei den Experimenten damals zumindest kam bei einigen Pipelines eine Menge unbalancierter Logik raus, und ich erinnere mich dunkel an einige MUXer issues. Ich bin mir auch nicht so ganz sicher, ob der urspruengliche Ansatz der 'Xilinx-Primitiven-Emulation' zu einigen eingeschleppten Problemen gefuehrt haben koennte. Mein Stand bezueglich nextpnr war, dass PnR grundsaetzlich mit den Logikprimitiven funktioniert, aber die aktuellen Details ob's dann auch in der HW tut: unbekannt. Die Probleme auch mit gut erforschten Architekturen wie ECP5 fingen immer bei so Details wie PLL oder JTAG-Primitiven an..Zeug, was man dann doch im Endprodukt braucht und das (Reverse) Engineering dann zaeh wird. Pat A. schrieb: > Es ist sogar eine 8er. Aber keine reine LUT, wie du auch schon bemerkt > hast, sondern ein "8-Input-LUT tree", was bei genauerem Hinsehen ein > "tree" aus kleineren LUTs ist. Wo der genaue Vorteil liegen soll, > erschließt sich mir auch nicht wirklich. Vermutlich architekturbedingt, wegen der Konfigurierbarkeit 8:1 und 4:2, resp. der alternativen Funktionalitaet als Multiplier?
Pat A. schrieb: >> Die 6 Input LUT ist bspw keine wirkliche 6er LUT > > Es ist sogar eine 8er. Stimmt. Das habe ich verwechselt... Ich hatte den Baum aus 3 2er LUTs im Kopf und war selbst verwirrt, wie ich auf 6 kam... Pat A. schrieb: > Florian schrieb: >> Das Board benutzt zum Programmieren einen FTDI-Chip, wie viele andere >> Boards auch. Allerdings muss man für das GateMate-Board auf Windows >> einen anderen Treiber installieren. Dann funktionieren aber die anderen >> Boards nicht mehr, die auf den Standardtreiber angewiesen sind. > > Stimmt, man muss mit Zadig einen libusb-Treiber installieren, aber bei > mir haben alle anderen FTDI-Programmieradapter ihren Treiber behalten. Das Olimex Board hat einen RP2040 (raspberry pico) drauf mit dirty JTAG oder so. Das geht unter Linux mit dem openfpgaloader einfach out of the box. Martin S. schrieb: > Ist es nur der Prozess oder doch ein suboptimaler > Mapping-Routing-Ansatz? Das wollte ich damit sagen. der Prozess ist eigentlich okay. Deswegen wundert mich eigentlich, dass das so langsam ist. Entweder ist die Toolchain Schuld, oder die haben das irgendwie im Design des Chips ausgebremst. Hätte auf jeden Fall mehr erwartet.
Pat A. schrieb: > Florian schrieb: >> Das Board benutzt zum Programmieren einen FTDI-Chip, wie viele andere >> Boards auch. Allerdings muss man für das GateMate-Board auf Windows >> einen anderen Treiber installieren. Dann funktionieren aber die anderen >> Boards nicht mehr, die auf den Standardtreiber angewiesen sind. > > Stimmt, man muss mit Zadig einen libusb-Treiber installieren, aber bei > mir haben alle anderen FTDI-Programmieradapter ihren Treiber behalten. Das ist jetzt länger her. Es war aber so, dass zwei andere Boards verschiedener Hersteller nicht mehr ansprechbar waren. Nach der Installation der Standardtreiber funktionierten die beiden Boards wieder, CologneChip nicht mehr. Wie gesagt, da gibt es sicher Lösungen, aber da es nur mal zum Ausprobieren bei der Arbeit war und Linux und Windows Probleme hatten, habe ich da dann nicht mehr weiterprobiert.
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.