| *** tpb has joined #symbiflow | 00:00 | |
| *** epony has joined #symbiflow | 00:33 | |
| *** rvalles has joined #symbiflow | 01:24 | |
| *** rvalles_ has quit IRC | 01:25 | |
| *** citypw has joined #symbiflow | 02:05 | |
| *** Degi has quit IRC | 02:27 | |
| *** Degi has joined #symbiflow | 02:28 | |
| *** TMM has quit IRC | 04:08 | |
| *** TMM has joined #symbiflow | 04:09 | |
| *** citypw has quit IRC | 04:12 | |
| *** citypw has joined #symbiflow | 05:47 | |
| *** OmniMancer has joined #symbiflow | 06:16 | |
| *** kgugala has quit IRC | 07:29 | |
| *** kgugala has joined #symbiflow | 07:29 | |
| *** lambda has quit IRC | 10:19 | |
| *** lambda has joined #symbiflow | 10:21 | |
| *** plexj has joined #symbiflow | 11:27 | |
| *** az0re has quit IRC | 11:30 | |
| *** citypw has quit IRC | 11:30 | |
| *** plexj has quit IRC | 12:49 | |
| *** _whitelogger has quit IRC | 13:18 | |
| *** _whitelogger has joined #symbiflow | 13:20 | |
| *** sf-slack4 has joined #symbiflow | 14:09 | |
| *** sf-slack has quit IRC | 14:09 | |
| *** OmniMancer has quit IRC | 15:59 | |
| *** az0re has joined #symbiflow | 15:59 | |
| *** kgugala_ has joined #symbiflow | 17:03 | |
| *** kgugala has quit IRC | 17:04 | |
| *** kgugala has joined #symbiflow | 17:13 | |
| *** kgugala_ has quit IRC | 17:16 | |
| *** kgugala_ has joined #symbiflow | 17:20 | |
| *** kgugala has quit IRC | 17:22 | |
| *** kgugala has joined #symbiflow | 17:23 | |
| *** kgugala_ has quit IRC | 17:25 | |
| *** kgugala_ has joined #symbiflow | 17:31 | |
| *** kgugala has quit IRC | 17:33 | |
| *** kgugala has joined #symbiflow | 17:44 | |
| *** kgugala_ has quit IRC | 17:46 | |
| litghost | hosana: Currently we only build the conda packages for Linux. It is not suprising that OS X is not working yet. This is something we are working on. | 17:53 |
|---|---|---|
| *** pdp7 has left #symbiflow | 18:36 | |
| *** mkru has joined #symbiflow | 18:50 | |
| mkru | Is there any evaluation kit that you would recommend for playing with open source synthesis and implementation? | 18:51 |
| litghost | Depends on your goals. Something like the fomu: https://www.crowdsupply.com/sutajio-kosagi/fomu is tiny, and gets you started | 18:58 |
| tpb | Title: Fomu | Crowd Supply (at www.crowdsupply.com) | 18:58 |
| litghost | If you want something a little bigger and beefier, the digilent series of 7-series boards (Arty, Nexus, Zybo) can scale up to 200k gates | 18:59 |
| litghost | The ECP5 dev boards are also supposed to be good, but I don't know much about them off hand | 18:59 |
| mkru | I would prefer something with PCIe and not from Xilinx | 19:00 |
| mkru | I have found single board on symbiflow website | 19:00 |
| litghost | When you say not from Xilinx, you mean not a Xilinx part or not a Xilinx board? | 19:01 |
| mkru | not a Xilinx part | 19:01 |
| litghost | ECP5 boards I believe are what you looking for | 19:01 |
| litghost | But I'll let others with more experience speak up | 19:02 |
| daveshah | The only ECP5 board with PCIe that is generally available is the Versa | 19:04 |
| daveshah | But, there is no complete open source PCIe IP for the ECP5 ye5 | 19:04 |
| daveshah | *yet | 19:05 |
| daveshah | https://github.com/ECP5-PCIe/ECP5-PCIe is the best work-in-progress | 19:05 |
| litghost | And to dovetail that comment, there are open source PCIe IP for Xilinx 7-series that have been demonstrated | 19:06 |
| daveshah | Indeed | 19:06 |
| mkru | Do you know where it has been demonstrated? | 19:23 |
| litghost | https://twitter.com/enjoy_digital/status/1308453215348887557 | 19:29 |
| sorear | IIRC litepcie is dependent on xilinx soft IP for that | 19:31 |
| litghost | sorear: Oh, :( | 19:31 |
| litghost | Is that also the case for the 7-series PCIe core? | 19:31 |
| litghost | e.g.: https://twitter.com/enjoy_digital/status/1257985111469015040 | 19:32 |
| daveshah | Not sure how much soft IP is involved. More like the Xilinx wrapper around their PCIe hard block | 19:35 |
| mkru | Do all projects using symiflow require nmigen? | 19:36 |
| litghost | The verilog -> bitstream stuff does not. But a lot of the example open IPs do use nMigen | 19:37 |
| mkru | Let's assume I have Xilinx part with PCIe, can I use it with symbiflow without being locked to nMigen? | 19:39 |
| whitequark | yes, absolutely | 19:39 |
| whitequark | I would not say that all symbiflow projects require nMigen, I'm pretty sure most of them don't | 19:40 |
| whitequark | though not like I have statistics | 19:40 |
| whitequark | in fact, when I work on nMigen, I specifically aim to contribute components upstream when possible, e.g. CXXRTL | 19:40 |
| mkru | I struggle to find any tutorial. Everywhere there is nMigen in the first or second sentence ... | 19:41 |
| daveshah | I can't speak for the Xilinx side so well, but the official examples for ECP5, are Verilog | 19:45 |
| daveshah | https://github.com/YosysHQ/prjtrellis/tree/master/examples | 19:45 |
| daveshah | Also note that the open Xilinx PCIe core, litepcie, being discussed is Migen not nMigen | 19:45 |
| daveshah | But in general LiteX stuff is possible to use from Verilog too | 19:46 |
| litghost | The examples for the 7-series are a mixture of Verilog and some LiteX generated | 19:46 |
| litghost | mkru: I also want to clarify something. We have not demonstrated LitePCIe on an open place and route flow yet. Only DDR and ethernet. There is almost certainly more work required to do 7-series PCIe on a fully open flows. However I have no reason to believe at this time it isn't simply a matter of expanding the fuzzers under prjxray to document the relevant bits. | 19:49 |
| sorear | is there a thing anywhere saying what is known to work on 7-series with fully open tools? I had no idea you had DDR working | 19:50 |
| litghost | DDR was working back in march :/ Woops. It is worth noting that it required hacking up the LiteX outputs to make it work, so we've been head down to remove those hacks. | 19:52 |
| litghost | We are getting very close to the point where the outputs directly from LiteX just work. There are just handful of XDC constraints we are working on finishing up | 19:53 |
| litghost | MMCM support is also needed for some targets, as LiteX sometimes wants to use the MMCM instead of the PLL | 19:54 |
| litghost | MMCM support is coming along, but not done yet | 19:54 |
| daveshah | I definitely had the output from LiteX working with nextpnr-xilinx directly at one point, maybe with reduced clock | 19:55 |
| daveshah | But yeah since then there have been quite big changes to LiteX | 19:55 |
| daveshah | That was also just ignoring those xdc constraints... | 19:55 |
| litghost | Ya, we've been working on adding support for the XDC constraints | 19:56 |
| litghost | It's mostly working, but still needs more iterations before it is fully baked | 19:56 |
| daveshah | Mmm | 19:56 |
| mkru | Lets assume I have some stuff written in VHDL, and I use yosys ghdl frontend for synthesis. How do I couple my part of the design with /DDR/Ethernet/PCIe or whatever part related? Do you I need to know LiteX, nMigen? I already use FuseSoc and I am more than happy, I do not want to learn another build tools. | 19:56 |
| litghost | Ah, tcal might have exactly what you want | 19:57 |
| daveshah | LiteX has some generators for generating standalone verilog cores for dram etc | 19:57 |
| mkru | The pictures on the symbiflow mentions tools such as yosys, nextpnr, Verilog to Routing, but examples on github all the time mention Litex or nMigen | 19:58 |
| litghost | So I think we need to seperate something for a minute | 19:58 |
| litghost | yosys consumes VHDL/verilog and generates elaborated netlists. nextpnr/VTR can then consume those elaborated netlists and generate place and routed designs | 19:59 |
| litghost | LiteX/nMigen/etc are generators that create VHDL/verilog/etc | 19:59 |
| litghost | The open P&R tools (generally) don't care where the elaborated netlist originates or what made it | 20:00 |
| litghost | You do need supply useful clock constraints, etc | 20:00 |
| litghost | So there is some coupling there | 20:00 |
| daveshah | Its notable that in general, both LiteX and nMigen put at least equal effort into integration into vendor tools as into open tools | 20:01 |
| mkru | Ok, so if you say, that you have added support for DDR, or you mention that you are working on MMCM, on which level are operating? Does support for such primitives depend on Litex or nMigen? | 20:01 |
| litghost | So MMCM and PHY support (e.g. GTX) are at the place and route level generally | 20:02 |
| litghost | So for 7 series that would be some prjxray work, and then support in the relevant P&R tooling | 20:02 |
| litghost | So as a concrete example, the fact that we got DDR working translates to support OSERDES/ISERDES/IDELAY and relevant differential buffer modes | 20:02 |
| daveshah | It is always possible to use such primitives without LiteX, nMigen, etc in Verilog or VHDL | 20:02 |
| litghost | Exactly | 20:03 |
| daveshah | However, for things like DDR3, there might not actually be an extant raw-Verilog-or-VHDL open source core that uses those primitives | 20:04 |
| daveshah | but that is simply because the people developing those cores have preferred to use a higher level HDL framework for more flexible meta-programming, not because anything stops you from developing one in Verilog | 20:05 |
| mkru | Ok, maybe I should just buy some board and check how it works. I would like to use open source tool chain for FPGA development, and I really honor what you do, but as a new comer I have an impression, that Litex and nMigen are crucial parts on this tool chain. | 20:05 |
| daveshah | It really depends what you are doing. You can, for example, simply treat LiteX the same way as the DDR3 core generator in Vivado which probably has some kind of scripting under its hood, but that's not something that end user considers an integral part of Vivado | 20:07 |
| whitequark | beyond that, as a part of working on nMigen I'm trying to improve cross-language integration; I would like to make it possible for people using Verilog to instantiate nMigen modules easily | 20:08 |
| mkru | Well, they should probably don't even care that some modules use nMigen | 20:11 |
| tcal | Hi mkru: your your "part of the design" -- do you envision it as a bus master controlling its own access to ethernet and DDR peripherals (IP blocks)? I am not yet familiar with FuseSoc -- does it use a standard bus to connect cores/blocks together? | 20:11 |
| mkru | no, it is rather build and dependency management tool. You can use any bus and cores you want, or no bus at all. | 20:12 |
| mkru | It is not build tool focused on SoCs solely, it is much more generic | 20:15 |
| tcal | Thanks mkru, I will probably learn it soon, I've had a few people recommend FuseSoc to me. | 20:16 |
| sf-slack4 | <kgugala> you can always talk to @olof.kindgren | 20:17 |
| sf-slack4 | <kgugala> :) | 20:17 |
| mkru | When you try it, you will realize how people coming from FuseSoc would like to use part related cores | 20:17 |
| daveshah | There was some work on fusesoc+litedram integration: https://github.com/enjoy-digital/litedram/pull/90 but I don't know where that went in the end | 20:19 |
| *** mkru has quit IRC | 20:27 | |
| umarcor | @mkru: in https://im-tomu.github.io/fomu-workshop/hdl.html you will find Verilog, VHDL, Verilog + VHDL and VHDL + Verilog examples using GHDL + Yosys + nextpnr. | 20:31 |
| tpb | Title: Hardware Description Languages FPGA Tomu (Fomu) Workshop documentation (at im-tomu.github.io) | 20:31 |
| umarcor | those examples are for Fomu. But similar makefiles work for e.g. Icestick or TinyFPGA: https://github.com/dbhi/vboard/tree/main/vga, https://github.com/juanmard/screen-pong | 20:33 |
| umarcor | precisely, those makefiles are based on https://github.com/antonblanchard/ghdl-yosys-blink | 20:34 |
| umarcor | Anton's microwatt (VHDL 2008) has been tested on several boards, using open and non-open tools | 20:35 |
| *** az0re has quit IRC | 20:37 | |
| sf-slack4 | <olof.kindgren> Hi @mkru. As @daveshah mentions, there has been work on wrapping Litex cores in FuseSoC generators | 21:22 |
| sf-slack4 | <olof.kindgren> But this will have to be done on a core-by-core basis as there is no common way of acheiving this. The first target will be be LiteDRAM and I have submitted some patches to make integration easier | 21:24 |
| umarcor | overall, I also had the perception that LiteX and/or migen/nmigen are required, but as dave said, that's only because users contributing examples use Python rather than traditional HDLs. | 21:25 |
| sf-slack4 | <olof.kindgren> I use a LiteDRAM core in the (otherwise fully verilog) SweRVolf SoC https://github.com/chipsalliance/Cores-SweRVolf | 21:25 |
| umarcor | in the context of Fomu, I'm looking forward to generating some black-box USB-to-UART core with litex/nmigen, which HDL designers can then instantiate "as a vendor component" | 21:26 |
| sf-slack4 | <olof.kindgren> Right now I generate the LiteDRAM core manually and store the generated verilog, but the ambition is to (optionally) allow users to specify the LiteDRAM generation parameters in the .core file and have it generated on the fly | 21:26 |
| umarcor | FTR, the people working on microwatt is combining a VHDL 2008 SoC with Litedram (Verilog). Simulation is done with GHDL's VHPIDIRECT + Verilator: https://github.com/ghdl/ghdl/issues/1335. | 21:28 |
| sf-slack4 | <olof.kindgren> Next in line would probably be liteETH. I have used the OpenCores ethmac for ten years (I'm even listed as a maintainer) but it just isn't very good and there are surprisingly few good ethernet macs | 21:28 |
| sf-slack4 | <olof.kindgren> FTR, Microwatt has FuseSoC support too. | 21:29 |
| umarcor | indeed... microwatt and litedram have fusesoc *.core files: https://github.com/antonblanchard/microwatt/blob/master/litedram/litedram.core and https://github.com/antonblanchard/microwatt/blob/master/microwatt.core | 21:30 |
| umarcor | however, I'm not sure about microwatt being tested on open source boards using open source tools only | 21:33 |
| sf-slack4 | <olof.kindgren> Don't know that either. I just submitted support for running on a Nexys A7 | 21:37 |
| umarcor | on the one hand, I know they have tested it on Digilent boards. on the other hand, I know that Anton was tinkering with GHDL + Yosys and the OrangeCrab. but I don't remember any tweet/comment combining both. | 21:39 |
| umarcor | https://youtu.be/N-_9dWdvLBA?t=771 | 21:42 |
| sf-slack4 | <cjearls> I have a Genesys2 board with a Xilinx Kintex-7 FPGA in it, what's the current status on the Kintex-7? Anything usable? | 21:50 |
| litghost | cjearls: Most focus has been on Artix and Zynq support, but we have the ability to create bitstreams for Kintex-7. We have not had someone try to stand-up support for it and test it. I believe if the Genesys2 part is in WebPack, it should be possible to add the fabric data for it, and add support for it. | 21:57 |
| daveshah | I don't think it is in WebPack | 21:59 |
| daveshah | Unless they've changed the threshold recently | 21:59 |
| sf-slack4 | <cjearls> It is not in WebPack, Digilent provides board files for it | 21:59 |
| litghost | So it not being in WebPack means that the current way we generate the prjxray data won't work without a significant amount of effort. However, I believe if you have a version of Vivado that runs locally, you could in theory run the fuzzers yourself. However because we haven't tested on that part, it means you will likely hit edge cases we are not prepared to handle | 22:01 |
| daveshah | Does prjxray have hpio yet? I had a brief look at making it work a while ago, as I have that board too, but that was one of the limitations | 22:02 |
| daveshah | A lot of the interesting IO is hpio | 22:02 |
| sf-slack4 | <cjearls> I see. I have a local version of Vivado, but I haven't ever used Symbiflow, so it sounds like getting it working for my board will probably be too difficult for me right now | 22:02 |
| litghost | prjxray does not have HPIO fuzzers right now | 22:02 |
| litghost | Do any WebPack parts have HPIO banks? | 22:03 |
| daveshah | Yeah, that means you'd pretty much need an ROI with that board | 22:03 |
| daveshah | I think the k70 probably does | 22:03 |
| litghost | Oh good | 22:03 |
| litghost | Well we have the basic database for the k70, so someone could write a HPIO fuzzer | 22:03 |
| litghost | Given the focus on the Artix and Zynq parts, I don't believe there has been a need to get a HPIO fuzzer stood up | 22:04 |
| daveshah | And if you don't care about the fancier modes, the existing HRIO fuzzer with the higher voltages removed would probably be a good base | 22:05 |
| daveshah | Likewise the HPIO IOLOGIC is a tiny bit different (adds the ODELAY) | 22:06 |
| sf-slack4 | <cjearls> Do you have a recommendation for hardware to use to get involved for someone new? I have my Bachelor's degree in Computer Engineering and am currently working on my Master's degree, so I have hardware and software design experience. | 22:06 |
| daveshah | Depends what you want to do. icebreaker, ULX3S and Arty A35T are all quite well supported boards | 22:07 |
| umarcor | cjearls, how much I/O do you want? do you need DDR? | 22:07 |
| sf-slack4 | <cjearls> I'm not sure about how much I/O. I'd like to do some RISC-V designs in the future, so I think I'd like DDR | 22:09 |
| umarcor | for tinkering with RISC-V from a computer architecture and SoC design perspective, I believe that absolutely any board will fit. just need to scale the design, and there are some really tiny cores out there. | 22:10 |
| sorear | you may have trouble with ice40lp384 ;) | 22:11 |
| umarcor | if you want to then run Linux and do some "acceptable" processing, DDR might be desirable. but you should first have some application that needs to crunch data fast. | 22:12 |
| sorear | possibly more important question: what is your budget | 22:12 |
| umarcor | sorear: that's true :), not the smallest, but UP5K, HX1K, HX4K, HX8K, ECP5, Artys... | 22:12 |
| sorear | there are a lot of good ca. 100 USD boards, if you're trying to go much less than that there are difficult choices | 22:12 |
| umarcor | sorear: which boards are you thinking about? On the open source side, I think 50-75€ is an acceptable budget (60-120 USB). | 22:15 |
| sf-slack4 | <cjearls> I don't have a set budget, just nothing too crazy into the several hundreds of US dollars | 22:16 |
| sf-slack4 | <cjearls> Both of those budgets sound reasonable to me | 22:17 |
| umarcor | There are a bunch of boards fiting that budget which are now listed in lattice's website: https://www.latticesemi.com/en/Solutions/Solutions/SolutionsDetails01/CommunitySourced | 22:18 |
| tpb | Title: Community Sourced - Lattice Semiconductor (at www.latticesemi.com) | 22:18 |
| sf-slack4 | <cjearls> Oh, awesome, I didn't realize that they were listed on their website, that's great | 22:19 |
| umarcor | icebreaker, icesugar, alhambra, doppler, blackice... all of those are the same concept: uC or FTDI + FPGA. the price is similar too. so it's mostly a matter of taste. | 22:20 |
| umarcor | tinyfpga and Fomu don't have an auxiliary uC or FTDI. Instead, they have an HDL bootloader. | 22:21 |
| umarcor | orangecrab, matt venn's ecp5 dev board, radiona's ULX3S... those have the more capable ECP5 FPGAs, instead of ICE40 family devices (as all the previous). | 22:23 |
| sorear | if you want to do computer architecture with more than 16 kB of RAM you want something with a ddr interface | 22:23 |
| sf-slack4 | <cjearls> A DDR interface allowing for connecting external DDR, or DDR on the board itself? | 22:24 |
| umarcor | from there on, I would look into Digilent and AVNET boards. which are traditional vendors for Xilinx dev boards. | 22:24 |
| umarcor | cjearls: typically, on the board itself | 22:26 |
| sf-slack4 | <cjearls> I see, so the amount of RAM the board comes with is the maximum that will be available | 22:26 |
| umarcor | for the <150USD boards yes | 22:27 |
| umarcor | those are "low-cost" development boards | 22:27 |
| umarcor | the mid-range boards (500-2000 USD) might have RAM sockets for you to plug SODIMM or so | 22:28 |
| sf-slack4 | <cjearls> Alright, sounds good. I'll probably start off with something cheap to get my feet wet | 22:29 |
| sf-slack4 | <cjearls> Other than the amount of RAM, are there other things I should consider? | 22:30 |
| umarcor | I would look at what I expect to connect the board to: VGA/HDMI/Ethernet, camera interfaces, displays, etc. However, if you plant to focus on computer architecture and the full system stack, those are mostly irrelevant. | 22:33 |
| sorear | make sure the fpga chip is compatible with the tools you intend to use | 22:35 |
| umarcor | compare, for example https://1bitsquared.com/products/orangecrab and https://radiona.org/ulx3s/ Same heart (FPGA), but completely different target use cases | 22:36 |
| tpb | Title: ULX3S (at radiona.org) | 22:36 |
| sorear | remember that "Kb" means kilobits, not kilobytes | 22:38 |
| *** _whitelogger has quit IRC | 23:13 | |
| *** _whitelogger has joined #symbiflow | 23:15 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!