10:19 <keesj> lkcl__: sounds ... very cool

10:20 <keesj> is this an open source project you can share?

10:23 <keesj> I .. am also kinda wondering.. some things can not be done in ASIC as far as i know e.g. initial values after reset. who will validate this / who is responsible for this

10:23 <keesj> I also heard that the ice40 also can not do this but that the open toolchain works around this

10:27 <daveshah> ice40 is different to an ASIC as in iCE40 all FFs init to zero, whereas in most ASIC technologies they init to undefined

10:27 <daveshah> So for iCE40 arbitrary initialisation can be done by wrapping 1-initialised FFs in inverters by Yosys to make them 0-initialised

10:28 <daveshah> The usual ASIC solution, aiui, is a power on async reset

13:05 <shorne> Is anyone maintaining the liteeth linux driver, I have a few cleanups for it. But it seems pretty obvious

13:06 <shorne> Also, I found the csr2dts generation is not working so well, for example it didn't specify interrupts in the dts. I had to manually add those

13:06 <shorne> maybe I am doing something wrong, using the latest version of litex-buildenv from last week

13:36 <lkcl__> keesj: http://git.libre-soc.org https://libre-soc.org/3d_gpu/

13:36 <tpb> Title: git.libre-soc.org Git (at git.libre-soc.org)

13:38 <lkcl__> keesj: the "problem" with ASICs is that power-on has total garbage from whatever stray capacitance happened to be floating around at the time, all the gates go "argh i have no idea if i'm on or off, errr i'll pick one"

13:39 <lkcl__> so you _have_ to wire in a reset pretty much everywhere

13:41 <lkcl__> sometimes however you actually don't care, such as clock-gated pipelines. you would just run those "empty" for a few cycles, just long enough for the valid/ready signals to pop out the other end of the pipeline.

14:29 <lkcl__> +

14:44 <somlo> shorne: I've been collecting (and, to the best of my limited time and abilities, trying to "curate") some linux drivers here: https://github.com/litex-hub/linux/tree/litex-rocket-rebase

14:44 <tpb> Title: GitHub - litex-hub/linux at litex-rocket-rebase (at github.com)

14:45 <somlo> if your liteeth patches can be tested on top of what's there using 64-bit rocket chip, I can test them and add your patch there -- I'm hoping someone at some point in the future will collect all that stuff and do a final rebase before pushing it all upstream (preferably in a way tha works not just on 32-bit CPUs with 8-bit litex-csr data width :) )

18:03 <CarlFK> ranzbak: this might be it, but I am not at all a tomo/fomu hacker:

18:03 <CarlFK> >>> l = [0,0,0,0]; l[2]=1;l

18:03 <CarlFK> [0, 0, 1, 0]

18:04 <ranzbak> The problem is, that when you set bit 3 after that, only bit three will be set, because it's the last rule that is applied to the array.

18:06 <ranzbak> l = [0,0,0,0]; l[2]=1; l[3]=1;l

18:06 <ranzbak> [0, 0, 1, 1]y

18:06 <ranzbak> hmm

18:06 <ranzbak> This way it does work, but not when I run it on my FPGA.

18:07 <ranzbak> But I'll go to the Migen channel, that might be a better place :-)

19:31 <leons> My Arty A7 arrived yesterday and after setting up the monster that is Vivado, LiteX straight up works out of the box. I'm really impressed. :)

19:35 <leons> Unfortunately, using --with-ethernet fails at linking the BIOS image since the rom-region overflows by 1412 bytes. Is there anything I can do about this? Can I simply adjust the rom region's length? Currently trying to figure out how/where regions.ld is generated

19:35 <keesj> leons: that is pretty cool (LiteX does depend on Vivado but we are going to ignore that for now) what .. problems did you encounter?

19:38 <keesj> ranzbak: .... I find that hard to believe but in the code you are not concatenating you are assigning counter[24] do a led[0]

19:38 <leons> keesj: I've really only generated a few gatewares and looked around the source, changing a few bits here and there.

19:40 <leons> But now I'm running a clean LiteX installation, unfortunately encountering the linker error while building the BIOS when running `./arty.py --build --with-ethernet` as outlined above

19:41 <keesj> Concatenations are done using the Cat object(from the https://m-labs.hk/migen/manual/fhdl.html documentation)

19:41 <tpb> Title: The FHDL domain-specific language Migen 0.8.dev0 documentation (at m-labs.hk)

19:55 <ranzbak> keesj: That's what I was kind of hoping for not to be the case, but I have to use a concatenation in order to assign a bit in a register array.

19:56 <ranzbak> keesj: Isn't that cumbersome, or am I missing other features in Migen that make it very efficient?

20:06 <leons> This hack seems to do the trick to get the BIOS building for Arty with ethernet: kwargs["integrated_rom_size"] = 0xb000 if with_ethernet else 0x8000

20:06 <leons> If it doesn't work out of the box (and other people can reproduce my behavior), is this a bug in LiteX then?

20:25 <_florent_> leons: it's possible the BIOS size increased a little bit recently (i should have a closer look), to workaround the issue, you can also add --integrated-rom-size=0xb0000 to ./arty.py --with-ethernet --build

20:26 <leons> _florent_: I've just now realized that the target python script also has a help which documents it! probably good practice to go through the source anyways :)

20:27 <leons> But yes, that's the issue I suspected. Adding ethernet seems to grow it just above the rom size (only about 1.5kB)

20:30 <_florent_> i've also been thinking recently about making the BIOS size dynamic to avoid this: first just build the BIOS with a large ROM (just to determine the size) and reduce it when building

20:48 <shorne> somlo: ok

20:59 <leons> _florent_: You wouldn't by chance know what the default tty baudrate of the prebuild gateware (incl BIOS) of the linux-on-litex-vexriscv is? I tried all imaginable ones, but I'm only reading gibberish :)

21:03 <leons> Sorry, nevermind, 1MBd/s was not picocoms manpage :)