Designer of the Neo here, and owner of the California "VLIW" license plate. As you can guess, I am a die hard VLIW advocate, and a strong believer that the original promises of VLIW (Drastically simpler decode logic, implicit instruction level parallelism, virtually no control/data hazards on chip).

VLIW has gotten an extremely bad rap outside of the embedded space due to Itanium, which I strongly contend was not a VLIW in spirit (which you cans see me talk in more depth on here: https://youtu.be/ki6jVXZM2XU?t=441). Itanium introduced a ton of indeterminism by having static scheduling unfriendly things like branch prediction, variable latency caches, and still trying to have some level of support for x86. The core problem for Itanium is that it was impossible for the compiler to make good decisions in the vast majority of applications since the compiler could not know exactly where and when things in memory would be. I believe the underlying failure point has been computer architects for failed VLIW architectures not realizing that fancy bells and whistles and "cleverly complex" hardware designs is the exact opposite of what you want when the compiler needs to be able to do purely static allocation. Adding fancy dynamic pieces in hardware to account from this (seen in a lot of places with Itanium) just makes the problem worse.

The main improvement we have made with the Neo architecture is we have hard (exact cycle count) guarantees on all memory movements on and off the chip, which actually gives the compiler the information it needs to make good decisions and very condensed code. I think the jury is out on the applicability for "general purpose" code on VLIWs... it is not something we at REX really care about at the moment, and I think RISC-V is a great solution with improvements over x86 and ARM.

> The main improvement we have made with the Neo architecture is we have hard (exact cycle count) guarantees on all memory movements on and off the chip ...

This is a fascinating idea, but I have a question.

What happens when the next process generation lets you improve cache timings? What about newer, faster DRAM (or whatever) timings?

Do I have to recompile the world in that case, to see any improvement in performance?

The assumption by us is that you would be recompiling from at least the LLVM IR level for each different version of the chip. This isn't a real problem for the markets we care about, as they have the source code for all of their applications. In the case of not wanting to distribute your source code, I am interested in being able to distribute emcrypted LLVM IR as a pseudo-binary, similar to how silicon IP companies deliver encrypted verilog and vhdl for integration into other chips.

Interesting. The traditional problem in this space is that the source code is lost or otherwise not available. It is not clear that some encrypted source analog to encrypted verilog would be more available.

Not a fan of RISC-V although Chisel is pretty cool. Still I was forced to admit that its free as in beer licensing has won some nontrivial design wins (NVidia). I think however that that was more Arm shooting itself in the foot.

Just a question, why are you against RISC-V?

I quite like RISC-V and think it's elegant and simple, but maybe I'm wrong :)

My biggest complaint about RISC-V is its lack of condition codes. This is just too puritanical. I think ARMv8 strikes a nice balance here. Leaving something out that both ARM and Intel provide seems pointlessly austere.

As was pointed out in the A History of Modern 64-bit Computing cite, both RISC and Itanium show an academic bias. Yes, RISC-V is elegant and simple and that helps in a one semester upper div architecture class. But that doesn't help you much outside of a one semester upper div architecture class.

So what do you tangibly get with that elegance and simplicity? You aren't going to write RISC-V assembly; compilers are better especially for such a regular and spare ISA. This is 2017 and LLVM has been a thing for quite some time. Compilers are not a big deal.

Lower power? Chip area? How much lower power and chip area are we talking about?

I'm not too sure about the "academic bias" point, since modern "CISC" CPUs are essentially "CISC on RISC" and essentially RISC already.

That being said, greater efficiency is the main point, it's not too difficult to get a RISC-V core that beats (albeit marginally) an equivalent ARM core.

Optimizing compilers can often be difficult though, especially if you want to use novel modifications to the backend to make things more efficient.

No, Skylake is not a RISC internally. Find something from the Intel Optimization Manual or their patents saying that. I been over this already. μops are hundreds of bits wide. Ain't nothing reduced about that.

Read up on horizontal microprogramming. A RISC ISA is an encoding with an opcode. A μop is really just a long set of fields with some bits clocking some FUs on and others off. There is no decoding; there is no opcode.

I'm aware of horizontal microprogramming,and I checked again but I still don't see your point. Maybe link a reference?

Smotherman.

A complete macroinstruction is executed by generating an appropriately timed sequence of groups of control signals (micro-operations).

http://www.frsn.utn.edu.ar/tecnicas3/manuales/Microprogrammi...

Originally, RISC cpus were hardwired but they are general purpose ISAs. RISC-V is fixed 32b ISA but has multiple formats controlled by an opcode.

https://image.slidesharecdn.com/20160130deckyfosdemportinghe...

Original microprogrammed CPUs had a writeable control store (WCS). Modern processors translate CISC instructions into μops and cache this translation. The difference is the μop cache (μstore) vs WCS. FWIW, Skylake also has a WCS for obscure instructions.

Microinstructions, μops, do not have an opcode. They are not decoded. Bits in a horizontal μop gate logic on/off directly.

The RISC-V people do say RISC-like.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-...

And even that's wrong. But then they never even define what a RISC is. So RISC-like could be anything.

How far away are you from getting to the point where you can accelerate workloads such as blender? Also I see that your backend isn't in the trunk -- is there plan to push to upstream and share the details? I'd love to learn about your isa.

It isn't something we have been looking at, as our current customers and target applications would have our chip as a standalone embedded processor. We are working on a prototype PCIe card with an FPGA to be able to convert our SerDes to something a PC can talk to, but it isn't really a priority unless we have someone come to us directly asking for it.

As for upstreaming, it is something that we want to do, but are not sure if it will be accepted as our chip is not generally available at the moment. It would probably be done around the same time as our next tape out (which would be in larger quantity than our first one) when we would have generally available development kits this coming winter.

I have been working on public documentation in my spare time... originally supposed to go out in March but we have had other priorities. If you watch my Stanford talk I show the basic ISA overview as well as the WIP documentation made using doxygen. I'm hoping to get stuff out on our website before our next media push in ~June.

What are some examples of VLIW succeeding? (I haven't watched your video yet)

The two best application cases of instruction level parallelism that we have at the moment are our FFT and DGEMM, where our 64 bit instruction word contains the operations for doing a double precision fused multiply add, two 128 bit load/stores, and an ALU op for address calculation. The inner loops of these programs are able to get up to 4 instructions per cycle (5 if you count the FMA as 2 ops, which is what everyone else does but I think is cheating), and compared to a superscalar architecture, uses very little space in local memory (fitting 4 operations in only 64 bits is awesome!). Compared to the latest 14/16nm offerings from Intel and NVIDIA, we have a 25x energy efficiency advantage for our FFT while our test chip is still on 28nm.

These are the same reasons why DSPs have been VLIW since the 90s, and our initial applications overlap a lot. It has been sad to see the trend of TI and other DSP makers going down the path of adding hardware caching (that reduces determinism and energy efficiency) to try to "make it easier for programmers" when they already have a decent enough architecture, but a lack of good compiler tools to take advantage of it.