Close
0%
0%

netpp node

Networked remote control on FPGA SoC

Public Chat
Similar projects worth following
The netpp node is a 'IoF' (Internet of FPGA) system on module, comprising a fully abstracted remote control system using netpp (network property protocol).
The clue of this hardware is, apart from the functional cores, that it is mostly defined in XML. For instance, a GPIO register bit can be exported as an abstract 'Property' to the network using a XML declaration node. This is then baked into C code (or even HDL) and downloaded onto the hardware over the network or USB.
Nodes typically run as UDP slaves in a sensor network. Node parameters are set in a very simple way, for example using Python:

> device = netpp.connect("UDP:192.168.0.20:2016")
> node20 = device.sync() # Synchronize property list
> node20.GPIO[8].Out.set(True)


The SoC is programmable using a standard Gnu Compiler (Opensource).

The build system 'MaSoCist' behind this setup has been released as an opensource variant that can be played with as a virtualized microprocessor system - under some restrictions.

Unfortunately, the copyright terms of FPGA vendors do not permit to publish all ip core and setup files, therefore all vendor specific files are omitted from this release.

See Docker notes how to reproduce a cycle accurate example of a interactive session with an opensource CPU, simulated by the opensource simulator GHDL:

https://section5.ch/index.php/2018/11/04/masocist-opensource-0-2-release/

The simulation can be run interactively, for example using a virtual UART, as shown in this screen capture:

CPU options

Since only logic resources and pin I/O are true restrictions on an FPGA (apart from maximum clock frequencies, of course), any CPU core that fits may be baked into this hardware. The MaSoCist supports the following CPUs:

  • OpenSource Zealot ZPU (small)
  • Proprietary pipelined ZPUng (fast and small)
  • neo430 msp430 architecture compatible (small, yet experimental support in MaSoCist)

The 'netpp operating system'

The default SoC for networking is the ZPUng 'dagobert' edition, supplying some extra hardware acceleration:

  • Autobuffer DMA for fast networking
  • 32 bit access SPI cache for program overlay to flash

The software, or say, the 'bare metal OS' makes usage of this hardware in a very lean and mean way, means that we managed to fit into 32kB of on-chip RAM:

  • UDP Stack
  • Ethernet drivers
  • Command shell
  • netpp (network property protocol) stack and simple task management

Exporting hardware entities to the network

The XML framework of netpp plays a core role in making hardware accessible from the network. This can be very application specific: on one hand, we might want a robust system that can not be messed with, on the other a very thin remote control layer with minimum overhead.

In any case, we have a XML hardware description that describes:

  • the SoC peripheral hardware registers (translates into C and HDL)
  • the export of hardware entities or functionality to the netpp layer

The lean and mean way of doing things (during prototype phase) is, to grant direct access to a register by a network property. This is displayed below for a GPIO array example. Two GPIO banks are implemented that way where as each bank is represented by 16 bit wide input, output and direction registers.

The more safe way is using function handlers, or in C++Speak: Getters and Setters. In the example below you see a regref node. This would be converted to a handler node, when using the getter/setter approach. This would then also allow to abstract a GPIO array differently, for example by representing each single pin configuration as an array element. You'd then have to code the getters/setters accordingly.

XML advantages

I get this question a lot: Why do you use %&;:!wrkfstf heavy weight XML and not JSON or something 'nice'?

First note: There is no XML passed around on the network. Nada. It's a compact binary block and 'zero copy' as far as possible. Means, we can pass buffer data (like audio or images) around without copying overhead. Would not be possible in JSON.

So the XML takes a purely descriptive role and is converted to bare metal HDL, C headers, and documentation elements (for the hardware reference).

Now, looking at the description layer, it could be argued that JSON could be used. However, there are various reasons that speak XML:

  • Provides a very robust framework for translation (XSLT)
  • Is considered 'type safe' and unambiguous
  • Provides sufficient schema rules (also...
Read more »

main-netpp-node.pdf

Netpp node 'data sheet'

application/pdf - 1.03 MB - 11/09/2018 at 14:54

Preview
Download

  • RISC-V (rv32i) on the netpp node

    Martin10/04/2019 at 07:37 0 comments

    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 byte 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):

    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.

    So, looks like a release can be rolled out in the next weeks - as a virtual chip.

  • Updates

    Martin06/25/2019 at 08:49 0 comments


    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.

View all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates