Trinity Core and Net

I have been thinking about the use of the comms system. At present we can send a large block of data and receive it in a memory.

However while this is useful for getting code and data around it still requires data to be read out and read in.

What if we directly wrote and read from internal CPU registers, a short message say of 16 bytes. We could do this in the normal method but this would be straight into the core.

Something to think about.

I've just completed the update to the system so that it has a Dual Port RAM that can be accessed by the Instruction and Data Busses for each node. I could have used a Single Port RAM but this has two draw backs.

1. I would have to put in an arbiter, and from previous experience of Harvard Machines you give the Data Bus priority.

2. It doesn't keep in the ethos of the system, why delay something when you can make it go faster.

It is also easier to just plug in a dual port memory block and go from there.

I need to test the set up which will happen at some point this week.

As an aside I have well an truly blown the 10,000 line limit for the Modelsim Altera Web Pack simulator. It's now amazingly slow, but I don't have the money to buy a full blown license so I just have to make do and get the 'job' done.
How typically British :).

I've now updated the top level so that there is a Master Node and a Slave Node. The Master Node Instruction memory will take an image of one instruction stream and the Slave Node take a different instruction stream. This allows me to create a kind of Job Dispatch algorithm.

While testing this I discovered a couple of issues with respect to the assembler which are now fixed.

The next thing is to update the array so that each node has a Von Neumann Memory. This will allow program code rather than just data to be distributed.

I decided rather than just sending a packet header through the network I thought I would write some assembly to create a full packet.

Lo and behold the core initially started behaving very oddly.

After looking into it I discovered an issue where there was a stall coming into the Prefetch at the same point that there was a starvation in the Prefetch horizontal FIFO.

I fixed this and then the program successfully ran, I still need to make the Prefetch significantly more efficient.

So with this in mind I examined the state of the interconnect. The interconnect is not complete with respect to the roting logic understanding that the matrix is circular in all directions so I expected the top plane packets to go 'down'.

It got as far as the next plane and then stopped.

Seemed odd as the other packets seemed to have got through.

Debugging found three sets of problems.

1. The old inversion of the direction tables (this should be in the common library !) so it wasn't going to go the right way once it got to the next level.

2. The Arbiter has three sets of arbitration, Priority Select, Round Robin above and below the last Selection. The Priority Select appeared fine, it selected the zero priority packet. However as the packet was a zero priority it is constructed to select other zero priority packets in a round robin sense. This ensures that things are fair.

So I spotted in the code that the trees to perform the latter selections were not set up correctly at the base, that one had had the 'x' 'y' swapped and that the inner loop started at 1 rather than zero (tree creation in VHDL is interesting).

Once this was done the packet flowed all the way through the matrix to it's bottom core.

I also observed that the 'send data' line was also still active after a packet had started to be sent. Not good as this would mean data loss !! This is now fixed.

So fixed a bug in the core, fixed a bug in the net ! Good work I feel !

I've now updated the Assembler Perl to allow conditional relative jumps. I can now have absolute Conditional Branches and Conditional Jumps. This is slow, but steady progress.

I have solved the issues that came to light over the last few days with respect to Trinity Net.
So I will go through them.

1. Incorrect reflection wiring within the array interconnect on two levels.

2. Node ID X and Z swapped.

3. Direction Selection encoding swapped the Z component so that it went in the opposite direction to that intended.

4. For simple header only messages there were multiple writes to memory.

The next stage stuff will look at the following.

1. Make the direction selection aware that the nodes are in a loop so it can use an optimal routing rather than the simplistic dumb routing it has now.

2. Write a kind of Monitor that each node can run up and accept some form of instruction code and run it.

3. To put in a method to allow the system discover it's own size. This might be a mixture of software and hardware.

4. Expand the Assembler so that it can accept more instructions and decide if a 'smaller' instruction can be used instead.

5. Implement the 8 bit instruction look up capability.

If I have learnt anything over the years it is that bugs are like onions, there are layers !
Each time you fix a problem and peel away a layer there is another bug that's been hidden waiting to cause more tears.

Trinity Net Nodes have an ID register, this has a format or rather had a format of Z,Y,X. The packet header used has X,Y,Z. The register has been updated and hey presto there are sensible transmissions.
Except that they are not. I seem to be getting stuff going in both directions. I think I know what it might be but I want to check.
As I say onions have layers.

Like all good Magicians Trinity Net has Misdirected some traffic in the matrix. I've solved one problem in that a 'reverse' connection was not correct. The next thing I suspect is that I need to recheck the adjacent node logic. Such things are sent to try us, but this is what writing a testbench is all about !

The simulation is showing an unexpected transmission from some adjacent cores and also some requested ones which don't exist. All very odd and so I need to debug !