06:34 <zyp> lkcl, there's some discussion around switching to nmigen in here: https://github.com/enjoy-digital/litex/issues/372

06:34 <tpb> Title: LiteX 2020 roadmap and new LiteX SoC class · Issue #372 · enjoy-digital/litex · GitHub (at github.com)

08:15 <_florent_> lkcl: i also wrote this which gives a bit of context: https://github.com/enjoy-digital/litex/wiki/Migen-nMigen

08:15 <tpb> Title: Migen nMigen · enjoy-digital/litex Wiki · GitHub (at github.com)

09:12 <lkcl> zyp, _florent_: appreciated. can i recommend some features to be added there? these are mainly for ASICs

09:13 <lkcl> 1) a pinmux. (obviously in FPGAs you don't want one, you just rebuild the bitstream with a different peripheral set, duh)

09:15 <lkcl> 2) JTAG boundary scanning. this involves close-coordinating of the pin-peripheral definitions

09:16 <lkcl> in the core itself then back again, right now, because litex doesn't include a JTAG TAP itself.

09:16 <lkcl> i describe the full process here https://bugs.libre-soc.org/show_bug.cgi?id=490#c27

09:16 <tpb> Title: 490 Complete peripheral set including litex for first functional POWER9 Core (at bugs.libre-soc.org)

09:18 <lkcl> 3) JSON-based pin / peripheral definitions. basically "_io" from Platforms but moved to a JSON file-format. just like in OpenTITAN except consulting widely with the community before proceeding with a design

09:20 <lkcl> i have to say that i love litex for how much time it saves: however the two incidents i've had with migen make me reticent to recommend or commit to it long-term.

09:20 <lkcl> the first was accidentally mixing sync and comb in a FSM. *no warning* whatsoever was given. this was a silent failure that was not even picked up by verilator.

09:21 <lkcl> the second was an incorrect IO platform definition that created an input rather than an output. verilator didn't notice: it was only when compiling the actual ASIC under coriolis2 that the mistake was detected.

09:22 <lkcl> nmigen would have noticed that the signal was "attempted to be driven from multiple sources"

10:29 <lkcl> other things that i feel should be on the "long-term" list:

10:30 <lkcl> 4) auto-generation of documentation of pinouts. this is done by the pinmux program https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/ls180.py;hb=HEAD

10:30 <tpb> Title: git.libre-soc.org Git - pinmux.git/blob - src/spec/ls180.py (at git.libre-soc.org)

10:30 <lkcl> an example result is here https://libre-soc.org/180nm_Oct2020/ls180/

10:30 <tpb> Title: ls180 (at libre-soc.org)

10:31 <lkcl> 5) auto-generation of full and comprehensive linux and u-boot and other OS header files and helper functions. particularly important for GPIO and particularly important for pinmux-based GPIO.

10:32 <lkcl> 5) auto-generation of device-tree files. this *is* quite big, is essential, and is what OpenTITAN does. this includes *all* features of the SoC that would normally be done "by hand".

10:34 <lkcl> every single one of those things is a nightmare recipe for the introduction of manual transcription errors that damage a SoC's adoption, require huge amounts of time to write manually, and are completely unnecessary to write manually.

10:36 <lkcl> 6) have all peripherals (even the bit-banging ones) take a "class" (or class instance) for the PHY. this to make it possible to do ASICs easily.

10:37 <lkcl> currently i have had to cut/paste copy-replicated pretty much every single one of the litex peripherals into libre-soc in order to change them to support _i/_o/_oe PHYs.

10:37 <lkcl> the only one that i didn't have to do that to is SDRAM because it's already been PHY-i-fied :)

10:39 <lkcl> last thing: about the csv/json export: i'd recommend there, don't make it an afterthought: split litex right down the middle based *on* csv and/or json file-formats, in exactly the same way that OpenTITAN does.

10:39 <lkcl> at that point you could hypothetically actually support OpenTITAN's JSON file-format (and tools)

10:40 <lkcl> based around collaboration and cooperation and standardisation

12:35 <st-gourichon-fid> Hi! When pushing a design using dfu-util, on some machines the -R option of dfu-util is needed.

12:35 <st-gourichon-fid> Is there any circumstance where a -R would cause a problem?

