Hands On With The First Open Source Microcontroller

2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a few silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.

The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.

We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.


Before I dig into this, I must discuss the openness of the HiFive 1, and RISC-V in general. Free Software and Open Hardware is a religion, and it’s significantly more difficult to produce Open Hardware than Free Software. No matter how good or how Open the design is, the production of the first Open Source microcontroller will generate far too many comments from people who use the words ‘moral imperative’ while citing utilitarian examples of why Open and Libre is good. You should ignore these comments, but not just because these people have only read the back cover of the Cliff’s Notes for Philosophy For Dummies.

The Openness of the HiFive 1 and RISC-V

The biggest selling point for RISC-V chips is that there are no licensing fees, and this microcontroller is Open Source. This is huge — your AVRs, PICs, ARMs, and every other microcontroller on the planet is closed hardware. You can’t study the silicon. If we’re ever going to get a completely Open Source computer, it has to start somewhere, and here it is.

With that said, this is an Arduino-compatible board with an FTDI chip providing the USB to serial conversion. If we had a facepalm emoji, we’d use it here. An FTDI chip is not Open Source, and they have designed drivers to break chips that aren’t theirs. The design files for the HiFive 1 were made with Altium, a proprietary and non-Free software.

This was the best picture for this section of content.
This was the best picture for this section of content.

Will Stallman ever say the HiFive 1 is Free as in speech? Absolutely not. Instead, the HiFive 1 is an incrementally more Free microcontroller compared to a PIC, ARM, or AVR. There will be people who will argue – over the Internet, using late-model Intel processors with Management Engines — this is insufficient to be called Free and Open Source. To them, I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source. Let’s not cut down the idea of an Open Source microcontroller because it’s not perfect on the first release.

Hardware Teardown

So, what’s in the HiFive 1? The spec sheet is simple enough, the datasheet is complete enough,  although there are some caveats:

  • Microcontroller: SiFive Freedom E310 (FE310)
    • CPU: SiFive E31 CPU
    • Architecture: 32-bit RV32IMAC
    • Speed: 320+ MHz (the stock frequency seems to be about 256 MHz, this can be changed)
    • Performance: 1.61 DMIPs/MHz
    • Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad
    • Other Features: Hardware Multiply/Divide, Debug Module, Flexible Clock Generation with on-chip oscillators and PLLs
  • Operating Voltage: 3.3 V and 1.8 V
  • Input Voltage: 5 V USB or 7-12 VDC Jack
  • IO Voltages: Both 3.3 V or 5 V supported
  • Digital I/O Pins: 19
  • PWM Pins: 9
  • SPI Controllers/HW CS Pins: 1/3
  • External Interrupt Pins: 19
  • External Wakeup Pins: 1
  • Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)
  • Host Interface (microUSB): Program, Debug, and Serial Communication

Basically, the HiFive 1 is the SiFive FE310 microcontroller packaged in an Arduino Uno form factor. The pin spacing is just as stupid as it’s always been, and there is support for a few Adafruit shields sitting around in the SDK.

There are no analog pins, but there are two more PWM pins compared to the standard Arduino chip. The Arduino Uno and Leonardo have 32 kilobytes of Flash, while the HiFive 1 has sixteen Megabytes of Flash on an external SOIC chip.

The HiFive 1 supports 3.3 and 5V I/O, thanks to three voltage level translators. The support for 5V logic is huge in my opinion — nearly every dev board manufacturer has already written off 5V I/O as a victim of technological progress. The HiFive doesn’t, even though the FE310 microcontroller is itself only 3.3V tolerant. It should be noted the addition of the voltage level translators add at least a dollar or two to the BOM, and double that to the final cost of the board. It’s a nice touch, but there’s room for cost cutting here.

Other than that, the only other chip of note on the board is the FTDI FT2232HL, a well-supported but most certainly not Free and Open Source USB to UART chip. This is a two-port chip that provides programming, serial, and debug connections simultaneously.

Getting Started With The HiFive 1

blinking-gifThe folks at SiFive realize documentation and SDKs are necessary to turn a chip into a development board. To that end, they have a bare-metal SDK and support for the Arduino IDE. The board itself comes with a bootloader, and when you plug the HiFive 1 into a USB you get the equivalent of the Blink sketch from the Arduino. Yes, you too can have Open Source blinkies. What a magical time to be alive.

Right now there are two methods of programming the HiFive 1. The Freedom E SDK, and the Arduino IDE. The Arduino IDE appears to be dependent on the Freedom E SDK, so either way, you’ll have to get the SDK running.

Right now, the SDK only works under Linux (and OS X, and possibly Cygwin), but support for Windows is coming. For Linux users, the getting started guide is more than sufficient, although it will take quite a while (at least 30 minutes) to build all the tools.

Once the Freedom E SDK is installed, support for the Arduino IDE pretty much falls into place. You’ll have to futz around with the Boards Manager, but with a few clicks, you get something fantastic. You can blink an LED with Open Source Hardware.


 Actually Programming the Thing

Blinking an LED is proof enough this can be programmed, but what about the vast SDK we had to install before getting the Arduino IDE working? Here, too, it’s pretty easy to get the SDK up and running:

For this example, I simply changed the ‘hello world’ program shipped with the SDK to a ‘hello Hackaday’ program, compiled it, and ran it. Yes, someone as dumb as me can compile and upload a program to the HiFive 1.

This Stuff is Still New, Okay?

