Hi Everyone,

For those of you who have not been to my transputer emulator website recently, I've an on-going project to access the uCode stored in the internal ROM inside the Inmos T414B Transputer device, with the goal being to provide a better understanding and
emulation of the T414 instructions.

A few months ago I was given a copy of the Inmos T414B Specification version 18 written by Roger Shepherd dated November 22,1985. Most of the document was very familiar however in section 4.1 - Function of pads, the content indicated that there was a
test mode to access the ucode ROM inside the T414B device by means of some test pins. An extract from the document is available at my website. See link below.

According to the Inmos T414 datasheet these test pads are defined as Hold To GND during normal use.

According to Guy Harriman and Rob Wadsworth this feature was used in Inmos Production die Tester to verify the uCode ROM contents. Apparently it was a 68000 based ATE but this is not confirmed.

Check out my webpage here: https://sites.google.com/site/transputeremulator/Home/inmos-t414b-ucode-rom

I've spent a lot of hours and time trying to get data out of the few samples I have with little success. Hence this blog to make the info available to the transputer group. Does anyone have any knowledge or thoughts where I might be going wrong?

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Gavin Crate <gavincrate42@yahoo.co.uk> wrote:

Check out my webpage here: https://sites.google.com/site/transputeremulator/Home/inmos-t414b-ucode-rom

I've spent a lot of hours and time trying to get data out of the few
samples I have with little success. Hence this blog to make the info available to the transputer group. Does anyone have any knowledge or thoughts where I might be going wrong?

What did you do? What happens?

I've never actually seen a transputer, but I've designed these kind of
silicon test interfaces before.

Things I would try:

Take ChangePadsForTestPad high
Put a binary count (or some other sequence) on LinkInput[3:0]
Check that you get the inverted count on LinkOutput[3:0]
- that'll confirm the test mode works

From my reading of the spec, to read the ROM you:

ChangePadsForTestPad:=1
EnableuRomTest:=1
noDoDPDriversfromROM:=1
TestShClk:=0

For n=0 to addresslength bits: (do you know the word and address lengths?)
TestShiftIn:=address[n] (do you know address endianness?)
pause some time
TestShClk:=1
pause
TestShClk:=0

notDoDPDriversfromROM:=0
pause
notDoDPDriversfromROM:=1
pause

for n=0 to datalength bits:
data[n]:=TestShiftOut
TestShClk:=1
pause
TestShClk:=0
pause


In the most basic sense, pulse TestShClk and see if you get any logic state changes on TestShiftOut after transitioning noDoDPDriversfromROM.
It's unlikely the ROM is full of zeroes, so any address should give you some output (though there's a risk address 0 does contain zeroes).

You would be wise to experiment with the global reset both asserted and deasserted (maybe in needs to be held in reset to prevent conflicts, or
maybe reset stops the shift register working).

The other question is whether you need the main clock(s) running to access
the ROM. When doing chip debug you'd rather not and design it that way (the fewer requirements on things you can't see the better), but if this is production test then if you can't start the PLL you junk the chip anyway so there's not much loss. Given that the ROM is probably used rather a lot by
the logic in the core clock domain, it wouldn't surprise me if that clock
needs to be running. I don't know how many clock domains the transputer
chip might have, but possibly more than one. I would hope the PLL is
something you can control from outside (rather than a modern chip where it's buried deep inside and only accessible from software).

Additionally, if this uses dynamic logic there may be minimum clock rates:
you may have to drive it approaching native speed - possibly bitbanging in software won't do.

Generally silicon debug is intended to be simple and bombproof - but it may just be you don't have the initial conditions right.

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Theo,

Thank you for taking the time in responding to my comp.sys.transputer forum bulletin. I've added some more details on my website to help describe my ucode ROM test setup: a). a schematic of the ucode ROM tester; and b). a block diagram of the FPGA tester
(one of the many versions).

Basically your thoughts about the operation of the test mode are in-line with my thoughts on how it might works. I will try all your suggestions and let you know what I find.


Regards

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Gavin!

This is an awesome approach to readout the microcode. Do you suspect any timing related issues? I act on the assumption that the test interface is pure static.

Anyway - my tiny approach to read out the microcode is also unsuccessful. I'm using a simple C011 for digital IO and a link adapter to set/readback the LinkIn/Out values.

After your post, I've double checked the setup and retried many signal sequences again, but the Error pin (e.g. StatusErrorOutPad/TestShiftOut with ChangePadsForTestPad aktive) stays at '1' - stubborn like a mule. Even the Reset pin has no effect.

I've tried it with two different transputer:
IMST414B-G15S 8708
IMST414B-G20S 8838

But the LinkOutput is the inverse of the Input value. So it looks, that the functionality (maybe not all) is available - but for only 4 inverters the effort is really too high :-)

