Forum: FPGA, VHDL & Co. Quicklogic setzt auf SymbiFlow


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 Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt News von Quicklogic. Ich hatte von denen sooo lange nichts mehr 
gehört, dass ich annahm, dass es die gar nicht mehr gibt.

Sie haben ganz frisch einen FPGA + Cortex-M4 SoC herausgebracht.

Interessant ist aber vor allem ihre Toolchain bzw. das ganze Ökosystem 
drum herum: Symbiflow, Renode, FreeRTOS, Zephyr RTOS.

Quelle:
https://www.quicklogic.com/software/qorc-mcu-efpga-fpga-open-source-tools/

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Oh weia, auf deren Devboard haben sie das MEMS Mikrophon mit der Öffnung 
nach unter bestückt.

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


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Oh weia, auf deren Devboard haben sie das MEMS Mikrophon mit der Öffnung
> nach unter bestückt.

Haeee? Das wird SMD bestueckt, wie sollen die das auch anderst machen?

https://www.infineon.com/cms/en/product/sensor/mems-microphones/im69d130/

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Klar. Aber das bestückt man dann auf der Unterseite der Platine damit 
die Öffnung nach oben zeigt. So zeigt sie nach unten ... ausser man 
dreht die Platine um.

Edit:
Danke für die negative Bewertung. Hier ist ein Bild:
https://www.cnx-software.com/wp-content/uploads/2020/07/QuickLogic-EOS-S3-Development-Board.jpg

Aber gut, die Platine ist nur einseitig bestückt, da ist das wohl ein 
Kompromiss.

: Bearbeitet durch User
von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Frei nach Känguru: "Oben, unten, das sind doch alles bürgerliche 
Begriffe" :-)

Freut euch doch ein FPGA Board zu bekommen inkl. KiCAD Daten und 
Opensource Toolchain.

Gustl B. schrieb:
> Oh weia, auf deren Devboard haben sie das MEMS Mikrophon mit der Öffnung
> nach unter bestückt.

Ach ja, genau, jetzt können wir hier im FPGA Forum endlich auch sagen: 
"Es ist Opensource, flick es doch selber" ;-)

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> "Es ist Opensource, flick es doch selber" ;-)

Auf meinem FPGA Board habe ich das Micro unten bestückt.

Klar, quelloffen ist eine super Sache. Was ich noch nicht einschätzen 
kann ist wie ausgereift das Ganze ist und wie weit das den großen 
Herstellern hinterher hinkt. Sowohl von der Hardware als auch von der 
Software.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Eine vernueftige Bezugsquelle wie Farnell, Mouser, Digikey waere auch 
schoen.

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Klar, quelloffen ist eine super Sache. Was ich noch nicht einschätzen
> kann ist wie ausgereift das Ganze ist und wie weit das den großen
> Herstellern hinterher hinkt. Sowohl von der Hardware als auch von der
> Software.

yosys ist im Kern als Synthesetool ziemlich gut. Je nach Architektur 
gibt es natuerlich etwas Optimierungsbedarf, das Memory-Subsystem ist 
noch nicht optimal. Und sobald es um Core-Generation geht, verliert man 
natuerlich gegen die Dollar-Tools und muss sich seine Library erstellen.

Die naechste Baustelle wo es beim Timing dann etwas knifflig werden kann 
sind die PnR tools (nextpnr). So ganz timing-kritische Dinger wo 
erwartet wird, dass die Tools die Optimierung machen, wuerde ich mit 
OpenSource bedingt anschmeissen.

Nichtsdestotrotz: Fuer den ECP5 von Lattice habe ich mal eine Portierung 
eines komplexeren RISC-V SoC in Angriff genommen, mit einigen 
Klimmzuegen beim BRAM laeuft das alles tadellos wie mit der Diamond 
toolchain - und baut etwa 3-5 mal schneller.

von Nun. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das sieht ja eigentlich ganz nett aus und ist auch schön dass die Open 
Source Tools unterstützt werden.

Allerdings frage ich mich, was man großartig in nur 2400 (effektiven! 
Sind eigentlich 891) Logikzellen und 4x 16 Bit Mults und 64kbit BRAM 
unterbringen sollte ausser ggf. bestimmte I/O-Schnittstellen.
Ja ist natürlich für Low Power ausgelegt, schon klar. Aber paar LUTs 
mehr wären vielleicht doch sinnvoll gewesen?



Martin S. schrieb:
> So ganz timing-kritische Dinger wo
> erwartet wird, dass die Tools die Optimierung machen, wuerde ich mit
> OpenSource bedingt anschmeissen.


