netpp node

With increasing complexities and more FPGA architectures and platforms coming into play, the underlying original MaSoCist setup has somewhat become complex in testing against various synthesis and simulation tools. Plus, it's still VHDL only for simulation, which is sometimes limiting.

And, it's bloody patchwork:

• XML for SoC descriptions translated to HDL config files
• Make-Rules depending on platform
• Ugly CPP (C preprocessor) hacks
• Impossible to document inline and cross-test documentation against functionality

The latest drug developed from Google developers turned out to be the mybinder.org service that runs Jupyter Notebooks. During the Covid19 lockdown, this enabled me to prepare step-by-step instructions on how to have design processes reproduced without having to install exactly the same OS setup and libraries.

Then on the other hand, active development on the yosys side has progressed so far that a fully python featured build and synthesis process gave full browser based synthesis for some architectures a boost.

Bottomline: The future MaSoCist development will fully focus on a Python based processing, being more transparent in what is exactly happening. The expected paradigm shift, outlined:

• CPP hacks gone
• kconfig translation hacks gone
• Inline documentation per Notebook
• Auto-tests and regress tests done from inside the Notebook
• Most VHDL modules and SoC generation ported to MyHDL
• More Co-Simulation functionality with Verilog designs

The MyHDL featured basic environment for synthesis out of the browser (for ECP5 platforms) is found via the sister project https://hackaday.io/project/171216-jupyosys.

Now, here comes the catch: Spartan6 is somewhat aged and efforts in reverse engineering the architecture for yosys support has been considered questionnable. So Place&Route will still be based on the ISE 14.7 toolchain. Means, a legacy MaSoCist for netpp node will remain.

If it comes to a next generation, the netpp node v2 will base on a more 'open' FPGA architecture that supports a robust multi-boot scheme like the Spartan6.

Slowly getting there: the yosys OpenSource toolchain has proven stable for the Verilog world, now an early development release of MaSoCist CPU builds for VHDL output is spinning on two Lattice ECP5 development kits:

• Versa ECP5G board
• EVDK video processing board stack

There are two CPU architecture configurations possible:

• ZPUng v1.1 (tested ok)
• RISC-V pyrv32 (not 100% functional, due to true dual port RAM issues)

Find the quick start instructions (Docker based) here.

Don't get too hyped on the RISC-V yet: Due to a lazy workaround implementation of the dual port RAM, the compiler may spit out code that is not correctly working due to a missing read-during-write scenario. A workaround could be to cover for this 'hazard' in the pyrv32 core.

Next step is to look at the rather crucial TDP (true dual port) RAM inference. Once this is working, I'm confident that all regression tests will pass.

A very pleasant little detail: JTAG access is working correctly and stable, so that we can debug the hardware in detail and do the same regression tests as done in the simulation.

Time for a change: The Berkeley RISC-V architecture has gone from a hype to a pretty mature architecture which performs very well on an FPGA as well as on hard silicon, as SiFive and others have demonstrated.

So, what's the reason to try anything else besides the running system? The ZPUng has been extensively verified for stability, but being a stack machine, its GCC port was never fully optimized for it, and actually, it's hard to. So, it would have been time to actually tackle a compiler update. Not much is being done on that front, and after all it turns out: Code density from RISC-V (compressed) gets very close to the compact ZPU instruction set, in some cases it performs even better.

So I've tried a few open RISC-V designs, but run into quirks:

• Incomplete Interrupt/exception implementations, incompatible implementations (f32c...)
• Just silly bugs
• Missing In circuit emulation features

As I've had an optimized RISC design (called PyPS, as written in Python) in the drawer, but not explored any further due to lacking compiler optimization, I gave it a go to make it RISC-V compatible. Naive thinking: Just swap out the decoder module. Ok, it got pretty close, but after all, I went for a complete rewrite anyhow. It's kinda sad, but with a well implemented compiler as working reference, it's easier to bash out a new hardware design than adapting the GCC RTL.

So after all it turns out: This design, including all netpp server code, actually fits on the netpp node (without requiring the SPI overlay program ROM cache). With some memory reorganisation there's just that small gain of free block RAM sufficient to free more space for a program so that the current architecture can be maintained.

Now the hard part comes in:  the full verification scenario has not been tackled yet. On the ZPUng with its eight bit opcodes and therefore limited combination scenarios, verification can be done in a few hours on a standard PC. The full dance for the 'pyrv32' is way more complex and it's likely that some scenario might slip.

The tests passed so far (Update):

• In-house emulation regression test
• I/O and event regression test
• Assumed official reference for RISC-V ISA compliance:
  https://github.com/riscv/riscv-tests

The full coverage dance is likely a number to big for me to tackle, it will be left at "works for me" for now.

There are some alternative regress tests still to be looked at, I'm gladly accepting hints.

Find quick start instructions here.

v0.4 bootloader / BIST firmware release

This release adds a few fixes and improvements:

• Compacted networking code
• Slight speed improvement of UDP packet bursts
• Enabled network discovery: running 'netpp' shows all listening netpp nodes attached to the LAN.
• Boot mode, firmware upgrade and defaults reset option (SW2) improved.

Property Changes:

• SysCtrl.Reboot no longer evaluates argument. You must now set SysCtrl.BootMode prior to issuing Reboot.