The only use case that comes to my mind is extracting live data from device strictly recording onto SDcard, but wifi enabled SDcards designed for that purpose are already on the market since 2010 (eyefi).
I think this product category is defunct. Eye-Fi ceased business in 2016. Toshiba's FlashAir and Canon's offering also disappeared around the same time.
I first I thought this was a regular storage microSD with an FPGA that allows you change the data live as as it is saved or something. But seems to be an fpga that has microSD connection with no real storage capability like you would have in a reguar microSD (other than storage for fpga bitstream), i.e it is not storage device use case. But why microSD? Is it just because you can load the bitstream without having to use uart or jtag?
"The Signaloid C0-microSD has two main use cases: You can either (1) use it as a hot-pluggable FPGA module, or (2) use it as a hot-pluggable Signaloid C0 RISC-V co-processor module."
That is not really a use case. Use case usually gives examples of how they are used in production, i.e, more specific about applications.
The SD Card interface spec includes general-purpose IO in the form of https://en.wikipedia.org/wiki/SD_card#SDIO_cards , which has been used for plenty of things that aren't storage. As to why you'd use it here - I assume the appeal is that if you have a SD slot on your computer (which is quite common) then you can plug this in and use it with no additional hardware at all.
If I buy it and plug into my computer, I guess my computer will see it as a storage device. If I send it a picture, does it overwrite the fpga bitstream? Do I have write custom drivers so that it does something useful?
I would not expect it to show up as a storage device, no; the point of SDIO is that the SD slot is generic like a USB port. You would need software that can use the device you've plugged in just like if you plugged in a separate FPGA programmer.
I used a Gameboy Flash card that showed up as a blockdevice that was formatted FAT device, writing/overwriting a file upon it will overwrite the flash and inserting it to the Gameboy would then start it.
I suspect that there was some transation firmware that acted as the blockdevice and routed data to the flash as the "file" was written by the computer, it was a pretty clever and frankly painless way of updating since there was nothing beyond connecting, copying and flipping back.
Yes, in the long run you want something directly USB connected (preferably with a debugger) but as for having a no-hassle setup this was quite neat.
And considering that many of the first generation of Gameboy flash-devices had been tied to dodgy paralell-port flash protocols that were hardcoded to even dodgier win95 era flashing programs that required full HW access(and not working well on winNT based systems not to mention osX or Linux) I think a bit of the thinking for this was to future-proof the device by just basing it on some standard block-device technology like SD cards or UMass that was unlikely to become unsupported.
This sounds fun to play with and get feet wet in HDL, but it's only a lattice ice40, I have no idea what you'd seriously do with this. Usually ice40 are used as glue logic, or multiplexing/buffering a bunch of ADC/DAC chips so the processor can do large data transfers instead of a bunch of tiny ones.
The website claims hardware acceleration and... I doubt they got timing closure on the soft CPU at anything greater than 100MHz and you still have to get data to/from it at likely 30~40 MB/s via an SDMMC bus.
For a lot of the iCE40 chips, it's extremely difficult to reliably get fMax > 50MHz even with extremely aggressive pipelining. I assume 80MHz is only possible on the highest-speed parts in the iCE40 family
I switched a design from iCE40 to ECP5 and got a ~3x speedup "for free"
Agreed that using Lattice FPGAs is super nice, mostly because you get to use the open-source Yosys toolchain, which is vastly better than proprietary toolchains IMO
Agreed. Not enough processing power for anything onboard, no IO out the back (seems like a missed opportunity tbh) for expansion to do fun things. Not sure what I'd do with this.
A quick search shows Hirose has a 0.5mm tall FPC connector that could fit 25 contacts within the width. Looking at their pictures, they have some spare height (unsure if enough though) and depth to move components forward. Even with good grounding, idk 12 IO is a decent amount.
This is likely an extremely rich attack vector if you can gain any reach through the SDIO interface.
That’s a big if… but because of the relative obscurity of the attack surface and requirements for unusual tools, this is probably largely unexplored territory for non-state actors.
It is very likely that the firmware and drivers for SDIO are at the very least insecure and likely rife with serious arbitrary-code-execution level bugs, manufacturer / letter agency back doors for special tools, and similar attack surfaces that will suddenly become accessible to anyone with a hundred dollars and the desire to dig in.
Ultimately, this will be good for device security, but the need for a specialized (but obtainable) tool to execute the attack means probably years of vulnerabilities in the wild, and won’t-fix for older devices.
The only use case that comes to my mind is extracting live data from device strictly recording onto SDcard, but wifi enabled SDcards designed for that purpose are already on the market since 2010 (eyefi).
I think this product category is defunct. Eye-Fi ceased business in 2016. Toshiba's FlashAir and Canon's offering also disappeared around the same time.
Reminds me of the old Electric Imp, which was like an ESP32 before the ESP32. Also came in a (full size) SD card form factor.
I first I thought this was a regular storage microSD with an FPGA that allows you change the data live as as it is saved or something. But seems to be an fpga that has microSD connection with no real storage capability like you would have in a reguar microSD (other than storage for fpga bitstream), i.e it is not storage device use case. But why microSD? Is it just because you can load the bitstream without having to use uart or jtag?
"The Signaloid C0-microSD has two main use cases: You can either (1) use it as a hot-pluggable FPGA module, or (2) use it as a hot-pluggable Signaloid C0 RISC-V co-processor module."
That is not really a use case. Use case usually gives examples of how they are used in production, i.e, more specific about applications.
The SD Card interface spec includes general-purpose IO in the form of https://en.wikipedia.org/wiki/SD_card#SDIO_cards , which has been used for plenty of things that aren't storage. As to why you'd use it here - I assume the appeal is that if you have a SD slot on your computer (which is quite common) then you can plug this in and use it with no additional hardware at all.
If I buy it and plug into my computer, I guess my computer will see it as a storage device. If I send it a picture, does it overwrite the fpga bitstream? Do I have write custom drivers so that it does something useful?
I would not expect it to show up as a storage device, no; the point of SDIO is that the SD slot is generic like a USB port. You would need software that can use the device you've plugged in just like if you plugged in a separate FPGA programmer.
I used a Gameboy Flash card that showed up as a blockdevice that was formatted FAT device, writing/overwriting a file upon it will overwrite the flash and inserting it to the Gameboy would then start it.
I suspect that there was some transation firmware that acted as the blockdevice and routed data to the flash as the "file" was written by the computer, it was a pretty clever and frankly painless way of updating since there was nothing beyond connecting, copying and flipping back.
Yes, in the long run you want something directly USB connected (preferably with a debugger) but as for having a no-hassle setup this was quite neat.
And considering that many of the first generation of Gameboy flash-devices had been tied to dodgy paralell-port flash protocols that were hardcoded to even dodgier win95 era flashing programs that required full HW access(and not working well on winNT based systems not to mention osX or Linux) I think a bit of the thinking for this was to future-proof the device by just basing it on some standard block-device technology like SD cards or UMass that was unlikely to become unsupported.
This sounds fun to play with and get feet wet in HDL, but it's only a lattice ice40, I have no idea what you'd seriously do with this. Usually ice40 are used as glue logic, or multiplexing/buffering a bunch of ADC/DAC chips so the processor can do large data transfers instead of a bunch of tiny ones.
The website claims hardware acceleration and... I doubt they got timing closure on the soft CPU at anything greater than 100MHz and you still have to get data to/from it at likely 30~40 MB/s via an SDMMC bus.
Lattice's FPGAs are very nice. With an iCE40 you can have a full featured RISC-V soft-core (RV32IMFAC) at some 80 MHz.
For a lot of the iCE40 chips, it's extremely difficult to reliably get fMax > 50MHz even with extremely aggressive pipelining. I assume 80MHz is only possible on the highest-speed parts in the iCE40 family
I switched a design from iCE40 to ECP5 and got a ~3x speedup "for free"
Agreed that using Lattice FPGAs is super nice, mostly because you get to use the open-source Yosys toolchain, which is vastly better than proprietary toolchains IMO
Agreed. Not enough processing power for anything onboard, no IO out the back (seems like a missed opportunity tbh) for expansion to do fun things. Not sure what I'd do with this.
A quick search shows Hirose has a 0.5mm tall FPC connector that could fit 25 contacts within the width. Looking at their pictures, they have some spare height (unsure if enough though) and depth to move components forward. Even with good grounding, idk 12 IO is a decent amount.
It's got 128KB of on-die SRAM - you could have a Z80 and a 6502, both with a full complement of SRAM!
I am a bit concerned here. I wonder how much time will pass before someone decide to use it to hack a computer?
IIRC there have already been proof of concept attacks made using MicroSD cards with the microcontroller modified https://www.welivesecurity.com/2014/01/02/could-new-malware-...
This is likely an extremely rich attack vector if you can gain any reach through the SDIO interface.
That’s a big if… but because of the relative obscurity of the attack surface and requirements for unusual tools, this is probably largely unexplored territory for non-state actors.
It is very likely that the firmware and drivers for SDIO are at the very least insecure and likely rife with serious arbitrary-code-execution level bugs, manufacturer / letter agency back doors for special tools, and similar attack surfaces that will suddenly become accessible to anyone with a hundred dollars and the desire to dig in.
Ultimately, this will be good for device security, but the need for a specialized (but obtainable) tool to execute the attack means probably years of vulnerabilities in the wild, and won’t-fix for older devices.