[HN Gopher] A programmable FPGA SoM in the tiny microSD form factor
___________________________________________________________________
A programmable FPGA SoM in the tiny microSD form factor
Author : LorenDB
Score : 55 points
Date : 2024-11-15 13:48 UTC (3 days ago)
(HTM) web link (www.crowdsupply.com)
(TXT) w3m dump (www.crowdsupply.com)
| mattofak wrote:
| 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.
| mechagodzilla wrote:
| It's got 128KB of on-die SRAM - you could have a Z80 _and_ a
| 6502, both with a full complement of SRAM!
| ruslan wrote:
| Lattice's FPGAs are very nice. With an iCE40 you can have a
| full featured RISC-V soft-core (RV32IMFAC) at some 80 MHz.
| wyager wrote:
| 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
| Neywiny wrote:
| 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.
| rasz wrote:
| 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).
| rgovostes wrote:
| 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.
| 0xmarcin wrote:
| I am a bit concerned here. I wonder how much time will pass
| before someone decide to use it to hack a computer?
| K0balt wrote:
| 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.
| robotnikman wrote:
| 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-...
| alnwlsn wrote:
| 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.
| lfmunoz4 wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
| lfmunoz4 wrote:
| 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?
| yjftsjthsd-h wrote:
| 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.
| whizzter wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-18 23:00 UTC)