07:10 <Melkhior> @_florent_ HBM has a lot more bandwidth than DDR4, but latency isn't much better, if at all, no? Wouldn't stuff like RLDRAM or QDR4 (both SRAM-based I believe) have much better latency than either and a reasonable size ? (few dozens/hundreds of MiB). Just curious.

07:42 <Jegeva> _florent_: yeah, right now is not the right moment to change my chip and reroute the board and all, so basically is i just take on of the "based on" timing profile it should work no ? (it doesn't meaning i may have to double check the routing and change anyways)

08:30 <_florent_> Jegeva: yes sure, you can probably just use the timings from the MT41K512M8 based SO-DIMMs

08:38 <_florent_> Melkhior: for now the idea was just to experiment with HBM2 on the FK33 (that are not very expensive since repurposed from mining)

08:40 <Melkhior> _florent_ Thanks; the e.g. VCU128 has tons of different RAMs but at that price you need a good reason to get one.

08:43 <_florent_> Melkhior: indeed, the FK33 can be found at around 800€ or less so a lot cheaper than the VCU128

09:07 <_florent_> Melkhior: Ah BTW, since you were doing some SDCard tests the other day, I just tested multi-block writes with the BIOS and did a fix on the core to support it: https://github.com/enjoy-digital/litesdcard/commit/a7e6c6e5bd995657a650556aabc2252eeedd0791, I already shared this with somlo but maybe you also want to test this... :)

09:07 <Melkhior> _florent_ yes i'll give it a try to, I'm mostly using sdcard-based root now

09:07 <Melkhior> so more speed would be better :-)

09:08 <Melkhior> although right now I'm also using NFS, currently the SoC is recompiling Perl, it's not fast :-)

09:08 <_florent_> ok thanks

09:16 <Quarky93TongWu[m> There is also the Alveo U50 (for 2500 USD) and ECU50 (for 1500USD same as U50 but without QSFP and has a much higher TDP due to better VRM and cooling)

09:18 <Quarky93TongWu[m> and SQRL's JC33 and JC35 SoM

09:25 <_florent_> Thanks Quarky93TongWu[m, do you know where information about JC33/JC35 can be found?

09:29 <Quarky93TongWu[m> SQRL is/was going through some financial trouble recently so production has stalled and you can no longer buy them new. However you can fetch them new for around the same price as FK33 (for JC33 with a VU33P chip) and about 1.5K for (JC35 with a VU35P chip)

09:29 <Quarky93TongWu[m> * SQRL is/was going through some financial trouble recently so production has stalled and you can no longer buy them new. However you can fetch them used for around the same price as FK33 (for JC33 with a VU33P chip) and about 1.5K for (JC35 with a VU35P chip)

09:30 <Quarky93TongWu[m> I can provide XDC file if you want (i'm not affiliated with SQRL)

09:32 <Quarky93TongWu[m> Here's an old promo doc

09:40 <Quarky93TongWu[m> Modules on these carriers can be connected via 8 lane 25g GT links

09:40 <Quarky93TongWu[m> the modules are compatible with any of these carriers

09:43 <Quarky93TongWu[m> Oh and watercooling is the default option, the price should include the waterblock

09:44 <Quarky93TongWu[m> * Oh and watercooling is the default option (as you can imagine for a 1000W PCIE board), the price should include the waterblock

09:46 <Quarky93TongWu[m> they were working on some other cool things before their financial issues, i.e. Intel Stratix 10 HBM modules and other interesting carrier options.

09:46 <Quarky93TongWu[m> they've been acquired by Avnet now, so the future is up in the air atm...

09:48 <Quarky93TongWu[m> there's probably well over a thousand JC33 modules out there atm and a few hundred JC35

09:50 <_florent_> Quarky93TongWu[m: thanks, that's useful to know to do some experiment at reasonable costs or recycle hardware

10:07 <Quarky93TongWu[m> Yea especially when crypto goes through the boom and bust cycles, JC33 was down at 500 USD last year

14:39 <tcal> _florent_: hello, I have been experimenting with custom function units (CFUs) added to VexRiscv (using VexRiscv since it provides a CfuPlugin option, and it's also awesome, although eventually we hope more CPUs support the interface). The CFU connects ONLY to the CPU, not to the system bus, and it has no CSRs of its own. I've been using CPU+CFU in LiteX systems for quite a while now, but I've been hiding the CFU from

14:39 <tcal> LiteX --- I make a wrapper containing the CPU+CFU, and the wrapper exports just the normal CPU signals, so LiteX doesn't even know the CFU is there.

14:41 <tcal> But now I think it makes sense to hook up the CFU in LiteX, so I'd like to ask your advice. I've mocked up a couple of ways of doing it. I have the code for connecting the CFU to the VexRiscv in cores/cpu/vexriscv/core.py --- it creates and hooks the signals, makes the CFU instance, and optionally addes the CFU source.

14:45 <zyp> tcal, my initial thought is that it'd probably make sense to bundle up the signals into a record, so that a CFU can be put in a separate module and easily connected to the interface on the CPU

14:46 <tcal> I've considered adding an option `--cpu--cfu=./path/to/cfu/source.v` to the soc core options (so it would be like --cpu-variant). The advantage is that it would be available instantly on all litex_boards/targets. (note: the CPU variant must also be modified with +cfu)

14:46 <zyp> that assumes that the CFU is a verilog source with a particular interface

14:46 <tcal> zyp: thanks, I was wondering if that was the LiteX way :)

14:47 <tcal> Yes, I should have mentioned, the interface is fixed. The CFU has lots of freedom, except for the interface.

14:47 <zyp> couldn't it have extra IO?

14:49 <tcal> Not in the current spec...but of course there's use cases for it connecting to external IO, or the system bus. I guess we are keeping it strictly a function unit for now, so as to distinguish it from a peripheral accelerator on the bus.

14:54 <tcal> zyp: I'm imagining how that would look. In soc_core.py, there would then be a few lines for adding the CFU in the `# Modules instances` section?

14:55 <tcal> (imagining having CFU as a separate module, and I guess then a command `self.add_cfu(....)` )