add the Hackaday Supercon ECP5 badge #31
Conversation
Add the Hackaday Supercon 2019 badge which has an ECP5 FPGA: https://hackaday.io/project/167255-2019-hackaday-superconference-badge These changes are from Michael Welling's fork: https://github.com/mwelling/linux-on-litex-vexriscv During Supercon, we trying two approaches: - use the built-in 16MB QSPI SRAM - use add-on cartiridge with 32MB SDRAM by Jacob Creedon We were not able to get the QSPI SRAM working so I've removed those changes, and I have just added the changes that are needed to boot Linux with the 32MB SDRAM. Thanks to Jacob Creedon, Greg Davill and Tim Ansell who helped debug. KiCad design files for the SDRAM cartridge are available at: https://github.com/jcreedon/dram-cart/ The SDRAM cartridge PCB is shared at: https://oshpark.com/shared_projects/IQSl2lid More information in this blog post: https://blog.oshpark.com/2019/12/20/ The Hackaday Supercon badge PCB design is here: https://github.com/Spritetm/hadbadge2019_pcb
|
Thanks, i hope you all had fun working on that! It's merged with additional cleanup/simplifications: Since i don't have the hardware, can you check that things are still working? (i'll merge the linux-on-litex-vexriscv PR just after writing this). |
|
@enjoy-digital thank you for merging and making the cleanups. I have tested and the badge still boots Linux correctly with lxterm and I can login OK as root: |
|
Great! thanks for the feedback. |
|
@enjoy-digital fyi - I recorded an asciinema in case it it useful for reference: https://asciinema.org/a/292299 |
|
Thanks for the asciinema record, i'll keep the link. Booting with SDRAM SoCs seems a bit slow, i'll try to identify the bottlenecks and speed things a bit. |
|
From what I can see there is something misconfigured somewhere. Everything (not just booting) seems a lot slower than the OrangeCrab. |
|
I agree that is surprisingly slow. Can the DDR on the @gregdavill OrangeCrab really make that big of a difference? |
|
The SDRAM is running with the following specifications:
The DDR3 on the OrangeCrab:
Of course this is ignoring latency and other differences between the DDR3 and the SDRAM. But there is a pretty big difference in the raw bus speed. |
|
@gregdavill thanks for the details specs. That is good to know there is an order of magnitude difference in raw bus speed. |
|
From the CPU side, the maximal throughput on the wishbone bus is : 48M*32/2=768Mbit/s. (/2 since a wishbone access takes minimum 2 cycles). I need to look at how the 32-bit are down-converted to 8-bit for the SDRAM accesses, it's probably not as efficient as it could be. (not sure i ever try to optimize this case since on most designs SDRAM's controller data width >= 32). A relatively easy next thing to do to speed things with SDRAM would be to run the SDRAM at 96MHz instead of 48MHz. Then the next optimization would be to support bursts on the wishbone bus to avoid the /2 factor. |
|
Side note, but having bursts on the Wishbone bus to avoid the /2 factor would be super awesome for lots of other projects.
…On 9 January 2020 17:41:51 GMT+08:00, enjoy-digital ***@***.***> wrote:
From the CPU side, the maximal throughput on the wishbone bus is :
48M*32/2=768Mbit/s. (/2 since a wishbone access takes minimum 2
cycles). I need to look at how the 32-bit are down-converted to 8-bit
for the SDRAM accesses, it's probably not as efficient as it could be.
(not sure i ever try to optimize this case since on most designs
SDRAM's controller data width >= 32). A relatively easy next thing to
do to speed things with SDRAM would be to run the SDRAM at 96MHz
instead of 48MHz. Then the next optimization would be to support bursts
on the wishbone bus to avoid the /2 factor.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#31 (comment)
|
|
@xobs: indeed, for now it was not that critical since the CPU was mostly used to assist the hardware and do some control, but now that we are running OSes on it's becoming limiting, i'll look at the options. |
|
With enjoy-digital/litedram@34e6c24 and enjoy-digital/litex@fa22d6a we have a ~10% boot time speedup on designs using SDRAM:
On Arty with DDR3 the gain is effect more limited: 8.7s to 8.4s. That would be interesting to test this on the badge. |
|
@enjoy-digital thanks! I will try it out |
|
@enjoy-digital I pulled litedram and litex but I got and error when running build: Maybe I am missing something? |
|
@pdp7: sorry, i introduced a typo when refactoring the CRG on the hadbage. If you use upstream litex/litedram/litex-boards and linux-on-litex-vexriscv, you should be able to build the design. (you can just use litex_setup.py update to update litex/litedram/litex-boards). Here is attached the bitstream i just generated for the hadbadge from upstream repos. |
|
@enjoy-digital I created an issue because I didn't want to keep adding comments to a merged PR: please let me know if I should do something differently like continue to comment here or create the issue in a different repo (such as linux-on-litex-vexriscv)? |
| Subsignal("fmark", Pins("G1"), IOStandard("LVCMOS33")), | ||
| Subsignal("blen", Pins("P5"), IOStandard("LVCMOS33")), | ||
| ), | ||
| ("spiflash", 0, # clock needs to be accessed through USRMCLK |
There was a problem hiding this comment.
Depending on whether you're using dual/quad SPI or single SPI, either could work. Since this is a board definition, it makes sense to describe both options. For example, if you only wanted to do single SPI due to working with a fresh ROM cartridge that hasn't had its "QE" bit set.
There was a problem hiding this comment.
@xobs thanks. Any idea as to how to know if the QE bit set in the SDRAM cartridge that I am using?
I'm currently using spiflash for the add_spi_flash() method:
#35 (comment)
However, I can not get it to boot from flash so I'm trying to figure out what I may be doing wrong:
#35 (comment)
Add the Hackaday Supercon 2019 badge which has an ECP5 FPGA.
These changes are from a fork by Michael Welling (@mwelling)
During Supercon, we tried two approaches:
We were not able to get the QSPI SRAM working so I've removed those changes, and I have just added the changes that are needed to boot Linux with the 32MB SDRAM.
In addition to @mwelling, thank you to Jacob Creedon (@jcreedon), @gregdavill, Tim Ansell (@mithro), and Sean Cross (@xobs) who all helped get Linux working on this badge.
KiCad design files by @jcreedon for the SDRAM cartridge are available on GitHub.
There is also a shared project to order the SDRAM cartridge PCB.
Refer to my blog post for more information.
The Hackaday Supercon badge schematic and PCB layout are on GitHub too.