12:36 <st-gourichon-fid> I ask because DFUProg class does not issue -R, code is at https://github.com/enjoy-digital/litex/blob/master/litex/build/dfu.py#L24

12:36 <tpb> Title: litex/dfu.py at master · enjoy-digital/litex · GitHub (at github.com)

12:36 <st-gourichon-fid> Opened https://github.com/enjoy-digital/litex/pull/662

12:36 <tpb> Title: Unconditionally ask dfu-util to "Issue USB Reset" by fidergo-stephane-gourichon · Pull Request #662 · enjoy-digital/litex · GitHub (at github.com)

12:36 <st-gourichon-fid> I can't imagine a situation where -R would break anything, that's why I ask here.

14:27 <st-gourichon-fid> We have a simple design that can run with a VexRiscV or SERV. Testing BIOD features mem_speed mem_test. With VexRiscV flush_cpu_dcache hangs the system. Any idea? Apparently this function only send ASM .word(0x500F), cf. https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv/system.h#L33

14:27 <tpb> Title: litex/system.h at master · enjoy-digital/litex · GitHub (at github.com)

14:27 <st-gourichon-fid> s/BIOD/BIOS/

14:30 <st-gourichon-fid> We use --cpu-variant=minimal where void flush_cpu_dcache(void) should do nothing. CONFIG_CPU_VARIANT_MIN is *not* defined, and probably should be.

14:31 <st-gourichon-fid> Ah, I think I found it MINIMAL != MIN . Code generates build/software/include/generated/soc.h:16:#define CONFIG_CPU_VARIANT_MINIMAL but test is for CONFIG_CPU_VARIANT_MIN.

14:32 <st-gourichon-fid> xobs1, _florent_, which is the correct one, CONFIG_CPU_VARIANT_MIN or CONFIG_CPU_VARIANT_MINIMAL? I can offer a PR if useful.

15:14 <st-gourichon-fid> Created https://github.com/enjoy-digital/litex/pull/663

15:14 <tpb> Title: Fix SoC CPU crash on minimal variants on call to flush_cpu_dcache(). by fidergo-stephane-gourichon · Pull Request #663 · enjoy-digital/litex · GitHub (at github.com)

16:01 <_florent_> lkcl: thanks for the ideas, things are improving slowly in this direction, that would need to be added to a 2021-2022 roadmap :) but keep in mind that LiteX's initial aim is just to have a tool to create FPGA based SoCs efficiently. It happens to be used for different purpose now by the community and it's great, but most of the systems i still create with it don't even have a CPU in the FPGA :)

16:06 <st-gourichon-fid> Created https://github.com/enjoy-digital/litex/pull/665

16:06 <tpb> Title: More precise log by fidergo-stephane-gourichon · Pull Request #665 · enjoy-digital/litex · GitHub (at github.com)

16:07 <_florent_> st-gourichon-fid: thanks for the PRs! i'll look at this a this a bit later

16:08 <st-gourichon-fid> _florent_, thanks for your kind attention. Some seem pretty relevant, for the one on adding -R to dfu-util I'm not sure if it could cause any regression on other machines.

16:15 <_florent_> st-gourichon-fid: i think the -R could indeed be a good idea but i'll do some tests before merging

16:16 <_florent_> nice catch otherwise for the Minimal Vexriscv variant

16:16 <st-gourichon-fid> Happy to help :-)

16:16 <st-gourichon-fid> Refining the one on performance measurement (the last one).

16:17 <_florent_> pepijndevos: ^ could it be the issue you had on Gowin with Vexriscv?

16:17 <pepijndevos> wah? lemme read back a bit

16:18 <_florent_> this one: https://github.com/enjoy-digital/litex/pull/663

16:18 <tpb> Title: Fix SoC CPU crash on minimal variants on call to flush_cpu_dcache(). by fidergo-stephane-gourichon · Pull Request #663 · enjoy-digital/litex · GitHub (at github.com)

16:22 <pepijndevos> I have no idea, maybe?

16:23 <_florent_> pepijndevos: were you using the minimal variant?

16:23 <pepijndevos> yyyyyea, most of the time at least

16:24 <_florent_> ok, i could also do the test, but I still haven't installed the Gowin toolchain...

16:25 <pepijndevos> I'll have a look after dinner

