Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace PicoSoC XIP flash controller with LiteX version #12

Open
mithro opened this issue Jun 25, 2019 · 12 comments
Open

Replace PicoSoC XIP flash controller with LiteX version #12

mithro opened this issue Jun 25, 2019 · 12 comments

Comments

@mithro
Copy link
Member

mithro commented Jun 25, 2019

No description provided.

@xobs
Copy link
Member

xobs commented Jul 8, 2019

This cannot be done until a solution has been found for adding write support to the LiteX SPI flash controller.

@enjoy-digital
Copy link
Contributor

If you want to have memory-mapped reads and bitbanging write, you can use SpiFlashDualQuad or SpiFlashSingle (depending if you flash support Single/Dual/Quad SPI reads) and you can this to see how to do write accesses:
https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/main.c#L312
https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/libbase/spiflash.c

@mithro
Copy link
Member Author

mithro commented Jul 8, 2019

You can even test this in Renode emulation....

@xobs
Copy link
Member

xobs commented Jul 8, 2019

I think I see how it's supposed to work, and I've modified foboot to use the new SpiFlash-with-bitbang mode.

However, the latest litex (which is required to get this mode) doesn't work. Something has changed and the CPU isn't booting at all. I was hoping to get this in before we went to mass production, but it doesn't look like that'll happen.

@mithro
Copy link
Member Author

mithro commented Jul 10, 2019

Last status: The bug preventing CPU from booting has been fixed. Now just need to get SPI flash writing going with the new interface.

@xobs mentioned that the LiteX version seems to save ~100 LCs....

@xobs
Copy link
Member

xobs commented Jul 10, 2019

Additionally, I would like to find a path forward to enabling quad-writes. picorv32 supports bit-banging quad writes, but SpiFlash doesn't appear to support that. I'd like as-good-or-better support in an upgrade, especially since higher-performance writes are definitely a thing we'll want.

@enjoy-digital
Copy link
Contributor

@mithro, @xobs i just created that: enjoy-digital/litex#215 Do you see others improvements?

@xobs
Copy link
Member

xobs commented Jul 10, 2019

That's a good list of improvements!

If we're asking for a wishlist of features, then an entire spi state machine would be nice. A single csr that you can write to and it does a spi tx/rx. That would greatly speed up writes. For Fomu we'll appear as a fat filesystem, so faster writes will become important.

@enjoy-digital
Copy link
Contributor

Something like this: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi.py ? :)
(but does not support Dual/Quad...)

@xobs
Copy link
Member

xobs commented Jul 10, 2019

Yes, something like that. Maybe there's a way to connect that FSM up to the bit bang pins to get the best of both worlds?

Plus, as you say, quad mode is an issue

@enjoy-digital
Copy link
Contributor

Thanks for the feedback, i was just trying to list the possible improvements. Not sure i'll be able to do that very soon (maybe in August), so that's probably better keeping PicoSoC SPI flash module for now.

@enjoy-digital
Copy link
Contributor

@xobs: are you sure supporting Quad mode for writes is really required in your case? It generally takes a lot longer to program the data in the flash than receiving it on the SPI bus so Quad mode seems only interesting for slow SPI clocks, from the winbond datasheet:
"The Quad Page Program can improve performance for PROM Programmer and applications that have slow clock speeds <5MHz. Systems with faster clock speed will not realize much benefit for the Quad Page Program instruction since the inherent page program time is much greater than the time it take to clock-in the data."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants