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/
Oh weia, auf deren Devboard haben sie das MEMS Mikrophon mit der Öffnung nach unter bestückt.
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/
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.
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" ;-)
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.
Eine vernueftige Bezugsquelle wie Farnell, Mouser, Digikey waere auch schoen.
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.
Gast
#6406450
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.
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.
Gast
#6406561
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 :-)
Vielleicht meinst Du arachne-PNR, das hatte m.W. ein architektonisches Manko diesbezueglich.
Gast
#6406737
Ja ich glaube das wars. Hatte ich dann direkt wieder verworfen die Idee damit was zu machen.
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.
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
Bitte melde dich an, um einen Beitrag zu schreiben.