Regards
Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mike!

Thanks for the feedback. The FPGA ucode Tester its fully synchronous (to the 50MHz clock) so there are no real timing issues to worry about. The only consideration is between the FPGA and the Transputer device when the test mode is run to do with data
set-up and hold. Again this should be sorted as the design is synchronous to ClockIn.

I too have also verified by tests that the Test mode (as documented in the Inmos T414B specification) does appear to be implemented in the silicon. My findings also show that the Link Outputs are the inverted Link inputs. This is encouraging and
indicates we may eventually gain access to the ucode ROM.

Since talking to Guy Harriman and Rob Wadsworth I have since contacted Jon Beecroft (who designed the cpu datapath and the EMI as well as other things) and he has given a few possible ideas and suggestions to try. Based on his feedback (which was very
helpful) I am currently revising the FPGA ucode Tester (versions Mk60) / (versions MK61) to investigate these new lines of avenue.

The good news is that discussions with Jon indicate that my original thoughts (which have led to Mk36 on my website) can be simplified and result in a much simpler design.

When I get the test results from the hardware I'll update my website with details.

My tests are being done using two working transputers:
IMST414B-G20S 8747
IMST414B-G20S ???? (not available at time of writing this blog)

I agree that it seems a lot of effort to make the Transputer invert four inputs, but joking aside if I can get ucode data out of the T414B device it would be a real coup (achievement). Then the fun and games will really start with the decoding... ;-)

Regards

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello all,

I though that I should drop a quick update with the status and some finding of my investigation to extract the ucode from the ROM in the Inmos T414B device.

Based on discussions with Jon Beecroft (who designed the cpu datapath and the EMI as well as other things) I went away and redesigned the timing sequence in the FPGA. In addition, I updated the hardware platform to provide a better 3.3V to 5V (and visa-
versa) level shifting interface between the FPGA and the T414B device.

The combined results are now showing success and I have successfully shifted data (fixed patterns) in and out of the Inmos T414B device using the Test shift registers. YES… data is finally coming out of the test shift Out / Error pin.

What I do know:

1. The internal test shift register is 69 bits in length (this is likely the microinstruction ROM word size);
2. The T414B clocks data out of Test Shift Out on the rising edge of the Test Shift Clock;
3. The test shift In data must be set-up on/after the falling edge of the Test Shift Clock and be stable during the rising edge of the Test Shift Clock;

The above is based on tests (and scope measurements) with the T414B being clocked (ClockIn) at 1MHz and the Test Shift Clock at 2KHz. I will try the T414B being clocked at 5MHz and 20MHz (i.e. latter with PLL enabled) in due course. The Reset pin MUST be
asserted (i.e. set to VCC/5V) to enable the test mode, which is not defined in the T414B Specification November 22, 1985 (Version 18) page 86 (see extract on my website link below).

What is interesting is the microinstruction ROM word size in the Simple 42 design (see the link to David Mays S42 documentation accessed from my website below) is 68 bits. I was quite surprised by the above finding for the T414B microinstruction ROM word
size of 69 bits as I have emails from Guy Harriman which discuss sizes of 100+bits.

