A 32 Bit Variable Length Instruction Set Core and Transputer Like Comms Network
I have decided to add two new peripherals to the Trinity Complexes.
The first is one that will drive a 2x16 LCD. It will do the initial set up of the display and then on a timer update the display continuously. This will be possible as the 'fabric' is designed to do this as a non block matrix. It will do the carriage return for the second line. I just need to work out how to manipulate the cursor on the display. This will take up 32 bytes of memory.
The second will read out memory and display on a 128x64 matrix LCD. This will mean that a 1kB memory will need to be used. Again this will be a timed update. I will be interesting to see how it goes.
In the meantime I shall continue to investigate the Uart and see if I can get it to work as expected.
I put some debug into the Interrupt Service Routine for the UART Tx to see it would work in the FPGA. While I shouldn't be surprised I still am and have a bit of a smile on my face.
While the Uart wasn't written by me (just made to work properly and debugged !), the rest of the chain was put together by me :).
Mr. Borodin was asked for just one ping. I asked for just one bit. As can be seen this bit is about 8.64 us which gives up approx 115.7 kHz which is roughly in the ball park for 115.2 kBaud. As can be seen we are swinging the full 12v which may be an issue these days as everyone expects to see 5V so I am going to have to work on that little problem before connecting to a laptop. If anyone has some suggestions than I am open to ideas, possible some Opto Isolation or the like.
Now I have cracked the LCD driving issue, one of the Data pins was assigned to the wrong pin in the FPGA by one character.
So I now have the ability to send text to the LCD under my control. I need to work on the organisation of the display but it's an important step since I got something VERY rudimentary a long time ago.
Now to get the Serial to work as expected !!
Well it looks like I didn't fix the interrupt handling as well as I thought I had. The test code worked fine when a simple count was short, unfortunately I when I extended this count I appear to have encountered an interrupt. This meant that everything went wild as wrong return vector was being used.
This, as far as I can tell, has now been corrected.
I will now respin the design and see if it will fit. Note that this is at 97% so it's going to be tight.
in other news my FPGA board that I bought several years ago has had some kind of failure. It no longer connects to the network and allows the ability to upload a new image.
Also the USB link has also gone down, whether there is a link to both of these symptoms I haven't been able to work out.
However I have been able to get a Bit blaster to connect and load up images. Not too sure how to get them into the flash but this is a start.
I've updated the Assembler, the Vectors can now take on labels. This then means that Exceptions and Interrupts be written as blocks as normal and the assembler can construct the vector table automatically.
I've now updated the Nested Interrupt Controller and ensured that the Processor Level is updated correctly.
The Processor Level now takes the Priority Level of the Interrupt plus 1. Also the Processor Level is now 5 bits rather than 4 bits so that the overflow stops any further Interrupts one a 0xF priority level interrupt has been hit.
Exceptions can still happen how but once the Processor Level hits 15 no more interrupts can be processed, the software has to deal with them to get the level down so it can accept more. The interrupts aren't lost just not acted upon.
Next to put the design back onto the server and see if it can be built again.
One thing I need to do is to update the Assembler so that the Vector table can take the labels as well. It will make things a lot easier.
The Uart I had found has now been tested in simulation to see if it can transmit at 115200 Baud. It looks like it can so the fixes I put in appear to have worked.
As the testbench connects the tx to the rx a loopback is formed.
On checking the data coming back it appears that the same value is received back.
It's looking like its the correct speed as well, a 4.67% error over the entire 10 bits. Also the count is reset again at the start of the transmission so it should be good.
This shows the result
Open Source is excellent stuff, I would highly recommend looking at the FOSSI organisation which is dedicated to Open Source Hardware.
Unfortunately some Open Source shall we say leaves something to be desired.
Like a standard reset scheme, synchronous or asynchronous. It's best NOT to mix the two schemes unless you REALLY HAVE TO.
I am in the middle of debugging the Uart I got hold of. So far I've seen a mix of resets and registers not reset.
I sincerely hope that there are no latches in there !!
It's been a while but I thought I would add a log.
I decided to write a generic routine to allow text to be sent to the LCD screen on the dev board I have. I wrote a specific one a long time ago that sent 'Hello World' out to the display.
Now with the Dual and Single complexs I thought lets start to put bits of code together so that they can be used.
Using the techniques used in getting unformatted text out on the 'console' in the simulator time to use that and add in the LCD option.
Extracted the specific routine and then started to write the more generic routine.
Ran it up and hit a problems. This can be quite disheartening in a project that has been running this long. When you you hit problems you start to think
'Is it all worth while ?'
An interregnum ensues where Phased Array audio is investigated and using HP Calculators.
But laptop is with me on holiday and I start to skin the onion, all bugs have layers and each layer brings tears to the eye.
Crack the first RTL bug, sometime skip the stack pointer update ! Move onto the Assembler, fix a bug there, hit a new RTL bug (where have the instructions gone ?), fix that. Finally fix a typo in the Assembler (this was part of the old code but not up to date with present instruction name.
Now I have the PIO block sending out the control signalling for the LCD. Next step to get it all synthed again and to plug into the dev board.
Next thing after this will be to add in a proper comms link, still not got a RS232 block in there which hopefully should not be too hard to get in there !