05:53 <shorne> OK, I am going to try to swith to litex-boards from litex-buildenv for my or1k development starting now :)

12:18 <Dolu> mithro : First there should be a FPU for Vex 32 bits ^^

18:51 <mithro> Dolu: I think FPU type stuff is a very different kettle of fish to 64bit VexRISCV

18:52 <mithro> Dolu: There was an interesting thought about the idea of keeping a 32bit data pathway in VexRISCV while supporting 64bit by having things like multiple cycle adds

18:53 <mithro> Dolu: I was also wondering if there are easy ways to optimize the 64bit add by skipping adding the top 32bit if they are all zero

18:54 <mithro> Dolu: Then I was wondering if it made sense to try and to something like a 4 cycle 16bit type thing for small FPGAs...

18:55 <mithro> Dolu: We should probably chat more

18:55 <mithro> daveshah: The AMD/NVIDIA trick is not owning a foundry meaning your at the mercy of others to actually deliver parts and hence can adapt the demand very quickly

19:02 <sorear> IIUC some versions of the pentium 4 had a pipeline stage inserted in the adder between the left and right halves

19:03 <sorear> so you could do a 64-bit add in each alu each cycle but the critical path only went through 32 bits

19:03 <sorear> hazard detection gets uglier (you can follow an add immediately with another add or a shl but a shr needs a bubble)

19:40 <mithro> sorear: The big question is that muxes are super expensive in FPGAs, so it is unclear to me if you would end up winning or not

19:43 <daveshah> I think the most useful thing to do first is look at the timing/area increase going to a 64-bit datapath in VexRiscv

19:43 <daveshah> Doesn't even have to be a working RV64, just would be interesting to guide optimisations

19:44 <daveshah> Given how fast dedicated carry logic is in FPGAs, I don't think 64 bit adds in themselves will be such a big problem

19:44 <sorear> if you start with 31 64-bit GPRs and 32 64-bit FPRs, then reformat as 16 bits, you have 255x16 almost the exact size of an ice40 bram

20:31 <Finde> sorear: I was told the above too about the P4

20:31 <Finde> but I was further told it was run at a higher clock... not sure about that part

20:44 <sorear> these aren't incompatible, the rest of the chip runs at 3.5GHz and can do 64-bit adds in a cycle, the 7GHz double pumped ALU needs the split hack

21:47 <shorne> one issue with litex-boards over litex-buildenv is the ip range of litex seems locked to 192.168.1.x on litex-boards, we could configure that with litex-buildenv

21:59 <somlo> shorne: the default IP addresses for netboot are in litex/soc/software/bios/boot.c; I assume litex-buildenv somehow provided an include file that defined them before the preprocessor got to that file, so the `#ifndef` was already false by then

22:01 <somlo> it should probably be relatively easy to allow them to be overridden via the target specific build files; personally, I find it relatively easy to add 192.168.1.100/24 as a secondary IP on my tftp server; once the kernel boots, it can dhcp for a *real* IP address, or you can set one manually, there's nothing forcing you to stick with what was used during tftp

22:07 <shorne> somlo: yeah, I rather keep the default then make the code changes

22:07 <shorne> the problem is I have another subnet with 192.168.1.x which when I add that subnet to my host is breaks routing

22:08 <shorne> I can change my network :)

22:08 <shorne> This seems like only a problem for me

22:14 <somlo> shorne: yeah, if your tftp server is multihomed and does "fancy" routing, that could be annoying...