00:14 <mithro> shorne / shorne: https://docs.google.com/drawings/d/1cC1eC-sNwRS-Z8WYhRO0yNXPa0zqN1dDcCHZXLPRhHI/edit

00:14 <tpb> Title: LiteX Linux Ecosystem - Google Drawings (at docs.google.com)

00:18 <mithro> somlo / shorne: I'm 100% open to changing the default IP address in litex-buildenv if someone updates the documentation at the same time...

01:02 <dkozel> _florent_ and miek did the camlink 4k support ever get tested, did it include any work on the HDMI interface?

01:04 <dkozel> mithro: Have you ever looked at the camlink as a target for the HDMI2TV project?

01:31 <shorne> mithro: the IP address in litex-buildenv is fine, it was a problem when using vanilla litex-boards, to get around it I just changed by subnet settings in my network

01:31 <shorne> working OK now

02:02 <mithro> shorne: Well, 192.168.1.x is a pretty common network for people to use...

02:15 <shorne> yeah, its that I have my worksation on a 10.0.0.x network and wifi on a 192.168.1.x network and route between the 2

02:16 <shorne> adding the 192.168.1.x ip to my workstation broke routing

02:16 <shorne> anyway, I got that sorted

02:17 <shorne> but, now I am facing another issue, using litex-boards, once I get to : Copying rootfs.cpio.gz to 0x07000000... / it seems to lock up/run really slow

02:17 <shorne> trying to debug now

02:18 <shorne> from tcpdump it seems its downloading the data but super slow compared to before

10:12 <_florent_> dkozel: camlink 4k is working fine yes (SoC with DDR3 support) but the HDMI interface as not been tested

16:04 <miek> dkozel: i ended up finding it useful in it's (mostly) stock state so i haven't done much hacking on it :p

22:50 <Dolu> About the Adder stuff, i think daveshah is right, the carry chain should be fast enough in the FPGA to not be the major issue.

22:52 <Dolu> Often, the critical path that i have are mostly due to routing

22:57 <Dolu> one thing which might be critical on 64 bits is the MMU TLB hit logic, as it double in size, and is already close to the critical paths

22:59 <Dolu> the D$ tags check should be fine as it the physical address, which can be set smaller than 64 bits

23:03 <Dolu> about the 4 cycles 16 bits type of thing, in other words, kind of having a microcode to translate the RISC-V instruction into multiple one. That's would be likely the best way to reduce area, i'm just afraid that the performance would be too low to run a 64 bits linux well

23:03 <Dolu> @ mithro

23:06 <sorear> what does "microcode" mean to you?

23:25 <mithro> Dolu: Have you looked at the highest possible fmax of VexRISCV recently?

23:34 <mithro> Dolu: Most of the LiteX usage of VexRISCV doesn't target the highest frequencies

23:36 <mithro> sorear: microcode means to me there is some "code" somewhere that is decoding an instruction stream into a different set of operations that happens transparently to the user....

23:37 <mithro> sorear: It doesn't literally have to be "code" in the traditional sense that software people would recognize (but pretty much is in most modern cases)

23:38 <Dolu> mithro : the last optimisation i did was to allow having way more i$D$ way without FMax penality, i had mainly to split the MMU translation between the execute and memory stage.

23:38 <sorear> mithro: i was asking dolu because there's a pretty broad range of what microcode can mean in the literature

23:38 <sorear> from "any multicycle instructions are microcode" to "microcode is an interpreter written for a separate full-fledged instruction set"

23:38 <mithro> sorear: I actually missed Dolu's comment

23:39 <mithro> Dolu: I think the 4 cycles 16bit type thing is probably going to have much larger gains on something like the very slow iCE40UP5K than the Artix 7

23:40 <sorear> does vexriscv use bram for the register file?

23:40 <Dolu> So to me microcode mean decomposing each ISA instruction in the decode stage into one or more instructions (of another kind) for the pipeline

23:41 <sorear> so a fun property of the 16x4 approach that I noticed while trying to work out details years ago

23:41 <Dolu> I was thinking about it as "more" than just multi cycle instruction

23:41 <sorear> since your registers come in 4 "colors" and accesses to registers are spaced 4 cycles apart, you can pipeline with close to no hazard logic

23:42 <Dolu> multi cycle instruction is ofcourse a possibility, but seems less flexible than microcode

23:42 <mithro> sorear: A while back, I was actually thinking about how the risc-v instructions map to byte data access

23:43 <sorear> shifts are a pain with a folded datapath

23:43 <Dolu> hmm, fore the baremetal cache less CPU, as far i have seen, the weak link was often I bus D bus

23:43 <Dolu> Maybe should have some "very" thigly coupled ram there

23:44 <Dolu> sorear : Vex can use both BRAM or distributed ram as register file

23:44 <Dolu> and can move the read of it in the decode or in the execute stage, by default that's done in decode

23:44 <mithro> Interesting, I just found this spreadsheet form 2019 -> https://docs.google.com/spreadsheets/d/1b_I0wfvCPjRWGztSw7gEBMdaGJjmJOyKu_v3QVCoyOE/edit#gid=0

23:44 <tpb> Title: RISC-V Soft Core Comparisons Documents - Google Sheets (at docs.google.com)

23:45 <Dolu> > you can pipeline with close to no hazard logic => lol XD right ^^

23:46 <Dolu> Hoo the frequancy of Vex is wrong

23:46 <Dolu> I messed up the synthesis scripts :/

23:46 <Dolu> updated the readme since

23:47 <mithro> sorear: https://docs.google.com/spreadsheets/d/1xm6jt4KPusxpKpOmjjWGJmsgpf61qQF4tzVSVIEyxQw/edit?resourcekey=0-xhcOseYjnvOp6PCuWYIbcA#gid=1878706814

23:47 <tpb> Title: RISC-V Instruction Set Encoding Exploration (ISA, CFU, etc) - Google Sheets (at docs.google.com)

23:48 <Dolu> I just updated the google doc fmax

23:48 <Dolu> (artix number were messedup)

23:48 <mithro> Dolu: Should probably have added a new "2020 VexRISCV" type thing?

23:51 <mithro> sorear: I was trying to understand how you might map things to a byte machine -- I think I discovered it ends up mapping to a frustrating 3/5 bit pattern

23:56 <Dolu> mithro : Apart the messed up Artix FMax (fixed now), there is no big change in the default config, basicaly the improvements were made on feature not realy used on them, but used in the multi core SMP + bigger caches configs

23:56 <mithro> Dolu: BTW Have you considered a VexRISCV 4-core complex with a single shared FPU unit?