The use-case is determined by power-efficiency, performance, and cost. Cost is already a loser at $72 vs $35. Performance is a loser at 18MHz vs 600MHz. What’s left is power-efficiency, but now that I know that this is an FPGA soft-core, I’m guessing the Teensy / ARM Cortex-M7 is also more power efficient.
So the Teensy is cheaper, faster, and (probably??) more power-efficient than the RISC-V soft-core FPGA implementation here.
The 8-bit uCs that I like to play with (AVR, or their competitors PIC12, Cortex M0+, Cortex M32, or TI MSP430) are all in the 5mA or less range (dramatically so: some in the 5uA range if you abuse sleep / idle states severely). These 8-bitters are closer to the performance that I’d expect of the 18MHz speed and 128kB of RAM here, but I have reason to believe that the 8-bit (and 32-bit / 16-bit competitors like Cortex M0+ / MSP430) are far more power efficient than the TKey.
In fact, cryptographic applications in an embedded low-power circumstance is typically handled by… that damn 8051 chip again in the form of our PKI cryptography inside of our credit cards. They are so power-efficient, there’s no battery involved but instead can absorb energy through Near Field Communications (aka: Tap to pay) alone. I doubt the TKey here has that level of cryptography + low power usage.
Reviewing the project here, it seems like a RISC-V / FPGA soft-core project trying to come up with a use case. It uses a more modern BLAKE cryptography algorithm (instead of the standard, still secure, SHA standards or AES standards because other chips like our credit-card chips, already implement hardware accelerated ASICs on that algorithm). Its almost like this was specifically designed to avoid the common use cases and form a new niche. Which is fine I guess. But a more realistic project would use a more standard Zinq kind of setup (ASIC hard-core Cortex-M of some kind + FPGA), rather than spending most of your FPGA LUTs on a soft-core IMO.
As such, I do believe that this is the kind of project that started as “How can I find a use of RISC-V?” and tried to find an application from there. Rather than the more appropriate “Think of a problem, then choose the best tool” forward-engineering kind of mindset. Nothing wrong with trying to experiment with RISC-V or trying to build the tools around a new, seperate ecosystem mind you. But there are downsides.
The problem is that this field is just so competitive. Each “mainstream” use of a device like this is basically overruled by like 3 or 4 competitors. Its difficult for me to think of a niche where pico-RISC-V soft-cores on an iCE40 FPGA is an appropriate solution.
How so?
The use-case is determined by power-efficiency, performance, and cost. Cost is already a loser at $72 vs $35. Performance is a loser at 18MHz vs 600MHz. What’s left is power-efficiency, but now that I know that this is an FPGA soft-core, I’m guessing the Teensy / ARM Cortex-M7 is also more power efficient.
So the Teensy is cheaper, faster, and (probably??) more power-efficient than the RISC-V soft-core FPGA implementation here.
The 8-bit uCs that I like to play with (AVR, or their competitors PIC12, Cortex M0+, Cortex M32, or TI MSP430) are all in the 5mA or less range (dramatically so: some in the 5uA range if you abuse sleep / idle states severely). These 8-bitters are closer to the performance that I’d expect of the 18MHz speed and 128kB of RAM here, but I have reason to believe that the 8-bit (and 32-bit / 16-bit competitors like Cortex M0+ / MSP430) are far more power efficient than the TKey.
In fact, cryptographic applications in an embedded low-power circumstance is typically handled by… that damn 8051 chip again in the form of our PKI cryptography inside of our credit cards. They are so power-efficient, there’s no battery involved but instead can absorb energy through Near Field Communications (aka: Tap to pay) alone. I doubt the TKey here has that level of cryptography + low power usage.
Reviewing the project here, it seems like a RISC-V / FPGA soft-core project trying to come up with a use case. It uses a more modern BLAKE cryptography algorithm (instead of the standard, still secure, SHA standards or AES standards because other chips like our credit-card chips, already implement hardware accelerated ASICs on that algorithm). Its almost like this was specifically designed to avoid the common use cases and form a new niche. Which is fine I guess. But a more realistic project would use a more standard Zinq kind of setup (ASIC hard-core Cortex-M of some kind + FPGA), rather than spending most of your FPGA LUTs on a soft-core IMO.
As such, I do believe that this is the kind of project that started as “How can I find a use of RISC-V?” and tried to find an application from there. Rather than the more appropriate “Think of a problem, then choose the best tool” forward-engineering kind of mindset. Nothing wrong with trying to experiment with RISC-V or trying to build the tools around a new, seperate ecosystem mind you. But there are downsides.
The problem is that this field is just so competitive. Each “mainstream” use of a device like this is basically overruled by like 3 or 4 competitors. Its difficult for me to think of a niche where pico-RISC-V soft-cores on an iCE40 FPGA is an appropriate solution.