| *** tpb has joined #litex | 00:00 | |
| *** _whitelogger has quit IRC | 01:42 | |
| *** _whitelogger has joined #litex | 01:44 | |
| *** jaseg has quit IRC | 02:31 | |
| *** jaseg has joined #litex | 02:33 | |
| *** Degi has quit IRC | 03:17 | |
| *** Degi has joined #litex | 03:20 | |
| *** TMM has quit IRC | 03:35 | |
| *** TMM has joined #litex | 03:35 | |
| *** _whitelogger has quit IRC | 04:18 | |
| *** _whitelogger has joined #litex | 04:20 | |
| *** avg has quit IRC | 06:13 | |
| *** nrossi has joined #litex | 07:40 | |
| *** carlomaragno has quit IRC | 09:45 | |
| *** carlomaragno has joined #litex | 09:47 | |
| *** benh has quit IRC | 09:47 | |
| *** benh has joined #litex | 09:47 | |
| keesj | lkcl__: sounds ... very cool | 10:19 |
|---|---|---|
| keesj | is this an open source project you can share? | 10:20 |
| 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:23 |
| 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:27 |
| daveshah | The usual ASIC solution, aiui, is a power on async reset | 10:28 |
| shorne | Is anyone maintaining the liteeth linux driver, I have a few cleanups for it. But it seems pretty obvious | 13:05 |
| 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:06 |
| 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:36 |
| 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:38 |
| lkcl__ | so you _have_ to wire in a reset pretty much everywhere | 13:39 |
| 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. | 13:41 |
| lkcl__ | + | 14:29 |
| 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:44 |
| 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 :) ) | 14:45 |
| *** proteusguy has quit IRC | 14:56 | |
| *** proteusguy has joined #litex | 15:10 | |
| *** CarlFK has quit IRC | 15:21 | |
| *** Felkin has joined #litex | 15:33 | |
| *** Felkin has quit IRC | 15:40 | |
| *** CarlFK has joined #litex | 17:05 | |
| *** _whitelogger has quit IRC | 17:57 | |
| ranzbak | When I do 'self.comb += board_leds[0].eq(counter[24])' it sets the first bit of my signal, but it also clears the other bits, what can I do other than concatinating to set just one bit in an array? | 17:58 |
| *** _whitelogger has joined #litex | 17:59 | |
| *** acathla has quit IRC | 18:00 | |
| 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:03 |
| *** acathla has joined #litex | 18:03 | |
| 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:04 |
| *** acathla has quit IRC | 18:05 | |
| *** acathla has joined #litex | 18:05 | |
| 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:06 |
| ranzbak | But I'll go to the Migen channel, that might be a better place :-) | 18:07 |
| 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:31 |
| 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:35 |
| 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:38 |
| 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:40 |
| 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:41 |
| 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:55 |
| ranzbak | keesj: Isn't that cumbersome, or am I missing other features in Migen that make it very efficient? | 19:56 |
| 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:06 |
| _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:25 |
| 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:26 |
| 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:27 |
| _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:30 |
| shorne | somlo: ok | 20:48 |
| 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 :) | 20:59 |
| leons | Sorry, nevermind, 1MBd/s was not picocoms manpage :) | 21:03 |
| *** lf has quit IRC | 23:32 | |
| *** lf has joined #litex | 23:33 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!