Embedded Files
May 2015 - I started working on a 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.
Back in November 2014, 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. Below is an extract from the document.
In the Inmos T414 datasheet these test pads are defined as Hold To GND.
According to Guy Harriman and Rob Wadsworth this feature was used in Production Test to verify the uCode ROM contents. Apparently it was a 68000 based ATE but this is not confirmed.
The following shows the schematic of the test board being used to reclaim the ucode ROM from the Inmos T414B device.
The following photograph shows the assembled board.
The above test board uses the Micro-Nova Mercury FPGA module (see www.micro-nova.com) which contains a Xilinx Spartan-3A FPGA (XC3S200A). Access to the laptop computer (used to pass data in and out of the shift registers) is done using a USB to Parallel I/O cable made by BMCM (see usb-pio).
The following diagram shows the block diagram of FPGA tester (version 60 (aka Mk60) used to try and extract the ucode ROM data from the Inmos T414B device. A number of builds have been tried with various processor clocks and test shift clock frequencies. The FPGA tester contains a finite state machine (fsm) which allows the input address to be loaded into the address shift register from the laptop computer (via the USB-PIO interface). Once loaded the laptop computer sends the GO signal and the FPGA clocks the data into the T414B device at the TestShiftClock rate, pulses the notDoDPDriverfromROM and then clocks the data out of the T414B device into the large shift register in the FPGA. Once done, the laptop computer collects the data from the large shift register using the USB-PIO.
The following timing diagrams show the workings of the FPGA (Mk72) used to extract the ROM data from the INMOS T414B device.
The following diagram shows the simplified test scan path within the Inmos T414B for ROM access and ucode extraction.
September 2016 - update 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, resulting in Mk60. 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 using Mk61 and Mk67 (both variants of Mk60) 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.
What is interesting is the microinstruction ROM word size in the Simple 42 design (refer to David May's S42 documentation accessed from my website - see Inmos S42 tab) 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. Guy has since emailed to updated his position to say that the T800 likely had a microinstruction 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 Inmos 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 couple).
I will start further investigations shortly to try and get data out of the ROM. This will be my next focus.
October 2016 - 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
The INMOS T414B ROM contents (the data is finally out)
SEE ATTACHMENT BELOW. The data was extracted using the ROMspy software tool v0.2 and the test board FPGA loaded with Mk73, which is a variant of Mk72 which was the first version to successfully extract data from the ROM. Mk73 has a reduced output shift register of only 70 bits (but otherwise identical to Mk72).
November 2016 - During November I spent some time reviewing the data extracted from the Inmos T414B device, done using my ROMspy software and FPGA version Mk73 - see attachment at the bottom of this webpage. What was initially very clear was that something was MISSING – there was no obvious NEXT or ROMFeedback address in the data extracted. This was expected since it was there in the Simple 42 ucode and I was lead to believe (by the desingers) that the T414 ucode was largely based in the same architecture and design.
I mentioned this to Guy and Jon and they jointly recalled the ucode being larger than 59 bits and Jon also recalled ‘vague’ memories of the data for the odd and even bits being extracted separately. Jon also mentioned that there appeared to be more lines on the Inmos T414 “Poster” Picture. Jon suggested I tried applying the dpd pulse on the opposite edge of the Test Shift Clock.
So I set about modifying the FPGA and created version Mk77. Straight away I got different data. NOTE: The output ucode data is INVERTED. Initially it was not repeatable but this was later identified by the requirement to apply the address bits on the OPPOSITE edge of the test shift clock (i.e. data must be setup on rising edge of Test Shift Clocks so it is stable during falling edge), compared to Mk73. Once I made the changes the data out was repeatable and DIFFERENT from the initial Mk73 data results. The mk77 data results are attached (Note: the ROMspy software automatically inverts the data to the correct polarity). A quick review of data indicates that the two outputs Mk73 and Mk77 are the separate odd and even bits of the ucode ROM. Also there is no duplication or empty columns.
I then wrote a program (known as the ROMweaver) to splice the two files data bits together to create the complete ROM data. I have attached two files at the bottom of this webpage – one with Mk77 results assumed to be the odd data and the other with Mk73 results assumed to be the odd data. SEE ATTACHMENT BELOW for complete ucode ROM contents.
Immediately the review of the complete ROM data showed the missing NEXT or ROMFeedback address in the data.
I have started to perform an analysis of the complete ROM data and identified the NEXT bit and identified that the primary instructions are mapped at 0x200 onwards. Instruction Rev is at 0x000. It would appear that the ROMFeedback (at least the upper 8bits of the 10bit address) is not in a logical order (i.e. bits are mixed up). Note: the lower two bits may be elsewhere in the data, since they go into the conditionalSelectbit1/0 logic.
So in conclusion, the micro-instruction size in the Inmos T414B is 59 x 2 = 118 bits wide. The ROM contains 647 ucode words.
The following timing diagrams show the workings of the FPGA (Mk77) used to extract the extra ROM data from the Inmos T414B device.
The following diagram shows the enhanced test scan path within the Inmos T414B for ROM access and ucode extraction, showing odd and even bit extraction paths.
The next task is the decoding phase. This could take quite some time…
December 2016 - During late November and into December I spent some time trying to make a start at decoding the ucode ROM bits. Based on these findings I'm now fairly confident that the data extracted by the FPGA Mk73 (i.e. Mk72 timing) is the ucode EVEN data bits, and the data extracted by the FPGA Mk77 timing is the ucode ODD data bits.
Based on these findings/ results I have uploaded what I now believe is the COMPLETE INMOS T414B ucode ROM data in correct bit order. SEE ATTACHMENT BELOW for complete ucode ROM contents.
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.
May 2018 - After a year of effort analysing the VBC (ucode) and writing a C based emulator (running using the actual VBC code) based on my findings I am pleased to release the first working version of the PC based Inmos Transputer T414 Rev. B VBC emulator (see the tab VBC Emulator).
Other news:
Whilst the focus of this webpage has been to extract the uCode from the T414B device, access to the uCode ROM in the other transputer devices, namely the Inmos T425, T400, T800 and T801 has also successfully been done by means of holding the three Proc Speed Select [2..0] pins B1, F1 and D2 ALL at VCC/5V. Which is defined as an invalid processor speed selection by the Inmos data sheet (see the figure below).
Whilst I had some spare time I've extracted the data from the INMOS T425C device. Extraction of the T425C ucode ROM data was done using the same software tools as for the T414B device. Two different FPGA builds were used. FPGA version Mk74 (based on Mk73 but with the three Proc Speed Selects pins all at Vcc/5V) was used to extract the EVEN data bits. FPGA version Mk78 (based on Mk77 but with the three Proc Speed Selects pins all at Vcc/5V) was used to extract the ODD data bits.
Some differences were noted during the T425C ucode ROM data extraction. Firstly the Address shifted out is INVERTED in both the two outputs (i.e. Mk74 and Mk78), unlike the T414B ucode ROM outputs (which were NOT inverted). Secondly the data from Mk74 output was INVERTED, where as the data from Mk78 was not inverted. This was the opposite way to the T414B data output. Both the outputs Mk74 and Mk78 are attached below. NOTE: The attachments have the data bits correctly inverted to the correct polarity by the ROMspy tool.
So in conclusion, the micro-instruction size in the Inmos T425C is 59 x 2 = 118 bits wide. The ROM contains 742 ucode words.
The complete T425C ucode ROM data, spliced using ROMweaver has been produced. SEE ATTACHMENT BELOW for complete ucode ROM contents.
June 2019 - Whilst I had some spare time I extracted the ucode data from the INMOS T800D device. Extraction of the T800D ucode ROM data was done using the slightly modified software tools as for the T414B/T425C device, in order to cope with the additional 2-bits in the micro instruction register / scan path. Two different FPGA builds were used. FPGA version Mk79 (based on Mk74 but with the output shift register increased by two to 72bits was used to extract the EVEN data bits. FPGA version Mk80 (based on Mk78 but with the output shift register increased by two to 72bits was used to extract the ODD data bits. In addition to the pins set for T425C ucode ROM data extraction, the BootFromROM (pin E2) must be held at Vcc/5V, in order to enable the CPU scan path.
Some notes regarding the T800D ucode ROM data extraction. Firstly the Address shifted out is not inverted in both the two outputs (i.e. Mk79 and Mk80). Secondly the data from Mk80 output was INVERTED, whereas the data from Mk79 was not inverted. Both the outputs Mk79 and Mk80 are attached below. NOTE: The attachment (Mk80) has the data bits correctly inverted to the correct polarity by the ROMspy tool.
So in conclusion, the micro-instruction size in the Inmos T800D is 61 x 2 = 122 bits wide. The ROM contains 720 ucode words.
The complete T800D ucode ROM data, spliced using ROMweaver has been produced. SEE ATTACHMENT BELOW for complete ucode ROM contents.
FPU ucode
The extraction of the T800D ucode ROM data for the Floating Point Unit (FPU) was done using the same software tools and FPGA versions (i.e. Mk74 and Mk78) as for the T425C device, the same pins set except the BootFromROM (pin E2) must be held at Gnd/0V, in order to enable the FPU scan path.
Some notes regarding the T800D FPU ucode ROM data extraction. The input address register is 9 bits. The MSB of the Address is shifted in first into the TestShiftIn pin. The data from Mk74 output was 60 bits in size. The data from Mk78 was 60 bits in size BUT one bit is unused. Hence it would appear from initial analysis (before any actual decoding of the data) is that the Mk74 data is ODD and Mk78 data is EVEN bits. Further analysis of row offsets 0x04, 0x05, 0x06 and 0x22 seems to confirm this.
So in conclusion, the micro-instruction size in the Inmos T800D FPU is 59 + 60 = 119 bits wide. The FPU ROM contains 384 ucode words. An initial analysis confirms that location 0 is empty (i.e. all column bits are logic 0) corresponding to the IDLE state.
The complete T800D FPU ucode ROM data, spliced using ROMweaver has been produced. SEE ATTACHMENT BELOW for complete ucode ROM contents.
February 2020 – I have spent the last few months analysing and decoding both the Inmos T800 Integer Unit (IU) and the Inmos T800 Floating Point Unit (FPU) ucode columns. The task has gone better than I ever expected. Right now, all the T800 IU ucode columns are fully known and defined. For the T800 FPU column ucode most are now known with only a few bits of logic still to be determined.
April 2020 - Whilst I had some spare time I extracted the ucode data from the INMOS T805D device. Extraction of the T805D ucode ROM data was done using the SAME method as for the T800D.
The micro-instruction size in the Inmos T805D is 61 x 2 = 122 bits wide. The ROM contains 753 ucode words.
The complete T805D ucode ROM data, spliced using ROMweaver has been produced. SEE ATTACHMENT BELOW for complete ucode ROM contents.
FPU ucode
The extraction of the T805D ucode ROM data for the Floating Point Unit (FPU) was done using the SAME method as for the T800D FPU.
The micro-instruction size in the Inmos T805D FPU is 59 + 60 = 119 bits wide. The FPU ROM contains 384 ucode words. The T805D FPU ucode contents is identical to the T800D FPU ucode contents.
The complete T805D FPU ucode ROM data, spliced using ROMweaver has been produced. SEE ATTACHMENT BELOW for complete ucode ROM contents.
Page updated
Google Sites
Report abuse