11:30 <_whitenotifier-e> [nmigen-boards] zignig opened pull request #36: Flashmap - https://git.io/Je1nc

13:02 <mtrbot-ml> [mattermost] <dpn> Ah, apologies for all the separate update messages

20:14 <ZirconiumX> This is possibly cursed, but if I want to implement a state that returns to its "caller", how would I do that? I'm writing an SD card controller, and need a state for performing an SPI transfer, but duplicating it for each SD command seems pointless.

20:16 <whitequark> can you elaborate?

20:20 <ZirconiumX> Essentially I want my state machine to do a function call

20:21 <ZirconiumX> Which means the state after it needs to be the state that called it

20:25 <whitequark> this is why people use soft-CPUs

20:25 <whitequark> in general

20:25 <whitequark> "programmable state machines"

20:25 <whitequark> (recommended reading: http://bleyer.org/pacoblaze/picoblaze.pdf)

20:25 <whitequark> as for your specific question: probably use two state machines

20:25 <whitequark> one to handle SPI, and another to drive it with commands

20:28 <ZirconiumX> That's currently how I have it structured, but I still end up needing to repeat the same basic code to drive said SPI state machine

20:29 <ZirconiumX> Perhaps I need to make the SPI buffer big enough to fit SD card commands

20:29 <ZirconiumX> Though the block data is going to be big enough to be worth putting into a Memory.

20:30 <whitequark> can you show your actual code?

20:30 <ZirconiumX> https://gist.github.com/ZirconiumX/b014381d1d5bddffa66a6c20207a293b

20:30 <ZirconiumX> Very WIP, but

20:31 <ZirconiumX> The SPI controller is a glorified shift register

20:31 <whitequark> hm

20:31 <whitequark> I don't see any code that drives the SPI state machine yet

20:32 <ZirconiumX> At present there is none; I'm thinking aloud as such

20:33 <ZirconiumX> For example, the handshake for an SD card in SPI mode requires sending multiple CMDs, and each step of the handshake would require the same basic code to drive the SPI state machine

20:35 <ZirconiumX> I suppose what you're saying here is "this should be in software"?

20:43 <whitequark> hmm

20:44 <ZirconiumX> I *do* have the luxury of a soft CPU, but I was wondering how much should be in gateware versus software

20:44 <whitequark> ideally that code should be 3-4 lines: present the byte, set the ready flag, wait for acknowledgement flag

20:45 <whitequark> which is a *bit* annoying, and I've actually thought about adding some tools to factor that out, but isn't unbearable

20:47 <ZirconiumX> I'm aware of the embedded-sdmmc crate, but also of size constraints of the bootstrap code

20:48 <ZirconiumX> My goal is to fit the bootstrap in a few DP16KDs.

20:48 <ZirconiumX> As a wishbone memory device/cache

20:55 <whitequark> I think what you want is totally realistic as a set of FSMs

20:55 <whitequark> I was more saying that, as your ad-hoc FSMs grow, they start to be closer and closer to a soft-CPU

20:56 <whitequark> that isn't a statement that tells you to change your approach; it is a high-level, general observation

21:00 <ZirconiumX> Right, okay.

21:54 <Stormwind_mobile> Now, I want to design a softcore with an "annoying bit" hidden somewhere in the flag register.

22:00 <ZirconiumX> Jump Sometimes

22:21 <davidc__> ZirconiumX: have the cache initially loaded with the boot code (with cache lines "locked"), then exec out of that while you init peripherals

22:21 <ZirconiumX> davidc__: that's the plan, yeah

22:26 <davidc__> (Heck, you can even use that to do XIP from the SD card, as long as you can trigger an interrupt on "cache miss")

22:26 <davidc__> No SD card gateware needed!

22:28 <ZirconiumX> Well, not *much* SD card gateware needed.

22:28 <davidc__> You could bitbang it!

22:29 <ZirconiumX> Not confident in my bitbanging skills

22:29 <ZirconiumX> ZipCPU's sdspi core has a nice interface, so I might reuse that