| *** tpb has joined #litex | 00:00 | |
| 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:14 |
| 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... | 00:18 |
| *** shorne has quit IRC | 00:26 | |
| *** lf has quit IRC | 00:50 | |
| *** lf_ has joined #litex | 00:50 | |
| *** lkcl has quit IRC | 00:57 | |
| dkozel | _florent_ and miek did the camlink 4k support ever get tested, did it include any work on the HDMI interface? | 01:02 |
| *** Degi has quit IRC | 01:04 | |
| dkozel | mithro: Have you ever looked at the camlink as a target for the HDMI2TV project? | 01:04 |
| *** Degi has joined #litex | 01:05 | |
| *** FFY00 has quit IRC | 01:07 | |
| *** FFY00 has joined #litex | 01:08 | |
| *** lkcl has joined #litex | 01:11 | |
| *** Dolu has quit IRC | 01:18 | |
| *** shorne has joined #litex | 01:28 | |
| 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 | 01:31 |
| mithro | shorne: Well, 192.168.1.x is a pretty common network for people to use... | 02:02 |
| 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:15 |
| shorne | adding the 192.168.1.x ip to my workstation broke routing | 02:16 |
| shorne | anyway, I got that sorted | 02:16 |
| 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:17 |
| shorne | from tcpdump it seems its downloading the data but super slow compared to before | 02:18 |
| *** TMM has quit IRC | 03:49 | |
| *** TMM has joined #litex | 03:50 | |
| *** FFY00 has quit IRC | 04:38 | |
| *** FFY00 has joined #litex | 04:39 | |
| *** Degi has quit IRC | 05:02 | |
| *** Degi has joined #litex | 05:03 | |
| *** kgugala_ has joined #litex | 06:28 | |
| *** kgugala has quit IRC | 06:31 | |
| *** kgugala has joined #litex | 06:31 | |
| *** kgugala_ has quit IRC | 06:35 | |
| *** Bertl_oO is now known as Bertl_zZ | 06:44 | |
| *** _whitelogger has quit IRC | 06:57 | |
| *** _whitelogger has joined #litex | 06:59 | |
| *** _whitelogger has quit IRC | 07:21 | |
| *** _whitelogger has joined #litex | 07:23 | |
| *** CarlFK has joined #litex | 08:58 | |
| *** peeps[zen] has joined #litex | 09:33 | |
| *** peepsalot has quit IRC | 09:33 | |
| _florent_ | dkozel: camlink 4k is working fine yes (SoC with DDR3 support) but the HDMI interface as not been tested | 10:12 |
| *** Dolu has joined #litex | 10:28 | |
| *** _whitelogger has quit IRC | 10:51 | |
| *** _whitelogger has joined #litex | 10:53 | |
| *** Bertl_zZ is now known as Bertl | 14:13 | |
| *** kgugala_ has joined #litex | 14:21 | |
| *** kgugala has quit IRC | 14:25 | |
| *** kgugala_ has quit IRC | 14:58 | |
| *** kgugala has joined #litex | 14:58 | |
| *** lf_ is now known as lf | 15:28 | |
| miek | dkozel: i ended up finding it useful in it's (mostly) stock state so i haven't done much hacking on it :p | 16:04 |
| *** peepsalot has joined #litex | 17:32 | |
| *** peeps[zen] has quit IRC | 17:34 | |
| *** Bertl is now known as Bertl_oO | 18:02 | |
| *** acathla has quit IRC | 18:04 | |
| *** acathla has joined #litex | 19:47 | |
| *** acathla has quit IRC | 19:54 | |
| *** acathla has joined #litex | 19:54 | |
| 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:50 |
| Dolu | Often, the critical path that i have are mostly due to routing | 22:52 |
| 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:57 |
| Dolu | the D$ tags check should be fine as it the physical address, which can be set smaller than 64 bits | 22:59 |
| 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:03 |
| sorear | what does "microcode" mean to you? | 23:06 |
| *** STOP_NO_Anime has joined #litex | 23:14 | |
| *** STOP_NO_Anime has quit IRC | 23:17 | |
| mithro | Dolu: Have you looked at the highest possible fmax of VexRISCV recently? | 23:25 |
| mithro | Dolu: Most of the LiteX usage of VexRISCV doesn't target the highest frequencies | 23:34 |
| 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:36 |
| 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:37 |
| sorear | mithro: i was asking dolu because there's a pretty broad range of what microcode can mean in the literature | 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 | 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| Dolu | > you can pipeline with close to no hazard logic => lol XD right ^^ | 23:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| *** david-sawatzke[m has joined #litex | 23:49 | |
| 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:51 |
| 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? | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!