Wednesday, 2022-03-02

*** tpb <[email protected]> has joined #f4pga00:00
F4PGASlackBridge<rod> G’day @torsten.reuschel @me1 - joining here from kintex-chatter to discuss/contribute/test Kintex7 support, specifically on QMTech Kintex7 and Genesys2 boards.00:20
F4PGASlackBridge<me1> @rod Are you the CTO of ASTC? 00:21
F4PGASlackBridge<rod> Yep00:22
F4PGASlackBridge<rod> it’s been 14 years, right? ;)00:24
F4PGASlackBridge<rod> Regarding Kintex7, I recently upstreamed OpenFPGALoader support for RAM and SPI Flash bitstream programming.  New to the F4PGA flow, however.00:26
*** bl0x_ <bl0x_!~bastii@p200300d7a70ffe004ca26f9ad24b4fff.dip0.t-ipconnect.de> has joined #f4pga02:25
F4PGASlackBridge<me1> @rod I've been at Google the entire time since leaving ASTC! Somehow I ended up back in the hardware / embedded space after doing tours on Partner Solutions, Maps Site Reliability Engineering and full time software developer on Chrome before applying to an internal startup incubator inside Google which evolved into my current position trying to deal with the Moore's law ending meaning we need a lot more hardware02:45
F4PGASlackBridgedesign.02:45
F4PGASlackBridge<me1> @rod I'm doing a lot of trying to open up the IC creation space with a fully open source, manufacturable 130nm PDK (https://skywater-pdk.readthedocs.io/) with no-cost shuttle program (run by https://efabless.com/) and fully open source ASIC tools like OpenLane.io and OpenROAD -- trying to blur the line between FPGA / eFPGA / ASIC using a software tooling approach.02:48
F4PGASlackBridge<rod> @me1 I've been following your work closely in this area :) :+1: 03:47
F4PGASlackBridge<me1> @rod I was actually talking to someone today about my (minimal) experience with SystemC at ASTC!03:48
F4PGASlackBridge<rod> We're intending to use the QMTech kintex board on a commercial project, and we've got a large SystemVerilog design that we're currently pushing through Vivado for it, so I'm interested to see whether the open flow can replace that.03:50
F4PGASlackBridge<rod> But I'm interested in what we can do for smaller designs too.03:51
F4PGASlackBridge<rod> But baby steps first, at least we can now flash the bitstream with open tools.03:52
F4PGASlackBridge<me1> @rod First step would be Surelog+UHDM-->Yosys-->Vivado 04:02
*** sf-slack1 <[email protected]> has quit IRC (Ping timeout: 250 seconds)07:29
F4PGASlackBridge<jonathan> @me1 Notwthstanding Surelog, I have seen better results for SystemVerilog compatibility with sv2v+yosys and also [email protected]:fabianschuiki/moore.git (which handles VHDL as well). I based my compatibility check with CVA6 (a.k.a. Ariane). Another possibility would be to just improve the yosys frontend until it can handle everything we want.09:53
F4PGASlackBridge<kgugala> @jonathan looking at https://chipsalliance.github.io/sv-tests-results/ Surolog passess more tests than moore10:45
tpbTitle: SystemVerilog Report (at chipsalliance.github.io)10:45
F4PGASlackBridge<kgugala> we're working on the Yosys frontend (atutally it's not only frontend - it is also internal processing) for UHDM10:45
*** adjtm <adjtm!~adjtm@2a0c:5a80:3609:e400:da35:a3df:2584:f0e5> has joined #f4pga11:43
F4PGASlackBridge<tgorochowik> The sv2v + flow is indeed pretty useful, but it's a two step process which makes things a little bit more complicated and harder to debug if something goes wrong, but we love and use it too in some cases!  The UHDM flow makes it much less complicated, please take a look a our latest blog note - it is pretty much the same as using yosys itself, you just need to load the plugin and use a different command to load12:48
F4PGASlackBridgethe sources. The rest is exactly the same.  Moore is also a great parser but for now it doesn't have any useful and simple integrations for SV synthesis - there are ideas to add the llhd <-> rtlil converters to be able to easily use it with yosys, but so far these are just ideas, the UHDM is already there and can be used in real designs. There is of course the option to parse sv and ouput vhdl and then use the ghdl plugin in12:48
F4PGASlackBridgeyosys, but this is even more complicated. To be honest it might even be a good idea to add UHDM support to moore (or a UHDM<->LLHD converter) - UHDM aims to be as universal as possible, Surelog is the first supported parser that we use, but it's not meant to be the only one - we want it to be a part of a bigger ecosystem. Extending the fronted of yosys seems like a great idea too, there are some issues with that though - it12:48
F4PGASlackBridgeextends only yosys so doesn't bring all the benefits of UHDM to the whole ecosystem (for which we have support in Verilator in a fork and hope to add other tools too)  Please let us know if you have any specific issues with the Surelog+UHDM flow, we'll be happy to help!12:48
*** adjtm <adjtm!~adjtm@2a0c:5a80:3609:e400:da35:a3df:2584:f0e5> has quit IRC (Quit: Leaving)12:56
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga15:17
F4PGASlackBridge<me1> @jonathan - You might find https://j.mp/sv-flow-diagram interesting15:55
tpbTitle: SystemVerilog flows (for OpenTitan and other SV designs) using open tools (for FPGAs and ASICS) - Google Zeichnungen (at j.mp)15:55
F4PGASlackBridge<me1> @jonathan - We most certainly want to support Ariane and the other OpenHWGroup / ETH Zurich cores in Surelog+UHDM->Yosys flow -- it just hasn't been a top priority at this moment (Ibex / OpenTitan and CHIPS Alliance + DARPA cores have been the priority)15:56
F4PGASlackBridge<umartinezcorral> FTR, Surelog and ghdl-yosys-plugin can be combined to have mixed-language synthesis support (verilog + sv + vhdl).<16:01
F4PGASlackBridge<umartinezcorral> Moreover, `ghdl synth --out=verilog`  is somehow equivalent to sv2v, and it allows to use yosys without ghdl-yosys-plugin. That's e.g. how NEORV32 or microwatt are supported in LiteX.16:02
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 240 seconds)16:07
*** adjtm <[email protected]> has joined #f4pga16:32
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga16:56
nsmlzlare ice40/ecp5 FPGAs supported by F4PGA/Symbiflow? Or, is using a Makefile with yosys, nextpnr, ecppack/icepack preferable?18:17
gatecatthe latter approach is probably the best way to go (although that's still loosely part of the symbiflow/f4pga umbrella in a sense)19:27
nsmlzlok, thanks!19:32
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection)20:30
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #f4pga20:31
*** ec_ <ec_!~ec@gateway/tor-sasl/ec> has joined #f4pga21:06
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection)21:06
F4PGASlackBridge<me1> F4PGA in partnership with HDL group on GitHub does package Yosys / nextpnr / Trellis || icestorm in Conda for example21:43
F4PGASlackBridge<me1> The current analogy I use is that F4PGA is kind of like "Debian" -- Linux isn't owned by Debian but it is very important part of almost all Debian systems21:47
F4PGASlackBridge<me1> Debian also does do direct development of various things which Debian needs too21:47
F4PGASlackBridge<umartinezcorral> Apart from F4PGA examples, regarding Lattice devices, I suggest to have a look at the CI of fomu-workshop. It uses Makefiles and it shows three tool installation solutions: fomu-toolchain based on fpga-toolchain (now deprecated in favour oss-cad-suite), containers and MSYS2. The Makefiles from fomu-workshop are based on antonblanchard's microwatt and ghdl-yosys-blink. NEORV32 use similar makefiles.21:48
F4PGASlackBridge<umartinezcorral> However, makefiles get complex when dealing with SoCs. Then, LiteX is worth a try.21:51
nsmlzlthanks for the clarification! Yeah, I already had a look at a few makefiles - I was just wondering if another solution exists. 22:34
*** hansfbaier <[email protected]> has joined #f4pga23:33

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!