05:03 <whitequark> azonenberg: comments? https://twitter.com/whitequark/status/1286527036090126336

05:03 <azonenberg> whitequark: i saw it. Don't have a plausible explanation but i'm also getting pretty tired and about to go to sleep

05:03 <azonenberg> will look more in the morning

05:10 <awygle> I should ask some of the old timers at work if they have theories (though yours sounds plausible to me)

05:12 <whitequark> i literally just wanted to read an EEPROM lol

05:12 <whitequark> "i bet my code is broken" (time passes) "i WISH my code was broken"

07:13 <awygle> whitequark: I work at a company that could be not-inaccurately described as "a collection of dozens of bitrotten (E)EPROMs"

07:14 <whitequark> i presume you can't send me any of those tho :p

07:14 <awygle> i dunno what our policy is on lending them out but i can ask

07:14 <whitequark> wait, you have a glasgow

07:14 <awygle> i have been waging a campaign to donate the really old stuff to a museum lol

07:14 <awygle> correct

07:14 <whitequark> you can just test my applet like... directly

07:14 <awygle> also correct

07:14 <whitequark> you'll need an adapter PCB with an obnoxious amount of 74xx logic

07:14 <whitequark> but that's easy

07:15 <awygle> if, as noted, obnoxious

07:16 <whitequark> typo?

07:16 <whitequark> oh

07:16 <whitequark> oh yeah

07:16 <whitequark> i mainly mean

07:16 <whitequark> i should just lay the PCB out in a proper CAD

07:17 <awygle> probably lol

07:18 <awygle> anyway i'm going to bed. later

07:19 <whitequark> nini

07:38 <pepijndevos> I have so far not really payed attention to the RISC-V hype. How does one assemble some core and peripherals into a SoC?

07:41 <OmniMancer> I think SiFive have a thingy but not sure what the result is

07:43 <sorear> I may have missed something in the scrollback but what are you trying to accomplish?

07:47 <pepijndevos> Well, say I download picorv32 or serv or some other core, to do something useful I need to integrate it with some memory, gpio, spi or whatever you want. Just curious if there is a generic ecosystem/tool for this, or you just have to download all the cores and write out the verilog glue

07:48 <daveshah> There are various tools to do this like LiteX and SoC-specific platforms like picosoc

07:48 <daveshah> But not one particular standard or anything

07:51 <sorear> I have no idea what you would consider "do something useful" to mean so I can't recommend specific cores or ecosystems

07:52 <sorear> there's also fusesoc and chipyard

07:52 <pepijndevos> I don't have a specific goal tbh

07:54 <pepijndevos> So what I was thinking... Rust embedded has a HAL ecosystem that supports various chip, but imagine I want to use Rust on my FPGA SoC...

07:55 <pepijndevos> I was just idly thinking if you could tie... LiteX, fuessoc, picosoc, chipyard, etc to automatic generation of Rust HAL support files or something.

07:56 <sorear> that sounds like it would go through device-tree or CMSIS as an intermediate stage

07:57 <sorear> I know most of the soc tools can generate device-tree and rust embedded can accept CMSIS, idk if anyone has tried to get them on a common language

07:58 <sorear> (they're different levels of abstraction - device tree tells Linux what devices exist at what addresses and what driver to use for them, CMSIS describes individual registers but not how to use them)

07:58 <pepijndevos> hmmm, I'm not really thinking anything linux capable

07:59 <pepijndevos> But basically you'd need a SoC tool to output CMSIS I guess

08:00 <sorear> also CMSIS is always generated and processed offline, device tree is generated offline and _could_ be processed offline but Linux uses it online

08:00 <pepijndevos> hm I see

08:00 <sorear> I was not meaning to imply you'd use Linux but there's no reason in principle the device tree data couldn't be used

08:01 <pepijndevos> Any particular SoC tool that's easy to play around with and get a device tree out of?

08:01 <sorear> the problem is that the device tree says you have a sifive,uart0 at 0x4C000 and you then need to map that into six registers for an embedded HAL; CMSIS gives you the registers directly

08:01 <sorear> it might make sense to / there may already exist a tool that knows the mapping and can translate

08:04 <RaYmAn> pepijndevos: It kind of sounds like https://github.com/rust-embedded/svd2rust - you'd need to generate a horrible XML file though. although unsure how

08:04 <RaYmAn> although unsure how well it's supposed*

08:08 <pepijndevos> Yea svd2rust seems how most Rust SoC are done

08:08 <pepijndevos> So would be interesting if one of the FPGA SoC tools can generate that.

08:14 <daveshah> https://github.com/litex-hub/lxsocdoc

08:14 <daveshah> Never tried it myself but this should be able to generate svds from litex socs

08:16 <sorear> I think SVD is the actual name of the CMSIS file format and everything I said above applies to SVD

08:18 <pepijndevos> ohhhhh fancy

08:27 <pepijndevos> I will add "play with LiteX" somewhere on my list of toy projects hehe

08:32 <zyp> litex also generates register headers directly so you don't have to take the detour through SVD

08:33 <pepijndevos> I want to try using Rust though

08:33 <zyp> ah, right

08:38 <sorear> although we've had a couple people there asking similar questions about soc tooling and me not being able to give a full answer

09:11 <pepijndevos> The Fomu actually has an example of LiteX generated SVD to Rust crate.

09:11 <pepijndevos> https://workshop.fomu.im/en/latest/riscv.html#using-rust

09:12 <pepijndevos> https://lib.rs/crates/fomu-pac