| *** tpb has joined #litex | 00:00 | |
| *** Dolu has quit IRC | 00:36 | |
| *** lf has quit IRC | 00:51 | |
| *** lf has joined #litex | 00:52 | |
| *** Degi_ has joined #litex | 01:04 | |
| *** Degi has quit IRC | 01:07 | |
| *** Degi_ is now known as Degi | 01:07 | |
| *** FFY00 has quit IRC | 01:36 | |
| *** FFY00 has joined #litex | 01:37 | |
| *** Bertl_oO is now known as Bertl_zZ | 02:01 | |
| *** davidlattimore has quit IRC | 02:26 | |
| *** davidlattimore has joined #litex | 02:26 | |
| *** _whitelogger has quit IRC | 05:06 | |
| *** _whitelogger has joined #litex | 05:08 | |
| *** shorne has joined #litex | 05:53 | |
| shorne | OK, I am going to try to swith to litex-boards from litex-buildenv for my or1k development starting now :) | 05:53 |
|---|---|---|
| *** kgugala_ has joined #litex | 07:31 | |
| *** kgugala_ has quit IRC | 07:32 | |
| *** kgugala_ has joined #litex | 07:33 | |
| *** kgugala has quit IRC | 07:33 | |
| *** kgugala has joined #litex | 07:52 | |
| *** kgugala_ has quit IRC | 07:55 | |
| *** futarisIRCcloud has quit IRC | 08:07 | |
| *** kgugala_ has joined #litex | 08:07 | |
| *** kgugala has quit IRC | 08:11 | |
| *** peepsalot has quit IRC | 09:25 | |
| *** peepsalot has joined #litex | 09:32 | |
| *** kgugala has joined #litex | 10:06 | |
| *** kgugala_ has quit IRC | 10:06 | |
| *** Dolu has joined #litex | 10:38 | |
| *** CarlFK has joined #litex | 12:13 | |
| Dolu | mithro : First there should be a FPU for Vex 32 bits ^^ | 12:18 |
| *** Bertl_zZ is now known as Bertl | 12:29 | |
| *** lkcl has quit IRC | 12:48 | |
| *** lkcl has joined #litex | 13:01 | |
| *** CarlFK has quit IRC | 13:30 | |
| *** kgugala has quit IRC | 14:25 | |
| *** kgugala has joined #litex | 14:26 | |
| *** Bertl is now known as Bertl_oO | 16:26 | |
| *** chrisps has quit IRC | 17:01 | |
| mithro | Dolu: I think FPU type stuff is a very different kettle of fish to 64bit VexRISCV | 18:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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 | 18:55 |
| sorear | IIUC some versions of the pentium 4 had a pipeline stage inserted in the adder between the left and right halves | 19:02 |
| 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:03 |
| 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:40 |
| 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:43 |
| 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 | 19:44 |
| 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:31 |
| 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 | 20:44 |
| 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:47 |
| 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 | 21:59 |
| 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:01 |
| 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:07 |
| shorne | I can change my network :) | 22:08 |
| shorne | This seems like only a problem for me | 22:08 |
| somlo | shorne: yeah, if your tftp server is multihomed and does "fancy" routing, that could be annoying... | 22:14 |
| *** somlo has quit IRC | 22:16 | |
| *** somlo has joined #litex | 22:16 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!