Trinity Core and Net

There have been a few developments.

The Perl Assembler has been updated in the following ways.

1. The introduction of the 'vector' key word to place vector information at the start of the data memory. This provides the Exception Vector Table.

2. The introduction of the 'text' key word which provides the ability to create text and put it into the Data memory, the text can be defined as having a carriage return or just a continuation.

3. Enabling Call Imm instruction and enabling the use of labels.

The following software routines have been written.

1. Creating a 'Putchar' routine.

2. Creating a routine that will take selected text and then send it character by character to the Putchar routine.

3. The creation of a hex to ascii routine to all the display of hex values.

On the hardware side

1. Re-enabling Pushf and Popf, initially mothballed for speed examination.

2. Discovery of a bug in the Prefetch that cause the incorrect creation of a PC and a rogue instruction. Now fixed.

3. The Branch Prediction seems to be working well.

Plans for the future.

1. Creating a Nested Interrupt Block.

2. A Non Blocking Memory Infrastructure to allow multiple masters.

3. A DMA Block which should make each node more efficient.

4. Code to run on a Master to dispatch Program code.

5. Code to run on a Slave to accept and run it (note a bit more than the ad hoc code to prove the concept).

So it's not over yet by a long chalk.

I have now added a simple Teletype function to the system so that when the code writes to a specifc address a character is added to a line variable.

If the character is a Carriage Return then it prints the line on the screen.

By this method I can start to see what the core is doing.

I had the pleasure of attending ORCONF 2016 in Bologne Italy.

There were some good presentations but two stood out. The Many Core projet Piton from Princeton and the Pipeline Messenging System from the University of Augsburg.

Both had elements that appear in Trinity which id very very encouraging.

I have now created or rather put together the first cut of a Branch prediction block.

It uses a simple method that I found in a book some time ago.

You don't decode the instruction, you just have to remember the PC and where it went. You have a small cache to store the PC and where it's off to.

Now to see if it compiles and then test it!

I have just had a look at the regular bulletin emails from the GHDL mail group.

There is a guy who is looking into creating a selected signal list that can be fed into GHDL !

This is fantastic news, I've emailed and advised that I have a large design that may be suitable to use as a test subject. Whether anything comes of the suggestion it doesn't matter. Someone is looking into the problem AND getting some success apparently !

By the way here is an image from the small testbench that looks just at the Trinity Net Rx in Gtkwave as a run on the Macbook.

I now have the GHDL simulation system up and running on my Trinity Server 2.

This has about 16 GB of memory and it also slow.

The main reason for this is that every signal in the entire design is recorded. If there was a method to just record a subset then it would I feel be a lot faster.

I could go for the VCD approach but seeing as the design is written with different types there is no point in what can be seen.

My Mac has been running a simulation for approx 10 hours and it has only run 664 us.

Whatever method I use to run the sim it's going to be slow.

Note also, both the Mac and Trinity Server 2 are running off SSD's.

I ran up the multi ore testbench after getting all the libraries including the Memories compiled up.

Unfortunately the resulting wave file is of the order of 330MB after 10 us of run.

The problem is that ALL signals are included in the waves and as far as I am aware there is no way to select a sub group.

When GTKWave attempts to open such a file a segmentation fault eventually happens.

The next step is to transfer the compilation scripts and put them on the Linux box to se if that version will fare better.

I have now got GHDL up and running on my MacBookPro. Getting the Gtkwave tool was at first entertaining.

Now I have been able 'compile' code and in one case run a testbench which looks all ok.

So I am now slowly going through the system and rebuilding the core in GHDL land. Got to stage 5 the execution bit so far.

I had to work out the method of libraries but I've think I've got there now. Having two or more may be interesting.

Once I've got the RTL sorted I need to create the original memories from the Altera memory models. Hopefully this wil be a simple compile but I fear this won't be the case.

I am exploring the alternative option of using the GHDL simulator.

I looked at this briefly at the start of the project. However I was familiar with the Modelsim product so went for the simple option.

However this was just with the Core being simulated. Now that I have an array I am starting to feel the limitations as mentioned before. I theory GHDL should not have this limitations and so it might run faster !

The other thing is that I can run it on my Mac which means I won't have to log into my machine. However apparently the Linux version has some form of PLI so things may still be better done there.

My core crashed, big time ! And this is FANTASTIC NEWS !

The reason why it's a good result is that it means the first time the Master Core has sent a Slave Core some data which it then tried to run. The fact that it was in fact garbage is of no matter, that will be changed to be real code soon.

The proof of concept has been achieved, this means that I can not only send data but I can send Instruction streams to any core that I want to.