Kümmert sich die Toolchain überhaupt richtig ums Timing? Weil wirklich 
vollständig dokumentiert über komplette "PVT" ist das für die FPGAs ja 
eigentlich nicht. Die Entwickler sind ja über reverse engineering 
drangegangen.
Nicht falsch verstehen, ich find das super. Interessiert mich aber ob 
man da was zuverlässiges rausbekommt was nicht nur bei 25°C und 
richtiger Mondphase funktioniert.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Klar, nextpnr macht timing-driven PnR. Funktioniert auch recht gut, was 
ich noch nicht gemacht habe, ist gate-level-Verifikation post-PnR. 
Ansonsten ist es nicht zu schwer, aus reverse-engineerten Primitiven die 
Timings herauszudestillieren, z.B. dann wenn sie der Hersteller nicht 
irgendwo in einen Blackboxed-Modell versteckt hat (fuer 
Post-PnR-Verifikation).
Wo es bisschen gehakelt hat, sind Designs mit verschiedenen 
Clock-Domains. Die ganz harten Dinger mit den Serdes (DCUA-Primitiven) 
habe ich noch nicht verifiziert, da koennt's noch Ueberraschungen geben.

von Nun. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Klar, nextpnr macht timing-driven PnR.

Das ist gut. Ich hatte vor einer Weile mal irgendwo gelesen dass das 
nicht so wäre, aber kann auch eine Vorgängerversion gewesen sein.

Muss ich mal ausprobieren :-)

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht meinst Du arachne-PNR, das hatte m.W. ein architektonisches 
Manko diesbezueglich.

von Nun. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja ich glaube das wars. Hatte ich dann direkt wieder verworfen die Idee 
damit was zu machen.

von Christoph Z. (christophz)


Bewertung
1 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Klar, quelloffen ist eine super Sache. Was ich noch nicht einschätzen
> kann ist wie ausgereift das Ganze ist und wie weit das den großen
> Herstellern hinterher hinkt. Sowohl von der Hardware als auch von der
> Software.

Dass ein Hersteller gleich die Unterstützung für virtuelle Prototypen 
bietet, hier mit Renode, kenne ich bisher nur von Microchip/Microsemi. 
Aus meiner Sicht hinken da Xilinx und Intel hinterher (Man kann es ja 
dann bei Strubi nachkaufen :-)). Korrigiert mich wenn ich was verpasst 
habe.

Nun. schrieb:
> Allerdings frage ich mich, was man großartig in nur 2400 (effektiven!
> Sind eigentlich 891) Logikzellen und 4x 16 Bit Mults und 64kbit BRAM
> unterbringen sollte ausser ggf. bestimmte I/O-Schnittstellen.
> Ja ist natürlich für Low Power ausgelegt, schon klar. Aber paar LUTs
> mehr wären vielleicht doch sinnvoll gewesen?

Alles wo man sonst einen kleinen Lattice MachXO oder ICE40 separat aufs 
Board gepackt hat. Je nach Design lässt sich so auch ein Cypress PSoC 
Design auf eine schnellere CPU portieren (ohne Analog halt).

Low-power ist nicht zu unterschätzen. Mit ein bisschen zusätzlicher 
schlau gewählter Logik lassen sich viele batteriebetriebene Systeme viel 
länger im Deep-Sleep halten als ohne.

Ja, ich habe auch zwei Designs gemacht mit dem kleinsten MachXO128, die 
in Produktion sind. Tun nicht viel aber das was sie müssen.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Dass ein Hersteller gleich die Unterstützung für virtuelle Prototypen
> bietet, hier mit Renode, kenne ich bisher nur von Microchip/Microsemi.
> Aus meiner Sicht hinken da Xilinx und Intel hinterher (Man kann es ja
> dann bei Strubi nachkaufen :-)). Korrigiert mich wenn ich was verpasst
> habe.

Haha. Ist doch Opensource (falls du die virtuellen SoCs meinst).
Der Renode-Setup ist unter Linux sehr elegant, einfach Container 
starten, zappelt (und ist, da Verilator darunter, recht flott). Halt 
damit leider nur Verilog-Support und von der VHDL-Nummer kommt man eben 
doch nicht schnell genug weg, Co-Simulation mit VHDL-Modellen wird somit 
wieder ne Baustelle. Falls jemand mal Renode mit VPI-Interface bedient 
hat, bitte schreien.

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.

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