Custom RISC-V Processor Built In VHDL

While ARM continues to make inroads into the personal computing market against traditional chip makers like Intel and AMD, it’s not a perfect architecture and does have some disadvantages. While it’s a great step on the road to software and hardware freedom, it’s not completely free as it requires a license to build. There is one completely open-source and free architecture though, known as RISC-V, and its design and philosophy allow anyone to build and experiment with it, like this build which implements a RISC-V processor in VHDL.

Since the processor is built in VHDL, a language which allows the design and simulation of integrated circuits, it is possible to download the code for the processor and then program it into virtually any FPGA. The processor itself, called NEORV32, is designed as a system-on-chip complete with GPIO capabilities and of course the full RISC-V processor implementation. The project’s creator, [Stephan], also struggled when first learning about RISC-V so he went to great lengths to make sure that this project is fully documented, easy to set up, and that it would work out-of-the-box.

Of course, since it’s completely open-source and requires no pesky licensing agreements like an ARM platform might, it is capable of being easily modified or augmented in any way that one might need. All of the code and documentation is available on the project’s GitHub page. This is the real benefit of fully open-source hardware (or software) which we can all get behind, even if there are still limited options available for RISC-V personal computers for the time being.

How does this compare to VexRISC or PicoSOC? We don’t know yet, but we’re always psyched to have choices.

30 thoughts on “Custom RISC-V Processor Built In VHDL

    1. Unlike x86, ARM is a highly orthogonal architecture which makes it difficult to write compilers for, it’s also more vulnerable to various security issues once you go beyond single core without prefetch. Instruction wise, x86 also has some legacy from Z80 and it makes it better suited for tasks done on typical home computer.

      1. “ARM is a highly orthogonal architecture which makes it difficult to write compilers for”
        Shouldn’t this be the contrary ?

        I mean, have you ever written a compiler for x86 and its totally wonky “architecture” ?

        “x86 also has some legacy from Z80”
        I’d be curious to know which :-D
        How would Intel be influenced by Zilog in the design of the 8086 ?

        1. Yeah, the orthogonality makes it simpler for the compiler to allocate registers.

          The actual issues (for the hobbyist) are licensing and creating your own variants, although there are a couple of free options.

          The 8086 had an 8080 compatible mode (at a source level, not binary) I believe, but not Z80, which was itself an extension of the 8080.

        2. To the question of how Intel could have been influenced by Zilog, the answer would more than likely be the x86 would have legacy from the 8085, which the Z80 implements (op code wise) and extends. Zilog was created when Federico Faggin and Ralph Ungermann left Intel, both worked on the 8080 microprocessors circa 1974. The Z80 became the most popular 8-bit microprocessor. So, there is a tie between Intel and Zilog, but the 8085 would be the more likely legacy relative to the 8086, maybe with some of the Z80 extensions. I entered the engineering world around 1984 and the Intel/Zilog “wars” were stories of legend…

          1. I entered the microprocessor world in college around 1980, after tinkering with PDP-11 of various models. Worked with 8080, 8085, 8741, Z80 and 6502 of Apple’s fame.
            The 8080 was an 8-bit processor that required 3 different voltages and several support chips, such as timers, parallel/serial ports, dynamic memory drivers, external dynamic/static memory. It has a 16-bit address bus and 8-bit data bus.
            The successor 8085 simplified designs somewhat by requiring a single 5v supply, and multiplexing addresses/data lines. It was still an 8-bit processor, object compatible with 8080.
            The Z80 was also a single voltage 8-bit processor. Somewhat binary compatible with 8080/8085, its assembly Instructions were different.
            The 8086 the next generation 16-bit processor, incompatible with previous Intel processors.
            The 8088 was a variant of 8086 that made it easier to interface then existing support chips, and so it was chosen by IBM for their first DOS personal computer.

        1. While I also would totally like to see some citations on that as a general rule of thumb just telling someone “no you’re wrong” on the internet without providing _any_ idea what qualifications you have to make that judgement isn’t as helpful as it may seem.
          After a while “you’re wrong” from people who don’t at least say “I work in x field that gives me some knowledge of this” let alone “here’s examples of why that doesn’t work” is just background noise on the internet, to be ignored along with “first” comments and cat pictures (Not that I necessarily expect you to provide examples, without the OP explaining where that’s coming from, it’s hard to debate the validity of the argument).

          – Someone who is wholly unqualified to judge any cpu architecture flaws, but *does* read a lot of the feedback on hack-a-day to get a better sense for if the original source is blowing smoke or there’s actually something cool going on here :)

    2. I honestly don’t know. But checking the web, I see these huge disadvantages:

      * Software Incompatibility: Compatibility issues remain a hurdle toward the full adoption of ARM-based processors for use in personal computers. Programs or apps written on x86 architecture will not run natively on ARM-powered devices.
      * Capability of Programmers: The performance of ARM processors is dependent on the quality of software or apps written by developers. RISC-based CPUs tend to perform poorly when fed with codes from poorly written programs.
      * Drawbacks of RISC Architecture: Developing programs for RISC needs more effort when compared to developing for CISC-based architecture such as x86 architecture. The simplicity of RISC puts a lot of stress on the app.
      * Concerns Over Choice: ARM architecture provides certain companies with an opportunity for vertical integration. There are some concerns over companies limiting developers and consumers due to their full control over their hardware and software.

      Everybody can see that developing for ARM processors is a huge effort, suffering from poor programmers writing poorly written programs, while the simplicity of RISC puts a huge stress in the app. RISC will run the app hot, and that in turn will make the CPU hot, of course.

      ARM probably needs huge efforts to cool the CPU because those developers and consumers don’t want to have their full control taken away and probably will not put any effort in developing the software. Every software update, you run the risk of burning your CPU because RISC is so simple.

      Vertical integration is the solution, it’s an opportunity. I guess because vertical integration increases the airflow?

      Clearly the ARM architecture is just crap, nobody should every use it.

      Seldom laughed so hard. :D

      I found this list of disadvantages in multiple places on the web. But copied it from here: https://www.konsyse.com/articles/pros-and-cons-of-arm-simplified/

      Seriously, this is maybe the most contrived list of disadvantages that I ever saw in my life. I feel embarrassed reading it. Clearly the writer was tasked with writing a list of advantages and disadvantages, couldn’t find any disadvantages and made a few up, apparently from 1980’s textbooks teaching students about CISC and RISC. :D

      1. “Drawbacks of RISC Architecture: Developing programs for RISC needs more effort when compared to developing for CISC-based architecture such as x86 architecture. The simplicity of RISC puts a lot of stress on the app.”

        Thanks. I needed a good laugh today.

        The apps on my phone are faster than on my x86 desktop sometimes, but are doing the same thing.

        By the way: you likely have an ARM processor in your phone.

    3. It depends on which “ARM” you’re talking about — versions through ARMv7 carried a lot of the historical baggage from the late 80’s, such as giving access to the program counter through register 15. This seemed clever 30 years ago, but is a real headache with today’s deeply-pipelined out-of-order processors. Likewise, conditional execution is an elegant idea but turns out to mostly be a waste of instruction bits. ARMv8 was a “clean-sheet” redesign of the instruction set and eliminated some of these historical quirks, but not all of them.

      This talk from a lead architect at ARM (https://soundcloud.com/university-of-cambridge/a-history-of-the-arm-architecture-and-the-lessons-learned-while-building-it) gives a great overview of the history of the architecture, and many lessons learned along the way.

    4. One of the big ones, in its current state, is the architecture started out with the goal of being a simple 80’s design. That design has been expanded, unfortunately with full backwards compatibility. And that is a huge flaw. The complexity added by ensuring it’s still compatible with 80’s code is huge, and limits expansion–almost like having several generations of chips in one package, instead of the simple design that made it affordable and fast. RiscV, on the other hand, has been designed from the start to be extensible, in both 32 and 64 bits, so weird hacks don’t have to be implemented. Yet.

    1. The bigger MAX10 parts could probably fit most of this, but you’re looking at around $90 for a single FPGA!
      Then again, FPGAs of this size are not meant to fit into [low end] products, if you want cheap, you want ASIC, and you want volume, nothing changes these rules.

      1. …also, unless you need to be in an FPGA for other reasons, you’ll pay a lot more, get less performance, and consume more power than a purpose built ASIC implementing this architecture.

        However, as a fun project where you don’t need to run for months on a battery or run at Ghz clock speeds this is pretty cool.

    1. The qomu only has 2400 logic blocks which I would think will not be enough, it also has an arm m4 core at 80MHz that’s not all that fast either, it also has a very very low number of pins, put those together and it is useless for the majority of applications, I see their whole line of products just as novelties to be honest. They are low performance and very small form factor, almost too small for the majority of applications.

  1. The ARM organization has been, and is, scared silly by the RISC-V, and by the threat it poses to their “cash cow”.

    It (ARM) even embarked upon a program of almost vitriolic misinformation and disinformation a while back, and scaled back when they started being laughed at because of their motivations being SO transparent.

    One request:
    If you don’t, absolutely know what you’re talking about, please don’t contribute to this mis / disinformation by spouting ‘experiential’, personal-opinion “FACTS”. (…orthogonality of an instruction set makes it much easier. in all respects, to work with a particular processor…)

    Without getting personal and naming specific pieces of what are obviously nothing but items of personal agenda, for whatever reason(s), let’s leave it at the fact that RISC machines have always been easier to work with than CISC machines…except, of course, unless the designers made some really stupid mistakes.

    In any arena of technical design of a specific TYPE of product, there will always be one (product) which stands out above the rest. And then there will be others which are more ‘stupider’…

    1. Well,nameing does make for some language FUD with minimal logic.
      aka wouldnt’ recommend putting this machine on the top rack, as that would set up a high risc situation.

  2. >While it’s a great step on the road to software and hardware freedom, it’s not completely free as it requires a license to build.

    Neither are the cost for CAD tools, chip fab expenses or any churn cycles you may incurred. There are no real hardware freedom. All chips aren’t really “free” in cost or IP. There is always the proprietary library that is optimized and tied to a foundry that layouts the transistors, IO pads, logic, memory, clock circuits etc.

    1. This. Maybe one day proponents of OSS will find a model that allows for the design of silicon to be done in such a way that it can be open while also having a viable business model to pay everyone needed to take a chip from concept to tape out. And that is a LOT of IP that has to be created by a lot of people as you state above. What makes it economical is when those costs can get amortized across the purchase of a large number of units.

    2. No one said that freedom means free from cost. Hardware and software freedom means that someone could build full functional and useful systems without restriction from some other company. With RISC-V, I can build an entire computer from the Si to the UI without paying a penny to anyone in royalties or signing any kind of licensing agreement. Something I can’t do with ARM, and especially not any of the other architectures like x86/x86_64, PowerPC, SPARC, MIPS, 68k, and other commercially-owned architectures.

Leave a Reply to ValCancel 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.