icebreaker-fpga / icebreaker

Small and low cost FPGA educational and development board
549 stars 74 forks source link

Can you add HyperRam ? #7

Closed mirecta closed 5 years ago

mirecta commented 6 years ago

I have an idea: Add HyperBus RAM (selfrefresh DRAM) to design, its small, cheap, low pin count but enough fast , and enough space (8 or 16MB) S27KL0641 or S27KS0641 http://www.cypress.com/products/hyperram-memory https://www.digikey.com/en/product-highlight/c/cypress/hyperram-memory

it will be good for image prcessing/buffering etc.

cliffordwolf commented 6 years ago
daveshah1 commented 6 years ago

IMO if onboard RAM is a very frequent request the only feasible option is QSPI PSRAM (like the ESP32 uses), this could have data lines shared with flash and would only need one extra IO (CS).

mirecta commented 6 years ago

This HyperRam uses OctoSPI similar QSPI i thing pins may be shared as wrote daveshah1

mirecta commented 6 years ago

QSPI would be a good idea too , any low pin serial psram

esden commented 6 years ago

First thank you for your interest in iCEBreaker! I do appreciate that. But we have to consider any feature addition, especially one that will change the current board feature set and cost, very carefully.

From the feature perspective. I am not convinced that having HyperRAM on every board is such a core feature that everyone would need and use. HyperRAM can be added as a PMOD for those that need it. On the other hand I know that having additional RAM will be useful for a variety of applications.

Adding Hyperram even when reusing the FLASH pins is not possible without giving up some signal on the board. It will at least require an additional Chip Select signal. There is no free lunch here. Before you suggest things like that make sure to look at the schematic. ALL pins have currently functions assigned. We even have double pin assignment using jumpers on the board. So as @cliffordwolf said, please make an argument based on the current schematic and think about which function we would have to give up to get that one additional signal. That would be even worse if we wanted OctoSPI... where do you want to steal another 4 signals?

Another reason to use HyperRam on the PMOD connector instead of reusing the FLASH pins is that then you can use Hyperram simultaneously with the FLASH.

Last but not least we also have the increased cost of the overall board when adding another chip and passives to the board. You are proposing of a retail price increase of almost $10 per board. Yes that is how part and assembly cost to retail cost translations work unfortunately... are you sure that everyone who is the potential user will see the hyperram as such a great feature that they will be willing to spend an additional $10 on it?

That said you will have to provide me with more reasons than just "I would like to have it" as that is not enough of a reason and "I feel like it is easy to do" because it is not.

All that is in the framework of the pure iCEBreaker. We could consider a separate version of the board that has Hyperram on board, but for that we have to still figure out what feature we want to drop to enable on board Hyperram. If you can figure out how to add the Hyperram with minimal impact to the current featureset of the iCEBreaker I still would like to hear about it.

cliffordwolf commented 6 years ago

I don't see how we can add the signals for HyperRAM. We just don't have the extra pins for the wider interface.

But I like @daveshah1's idea of supporting QSPI PSRAM. We could add a footprint compatible with SOIC-8 and SOIC-8-N to the backside of the board and use ~BUTTON as chip select for the footprint and share the other pins with the main flash.

That would allow users to add another flash or serial RAM at the cost of the button. We would not have extra cost because it's an unpopulated part. This scheme would even work with the FTDI FIFO because xFIFO_WKUP is an optional signal in the FT2232H Async FIFO protocol.

daveshah1 commented 6 years ago

Although it seemed like a good idea, for some reason none of the main distributors seem to carry any decent QSPI PSRAM parts - despite there being several manufacturers in China/Taiwan of it, so it may not be feasible.

The ideal part would be the LY68L6400, which is 64Mbit 3.3V SQI, up to 33MHz normal/100MHz fast reads. However despite some tantalising photos and forum posts of people who have it, it doesn't seem to be available anywhere, even Taobao - the usual source for these obscure things.

The other option that came to mind was the part ESP make for their ESP32, the ESP-PSRAM32, which is 32Mbit, but only 1.8V, so would complicate things significantly.

Maybe it's still worth considering the footprint, the parts may become more available, or it may be a case of biting the bullet and buying a reel from the manufacturer if there's enough interest.

smunaut commented 5 years ago

The LY68L6400 is in stock at LCSC :)

Even if no footprint is added or for previous revision of the board, it should be fairly easy to add ... just solder it above the flash chip and use a wire to route the CS_n pin to the right place.

mithro commented 5 years ago

There is a hyperram dual pmod board which should work on the icebreaker. Does mean you are down to a single pmod for other things.

smunaut commented 5 years ago

@mithro Yes. I was also considering making a single PMOD hyperram by just dropping 4 data bits ... (and given the DDR nature, you'd still have 8 bits per clock which is not unnatural).

smunaut commented 5 years ago

Never mind, it's a stupid idea ... you also need to send commands through that bus ... doh ... too early in the morning :p

esden commented 5 years ago

What we could do is put the unpapulated LY68L6400 footprint on the back of the board so that it can be added as an option, by the user. I don't think we have enough space on the front of the board for it. Still this might be a nice option. I would also use one of the on board LED lines to drive the RAM CS line. We can reconsider how things go together for the V2.0 of the iCEBreaker... ;)

esden commented 5 years ago

I am closing this issue in favor of the #19 I think that this is the most reasonable path forward.