So einfach ist FPGA inbetriebname noch nie gewesen. Ist in englischen blog etwas länger beschrieben: http://antti-brain.blogspot.com/2023/10/gatemate-som.html Deutscher FPGA ist lebending auf meinem Tisch, es blinkt! Wirklich die tools sind so klein und rasendschnell, auch das SPI flashen geht in wenigen sekunden, da hatte ich anfangs Angst wegen der Zadig, das ging aber alles schmerzfrei.
War nicht als werbung gemeint. War sehr guter Laune als der GateMate zum leben kam, und wollte berichten wie einfach dinge mit GateMate tools sind.
Ich war etwas voreilig zu berichten das alles glatt läuft. Von 10 getesteten platinen laufen leider nur 9. Es handelt sich um den GateMate standard LED blinky das auf 9 platinen gut läuft. Was kann der grund sein warum nur 9 aus 10 laufen? Ich habe es herausgefunden. Und jetzt laufen alle 10 platinen! Kann jemand erraten WAS könnte die ursache sein wenn blinky auf 9 von 10 boards läuft?
Magnus M. schrieb: > LED um 180° gedreht bestückt oder nicht bzw. schlecht verlötet. Nein. Der LED leuchtet kurz beim configuration. LED ist schon in Ordnung.
Antti L. schrieb: > Magnus M. schrieb: >> LED um 180° gedreht bestückt oder nicht bzw. schlecht verlötet. > > Nein. Der LED leuchtet kurz beim configuration. LED ist schon in Ordnung Oh super! Ich hol schon mal Baguette und Butter für die nächsten Salami-Scheiben!
Stefan S. schrieb: > Antti L. schrieb: >> Magnus M. schrieb: >>> LED um 180° gedreht bestückt oder nicht bzw. schlecht verlötet. >> >> Nein. Der LED leuchtet kurz beim configuration. LED ist schon in Ordnung > > Oh super! Ich hol schon mal Baguette und Butter für die nächsten > Salami-Scheiben! Wie gewünscht, als nächstes: mems oszi war es auch nicht, die ist in ordnung auf allen 10 Platinen und liefert die gleiche Frequenz.
Was für ein Kindergarten! Du machst keine gute Werbung für deinen Arbeitgeber...
F. M. schrieb: > Was soll diese Werbung? Wahrscheinlich sattelt Trenz auf Kölsche FPGAs um. Wäre mir aber egal. Eigentlich muss man froh sein, wenn es ein Gegengewicht gegen die beiden Riesen im Markt gibt, vor allem nach dem nun auch die Chinesen aufholen und eigene FPGAs bauen. Vielleicht kann man dann ja auch künftig wieder einfacher neue sicherheitskritische Anwendungen entwickeln, ohne 100 Seiten Ausfuhrkrimskrams auszufüllen, um an amerikanische FPGAs heranzukommen oder monatelang zu warten, weil man Nummer 3 in der Lieferschlange ist. Und schließlich brauchen wir ja mittelfristig eine eigene intelligente Technologie, wenn die Russen jetzt von den Chinesen mit Halbleitertechnik beliefert werden, um ihre Waffen zu produzieren, mit denen sie Europa überfallen.
Motopick schrieb: > Da steckt bestuemmpt ein Stopfelektron aus einem A.K.W. dahinter! Nein elektronenstrahl aus AKW ist nicht das problem gewesen mit blinky! Noch infos zu dem ausfall - 9 platinen blinken, der 10te hat * jtag boot: LED dauer-AUS * SPI boot: LED dauer-AN
> Nein elektronenstrahl aus AKW ist nicht das problem gewesen mit blinky! > > Noch infos zu dem ausfall - 9 platinen blinken, der 10te hat > * jtag boot: LED dauer-AUS > * SPI boot: LED dauer-AN Moeglicherweise wurde ein Bit zu viel konfiguriert, wegen einem puttugen Serienterminierungswiderstandes. Ersatzweise auch eines zu wenig. Wenn du hier schon Werbung machst, habt ihr auch was fuer den preisbewussten Heimanwender, mit 50-60k LEs und >120 (18x18) Multipliern?
Motopick schrieb: >> Nein elektronenstrahl aus AKW ist nicht das problem gewesen mit blinky! >> >> Noch infos zu dem ausfall - 9 platinen blinken, der 10te hat >> * jtag boot: LED dauer-AUS >> * SPI boot: LED dauer-AN > > Moeglicherweise wurde ein Bit zu viel konfiguriert, wegen einem > puttugen Serienterminierungswiderstandes. Ersatzweise auch > eines zu wenig. nein, obwohl es unterschiede gibt beim flashen/booten gibt es keine probleme mit konfiguration, wenn es geht geht immer, und das problem ist irgendwo anders... > Wenn du hier schon Werbung machst, habt ihr auch was fuer den > preisbewussten Heimanwender, mit 50-60k LEs und >>120 (18x18) Multipliern? mache ja keine werbung... Tjah du willst was billiges mit Spartan S50, da haben wir nichts passendes. Digilent hat: Arty S7-50 Spartan-7 FPGA ist aber nicht mehr so billig, sorry :(
Antti L. schrieb: >> Moeglicherweise wurde ein Bit zu viel konfiguriert, wegen einem >> puttugen Serienterminierungswiderstandes. Ersatzweise auch >> eines zu wenig. > > nein, obwohl es unterschiede gibt beim flashen/booten gibt es keine > probleme mit konfiguration, wenn es geht geht immer, und das problem ist > irgendwo anders... Antti L. schrieb: > Motopick schrieb: >>> Nein elektronenstrahl aus AKW ist nicht das problem gewesen mit blinky! >>> >>> Noch infos zu dem ausfall - 9 platinen blinken, der 10te hat >>> * jtag boot: LED dauer-AUS >>> * SPI boot: LED dauer-AN >> >> Moeglicherweise wurde ein Bit zu viel konfiguriert, wegen einem >> puttugen Serienterminierungswiderstandes. Ersatzweise auch >> eines zu wenig. > > nein, obwohl es unterschiede gibt beim flashen/booten gibt es keine > probleme mit konfiguration, wenn es geht geht immer, und das problem ist > irgendwo anders... Ich stelle es mir gerade richtig schön vor: Jemand kauft bei euch so ein Board. Hat Pech und hat Probleme mit der Inbetriebnahme des Blinky-Beispiels. Er fragt Google und stolpert über diesen Thread und freut sich, dass nicht nur eine weitere Person offenbar die gleichen Probleme hat, sondern auch noch ein Vertreter des Verkäufers ist. Und dann spielt der Verkäufer ein albernes "Raten mit Antti!". Anstatt "PSA: Es gibt das Problem XXX mit einzelnen Boards. Es äußert sich so: ... und lässt sich so beheben: ...!" schreibt er nur: "1 von 10 hat ein Problem! Woran es liegt? Ratet doch mal!".
Problem wurde mit änderung des VHDL codes in blinky.vhd behoben. Eingangs clock für PLL war falsch, da ist eine platine in "overclocked" mode nicht gelaufen. Der platinen clock ist 25MHz und der PLL in VHDL erwartete 10MHz clock. Das wars. VHDL geändert - all platinen laufen.
Was soll dieses peinliche Online-Ratespiel? Das ist ja lächerlich für eine Firma die FPGA Boards verkauft.
> Der platinen clock ist 25MHz und der PLL in VHDL > erwartete 10MHz clock. Das wars. Da wurde also einfach nur gefuscht. Das disqualifiziert es als Rateobjekt dann ohnehin grundsaetzlich. Bei einem chinesischen FPGA Board war der gewaehlte Takteingang ueberhaupt nicht an eine PLL routbar. Da musste man dann mit CuL ein wenig nachhelfen. Der Fehler war aber offenbar mit Bedacht "eingebaut" worden. Denn stabil lief die PLL mit einem tauglichen Clockeingang dann auch nicht. Da musste Mann dann nocheinmal mit "fiktiven" Frequenzen bei der PLL Konfiguration nachhelfen. Mein Eindruck: So einen Murks baut ihr also scheinbar auch. :)
Ist schon alles richtig gebaut, clock hat valid Frequenz und ist an clock capable pin angebunden. I hatte nur nicht gleich die VHDL datei angepasst, das war der Fehler. Mit der Platine ist Hardware mässig alles in Ordnung.
:
Bearbeitet durch User
Antti L. schrieb: >> Wenn du hier schon Werbung machst, habt ihr auch was fuer den >> preisbewussten Heimanwender, mit 50-60k LEs und > Tjah du willst was billiges mit Spartan S50, da haben wir nichts > passendes. Ich baue u.a. mit den TE0725. Die sind mit die bastlerfreundlichsten. Motopick schrieb: > Bei einem chinesischen FPGA Board war der gewaehlte Takteingang > ueberhaupt nicht an eine PLL routbar. Hatte ich bei dedizierten XI-evals auch schon. Inklusive falschem Pin-file ...
Abgesehen vom Influtrenzer-Gschmaeckle ist der Informationsgehalt eines "Ich nehme mal eben Board XY in Betrieb"-Berichts ziemlich homoeopathisch veranlagt. Schlussendlich interessiert den Entwickler wenig, ob der Chip nun deutsch ist und ob beim Anschliessen eine LED blinkt. Eher waere lesenswert: * Wie tut die Toolchain, insbes. in Bezug auf VDHL/Verilog (yosys?) * Wie schaut's mit dem Mapping aus, werden uebliche Konstrukte (BRAM, Counter, usw.) effizient auf die CPE-LE resp. Primitiven umgesetzt? * Wie effektiv ist PnR, Geschwindigkeit, Timing-Analyse, usw. Da muss definitiv noch mehr Fleisch an den Knochen. Die GateMate FPGA haben definitiv Features, die sie potentiell interessant machen, aber ich haette da noch eine Menge offener Fragen zur Toolchain gehabt...
Martin S. schrieb: > Abgesehen vom Influtrenzer-Gschmaeckle ist der Informationsgehalt eines > "Ich nehme mal eben Board XY in Betrieb"-Berichts ziemlich > homoeopathisch veranlagt. > Schlussendlich interessiert den Entwickler wenig, ob der Chip nun > deutsch ist und ob beim Anschliessen eine LED blinkt. Eher waere > lesenswert: > * Wie tut die Toolchain, insbes. in Bezug auf VDHL/Verilog (yosys?) > * Wie schaut's mit dem Mapping aus, werden uebliche Konstrukte (BRAM, > Counter, usw.) effizient auf die CPE-LE resp. Primitiven umgesetzt? > * Wie effektiv ist PnR, Geschwindigkeit, Timing-Analyse, usw. > > Da muss definitiv noch mehr Fleisch an den Knochen. Die GateMate FPGA > haben definitiv Features, die sie potentiell interessant machen, aber > ich haette da noch eine Menge offener Fragen zur Toolchain gehabt... Der toolchain benutzt Yosys für synthese (ist mit SystemVerilog support kompiliert). Place&Route is eigener. FPGA und Flash programming mit OpenFPGALoader, nichts eigenes. Den toolchain gibt es für Windows und Linux, ich habe mit Windows version gerbeitet, a gibt es einen run.bat den man mit unterschiedlichen parameter starten muss um synthese oder p&r zu starten. Bei LED blinky waren synthese und implementation zeiten wirklich sehr klein, bei etwas grösseren design schon wesentlich länger. Da gibt es auch kein progress indication, man muss selber den LOG file beobachten um den progress zu sehen, das ist etwas doof. Es sind 2 demo quellcodes da, erstens LED blinky mit PLL instance und zweitens ein 18x6 bit multiplikation. Timing: Es wird timinganalyze gemacht, für LED blinky (26 bit counter) ist max Frequenz als 188 MHz angegeben. Wegen der fehler in VHDL ist es aber auch mit 250MHz gelaufen (naja an 9 platinen von 10). LED blinky benutzt 34 CPE's. Das 18x6 MULT nimmt 115 CPE's und hat max Clock 134MHz. Natürlich ist LED blink nicht massgebendes demo, da wollte ich den InstantSoC RISC-V ausprobieren. Leider ist der Yosys nicht fähig den InstantSoC SystemVerilog zu synthesieren, es scheitert mit fehler. Dann habe ich den SystemVerilog mit opensource tools ins Verilog konvertiert. Die konversion hat gescheitert an einer zeile, den habe ich dann manuell konvertiert. Dieser design nimmt 6900 CPE's (33% von dem chip). Xilinx zeigt für das gleiche design 2000LUT/2300FF. Für diesen design ist GateMate tool estimate für max Clock 15MHz. Leider konnte ich InstantSoC nicht wirklich ausprobieren mit GateMate da das translierte Verilog nicht lauffähig ist, der läuft mit Xilinx auch nicht. Irgendwo passt etwas mit dem SystemVerilog konversion nicht, ist aber schwer zu sehen was es sein kontte. Des InstantSoC systemverilog is generierte code und obfuscated :( Was mich positive überascht hat war das FPGA und SPI Flashen. Da hatte ich Probleme erwartet, gab aber keine es geht einfach und ist rasend schnell. Mehr kann ich leider nicht viel sagen. Der GateMate FPGA toolchain ist benutzbar, der bauteil is programmierbar, und kleine sachen kann man damit machen. Wie da mit Block RAM geht weiss ich nicht, da war kein BRAM beispiel dabei und ist auch nichts darüer in datasheet zu finden.
:
Bearbeitet durch User
Antti L. schrieb: > Wie da mit Block RAM geht weiss ich nicht, da war kein > BRAM beispiel dabei und ist auch nichts darüer in datasheet zu finden. Oha! Das müsste aber schon irgendwie gehen und auch dokumentiert sein, weil so ganz unwichtig sind Block-RAMs ja nun nicht. Wenn ich mehr Zeit hätte, täte ich mich mit den FPGAs ja auch mal näher befassen. Momentan bleibt mir aber nur die Zuschauerrolle, gleichwohl verfolge ich das interessiert. Aus der Sicht finde ich Berichte wie diesen durchaus begrüßenswert. Was mal interessant wäre, ist ein Testdesign auf einemal einem aktuellen Altera, Xilinx und dann einem GateMate mit Blick auf Resourcenverbrauch, MaxSpeed und Kosten um zu sagen, was da geht und wo man rauskommt. Eine konkrete Frage wäre z.B. welcher GateMate-FPGA mit einem Artix7-100 konkurrieren kann, in Sachen BRAM, MUL und FFs/LUTs.
Angehängte Dateien:
-
gatemate.png
550 KB
Antti L. schrieb: > Wie da mit Block RAM geht weiss ich nicht, da war kein > BRAM beispiel dabei und ist auch nichts darüer in datasheet zu finden. Die BRAMs sind im Datasheet eigentlich ziemlich ausführlich beschrieben, sogar die Inferred-Beschreibung in VHDL und Verilog - und die funktioniert auch ;-) J. S. schrieb: > Eine konkrete Frage wäre z.B. welcher GateMate-FPGA mit einem Artix7-100 > konkurrieren kann, in Sachen BRAM, MUL und FFs/LUTs. Im Moment scheint es nur einen GateMate-FPGA zu geben, den CCGM1A1 mit ca. 40k LUT/FF (der kleinste). Nach meinem Test erreicht der CCGM1A1 etwa grob geschätzt 70% der Geschwindigkeit von einem Lattice MachXO3 (gleiches Design), der wiederum deutlich langsamer sein dürfte als ein Artix-7. Als Spaßbremse sehe ich eher die max. IO-Spannung von nur 2,5V. [Edit] Laut der Homepage von CologneChip soll nun auch der CCGM1A2 (80k LUT/FF) verfügbar sein.
:
Bearbeitet durch User
Betr. BRAM habe ich einige Szenarien ausgiebig durch die Post-Mapping-Simulation (Verilog) gejagt, der grosse Haken mit VHDL/Verilog lag da bei yosys, da ist im RAM-Mapping fuer verschiedene Targets ein architektonischer Bock, an dem sichtlich lange herumgemurkst wurde, grundsaetzlich funktioniert aber die BRAM-Inferenz auf die Gatemate-Primitiven mit Verilog sowie VHDL, nur bei gewissen Dual-Port-Konstellationen treten halt die Kniffligkeiten auf, die man aber auch von anderen Synthesetools kennt, die dann bei unterschiedlichen Read/Write Clock-Domains auftreten. RISC-V mit True-Dual-Port-BRAM ist vermutlich nicht 1:1 in der VHDL portabel wie z.B. zwischen Xilinx und Lattice, habe es aber seit einem Jahr nicht mehr getestet. J. S. schrieb: > Was mal interessant wäre, ist ein Testdesign auf einemal einem aktuellen > Altera, Xilinx und dann einem GateMate mit Blick auf Resourcenverbrauch, > MaxSpeed und Kosten um zu sagen, was da geht und wo man rauskommt. Habe ich mal mit X, L und G versucht anzuschmeissen, aber es noch wegen der in Arbeit befindlichen LUT-Tree-Optimierung in yosys seinlassen, waere kein fairer Vergleich gewesen. Die CPE ticken eben in gewissen Szenarien doch etwas anders. Ueberrascht bin ich auch, dass obige 18x6 soviele CPE braucht, aber wenn die Pipeline-Details fehlen, macht da auch ein Vergleich keinen Sinn. Ansonsten danke @Antti, die Info geht durchaus in die wertvolle Richtung.
Pat A. schrieb: > Nach meinem Test erreicht der CCGM1A1 etwa grob geschätzt 70% der > Geschwindigkeit von einem Lattice MachXO3 (gleiches Design), der > wiederum deutlich langsamer sein dürfte als ein Artix-7. hm ...
Andi F. schrieb: > Vielleicht kann > man dann ja auch künftig wieder einfacher neue sicherheitskritische > Anwendungen entwickeln, ohne 100 Seiten Ausfuhrkrimskrams auszufüllen, > um an amerikanische FPGAs heranzukommen oder monatelang zu warten, weil > man Nummer 3 in der Lieferschlange ist. Musst dich mal bei den Franzosen umsehen. nanoXplore z. B. macht FPGAs für Raumfahrt und sicherheitskritische Anwendungen, ITAR frei. In Frankreich entwickelt, in Frankreich gebaut (ST), französische Chip Prozesse (ST Space65 oder FD-SOI 28 nm aus Grenoble), bezahlt mit Europäischen Steuergeldern via ESA. Stromverbrauch ist etwas hoch im Vergleich. Daneben gibt es noch Menta, die kenne ich aber nur von ihrer Homepage.
:
Bearbeitet durch User
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.