Last visit was: Thu Oct 22, 2020 9:32 am
It is currently Thu Oct 22, 2020 9:32 am



 [ 22 posts ]  Go to page Previous  1, 2
 Noc - Network on chip 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1197
Location: Canada
Finally ! The simulation problem has been circumvented. It doesn't work in simulation yet, but at least it's possible to simulate.

_________________
Robert Finch http://www.finitron.ca


Fri Dec 23, 2016 8:16 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1197
Location: Canada
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.
Attachment:
RandChars.png


You do not have the required permissions to view the files attached to this post.

_________________
Robert Finch http://www.finitron.ca


Fri Dec 23, 2016 7:56 pm WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1463
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."


Sun Jun 10, 2018 8:50 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1197
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Mon Jul 27, 2020 3:20 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1197
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Thu Jul 30, 2020 2:23 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1463
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.


Thu Jul 30, 2020 7:18 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1197
Location: Canada
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.
Code:
RecvLoop:
noMsg1:
      lb      r1,ROUTER+RTR_RXSTAT
      beq      noMsg1
      call   Recv
      call   RecvDispatch
      bra      RecvLoop


Operation of most normal nodes is as follows:
Code:
 ; Operation of an ordinary (worker) node is pretty simple. It just waits in
; loop polling for recieved messages which are then dispatched.

      .code
start:
      lw      sp,#$1FFE            ; set stack pointer
      call   ResetNode
start2:
      lw      sp,#$1FFE            ; set stack pointer
noMsg1:
      lb      r1,ROUTER+RTR_RXSTAT   ; get the receive status
      beq      noMsg1               ; is there a message ?
      call   Recv               ; copy the receive message to local buf
      call   RecvDispatch         ; dispatch to a handler based on type
      br      start2               ; go back and repeat the process

_________________
Robert Finch http://www.finitron.ca


Fri Jul 31, 2020 3:37 am WWW
 [ 22 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software