However, having thought about my findings the 69 bit length could stack up. In the S42, dedicated field bits are used for the X bus, Y bus source and Z bus destination and these could have been replaced in the T414B design with decoded fields (such that
3bits could define 7 register locations) to minimise the size of the field bits and overall microinstruction ROM size. The S42 documentation does mention that some decoded fields are used and it could have been done in the T414 design. Also it makes
sense based on the introduction date of the T414A (circa 1983) within 1 year of the S42 design (circa 1982) that the T414 was highly based on the S42 design. Obviously the T414 design had additional registers in its architecture (i.e. Dreg, Ereg to name
a few).

https://sites.google.com/site/transputeremulator/Home/inmos-s42

I will start further investigations shortly to try and get data out of the ROM. This will be my next focus.

https://sites.google.com/site/transputeremulator/Home/inmos-t414b-ucode-rom


I'll keep you all posted on my progress.

Regards

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Everyone,

After 1 year and 5 months of head scratching, dead ends and lots of effort I have finally successfully extracted all the ROM contents from the INMOS T414B device.

I’ve not done any detailed analysis yet but the data initially looks complete and what I was expecting. At least the first ucode at ROM location 0 looks like REV instruction, which is what I was expecting to see.

The following is some basic facts I have determined whilst extracting the ROM contents.

The test shift register size is 69 bits.

The Input Address is 10 bits. The MSB of the Address is shifted in first into the TestShiftIn pin.

The ROM size is 59 bits wide. (i.e. the microinstruction ROM word size)

The 10 bit Input Address register is connected to the microinstruction ROM word output register. This scan path is connected to the TestShiftIn pin and the TestShiftOut pin (i.e. Error)

The ROM contains 647 ucode words. This was a surprise as rumours from various sources had the size to be expected at 512 (i.e. 1FF).

The data was captured using my romspy software tool, which talks to the target board (containing a FPGA and the INMOS T414B device).

Bit 0 is first out of ROM data. The last bit out is bit 68. The last ten bits out are the 10 bit address. With the LSB of the Address out last.

ROM location (n=0) looks like ucode (or VBC) for the REV instruction, with two bits set.

Based on the Simple 42 REV instruction ucode being: BfromA AfromB Next


For more information regarding the method to extract the ROM data and a copy of the Inmos T414B ROM data, please refer to my website:

https://sites.google.com/site/transputeremulator/Home/inmos-t414b-ucode-rom

The next task is the decoding phase. This could take quite some time…

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

Just a quick update on my on-going Inmos T414B ucode ROM investigation. I have now successfully managed to identify 89 of the 118 ucode ROM column output signals within the INMOS T414B device. This equates to 75%.

Check out my webpage here: https://sites.google.com/site/transputeremulator/Home/inmos-t414b-ucode-rom


Regards

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone!

July 2017 – I thought it was time for a progress update. I’ve spent the last few months continuing to decoding the ucode ROM bits in the Inmos T414B device (see Inmos T414B uCode ROM tab). I’ve now successfully decoded 111 of the 118 columns in the
T414B uCode ROM (or vbc). That 94% complete or in other words just 7 to determine function!

The task has got much slower and more complicated recently due to a number of reasons. Firstly the simple instructions are not helping to uncover any further little gems; and secondly the checkout test software which helped give clues to ucode columns
has now relinquished all its helpful gems too.

The most recent effort has focused on the decoding of the enbc, disc and start (1FF) instructions. For information the start consists of 35 ucode instructions. After lots of head scratching I’ve uncovered the further column bits used for link engine
control and other subtle logic control, including a column identified and suitably called “DataMAddrfromPreviousReadreg” which loads the DataMemoryAddress register with the previous memory read access address. I have to take my hat off in
appreciation of the Inmos engineers involved in the T414B design. Cool design.

I now have a complete understanding of all the ALU op-codes used by the ucode, all the conditional logic bits and feedback address logic. Plus most of the Xbus and Y bus selection and Z bus destination control bits.

The byte move logic is still a mystery and as such 3 ucode column bits are stopping a full decode of lb and sb instructions and understanding. Guy Harriman and Jon Beecroft have provides some helpful 30 year old memories and in time I might work it out.

I’m almost at a stage where I could now start writing a real T414B emulator using the extracted ucode and writing C code to emulate the hardware, in a similar way as done with the Inmos Simple 42 emulator I wrote a few years ago.

Regards

Gavin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)