Finally ! The simulation problem has been circumvented. It doesn't work in simulation yet, but at least it's possible to simulate.

Got a small program to display random characters on the screen running. With three cpu's running the display is updated three times as often as a single cpu could do. (The system has six cpu's) but only three are being used for the display. It doesn't work perfectly yet, a couple of chars on the screen are "stuck" at fixed values. Probably a random number generator problem.

We mentioned ZMOB earlier, a scalable highly parallel Z80 based architecture. It turns out it was also built - maybe in 1988 - with 68k CPUs, dubbed McMOB:
http://www.dtic.mil/docs/citations/ADA196942
"... a parallel problem solving system, PRISM (Parallel Inference System), that was implemented on the VAX/11-780, the PYRAMID and SUN machines, was ported successfully to McMOB and then to the BBN Butterfly parallel architecture. The McMOB architecture is essentially the ZMOB architecture with 16 Motorola 68000 processors, upgrading the Z80A microprocessors, interconnected in a ring structure. Experimental testing of PRISM on McMOB was undertaken in the current year."

Started working again on this project from three years ago. I have several network on chip projects shelved atm. Mainly varying in processor chosen and consequently number of nodes supported. The one I’ve picked up is ButterflyNoC – Butterfly processing core network on chip. Not sure I described it before. 56 nodes in an 8x7 grid connected in a toridal fashion. In theory multiple grids may be connected. Routers for each node support up to three directions, x,y, and z. Network data transmission is in the form of 128-bit packets, transmitted asynchronously 4-bits wide. Roughly, the packets are a reduced format (RTCP) similar to TCP/IP with 12-bit source, dest id’s an aging field and about 80 bits of payload data. I wanted to be able to write a 32-bit system data and address using just a single packet. The aging field is important in preventing packets from circulating forever if a node becomes unavailable.
A lot has changed in three years. I’ve picked up a slightly different coding style, using two spaces to indent instead of four. DDR memory access is handled completely differently. The Mig module is accessed outside of the controller core rather than being embedded within it. A different toolset (version 19.02) is being used now to build the core.

Note: I called the processor core 'Butterfly' which is just a coincidence to the name "BBN Butterfly parallel architecture" they are not the same thing.

Since it’s been a while since this project was worked on, the state it was left in is uncertain.
Rebuilt the Noc without changing anything and powered it up. Display is blank. The first issue found was the program code for the Noc was being accessed from a directory on C:, that code was moved to D:, so the drive designator needed to be updated. With an updated address of the noc code, a rebuild of the system reveals the same result: display is blank.
The next issue was that a clock signal “clk40” used to drive much of the noc was not actually being driven by anything. I must have renamed it from the system clock when I was last working on it. The clkgen component was replaced with a component generated by the IP core clock wizard, and the clk40 signal wired up. On loading the system into the FPGA: screen is still blank.
Time to build in a logic analyzer to see just what’s going on.

Giving some thought as to an application – Some of the simpler original arcade games come to mind. A pacman like game where each ghost is controlled by its own processing node. Or space invaders with each invader controlled by a node.

It's a very good question: how to motivate and showcase a parallel machine. I quite like the idea of a distributed object simulator, in the form of a video game kind of world.

A game something like Age of Empires has lots of potentially parallel operations.

There were issues with files imported into the project and the versions actually desired. The correct versions of files needed to be moved to the correct folders to get a good system build. Everything still isn’t completely sorted out.
The device enumeration list for the master node x111 now displays in a scrambled fashion on-screen. So, something is working. Master node x111 has a direct connection to the text output display. ROM for that node can write directly to the screen. Other nodes must request output by sending messages to node x111. Since all the nodes are wired almost identically by the node component, it’s likely they are working, just unable to display output yet. The most likely area needing improvement is the software in node x111.
The program for node x111 does a reset operation then enters a receive message and dispatch loop.


Operation of most normal nodes is as follows:

(Over in the world of Z80, Chris Fenton has recently built ZedRipper, a 16-processor setup using a kind of token ring. See here and here.)

That is a very cool project. Smartly done, making use of existing software. The 16 z80’s only use up about 10% of the LUTs, leaving lots of room for expansion.

Got back to working on a new NoC now. Using a different processing core now – a 12-bit version of the 6809. I like the 6809 but wanted something that could access a few MB of memory. I am also after a core that can run existing software. I should be able to recompile source with minimal modifications for 12-bits. I took the 6809 core I had already written an extended it from eight-bit bytes to twelve-bit bytes. The core is small enough that it should be possible to fit 16-cores in the FPGA board. Cores will be paired sharing 64kB RAM+16kB ROM directly. RAM will be accessible to other paired cores via the network.