| *** tpb has joined #symbiflow | 00:00 | |
| -_whitenotifier-f- [symbiflow-examples] mithro opened issue #56: Add Music box example from FPGA4Fun to symbiflow-examples - https://git.io/JTLHd | 00:32 | |
| -_whitenotifier-f- [symbiflow-examples] mithro opened issue #57: Add all fpga4fun - "FPGA projects - Basic" examples to repository - https://git.io/JTLHh | 00:34 | |
| *** maartenBE has quit IRC | 01:10 | |
| *** maartenBE has joined #symbiflow | 01:16 | |
| *** citypw has joined #symbiflow | 01:39 | |
| *** Degi has quit IRC | 02:20 | |
| *** Degi has joined #symbiflow | 02:20 | |
| *** TMM has quit IRC | 03:55 | |
| *** TMM has joined #symbiflow | 03:55 | |
| *** az0re has quit IRC | 04:46 | |
| *** mkru has joined #symbiflow | 07:03 | |
| sf-slack | <olof.kindgren> Trying to build nextpnr-xilinx but I'm getting a bit confused. According to the docs I need to first download and build prjxray, but looking at the prjxray docs it seems this needs a copy of Vivado 2017.2. Do I really need all this to build nextpnr-xilinx? | 07:19 |
|---|---|---|
| sf-slack | <olof.kindgren> Oops. I was in the wrong project directory. Nevermind | 07:23 |
| *** kraiskil has joined #symbiflow | 07:25 | |
| *** az0re has joined #symbiflow | 07:34 | |
| *** az0re has quit IRC | 07:35 | |
| *** ZipCPU has quit IRC | 07:41 | |
| *** ZipCPU has joined #symbiflow | 07:42 | |
| -_whitenotifier-f- [symbiflow-examples] tcal-x opened issue #58: Error with "make README.rst": "TypeError: Got secondary option for non boolean flag." - https://git.io/JTt08 | 07:44 | |
| *** rvalles_ is now known as rvalles | 08:00 | |
| *** az0re has joined #symbiflow | 08:05 | |
| sf-slack | <olof.kindgren> ok, so for nextpnr-xilinx the chip definition files are distributed with prjxray, analogous to how they are shipped with trellis and icestorm for the ecp5 and ice40 cases, right? | 08:06 |
| daveshah | X-ray or RapidWright | 08:06 |
| sf-slack | <olof.kindgren> True | 08:06 |
| sf-slack | <olof.kindgren> I was thinking, wouldn't it be nice if we could set the path to these files at compile-time, like we do for the other nextpnr versions? | 08:07 |
| sf-slack | <olof.kindgren> For me as an end-user it would be preferable | 08:07 |
| sf-slack | <olof.kindgren> Another option would be to do like yosys (yosys-config) and offer a command for getting relevant paths | 08:08 |
| sf-slack | <olof.kindgren> And still allow overriding with `--chipdb` for those who need that | 08:09 |
| daveshah | It's not end user ready and won't be until next year | 08:10 |
| daveshah | There's no point focusing on small usability issues before bigger ones like timing data and overall robustness | 08:10 |
| sf-slack | <olof.kindgren> I guess the only reason from my point of view would be that it can be easier to do comparisons if there's an Edalize backend for the flow | 08:13 |
| *** OmniMancer1 has joined #symbiflow | 08:13 | |
| sf-slack | <olof.kindgren> Long term I'm hoping to enable external backends to plugin more easily. That way an experimental backend can be developed more easily in isolation | 08:14 |
| *** OmniMancer has quit IRC | 08:16 | |
| *** kraiskil has quit IRC | 08:19 | |
| sf-slack | <olof.kindgren> But at this point I would need a good reason to add the backend. @acomodi @kgugala, is fpga-perf-tool the main (only?) use case for this backend, or did I miss something? | 08:21 |
| sf-slack | <kgugala> I think it is the main use case right now. Currently we need to use edalize fork to get nextpnr (I'd be awesome to switch to mainline) | 08:22 |
| sf-slack | <olof.kindgren> Thanks. That's good to know. I'm starting to get a clearer view of the situation now | 08:24 |
| sf-slack | <olof.kindgren> I'm open to merge it even if it's not good enough for end-users yet under the condition that I know it's being worked on and that there won't be any changes coming up that will need larger changes to the Edalize backend, because that will be a mess to keep track of | 08:27 |
| sf-slack | <olof.kindgren> In that case it will come with a disclaimer that it's alpha quality and that vivado (or yosys+vpr?) is the better option for now | 08:28 |
| sf-slack | <olof.kindgren> I also think by now that it would make more sense to call the backend xray rather than nextpnr-xilinx, since that's what it's really about | 08:28 |
| sf-slack | <olof.kindgren> Analogous to how we have trellis and icestorm backends that uses yosys+nextpnr+<backend-specific stuff> | 08:29 |
| sf-slack | <olof.kindgren> Speaking of Edalize, the latest issue of El Correo Libre was just released https://medium.com/librecores/el-correo-libre-issue-32-e3cc88256c50 | 08:34 |
| tpb | Title: El Correo Libre Issue 32. Antmicro Integrates Embench for Quick… | by Gareth Halfacree | LibreCores | Oct, 2020 | Medium (at medium.com) | 08:34 |
| sf-slack | <kgugala> :) | 08:34 |
| sf-slack | <acomodi> I think that nextpnr and xray are two separate things. Meaning that what nextpnr outputs is a fasm file, as well as vpr. XRay contains the libraries and data to write the bitstream, and calling nextpnr-xilinx "xray" might lead to confusion. | 08:37 |
| sf-slack | <olof.kindgren> The whole thing is slightly confusing for sure :) | 08:42 |
| sf-slack | <olof.kindgren> Calling it xray would be consistent with how the other yosys+nextpnr backends are called, and the yosys+vpr+fasm flow is already merged as symbiflow | 08:44 |
| sf-slack | <olof.kindgren> But we're at the limit of how far the naming scheme can be stretched. Ahh!! Could everyone please just stop creating EDA tools for a second?! ;) | 08:45 |
| sf-slack | <olof.kindgren> The other sensible (for me at least) option would be to have nextpnr as an alternative to vpr in the existing symbiflow backend | 08:46 |
| sf-slack | <olof.kindgren> Like the icestorm backend can switch between nextpnr and arachne | 08:46 |
| sf-slack | <acomodi> That makes sense I think, because the end-user can choose between a variety of options to have a final synth_tool + P&R_tool + bit_tool combination | 08:48 |
| sf-slack | <acomodi> The P&R_tool + bit_tool is currently merged together, hence the confusion :) | 08:49 |
| sf-slack | <olof.kindgren> Yeah. This was the traditional way after all, like quartus, vivado, ise etc | 08:49 |
| *** mkru has quit IRC | 09:04 | |
| *** mkru has joined #symbiflow | 09:33 | |
| sf-slack | <blue> I'd like to file an idea about having a SymbiFlow IP integrator. I don't think that exists yet, there is an RTL viewer issue but this is more a schematic editor but with IPs | 10:04 |
| sf-slack | <blue> This would allow you to graphically connect IPs just like Vivado IP integrator (I think it's called) and Intel Platform Designer / Qsys | 10:05 |
| sf-slack | <olof.kindgren> @blue I have been trying to get some traction behind IP-XACT for many years now for this purpose | 10:07 |
| sf-slack | <blue> That's a standard to make the symbols and parameters to the instances right? | 10:08 |
| sf-slack | <olof.kindgren> It's a lot of things, but the interesting parts in this area is that you can describe the perimeters (parameters, buses and single signals) of your cores and how they are connected to other cores | 10:09 |
| sf-slack | <blue> Oh, so it can do inter-core stuff? | 10:09 |
| sf-slack | <olof.kindgren> On the graphical side there is a project called Kactus2 that hasaimed to be something that you're looking for. I have followed and worked with the Kactus2 people for a long time. Unfortunately it has been _almost_ there for a very long time, but there's always something that prevents me from using it as a daily driver | 10:10 |
| sf-slack | <olof.kindgren> But I have built OpenRISC-based SoCs for reference with it | 10:10 |
| sf-slack | <olof.kindgren> Everything you need to know about IP-XACT can be found here https://olofkindgren.blogspot.com/2016/11/ip-xact-good-bad-and-outright-madness.html | 10:10 |
| tpb | Title: Tales from Beyond the Register Map: IP-XACT: The good, the bad and the outright madness (at olofkindgren.blogspot.com) | 10:10 |
| sf-slack | <olof.kindgren> Also, earlier this year I finally did something I promised never to do and wrote my own rudimentary IP-XACT to verilog generator | 10:11 |
| sf-slack | <olof.kindgren> I already have a python library https://github.com/olofk/ipyxact that can parse and read IP-XACT files | 10:12 |
| tpb | Title: GitHub - olofk/ipyxact: Python-based IP-XACT parser (at github.com) | 10:12 |
| sf-slack | <olof.kindgren> Because I don't think we need another standard. We need more tooling for this standard. A graphical block diagram editor is one thing. Tools to enter and extract register maps is another. Command-line-based verilog generators is a third and so on | 10:13 |
| sf-slack | <olof.kindgren> And FuseSoC core description files reuses concepts from IP-XACT where it makes sense and can even parse some information from IP-XACT files in an attempt to avoid duplication | 10:13 |
| sf-slack | <olof.kindgren> But there hasn't been enough available time to make a real push in this area, but it's something I have seen as lacking for a long time | 10:14 |
| sf-slack | <blue> I agree that we should unite around one standard, but likely we need a new tool to do the graphical stuff, and unless IP-XACT can describe X/Y positions of components in relative to eachother we would need a new file format to store the schematic in | 10:36 |
| sf-slack | <olof.kindgren> IP-XACT supports non-standard additions (vendor extensions), so it's possible to store this info in the design/component files | 10:40 |
| sf-slack | <olof.kindgren> But additional metadata works too | 10:40 |
| sf-slack | <olof.kindgren> And yes, it would be great if someone came up with a new graphical tool | 10:41 |
| sf-slack | <olof.kindgren> icestudio is far too simple to be used unfortunately. There have been some experimentation with using kicad, but I worry that the conceptual mismatch might be too large | 10:42 |
| sf-slack | <olof.kindgren> Fun fact. Vivado can import IP-XACT 2009 files. I was looking a while ago to see if they started supporting IP-XACT 2014. Found a forum post by someone who had asked the same thing with a link to my IP-XACT blog post :) | 10:46 |
| sf-slack | <blue> I'd likely base the software vision (not necessarily code) on VLSI schematic like xschem then. Having multiple layers and quickly being able to go into and out of sub-schematics seems to me as a killer feature | 11:12 |
| sf-slack | <blue> That annoys me so much with Qsys, it's very slow to descend | 11:13 |
| -_whitenotifier-f- [fpga-tool-perf] acomodi opened issue #245: Create separate environment for different toolchains - https://git.io/JTtSt | 11:14 | |
| sf-slack | <blue> Then you'd need some work to make a design rule checker (DRC) just like VLSI stuff to figure out when you accidentally connected two different clock domains or need to insert a bus arbiter | 11:14 |
| sf-slack | <blue> And then there of course needs to be a library with the bus arbiters and clock crossing helpers | 11:15 |
| sf-slack | <blue> Did I dream of that orpsoc-cores has stuff like that? | 11:16 |
| sf-slack | <blue> I seem to recall having conversations with @olof.kindgren about wishbone arbiters and autogenerated code like 7 years ago | 11:16 |
| sf-slack | <olof.kindgren> I have a library called wb_intercon that can generate bus interconnects. I have even written (but not released) support for generating an accompanying IP-XACT component description for the interconnect | 11:18 |
| sf-slack | <olof.kindgren> orpsoc-cores is mostly deprecated but you can find it in the new base library fusesoc-cores | 11:18 |
| sf-slack | <olof.kindgren> Also, it has generator support now, so that you can parametrize your interconnect directly from your FuseSoC core description files, e.g. https://github.com/chipsalliance/Cores-SweRVolf/blob/master/swervolf.core#L127 | 11:20 |
| tpb | Title: Cores-SweRVolf/swervolf.core at master · chipsalliance/Cores-SweRVolf · GitHub (at github.com) | 11:20 |
| sf-slack | <olof.kindgren> FuseSoC generators is another thing that intends to wrap/replace proprietary vendor standards. It's designed for the cases where you need to generate verilog, vhdl or something else that the EDA tools understand from another format | 11:21 |
| sf-slack | <olof.kindgren> It can be ipxact to verilog, migen to verilog, C code to a $readmemh file, a set of defines from a database or whatever | 11:22 |
| sf-slack | <olof.kindgren> They are created for FuseSoC, but can be used standalone as well | 11:23 |
| sf-slack | <olof.kindgren> One mid-term goal is to be able to generate stand-alone IP cores from most Litex cores so that they can be easily dropped into traditional verilog flows | 11:24 |
| sf-slack | <blue> The project could be called intergreat | 11:30 |
| -_whitenotifier-f- [fpga-tool-perf] acomodi opened issue #246: Enable the arty a7 100T board - https://git.io/JTt9w | 11:31 | |
| sf-slack | <olof.kindgren> :) | 11:32 |
| sf-slack | <blue> Probably it would make sense to have some middle-representation between the graphical schematic and the generated HDL. Something that is like a netlist. Would make it easier for other tools to also generate interconnected designs | 11:36 |
| sf-slack | <blue> Kaktus2 looks pretty good | 11:39 |
| sf-slack | <olof.kindgren> Kactus2 is definitely good enough for many things. Then there are some design decisions that I'm not super excited about. Some can be worked around, and others not | 12:00 |
| -_whitenotifier-f- [yosys-symbiflow-plugins] tmichalak opened issue #48: Improve get_nets to return logical nets instead of wires. - https://git.io/JTtdP | 12:21 | |
| *** citypw has quit IRC | 12:36 | |
| sf-slack | <blue> In my head I'm visualizing something more free layout wise than Kactus2 though, like how electrical schematics are free. Blender's Node Editor comes to mind in how they have made more or less parameterizable "IPs" easy to connect to eachother | 13:52 |
| sf-slack | <blue> Qsys is really annoying when the designs get large in that regard | 13:52 |
| *** OmniMancer1 has quit IRC | 14:13 | |
| sf-slack | <kgugala> gi | 15:16 |
| sf-slack | <kgugala> sorry, wrong window :) | 15:17 |
| sf-slack | <olof.kindgren> When it comes to EDA tools it's always a better idea to look at other things than existing EDA tools for inspiration since other tools generally make more sense :) | 15:19 |
| sf-slack | <olof.kindgren> And yes, the Kactus layout constraints are awful | 15:20 |
| mithro | https://github.com/emeryberger/scalene/blob/master/README.md | 16:05 |
| tpb | Title: scalene/README.md at master · emeryberger/scalene · GitHub (at github.com) | 16:05 |
| *** flokli has quit IRC | 16:27 | |
| *** flokli has joined #symbiflow | 16:32 | |
| *** titanbiscuit has joined #symbiflow | 17:25 | |
| *** az0re has quit IRC | 17:28 | |
| *** az0re has joined #symbiflow | 17:39 | |
| -_whitenotifier-f- [prjxray] litghost opened issue #1458: Add automated PR generation - https://git.io/JTqPf | 18:27 | |
| sf-slack | <olof.kindgren> Hmm.. do I need a special cable to program the quickfeather? | 20:07 |
| sf-slack | <kgugala> not really | 20:08 |
| sf-slack | <kgugala> any TWI programmer should work | 20:09 |
| sf-slack | <olof.kindgren> What's a TWI programmer? | 20:09 |
| sf-slack | <kgugala> ehhh | 20:09 |
| sf-slack | <kgugala> it's too late | 20:09 |
| sf-slack | <olof.kindgren> I have an Altera USB Blaster and a Digilent HS2 if that is of any help | 20:10 |
| sf-slack | <kgugala> SWD | 20:10 |
| sf-slack | <olof.kindgren> What's an SWD programmer? :) | 20:10 |
| sf-slack | <kgugala> https://embeddedinventor.com/swd-vs-jtag-differences-explained/ | 20:11 |
| sf-slack | <olof.kindgren> ok, it seems you can get those froma bunch of different places | 20:11 |
| sf-slack | <kgugala> yep | 20:12 |
| sf-slack | <kgugala> there is upstream openOCD support for it | 20:12 |
| sf-slack | <olof.kindgren> Aha, it's an alternative protocol to JTAG? Then I'm pretty sure I don't have any right now | 20:12 |
| sf-slack | <kgugala> we recently added support for eos-s3 and quickfeather | 20:12 |
| HackerFoo | The protocol is still JTAG. | 20:13 |
| sf-slack | <olof.kindgren> Is it a layer on top of JTAG then? | 20:13 |
| HackerFoo | It's just reduces the pin count by using a different way to shift the bits across the wire. | 20:14 |
| sf-slack | <olof.kindgren> I got my quickfeather now and was hoping to try them out but it seems I need to order a programmer from somewhere first | 20:14 |
| sf-slack | <kgugala> TBH you can use an FTDI adapter and openOCD - just need to do this https://plaes.org/technotes/embedded-systems/ftdi-ft232h-for-hardware-hacking/ | 20:14 |
| tpb | Title: FTDI FT232H for hardware hacking — plaes.org (at plaes.org) | 20:14 |
| HackerFoo | IIRC it's similar to I2C while 6 (?) wire JTAG uses a more direct way to signal like SPI. | 20:15 |
| sf-slack | <timo.callahan> I too would like to know how to put a bitstream on my Quickfeather board https://github.com/SymbiFlow/symbiflow-examples/issues/3#issuecomment-707949963 | 20:16 |
| tpb | Title: Add instructions for loading bitstream / connecting to board (maybe factor out to new guide) · Issue #3 · SymbiFlow/symbiflow-examples · GitHub (at github.com) | 20:16 |
| sf-slack | <olof.kindgren> Need to check what FTDI adapters I have here | 20:16 |
| *** nickray has quit IRC | 20:17 | |
| HackerFoo | If nothing else, you can use another FPGA board. | 20:21 |
| sf-slack | <kgugala> here is eos-s3 target https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/target/eos_s3.cfg and quickfeather https://sourceforge.net/p/openocd/code/ci/master/tree/tcl/board/quicklogic_quickfeather.cfg | 20:21 |
| sf-slack | <olof.kindgren> Right, so it seems similar to i2c as @hackerfoo said. Wonder if they run the ft232h in i2c mode | 20:21 |
| tpb | Title: OpenOCD - Open On-Chip Debugger / Code / [3ffa14] /tcl/target/eos_s3.cfg (at sourceforge.net) | 20:21 |
| sf-slack | <olof.kindgren> @hackerfoo: Technically, yes. But I would need a driver at an FPGA image that implement the protocol | 20:21 |
| sf-slack | <kgugala> openocd has SWD over FTDI support | 20:21 |
| sf-slack | <olof.kindgren> @kgugala How does that work? SWD seemed to use a bidirectional data pin but all JTAG pins are unidirectional | 20:22 |
| sf-slack | <kgugala> QL toolchain will produce you an openOCD script you can run to program the FPGA | 20:22 |
| sf-slack | <kgugala> see this link https://plaes.org/technotes/embedded-systems/ftdi-ft232h-for-hardware-hacking/ | 20:23 |
| tpb | Title: FTDI FT232H for hardware hacking — plaes.org (at plaes.org) | 20:23 |
| sf-slack | <kgugala> you need to connect it correctly | 20:23 |
| sf-slack | <kgugala> SWDIO line is connected to TDI and TDO | 20:24 |
| sf-slack | <olof.kindgren> ah ok. I see it | 20:24 |
| sf-slack | <kgugala> the resitor there is quite important | 20:24 |
| sf-slack | <olof.kindgren> And then they just run the ft232h in jtag or spi mode I guess | 20:24 |
| sf-slack | <olof.kindgren> JTAG. See now | 20:25 |
| sf-slack | <kgugala> yep | 20:25 |
| sf-slack | <olof.kindgren> Got it. Then I need to check if I have any FTDI chips with easily accesible pinout that can run in JTAG mode. Should be able to use the USB blaster otherwise I guess | 20:26 |
| sf-slack | <kgugala> the toolchain can also generate programming script for segger JTAG programmer | 20:27 |
| sf-slack | <olof.kindgren> Hmm.. Does it matter which JTAG programmer it is? Doesn't OpenOCD provide abstraction for the type of JTAG programmer? | 20:28 |
| sf-slack | <kgugala> if you use openOCD it does not matter | 20:29 |
| sf-slack | <olof.kindgren> Cool. And there's a driver for the USB Blaster, so I'd thought that could work | 20:29 |
| sf-slack | <kgugala> mhm - it can work | 20:29 |
| sf-slack | <kgugala> haven't tested this combo | 20:29 |
| sf-slack | <olof.kindgren> I think my only standalone FTDI adapter is an FT232R which only implements UART, so the Blaster is probably the only real JTAG adapter I have with OpenOCD support | 20:32 |
| sf-slack | <kgugala> we used this adapter configuration in our tests https://github.com/antmicro/openocd/blob/f0ccb9035cbb2d8ced76787a770fbe12a6328f7f/tcl/interface/ftdi/antmicro-dongle-hacked.cfg | 20:36 |
| tpb | Title: openocd/antmicro-dongle-hacked.cfg at f0ccb9035cbb2d8ced76787a770fbe12a6328f7f · antmicro/openocd · GitHub (at github.com) | 20:36 |
| sf-slack | <kgugala> so if you have any board with dual channel FTDI chip this configuration will work | 20:38 |
| sf-slack | <kgugala> the beatiful ascii art there presents how it should be connected | 20:38 |
| sf-slack | <kgugala> the following command should program the FPGA | 20:41 |
| sf-slack | <kgugala> `openocd -f antmicro-dongle.cfg -f board/quicklogic_quickfeather.cfg -s tcl -f /path/to/top.cfg` | 20:41 |
| sf-slack | <kgugala> `top.cfg` is generated by the toolchain from bitstream file | 20:42 |
| -_whitenotifier-f- [symbiflow-examples] tcal-x opened issue #59: Redundant conda download when doing 'make README.rst' - https://git.io/JTqND | 21:05 | |
| sf-slack | <olof.kindgren> Thanks. I think I have the concept now and I believe it should work with any JTAG adapter, so I'll might give it a try tomorrow unless I finda proper SWD adapter somehwere before that | 21:21 |
| *** kgugala_ has quit IRC | 21:30 | |
| *** kgugala has joined #symbiflow | 21:30 | |
| *** kraiskil has joined #symbiflow | 22:46 | |
| *** awordnot has quit IRC | 23:21 | |
| *** awordnot has joined #symbiflow | 23:22 | |
| *** Ultrasauce has quit IRC | 23:22 | |
| *** Ultrasauce has joined #symbiflow | 23:23 | |
| *** vup has quit IRC | 23:25 | |
| *** vup has joined #symbiflow | 23:25 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!