Forum: FPGA, VHDL & Co. GateMate FPGA inbetriebname


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 Antti L. (trioflex)


Lesenswert?

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.

von F. M. (foxmulder)


Lesenswert?

Was soll diese Werbung?

von Antti L. (trioflex)


Lesenswert?

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.

von Antti L. (trioflex)


Lesenswert?

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?

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

LED um 180° gedreht bestückt oder nicht bzw. schlecht verlötet.

von Antti L. (trioflex)


Lesenswert?

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.

von Stefan S. (chiefeinherjar)


Lesenswert?

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!

von Antti L. (trioflex)


Lesenswert?

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.

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

Was für ein Kindergarten!

Du machst keine gute Werbung für deinen Arbeitgeber...

von Motopick (motopick)


Lesenswert?

Da steckt bestuemmpt ein Stopfelektron aus einem A.K.W. dahinter!

von A. F. (chefdesigner)


Lesenswert?

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.

von Antti L. (trioflex)


Lesenswert?

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

von Motopick (motopick)


Lesenswert?

> 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?

von Antti L. (trioflex)


Lesenswert?

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 :(

von Stefan S. (chiefeinherjar)


Lesenswert?

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!".

von Antti L. (trioflex)


Lesenswert?

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.

von F. M. (foxmulder)


Lesenswert?

Was soll dieses peinliche Online-Ratespiel?
Das ist ja lächerlich für eine Firma die FPGA Boards verkauft.

von Motopick (motopick)


Lesenswert?

> 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. :)

von Antti L. (trioflex)


Lesenswert?

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
von J. S. (engineer) Benutzerseite


Lesenswert?

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 ...

von Martin S. (strubi)


Lesenswert?

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...

von Antti L. (trioflex)


Lesenswert?

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
von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Pat A. (patamat)


Angehängte Dateien:

Lesenswert?

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
von Martin S. (strubi)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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 ...

von Christoph Z. (christophz)


Lesenswert?

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
Bitte 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
Noch kein Account? Hier anmelden.