Ehhhh… I’d recommend a Teensy instead, or a variety of other microprocessors. At $72, this is awful value. And there seems to be no specifications with regards to power-consumption.
Teensy 4.1 gives you Hardware Floating point, 100 MBit Ethernet, USB, 600MHz, 1024kB of SRAM, 7MB of Flash for like $35 and within ~100mA of current usage at this 600MHz speed, meaning it easily runs off of AA Batteries for over a day with just a bit of idle/sleep cycles.
there are use cases, such as security, where you want as few instructions as possible, so a full ARM processor isn’t the best idea. You may want to read the threat model page: https://tillitis.se/products/threat-model/
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.
Ehhhh… I’d recommend a Teensy instead, or a variety of other microprocessors. At $72, this is awful value. And there seems to be no specifications with regards to power-consumption.
https://www.pjrc.com/store/teensy41.html
Teensy 4.1 gives you Hardware Floating point, 100 MBit Ethernet, USB, 600MHz, 1024kB of SRAM, 7MB of Flash for like $35 and within ~100mA of current usage at this 600MHz speed, meaning it easily runs off of AA Batteries for over a day with just a bit of idle/sleep cycles.
there are use cases, such as security, where you want as few instructions as possible, so a full ARM processor isn’t the best idea. You may want to read the threat model page: https://tillitis.se/products/threat-model/
On the contrary, RISC-V is typically bigger and less efficient than Cortex-M7 on the Teensy.
There are 10-cent ARM Cortex M0+ processors (M0+ being the smallest ARM). M7 is kinda-small. ARM scales to different sizes and power-efficiencies.
deleted by creator
https://developer.arm.com/documentation/dui0646/c/The-Cortex-M7-Instruction-Set/Instruction-set-summary
So is the Cortex M7. The entirety of the M0+, M4, and M7 microcontroller cores are very, very small ARMs.
Hmmm. Okay, so its an FPGA Risc-V then.
That’s kind of sad, that means there’s no hope that its as power-efficient as a proper ASIC core like ARM-M7.
Wow.
I have no idea what I’d use it for (or even how to use it) but I want one!
Completely different use cases
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.