The specs are literally the reason why people would buy this. It’s basically the best device we have available that can be used as a base for devices handling secure computation, or software handling secure computation. Think of a FIDO2 key, or a gpg smartcard, all secure and verifiable
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/
in this case the instruction set is extremely small (and includes open source verilog, so you could even fab it yourself)
quote from the website:
The CPU of the TKey is a modified version of PicoRV32, 32-bit RISC-V running at 18 MHz. Modifications includes a fast 32x32 multiplier implemented using the multiplier blocks in the iCE40 DSPs as well as a HW trap function.
The supported instruction set supported by the CPU is a subset of RV32I. Specifically it includes compressed instructions, but excludes instructions for:
Counters
System
Synch
CSR access
Change level
Trap redirect
Interrupt
MMU
The instruction set implemented by the CPU also includes multiplication instructions from the RV32IC_Zmmul (-march=rv32iczmmul) extension. Division is not supported.
Any illegal, unsupported instruction will halt the CPU. The halted CPU is detected by the hardware, which will blink the RGB LED with red to indicate the error state. There is no way for the CPU to exit the trap state besides a power cycle of the device.
Note that the CPU has no support for interrupts. No instructions, ports or logic.
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.
The specs are literally the reason why people would buy this. It’s basically the best device we have available that can be used as a base for devices handling secure computation, or software handling secure computation. Think of a FIDO2 key, or a gpg smartcard, all secure and verifiable
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.
in this case the instruction set is extremely small (and includes open source verilog, so you could even fab it yourself)
quote from the website:
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.
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.
Wow.
I have no idea what I’d use it for (or even how to use it) but I want one!