16:25 <pepijndevos> Not too excited about trying to merge a branch into my branch and not destroying everything

16:33 <_florent_> pepijndevos: btw, i'm ok merging you initial gowin build support and TEC0117 PRs, it will also make things easier for me (for the same reasons :))

16:33 <pepijndevos> yea go ahead

16:34 <pepijndevos> If there is nothing obviously wrong...

16:45 <lkcl> _florent_: well, the lack of "CPUs" is actually a really good thing because it ensures full independence. OpenTITAN is fantastic... yet fundamentally it's not a "peripheral inter-connect", it's a "RISC-V inter-connect".

16:47 <lkcl> over the next 6 months we *need* a "pinmux plus peripheral" home, if you know what i mean.

16:47 <lkcl> we've got NLnet funding (and could likely help you to apply for a EUR 50,000 Grant of your own)

16:48 <st-gourichon-fid> Refined https://github.com/enjoy-digital/litex/pull/665 . Now speed is done with a precise computation. Previous computation underestimated a lot, and even replacing 1000000 with 1000 did not provide precise figures in kb/s. Now figures are consistent whatever the size of the tested range.

16:48 <tpb> Title: More precise log by fidergo-stephane-gourichon · Pull Request #665 · enjoy-digital/litex · GitHub (at github.com)

16:49 <lkcl> i think what i'm saying is: *if* we choose litex as the Libre-SOC "peripheral interconnect home" (for both FPGA and ASIC versions) would you be happy to accept (clean, clear, reviewed) patches?

16:51 <lkcl> a lot of things, such as the kernel header files, technical manuals, and device-tree files can be done as external components based off of the JSON/CSV format

16:54 <_florent_> yeah, things that seem obvious now weren't before because nothing existed :)

16:55 <_florent_> i'm ok going in this direction, but it's not mandatory to integrate everything in LiteX, just the features that ease/allow other project to be built with it

16:55 <pepijndevos> _florent_, FYI you might not need the Gowin license for the TCL shell, not 100% sure. But saves a bit hurdle.

16:55 <_florent_> at least in a first time, to mature things

16:56 <_florent_> pepijndevos: ah ok interesting

17:04 <_florent_> lkcl: thanks for the NLnet offer, i already have lots of other commitments, i'm better just helping a bit on this for now

18:20 <pepijndevos> _florent_, good news! vexrisc boots to console now

18:20 <pepijndevos> I assume my kernel failures are just my failure to link something in a way that does not conflict wit the bios

18:29 <KSmith> hey guys im quite new to using litex and am attempting to install a prebuilt for the nexys4ddr linux-on-litex-vexriscv https://github.com/litex-hub/linux-on-litex-vexriscv following the instructions,

18:29 <KSmith> the near future

18:29 <tpb> Title: GitHub - litex-hub/linux-on-litex-vexriscv: Linux on LiteX-VexRiscv (at github.com)

18:29 <KSmith> -Installing Verilator(isnt particularly required at the moment but thought may come in handy in the future)

18:38 <Felkin> My struggles with pynq - litex integration continue TT Seems like vivado refuses to generate .hwh files for the pynq overlay system unless the litex soc is put in a block design and wrapped with a top hdl. It also seems to need to see the ps7 core.

18:39 <Felkin> The SoC builder seems to hide it, at least from what i gather from Vivado's cryptic messages.

18:42 <leons> While debugging interrupt-driven UART i'm wondering about the following line:

18:42 <leons> https://github.com/enjoy-digital/litex/blob/6916674ff6771b7f0dec11c2d18737abe16d3c95/litex/soc/interconnect/csr_eventmanager.py#L152

18:42 <tpb> Title: litex/csr_eventmanager.py at 6916674ff6771b7f0dec11c2d18737abe16d3c95 · enjoy-digital/litex · GitHub (at github.com)

18:42 <leons> As part of a combinational statement it sets clear to 1, however I can't find any location where the Signal clear is then reset to 0

18:43 <leons> Is the signal value implicitly 0 when it's not set as part of a combinational statement?

18:46 <leons> I would've guessed this would infer a latch but I'm at a level of despair where I don't trust such intuitions anymore :)

18:48 <leons> Nevermind, the minute you ask you of course find the piece of documentation that says that migen can't produce latches