Before receiving the HiFive 1, I originally planned to benchmark this dev board against other small, common dev boards. The SDK comes with a Dhrystone program, making this the obvious choice. The results were not good, but this isn’t a reflection of the power of the FE310 microcontroller. Allow me to present the shocking infographic you should not pay attention to:

Ignore this infographic

This test used this Dhrystone Arduino sketch with the Arduino Micro, HiFive 1, and the Teensy 3.6. As you would expect the Arduino Micro performed poorly (but still ten times faster than a mainframe from 1988), and the Teensy 3.6 was extremely fast. According to this benchmark, the HiFive 1 did terribly at barely twice the computing power of the Arduino while running 16 times faster. If this benchmark was accurate, it would immediately spell the end of the RISC-V ISA.

The above benchmark is not accurate, and the poor Dhrystone performance was due to incorrect assumptions about the timer’s frequency. I plopped this problem up on the SiFive forums, and a patch was available in a few hours. What does the real benchmark say?

That’s a fast microcontroller. RISC architecture is gonna change everything.

love this test. Beginning this review, I originally planned to run a few benchmarks on an Arduino, a Teensy, and the HiFive 1, throw together a graph and spend a hundred or so words on the results.  I got so much more.

Right off the bat, we can see the HiFive 1 is fastReally, really fast. Right now, if you want to build a huge RGB LED display, you have one good option: the Teensy 3.6. If you need a microcontroller to pump a lot of data out, the Teensy has the power, the memory, and the libraries to do it easily. In this small but very demanding use case, the HiFive 1 might be better. The HiFive 1 has more Flash (although it’s an SPI Flash), it has DMA, and it has roughly twice the processing power as the Teensy 3.6. This could be very, very cool, and I can’t wait to see the real life examples of how much the HiFive 1 can push out of its pins.

There’s your hundred word review on the performance of the HiFive 1 based on synthetic benchmarks. However, getting this benchmark working revealed far more about the state of the HiFive’s software, and how much support SiFive is throwing at it.

Admittedly, I do have a very early version of this board, and the CrowdSupply campaign for the HiFive 1 was only funded last week. No one would expect one of the three demo apps shipped with a newly released board with a mature architecture to be completely broken (unless it’s an Allwinner chip, but whatever). Very few people would expect the devs to get a patch out in less than 24 hours in response to a random person on a support forum.

All of this circles back to a single observation on the HiFive 1: It’s new. The HiFive 1 and all RISC-V microcontrollers don’t have a vast market share, user base, or decades of work behind them. However, the SiFive team seems to be taking their work seriously. They’re fixing the problems they have, and they’re constantly pushing out new documentation. This is great, and a very good indication of how much support the RISC-V chips from SiFive will have.

Chips As A Service

I should note that the folks at SiFive aren’t in the business of building RISC-V Arduino boards. They’re in the business of making chips for people. This is custom silicon we’re talking about here.

The easiest parallel to draw is between SiFive and OSH Park. These companies don’t have their own manufacturing capability; the value is in connecting end users (engineers, startups) to manufacturers. OSH Park connects you to a board house that really knows purple, and SiFive connects you to a chip fab. In the case of the FE310, that’s TSMC.

For anyone who wants silicon you can study, this is great. No, it’s not as simple as sending a board off to a fab house, but it’s a start. The fact that SiFive chose to start with Open Hardware is great, and we can’t wait to see the other hardware made with their sweat and hydrofluoric acid.

Update: You can already get your hands on the RTL for the SiFive chips if you want to run the cores on your own FPGA.

It’s a Beginning

At the base level, the HiFive 1 is a powerful microcontroller with a lot of Flash, with support for hundreds of Arduino libraries. That’s great, and alone this might be worth the $60 price of admission.

However, the big story here is the Openness of the HiFive 1. Is it completely open? No. the HiFive 1 itself uses an FTDI chip, and I’ve heard rumor and hearsay the FE310 chip has proprietary bits that are ultimately inconsequential to the function of the chip. A strict interpretation of Open Hardware will not allow this board to be called Open Hardware. Those who advance this interpretation are dumb, and to counter this argument I will quote the man himself:

…We need to distinguish levels in the design of a digital product (and maybe some other kinds of products). The circuit that connects the chips is one level; each chip’s design is another level. In an FPGA, the interconnection of primitive cells is one level, while the primitive cells themselves are another level. In the ideal future we will want the design to be free at all levels. Under present circumstances, just making one level free is a significant advance.

– Richard M. Stallman, Free Hardware And Free Hardware Designs

A design that fails to be completely Open does not deserve to be grouped with designs that are explicitly closed.

Nevertheless, this is the best we have so far, and it is only the beginning. We’re going to have more microcontrollers that are more Open, but until then, the HiFive 1 is actually a pretty cool board.

