_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
Dolu has quit [Ping timeout: 272 seconds]
lf has quit [Ping timeout: 260 seconds]
lf has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
Bertl_oO is now known as Bertl_zZ
davidlattimore has quit [Ping timeout: 260 seconds]
davidlattimore has joined #litex
_whitelogger has joined #litex
shorne has joined #litex
<shorne> OK, I am going to try to swith to litex-boards from litex-buildenv for my or1k development starting now :)
kgugala_ has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 268 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 260 seconds]
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #litex
kgugala has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
Dolu has joined #litex
CarlFK has joined #litex
<Dolu> mithro : First there should be a FPU for Vex 32 bits ^^
Bertl_zZ is now known as Bertl
lkcl has quit [Ping timeout: 268 seconds]
lkcl has joined #litex
CarlFK has quit [Quit: Leaving.]
kgugala has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
Bertl is now known as Bertl_oO
chrisps has quit [Remote host closed the connection]
<mithro> Dolu: I think FPU type stuff is a very different kettle of fish to 64bit VexRISCV
<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
<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
<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...
<mithro> Dolu: We should probably chat more
<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
<sorear> IIUC some versions of the pentium 4 had a pipeline stage inserted in the adder between the left and right halves
<sorear> so you could do a 64-bit add in each alu each cycle but the critical path only went through 32 bits
<sorear> hazard detection gets uglier (you can follow an add immediately with another add or a shl but a shr needs a bubble)
<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
<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
<daveshah> Doesn't even have to be a working RV64, just would be interesting to guide optimisations
<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
<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
<Finde> sorear: I was told the above too about the P4
<Finde> but I was further told it was run at a higher clock... not sure about that part
<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
<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
<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
<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
<shorne> somlo: yeah, I rather keep the default then make the code changes
<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
<shorne> I can change my network :)
<shorne> This seems like only a problem for me
<somlo> shorne: yeah, if your tftp server is multihomed and does "fancy" routing, that could be annoying...
somlo has quit [Remote host closed the connection]
somlo has joined #litex