| *** tpb has joined #litex | 00:00 | |
| *** FFY00 has quit IRC | 00:08 | |
| *** FFY00 has joined #litex | 00:08 | |
| *** FFY00 has quit IRC | 00:49 | |
| *** _whitelogger has quit IRC | 01:42 | |
| *** _whitelogger has joined #litex | 01:44 | |
| *** CarlFK has quit IRC | 01:45 | |
| *** CarlFK has joined #litex | 01:58 | |
| *** Degi has quit IRC | 02:36 | |
| *** Degi has joined #litex | 02:36 | |
| *** CarlFK has quit IRC | 02:36 | |
| *** CarlFK has joined #litex | 02:41 | |
| *** andrewb1999 has quit IRC | 02:49 | |
| *** CarlFK has quit IRC | 03:23 | |
| *** CarlFK has joined #litex | 03:28 | |
| *** _whitelogger has quit IRC | 04:45 | |
| *** _whitelogger has joined #litex | 04:47 | |
| *** indy has joined #litex | 06:05 | |
| *** _whitelogger has quit IRC | 06:27 | |
| *** _whitelogger has joined #litex | 06:29 | |
| 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) | 06:34 |
| _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) | 08:15 |
| *** awordnot has quit IRC | 08:42 | |
| *** awordnot has joined #litex | 08:43 | |
| *** indy has quit IRC | 08:45 | |
| *** shorne has quit IRC | 08:51 | |
| *** indy_ has joined #litex | 08:53 | |
| *** shorne has joined #litex | 08:57 | |
| lkcl | zyp, _florent_: appreciated. can i recommend some features to be added there? these are mainly for ASICs | 09:12 |
| lkcl | 1) a pinmux. (obviously in FPGAs you don't want one, you just rebuild the bitstream with a different peripheral set, duh) | 09:13 |
| lkcl | 2) JTAG boundary scanning. this involves close-coordinating of the pin-peripheral definitions | 09:15 |
| 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:16 |
| 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:18 |
| 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:20 |
| 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:21 |
| lkcl | nmigen would have noticed that the signal was "attempted to be driven from multiple sources" | 09:22 |
| *** _whitelogger has quit IRC | 10:00 | |
| *** _whitelogger has joined #litex | 10:02 | |
| *** lambda has quit IRC | 10:28 | |
| lkcl | other things that i feel should be on the "long-term" list: | 10:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:36 |
| 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:37 |
| 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:39 |
| lkcl | based around collaboration and cooperation and standardisation | 10:40 |
| 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:35 |
| 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. | 12:36 |
| *** Degi has quit IRC | 12:56 | |
| *** FFY00 has joined #litex | 12:56 | |
| *** Degi has joined #litex | 12:56 | |
| *** andrewb1999 has joined #litex | 14:21 | |
| *** andrewb1999 has quit IRC | 14:24 | |
| 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:27 |
| 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:30 |
| 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:31 |
| 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. | 14:32 |
| *** benh has quit IRC | 14:50 | |
| 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) | 15:14 |
| *** Felkin has joined #litex | 15:49 | |
| _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:01 |
| 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:06 |
| _florent_ | st-gourichon-fid: thanks for the PRs! i'll look at this a this a bit later | 16:07 |
| 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:08 |
| _florent_ | st-gourichon-fid: i think the -R could indeed be a good idea but i'll do some tests before merging | 16:15 |
| _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:16 |
| _florent_ | pepijndevos: ^ could it be the issue you had on Gowin with Vexriscv? | 16:17 |
| pepijndevos | wah? lemme read back a bit | 16:17 |
| _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:18 |
| pepijndevos | I have no idea, maybe? | 16:22 |
| _florent_ | pepijndevos: were you using the minimal variant? | 16:23 |
| pepijndevos | yyyyyea, most of the time at least | 16:23 |
| _florent_ | ok, i could also do the test, but I still haven't installed the Gowin toolchain... | 16:24 |
| 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:25 |
| _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:33 |
| pepijndevos | If there is nothing obviously wrong... | 16:34 |
| *** benh has joined #litex | 16:34 | |
| 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:45 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:51 |
| _florent_ | yeah, things that seem obvious now weren't before because nothing existed :) | 16:54 |
| _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:55 |
| _florent_ | pepijndevos: ah ok interesting | 16:56 |
| *** kgugala_ has joined #litex | 16:59 | |
| *** kgugala has quit IRC | 17:03 | |
| _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 | 17:04 |
| *** kgugala_ has quit IRC | 17:04 | |
| *** kgugala has joined #litex | 17:05 | |
| *** KSmith has joined #litex | 17:58 | |
| 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:20 |
| 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:29 |
| *** KSmith has quit IRC | 18:29 | |
| *** KSmith has joined #litex | 18:31 | |
| 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:38 |
| Felkin | The SoC builder seems to hide it, at least from what i gather from Vivado's cryptic messages. | 18:39 |
| 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:42 |
| leons | Is the signal value implicitly 0 when it's not set as part of a combinational statement? | 18:43 |
| 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:46 |
| leons | Nevermind, the minute you ask you of course find the piece of documentation that says that migen can't produce latches | 18:48 |
| *** KSmith has quit IRC | 19:00 | |
| *** tucanae47__ has joined #litex | 20:19 | |
| *** guan_ has joined #litex | 20:20 | |
| *** tucanae47 has quit IRC | 20:25 | |
| *** benh has quit IRC | 20:25 | |
| *** guan has quit IRC | 20:25 | |
| *** midnight has quit IRC | 20:25 | |
| *** tucanae47__ is now known as tucanae47 | 20:25 | |
| *** guan_ is now known as guan | 20:25 | |
| *** benh has joined #litex | 20:27 | |
| *** midnight has joined #litex | 20:28 | |
| *** Felkin has quit IRC | 21:51 | |
| *** guan has quit IRC | 22:14 | |
| *** guan has joined #litex | 22:18 | |
| *** lf has quit IRC | 23:11 | |
| *** lf has joined #litex | 23:11 | |
| *** _whitelogger has quit IRC | 23:39 | |
| *** _whitelogger has joined #litex | 23:41 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!