148 thoughts on “Hands On With The First Open Source Microcontroller

  1. Nice writeup! I had to do a double-take at that second performance graph, though… at first I was thinking “oh, with the fixed test it’s still only half as powerful as a Teensy?”, before I realized that the green and purple bars had switched places.

    1. While it is showing great performance. It is a bit apples vs oranges. As the chips run at vastly different frequencies.

      Score per Mhz is:
      AVR: 0.631
      Teensy: 1.239
      HiFive: 1.557

      Which also isn’t a really good comparison. But it still comes out on top. Next interesting metric, MIPS per Watt.

          1. The Arduino IDE gives you a choice of 16 MHz or 256 MHz. In fact it defaults to 16!

            Other speeds are possible by editing config files, but then you need to calculate divisors for things such as the SPI bus to the flash chip and I guess serial baud rate. That’s not super well documented or automatic right now. SiFive say all the chips should run at least at 320 Mhz, and some of them probably close to 400. 256 is nice and conservative for a start.

            My own quickie tests (that fit into 16 KB) show the HiFive1 going neck and neck on a per MHz basis with an A7 or an A53 running 32 bit code (both of which are dual issue, while the HiFive1 is single-issue). Of course it loses badly to A9 and A15.

      1. I second the interest in MIPS per Watt. But I still think HiFive having more MIPS per cycle while simultaneously having a higher frequency is still impressive. Both metrics are interesting and useful in their own way.

    1. The article covered the a good reason for “open” hardware – licenses. An open hardware design can be fabbed by anyone. This means: lots of (potential) competition around manufacturing to drive cost down. When mainstream manufacturers stop producing, design can easily (from a legal/copyright/license point of view) be sent to someone else to produce a custom run.

      The other reason is presumably “open” means a better chance at looking into the guts at what makes it tick. This is a bit strawman, as I certainly won’t audit hardware, but someone might. “open” should mean nothing hiding behind NDAs and protective fuses. So, no clever NSA inserted firmware, etc.

        1. ^ This. It’s no problem whatsoever to insert some subtle bug or backdoor at the fab. Especially if you can fund a production run that floods the market at below the next best price.

          1. I shudder in horror when I think what sort of intelligence the NSA is extracting from my RGB led driven by a micro. There are only certain cases it makes sense to have any sort of backdoor, Network gear particularly since it will always have an established communication path. A microcontroller… eh? not so much.

      1. “An open hardware design can be fabbed by anyone.”

        …with enough money to hire a semiconductor fab and the resources to handle a production run of a million units to make it “cheap”.

        1. Yes, that’s the rub here and I think software people often don’t appreciate the costs and logistics involved in getting hardware made. You don’t get a chance to go roll out a bug fix or update after release, and you don’t get your money back if it all goes wrong. There’s a very limited number of fabs in the world, and a very limited number of competent designers so competition will be low. Fabs won’t be falling over themselves to compete, even for 1M units. Contrast that with the software world where the barriers to market are essentially zero.

          I certainly support the effort but, as an aside, can a chip outsourced for manufacture ever be considered totally secure/open? If the fab were lent on by a large agency, for example, to put in some backdoors after design submission, the end user wouldn’t know about unless they had physical access to the die and the time to go through all the logic. Possibly a contrived scenario, but you don’t have the same transparency as compared to software where you have everything visible to you.

          1. That is a valid concern, but luckilly, there are safegaurds. Firstly, the fab doesn’t necissarily understand the design you give them (except in this case, where you’d ideally open-source the design), but under normal circumstances, the fab house would have to spend resources to reverse engineer your design, then design a compatible back-door, and ‘plug it in’ to your design. That’s a lot of time and money, especially for designs as complex as SoCs. Secondly, the more robust safeguard is physical verification. Once you get your million something chips back from the fab, you can sacrafice a couple; decap them and use a microscope to verify that the silicon matches the design verbatim. Plus, if any fab were caught putting backdoors into designs, I’d imagine no company would ever use that fab again, so the fab would be taking a lot of risk, and spending a lot of resources just to put a backdoor in a specific rev of a specific ship.

        2. This was exactly my thought. If you are deep into tin foil hats and/or worrying about your terrorist cell getting uncovered then I see the point of looking for back doors. But for purposes of being able to “screw with stuff”, which is what open source is all about for me, the issue is that I don’t have a semiconductor fab here in my garage. So for me an FPGA is the only path to “open hardware”.

        3. The difficulty of manufacture doesn’t diminish the value of open source hardware.

          Frankly, I avoid compiling open source software at all costs, but I still prefer using open source software.

          1. I think it does though, particularly for semiconductors. The beauty of open software is that anyone can get involved, and it’s possible to rapidly iterate through versions and ideas with zero added cost, other than time, no NRE costs, and those changes can be instantly spread across millions of users. The design of hardware is inherently much more conservative: it has to be correct first (ideally!) time, each run typically has substantial NRE costs, and getting a new design out is intrinsically physical. Further, the cost of the tools used to design semiconductors place it far out of reach of the vast majority, even if they did know how to use them. Open sourcing your projects is one thing, maybe you’d spend £100s, maybe £1000s for more complex designs, but for semiconductors at chip scale you’re talking £Ms.

        4. In fact ARM license costs are so low that open hardware like risc-V are mostly irrelevant cost-wise.
          The real advantage is to have an opensource core you can modify at will on the ISA level, which is something you can’t do on a std arm core.

          1. “The real advantage is to have an opensource core you can modify at will on the ISA level, which is something you can’t do on a std arm core.”

            This is a bit misleading. Yes you can technically modify the ISA, but unless you have millions upon millions of dollars to spend you will never get to actually use those changes.

            Calling it the first open source mcu doesn’t sound right to me. OpenCores have had fully open designs for a long time. While a slightly more open design is certainly a step in right direction, let’s not call it something it’s not.

            What the world desperately needs isn’t yet another open source ISA. Instead it’s massive reductions in semiconductor fab costs.

      2. Audit is not the only reason to look at the guts. We recently had a pretty nasty encounter with an I2C slave chip, which would randomly lock up the bus. And it is a major problem for us. We contacted the manufacturer (NXP). However, the end result is “we also do not know why this is happening. Try to add a delay at point X, maybe then your problem is gone”

        Insight in the chip would give us a chance to actually find the root cause instead of random guessing and hoping for the best.

        1. You do know slaves are allowed to clock stretch?
          Also monitor the transients between the ground plane and the I2C pins to make sure the bus is not being glitched by interference.

          1. Slaves (or masters in a multi-master setup) locking up the I2C bus definitely happens. This is a major reason why SMBus was developed in the first place, because the lack of timeout functionality seriously hampers the reliability of I2C. The only way a slave actually clock-stretches is if it’s doing some kind of external activity, which means there’s always a possibility for something to go horribly wrong.

        1. The chip individually? Perhaps not.
          But given that the cab is not going to change the design of half of even 10% of the chips being put on a wafer, you can decap and inspect a few samples to ensure that the design is what you ordered. I don’t expect every consumer of these chips to have the expertise to do this, but that is how open source functions; there is someone out there, either at SiFive or elsewhere, who will look and see if the silicon matches the design.

          1. That’s a pretty difficult thing to do – logic looks like logic looks like logic, and it’s incredibly hard to look in – multiple metal layers, buried/blind vias etc. Unless you have an very good (read: experienced, expensive, and well equipped) audit team, this is not going to happen. Sure, gross changes are visible, but one could modify things discretely so it would be very hard to track down changes, especially when you’re talking millions of transistors.

    2. TL;DR: It seems to me that open hardware offers many of the same benefits as open software, although to (at present) a much smaller group of people.

      My 2¢:

      Yes, but how often is the documentation good enough? And isn’t the advantage of anything open that anyone can contribute to debugging it? Anyone with the know-how can look at the design and offer input on how to fix or improve it. Or fork it and make it themselves, with the help of orgs like HiFive and OSH Park etc.

      And it seems like you get the same potential security benefits from open hw that you do with open sw, in the case of eventually building a fully open computer. If each chip can be independently vetted, you know that none of them are doing things under the covers that you don’t want them to do.

      Of course I suppose one big difference here is that the set of people who can develop software is vastly larger than the set of people who can develop a microcontroller. So it’s harder to get that large number of independent reviewers. But there again, actually having a working open hardware design can also be a teaching tool for those of us who learn best by seeing examples. Someone could put together a pretty informative course on microcontroller design just by going through the design of the Freedom E310, explaining how it works, discussing strengths and weaknesses, etc.

  2. Sorry, but merely releasing an instruction set specification is far from being an “Open Source Microcontroller”. I’d Argue that the Parallax Propeller 1 and 2 are more open source, they actually release the *HDL files under the MIT license!

    This whole RISC-V thing smells like marketing propaganda. From the little I can glean in 60 seconds of giving a crap, it’s an instruction set designed by some powerful companies, released into the “open source” so they all can build, or source, chips that will carry a common instruction set for the IoT and/or cloud computing plans. I would speculate that “open source” was not an objective, driving down their costs by not paying for ARM or x86 processors was their objective.

      1. The RISC-V ISA was designed at UC Berkeley and the specification is released into open source under a BSD license, which means anybody can implement RISC-V freely. There are multiple open source instantiations of RISC-V cores put out by various folks. The FE310 is an open source SoC which includes a RISC-V CPU core plus peripherals.

    1. You’re way, way off base. RISC-V is from UC Berkeley, not some nebulous group of “powerful companies” looking to get out of paying licensing costs. The design being open is practically the main reason the project was started.

  3. The chip is twice as fast as a Teensy 3.6, but the IPC is only 25% more when you factor out the clock speed. Don’t get me wrong, that’s fantastic for the first spin of a new design going up against an established architecture and vendor. But we can’t forget the terrible lessons the Pentium 4 taught us about competing on MHz alone.

    1. 1.65 DMIPS/MHz is what a PIC32MZ does…. back in 2013 at least. Many of the other PIC32 cores do 1.25 Mips/Mhz or 0.9 depending on the model.

      This chip is only 1.55 Mips/Mhz… so it is good but not best in class. And it potentially uses more power as well.

      1. I can guarantee you that it will use more power. Modern processors are made in such volume that it makes sense to run them in the most cost-effective process, which seems to be 28nm right now. That works great when you are making millions of parts.

        This part, on the other hand, is made using a 130nm process (roughly 20 times bigger, and a lot more power). You will never see parity on power until this part is made using a more modern process.

        However, power and IPC are not really the goals here — openness is.

        1. A larger process does not necessarily mean a higher power process…. And you are also dead wrong. PIC32 processors my be high volume but they are not high margin… both use relatively old cheap processes… because those old cheap processes happen to also have become very mature, cheap and power optimized. “130 nm upgrade to the slower 250 nm PIC32MX”http://siliconexposed.blogspot.com/2014/03/microchip-pic32mz-process-comparison-to.html

          1. A larger process generally DOES mean a higher power process. There are tricks that you can do to minimize this (power islands, voltage/frequency scaling, etc.). So, a larger process, properly designed, can indeed be lower power than a smaller process where they did not put in the effort. However, all things being equal, smaller = lower power.

            Well, lower DYNAMIC power. This is the power that scales with frequency. Simply stated, power, is related to charging and discharging of gate capacitance. Smaller geometry = smaller capacitance, and shorter wires from source to destination. Simply physics.

            Where smaller geometry hurts, however, is in leakage. That is the amount of power consumed just by applying voltage to the power pins, even in the absence of a clock. There are techniques to control this, however, such as using transistors with different threshold voltages.

            You do have a point about some chips using larger geometries. Microchip, which you mentioned, (and who I currently work for), owns some of their own fabs. However, these tend to be older ones with larger geometries. There can be cost savings going with your own fabs vs. sending work to places like TSMC and UMC.

            However, my point still, in general, stands. The cheapest transistors are right around the 28nm mark. However, this assumes a relatively large design. You need a certain amount of space for the IO ring to handle all of the pins on the chip. Simply stated, the number of IO pads determines the minimum size of your chip. Even if transistors shrink, the pads that wire-bond machines have to hook wires up to are not shrinking. So, shrinking your geometry will not reduce your die size below that point (that is called “IO bound”). In that case, going to smaller features will not save you money.

            Note that the cheapest transistors being 28nm is just for manufacturing. That does not include the design cost. For smaller volumes, larger transistors can be much cheaper just do to the decrease in mask costs.

          2. As you say a larger geometry may also be less IO bound and thus cheaper as not all designs need that many transistors… my point earlier was that going to a smaller geometry does not guarantee lower power… neither does doing lots of tricks guarantee that you can beat a smaller unoptimised geometry … in short making generalizations and assumptions are bad.

            I think things will get more interesting ones optical interconnects become more of a thing…. making designs less IO bound.

        2. @kevin….from the datasheet it seems that the manufacturing process for this microcontroller is actually 180nm not 130nm…..For comparison, TI’s Tiva C microcontrollers use a 65nm process and many of the stm32 microcontroller utilize the 90nm process. So I imagine that power consumption for the siFive would be at least 1.5X/2X as large as that of these two microcontrollers….which is still not bad given that it is open and developed by a much smaller company.


          I’d switch to siFive1 from stm32 in a second if it gets some analog peripherals like an analog comparator & ADC, and if they use at least a 90nm process.

          Still I have to say that fabricating an open microcontroller and starting a business around it is no small feat. I must congratulate them for it and will be buying one of their boards to support them and their initiative.

      1. Like most communities, it is a mix but I am generally quite appreciative of the comments on most projects and posts here. Some posts are of course lightning rods for controversy and double as clickbait but by and large, people that post here are not jerks or assholes just to be assholes. There will always be dissenting opinions of course but that’s fair for almost any group that is not literally just clones of each other.

  4. The idea that you can’t study AVR core etc. is pretty much exaggerated.
    Lots of them are available for download at opencores.

    And as far as I know patents of the older ARM cores are expired and as far as I know those are up for grabs.
    And a quick eyeball show all the older cores are also there.
    Dont blame me, I’m not a laywer.

  5. About the FTDI chip and open source: yes, FTDI is jerks. But the FT2232H is the fastest path to getting a high speed JTAG and UART on an eval board working with OpenOCD. Certainly that choice pales in comparison to all of the commercial tools and fab NDAs needed to get the design in silicon. I’d rather they get the chip out the door and not waste funding on yet another JTAG debug interface.

      1. What would you do with them if you had them?

        This is not PCB manufacturing. You can’t ship masks to any fab and end up with a working chip like you can with gerbers. The process is proprietary to the fab, to the point where fabs provide designers with libraries for common components that are known working on a given process of theirs.

    1. Uh, then send them a pull request to add a USB to Serial bridge into the hardware description language, and pay for the debugging and testing of said design.


      Then quit whining and be patient. They’ll get there eventually, with or without your support. Incremental progress.

        1. USB uses 3.3V signalling (VBUS is 5V though). You would need an analog PHY circuit anyway in the chip to talk to the USB port in a compliant manner, so you can design the outputs this has yourself.

  6. I backed them for one out of curiosity. One of the places where openness is lacking is that they have decided to not open their implementation. Openness stops at the RTL. The gate netlist is not open nor the LEF/DEF nor GDS. I was hopeful because it would be interesting to experiment with full-scan debug but alas. But, also, from a security standpoint, there are changes between the RTL and the implementation and a user of this device will not know what they are without this openness.

  7. Awesome microcontroller! Who cares about what other chips are used on the demo board, that’s just to make it work as a quick and dirty dev platform and you could do whatever you wanted in your own designs. You can’t expect them to build a host of open support chips from the get go as well, you have to start somewhere. The point is that the micro is open. And fast!

    As a side note: please just let 5V die. It has been dead for a long time in most electronics. The only reason it’s still alive in the Maker community is stupid ancient AVR Arduinos. Let it go people. Stop level shifting everything, the electronics world has moved on, so get with the program and base your next project on a 3.3V system.

    1. We will bury 5 V when the last 3.5 mm audio connector is buried, when the last TIP blows up, and last ECC83 burns it’s filament. Meaning never. And that is how it should be. Amen.

  8. Interesting I see no mention of how much RAM it has in the article here, anyone know? I see the 16kb data scratchpad but is that all it has ram wise? If so that could mean that even though it’s faster the Teensy 3.6 will beat it out in a number of uses.

    1. Checking the datasheet it is confirmed. It as only 16Kb data RAM on chip. This means if an application require more than 16kb RAM it will have to use external RAM. The chip as no external address and data bus this means external SPI RAM. This will be a real bottleneck. If using virtual memory scheme only 16kb RAM on chip don’t give much in term V.M. pages, 4 x 4kb pages that is…

      1. Well as long as there is either 8/16/32 GPIO pins for bit-banging data and data encoded address space along with additional GPIO for bit-banging communications/states, then that 16K/16K code/data RAM could be used as a pseudo cache and the uC could run some form of VM as a Virtual_CPU-on-CPU (OK halve the 16K code/data as some is used for caching parts of the VM from external 16MB/128Mbit flash).

        A seperate controller (or two, as a form of northbridge like role) could take the data encoded addresses and pull the appropriate address buses high/low and or map hardware into said address space (Via another Virtual machine acting as a peripheral controller hub) and then pass data/control-signals/etc..

        A bit of a hack job. As for the VM side of things, think like that project posted around here that ran Linux on an avr or something… With external RAM slapped onto it.

        OK, yeah, a little overkill and a performance killer when there are better alternatives. Also I wouldn’t know where to start programing wise on such a project.

        The above is purely an IDEA.

        The only IRL circuit I came across closest to this configuration idea is from an old bar till range that ran a text-GUI on a cross-pattern-strip style touchpanel (We fixed these boards at work due to common fault with leaky Ni-Mh batteries).

  9. Of course there are points I like and dont.
    I am glad there is a open chip now. I am not so glad of the FTDI they have used, but I am hoping that they get rid of it as soon as they can. I can only see this hurting them in the short come. FTDI has done way to much damage to us. And me as one of the victims, they cost me hundreds of dollars and a lot of time and made me look like a fool on the phone, and I had nothing to do with them But buy reputable manufacturers Items that had fake chips in them some how.

    I am really looking forward to getting my hands on one or two of them when they get rid of that chip.

    Good luck

      1. Yes it will, in theory. You could say that any derivatives are just a next step, not a counterfeit. But if the license is not honored, then you get into trouble with such a claim.
        Besides: has the problem of ‘no copyright for hardware’ been solved yet? Copyright is still the foundation for OSS, but can it be for OSH?

      1. Depends of course. If you buy just the chip you get a chip (duh). If you buy one of the nucleo or discovery boards you get a board with programmer and peripherals. The board is typcally 5-15$

  10. I was excited (at hype) and so close to order Founder’s Edition of HiFive1 at the end of November until I turn my reality check lever and research on to it design and architecture. And I DID NOT waste 79$ on device that promise to be MCU but does not have single analog input (not even comparator’s that even old 80′ MCU have) so disappointment was complete.
    Instead I rush and buy me some ARM Cortex M7 Nucleo-144 STM32F7xx boards to play with, for just a fraction of price that HiFive1 costs, and I get so much more. Promise of 500DMIPS is nothing special in today’s hi-performance MCU arena, even 6-7$ ESP32 can deliver that and it also have very “distinctive” Xtensa LX6 DPU arhitecture :)
    I keep some 8x SN74F181 4bit APU-s ( and rest of logic IC needed) so that one day I may use to play and make my homebrew CPU and then it will be true OPEN DESIGN for me :)
    Until then Raspberry Pi’s can “wipe the floor” with HiFive1 and for 1/2 price it is solution with 2-3000 DMIPS CPU and 57(125)MHz bit-banging all digital GPIO’s that is much better and proven working alternative.

    p.s. Brian please try this: https://developer.mbed.org/users/JovanEps/code/Benchmark_Whetstone/ on HiFive1 and report us results you get. Thank you in advance :)

    1. The HiFive1 wasn’t meant for you.

      It’s the first part out the gate for a new architecture from a new company. If you want a good performance or feature value right now, stick with the standards. If you want to develop on something new and interesting, buy one of these.

          1. Because all this post and hype that this startup is making about this board, chip and concept is MISLEADING to put it mildly!
            Be honest and stop trolling in favor of thing that is unusable in context of use that is put on. When you put it in Arduino form factor it has to do job as Arduino or any other MCU does, right.

            On the other hand this review (and all others) did not say:
            1. How fast this Dev. can access and change its GPIOs (regardless of its pure digital nature), how fast it can bit-bang or do ring-osculation over its pins?
            2. How it performs in SP i DP Arithmetic and with required that need FPU/DSP functions.
            3. Skip the cr* about Openness and Chips As A Service marketing hypes and past proper answer to technical questions regarding architecture, realization and real life results.

            Or you indeed is not for this site, along with that board and do not bother to post on it.

    2. I understand your point, but please do not try to prove this device is crap unless you have something to say about the open-sourceness of it – since that’s what people are buying it for. You’re missing the point of this chip and what it means to other people.

    3. As I did order one of thise HiFive boards and received mine today I ran some benchmarks. I got 412DMIPS, comparable to what Brian got. On coremarks I got the following:
      Iterations/Sec : 700.218818
      Coremarks/Mhz :2.7

      And just for you I also ran the Whetstone benchmark you linked and got the following:
      Loops: 25000 , \0x09 Iterations: 1, \0x09 Duration: 203.000 sec.
      C Converted Double Precision Whetstones: 12.315 MIPS
      Not too impressive, but I haven’t bothered to do much in compiler options, I compiled it with -02 and that was it.
      Clock running at 260Mhz.

      1. Thank you Rik,
        I can say that you understand a bit about what I wanted to talk about about this solution. The RISC is not from yesterday but due to other IP solutions were sitting in the shade and waiting for his moment, hypo who have tried to launch the guys on the west coast now died down a bit so we can talk about serious technical issues of implementation.
        Time has shown over the last 2 years that the ESP32 has exploded as a popularity solution, that in China, RISC V based solutions (Hummingbird E200) are developed as mushrooms after the rain. So even I now own Lichee Tang FPGA development board with RISC-V soft CPU cores (at a price less than 25USD), and maybe when I get a time will play with them.
        In any case, thank you for the useful information that we could not get from the article.

    4. If you want an alternative to Arduino then this board is actually not for you. I think almost everyone who is interested in the RISC-V technology is not focused on the Arduino compatiblity but is excited to have a real RISC-V in silicon. Simulation is nice but real silicon is another thing. I purchased this board just to have an education system to learn RISC-V development at the bare metal level. And I purchased this board also to make a contribution to the Open Hardware movement. HiFive is just a starting point, and worthy to be supported.

  11. Talk about poisoning their own namespace!

    This is a total mess of confusion.

    We have a board and it has *something* to do with an open source micro-controller????

    OK what’s the board – it’s either a si-five of a hi-five. I did read what it was and these two thing are impossible to confuse NOT!!!!!!!!!

    OK, then what’s the micro-controller – well it’s one of the above, I think it’s a hi-five cos that the name used. BUT wait hi-five is just an organisation or something and the micro-controller is NOT si-five or hi-five and si-five just an instruction set architecture that is open source and not the micro-controller per-say.

    And if you google for the hardware architecture of this implementation then you find that the haystack is full of needles relating to the the Instruction set *architecture* and not the hardware architectural so you are looking for one specific needle in a tone of needs instead of a haystack.

    Then you find some PDF’s embedded into some web pages but the print is too small to read and you want to have a quick look for the number of GPIO’s but there is no really really basic pinout so instead you have to scroll through pages of hard to read print of the pin *descriptions* to try to keep a mental tally of the GPIO’s.

    Seriously ….

    Good – HTML web page that has been converted FROM a PDF
    Fair – PDF available for download
    Crap – Embedded PDF’s

    Good – Documentation that has an overview and basic information at the start
    Fair – Documentation that has basic information close to that start
    Crap – Documentation that has no overview so you don’t know if it’s about a uC or South African desert crabs.

    Good – Names that make it clear what they are.
    Fair – Names that give some idea about what they are.
    Crap – Names that are so similar that it’s inherently likely that you will confuse them and are so non-descriptive that you don’t know if they an organisation, hardware implementation, or micro-controller

    Good – Not poisoning your competitors namespace.
    Fair – Poisoning your competitors namespace after they poison your namespace.
    Dumb as Fu(k – Poisoning your own name space.

    With what I did find when I looked because this chip might be good for hardware control (3Dx) –

    Good – Chip that has good performance even perhaps to run a simple OS
    Fair – A bit of a limitation with RAM – no bigie for hardware controll
    Bad – Arduino Uno form factor with not enough GPIO

    Seriously I hope this project does well but I seriously doubt it will because of the tragic use of namespace – hey guys – the internet – it’s real you know.

    1. RÖB, you are absolutely (100%) right, although I research a little more about it, just to make sure what I want to buy.
      Although I have great respect for people that make it, all I can find is hype, more hype and shallow technical background doc/spec.
      It say that is Open source but its really act more like patent pending, close source solution from start-up company that want to establish theirs own new ecosystem and (in future) sell good on stock market.
      I hope time and theirs future efforts will prove me wrong, but right now it sound, and look like hollow story.

    1. Sadly that’s never going to happen. NRE on silicon is pretty large, and any manufacturer is going to want special sauce in the peripheral set to lock you into their SoC line.

      Case in point: ARM Cortex-M had us all convinced that a common core standard and some standards for libraries would save the world from SoC vendor lock-in. It did succeed in causing more manufacturers to shy away from proprietary tools. But there’s still no such thing as second sourcing ARM SoCs.

    2. Do you and your open source buddies have millions at your disposal to ensure this doesn’t happen. Remember fabbing the chip is very expensive.

      BTW there are 3rd party manufacturers that still manufacture those micros that have been obsoleted by their OEM’s.

      So far releases like this are irrelevant. The small business owner who wants to sell a low cost product can’t afford a crippled micro that sells for $50 or so.while they can buy a ARM micro for the less than the cost of a soda.

      I’ll get interested when it has the same peripheral set as a M3 ARM and on board flash and is price competitive with the offerings from ARM and Microchip.

      Right now this micro is for fashionistas and social posturing.

  12. The FTDI chip isn’t really relevant. It’s just a way of getting a dev board out into the world quickly. They can surely replace it with something else when they’ve got the time to work on that. Considering this is brand new silicon, FTDI is a good idea, since it’s use is known and understood, as opposed to the Chinese knockoff thing cheap Arduinos use.

    Using the FTDI means they’ve got a known-good USB interface, so it’s less likely to hit them with some obscure bug down the line, which might have happened with some other USB interface. Best to get everything else on the board as reliable as possible, while the silicon itself is still a new design.

    For now it’s not relevant, what’s relevant is the new chip itself. In a little while, I’m sure they can change it for something cheaper, from a company less hated and evil. And if they don’t, some enterprising Italian can do it instead, because it’s open hardware.

    1. Finally a well placed opinion! This anti FTDI rant is like debating over whether it is kosher to use any semiconductors in a tube amplifier. If it makes you feel better.. One thing FTDI has for sure is that it just works well, provided your supply chain doesn’t suck, so you can focus on other more important things.

    2. It’s important to hold FTDI’s feet to the fire. They did some extremely user-hostile actions, and the only way to stop it happening again is to make sure the PR fallout is long-lasting. It also serves to warn off other manufacturers who may have considered doing similar things.

      That doesn’t necessarily mean they should be boycotted forever, but it’s history that shouldn’t be forgotten.

          1. The buggy Linux drivers for the CH340 should be fixed soon thanks to the efforts of like 3 or 4 people. Unfortunately, this was slightly derailed by the fact that it appears there are, in fact, CH340 clones out there and they’re really rather buggy. (Initialization command does not function as expected, register writes need to be paired up in exactly the pairs it’s expecting, probably other bugs.)

        1. Not in this case it isn’t. FT2232H has two separate channels, with one acting as USB-UART and the other as a USB-GPIO for JTAG. And it’s USB-HS. The CH340 may be a fine UART, but it doesn’t take the place of the FT2232H as a quick and dirty USB debugger that isn’t dependent on firmware.

  13. After all these comparisons to the Teensy, maybe Paul Stoffregen could be inspired to build – the Weensy 1.0 ?
    Putting this new chip on a board with Teensy dimensions [or similar].

  14. I was pleased to see that they used scala/Chisel for the periph and top design :D even if scala/SpinalHDL seems way more promising to me.
    Verilog and VHDL should really be buried as some netlist languages.

    For some reason they stripped the tests, which are essential in a hw design, so for me even the software design is only partially open-source.

  15. FTDI there -> I am out. There is some things in what resposible people does not support. example ISIS, mexico drug cartel, boko haram, FTDI and most probably Prolific is also bad for your mental healt and ethically wrong to support.

    1. I think that Prolific’s response to fake devices was reasonable but FTDI crossed a line by using the Microsoft signed driver update mechanism as an attack vector to brick hardware.

      While no one was looking Microsoft took control of the VID/PID allocation system.

  16. All that fuss and buzz about Hi Five1’s fixed Dhrystone 2.1 benchmark performance, forced me to sit and port that benchmark to (mbed) ARM Cortex M7 *STM32F767 and to test it:
    And what I get is this : …”
    Dhrystone Benchmark, Version 2.1 (Language: C)Beginning DHRYSTONE Benchmark
    Default MCU clock is 216 MHz
    Execution starts, 2000000
    runs through Dhrystone

    Execution ends in : 1528664 us

    Microseconds for one run through Dhrystone: 0.76

    Dhrystones per Second: 1308331.98

    VAX MIPS rating = 744.64

    I really do not want to promote ARM but that 744 VAX MIPS on 216MHz M7 for just 21$ and with “zillion ” of D/AD/DA ports is real MCU board :)
    You can check code at: https://developer.mbed.org/users/JovanEps/code/Benchmark_Dhrystone/

  17. Wow. Lot’s of debate on the value of open hardware.

    First, yes, it will probably be a long time if ever before we can ever fab chips at home meaning the same kind of easy user modifications that happen in software are unavailable as a fabbed chip. You can still do that in FPGA though and I would expect that good changes which are shared upstream would eventually make it onto a fabbed chip.

    Second, that’s not the only value of open source. I like open source software because once something reaches some critical mass of ‘community’ size it or something totally compatible with it is likely to be around for a very very long time. I like my Linux that still has drivers for the old crap parts piled in my garage and can still read the filesystems on the storage devices. I like my programs that can still read the files I wrote as a kid with no artifacts due to imperfect conversions.

    You only get support with closed stuff so long as there is a strong monetary incentive for a company to continue supporting it.

  18. The Pine-64 had a very bad review on this site. I do not agree with that review. But that is not my point. My point is that this review is mentioned completely out of topic in a number of other Hackaday articles. Including this one. What did happen? Did Mediatek refused to advertise on this site?

    1. haha, just tried download Pine image from the FIRST LINK on their site:

      ERROR 404 – Not Found!

      The following error occurred:

      The requested URL was not found on this server.

      Please check the URL or contact the webmaster.

  19. The best part about religions is that (almost) everyone can be right about them. They are right, who say that HiFive 1 is not free. No less is right [Brian Benchoff], who say it’s good enough to begin with.

  20. What I would like to see is an open source credit-card format processing engine, that behaves somewhat like an INMOS Transputer of old that I could build up over time with an array of cards to be my own parallel processing machine. I met Parsytec at CeBIT in Hannover many years ago when they were demonstrating a PowerPC based machine to replace their T800 engine. I think they intended to go with T9000, but that failed to arrive. Maybe what sold me on it was the fantastic industrial design they had – it really did look the biz (google for the Parsytec Power Xplorer). That and they were a PowerPC customer (albeit Motorola, and not IBM) when I was in IBMs OEM division, trying to sell bits of IBM technology to other companies.

    Given that was 20 years ago or more, they were hampered by available technology in terms of the resources that could be made available to each node (like 32MB RAM for instance). We could do hundreds of times better now with lower cost, less energy required and hopefully slightly more mature software tools.

    I always thought that if we standardised on a card format, I could just add to it over time as technology matures, relegate first generation cards to I/O operations and control computers, have a reconfigurable fabric of engines that could address real-world HPC-style problems, like cracking genomes, or providing radiologists with computer aided detection of possible cancers in DICOM imaging.

  21. If we you just change title from “Hands On With …Microcontroller” to “…SoC RISC development board system in Arduino form factor” whole this story will be more relevant and much truer. Although documentation and Block diagrams for E3 Coreplex and Freedom E300 SoC shows ADC and DAC block elements in design (http://files.linuxgizmos.com/sifive_e300_block.jpg), in this design based on FE310 there ware omitted, WHY is the real question?

    So, if someone could make a serious and thorough review of that device (Dev.board, SoC, ports etc.) its operation, architecture in a proper technically minded way?
    I am sure that we all will be more then thankful for that.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.