Tube ULA Reverse Engineering

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Tube ULA Reverse Engineering

Postby hoglet » Tue Aug 05, 2014 8:04 pm

Hi all,

I thought I would start a new thread talking about a new project I've been spending time on recently.

In the past there have been attempts to re-create the Tube ULA from scratch, given just the public specifications:

  • John Kortink's ReTuLa. This is not, however a complete implementation (e.g. it doesn't support DMA used by the 80186 co-processor), and John's also not (yet...) shared the sources.
  • Robert Sprow's ARM7TDMI co-proc,. Again, sadly not open source.
  • BigEd and Richard Evans over at beeb816 start a Verilog project here. There was a release here, but I'm not sure how compatible it is with the original. BigEd: any comments on this? It looks pretty complete to me.

A couple of weeks ago, BigEd contacted me and asked if I was interested in a new challenge. :shock:

How could I possibly say no.... :lol:

BigEd, and co-conspirator Chris Smith (who reverse engineered the ZX Spectrum ULA) have been in contact with Steve Furber, who worked at Acorn during the 1980s first as a hardware designer (on the BBC Micro), and later as the overall Design Manager. From Steve, they were able to ascertain that there still existed some design information from the Tube ULA, namely some of the original "check plots" produced I think by Ferranti as part of signing off the design.

Thanks to lots of hard work by Steve, we now have a very high resolution scan of one of these check plots of the Tube ULA. This is a single PNG file, weighing in at 25200 x 29388 pixels, and 1.8GB is size. :shock: :shock: :shock:

Here's a lower resolution JPG version, so you get an idea of the starting point:
Tube-design.jpg


The core of the Ferranti ULA contains contains 9 identical blocks of 10 x 11 ULA cells. Each ULA cell contains a current source and four transistors, which is enough to make a pair of two-input NOR gates. That makes a total possible gate count of about 4000 gates.

The only part of the ULA that was customizable was the metallization layer, so in theory if you can figure out the metallization pattern, that's all you need to reverse engineer the design. What's nice is that all the routing in the core was done on an exact grid, which should help with the analysis. Each ULA cell is exactly 15 x 16 routing cells.

So, I've embarked on what I expect to be quite a long journey, towards a 100% compatible, open source Tube ULA design in Synthesisable VHDL, that could fit into the corner of a modern FPGA.

The steps that need to be completed:

1. Chop the original massive image into more manageable pieces, e.g. one image for each of the nine identical blocks of ULA cells.

2. Accurately correct the small amount of perspective distortion present in the original image. I'm not exactly sure what process Steve used to digitize the check plot, but structures that should be rectangular are very slightly parallelogram-like. It's enough to make overlaying a grid tricky. A perspective transform needs to be calculated to correct each of the array blocks.

3. Process each of these images (using GIMP or Photoshop) to quantize down to a small number of colours to make automatic extraction of the metallization pattern simpler. (e.g. make the metal and only the metal blue)

4. Superimpose the original routing grid, as accurately as possible, over the whole design. This is harder than it sounds, as even after perspective correction there are still some non-linear distortions present.

5. Look at each routing cell, and try to do some pattern matching to determine its connectivity to its immediate neighbours. Attempt to improve the results by running some design rule checking, and looking for unexpected features, like cells that look to be connected from one side, but not the other. Ideally fix these automatically, but flag the cell for manual inspection.

6. Manually identify the pin name of each peripheral cell, its configuration, and where the signals enter the core. It's easier to do this manually, as there are only 40 pins, and that saves having to write code that deals with the additional variability (and orientations) of the peripheral cells. There's plenty of documentation around that gives the Tube ULA pinout.

7. Generate a transistor level netlist for the whole design from this cell connectivity data and where the 40 (ish) external signals enter the core.

8. Process the transistor level netlist and try to reduce it down to a netlist of 2-input NOR gates.

9. Identify patterns of cross-coupled NOR gates that form latches and/or registers.

10. Eventually produce gate-level VHDL (mostly NOR gates and registers) that can be synthesised into an FPGA.

11. Test this by simulation and/or synthesis into a GODIL.

Phew! If you are still with me, then well done. :lol:

I'm currently up to about step (5).

Here's an example of what's involved....

A small portion of the original image:
sample1.png

After correcting for the small amount of perspective distortion:
sample2.png

After cleaning up in GIMP:
sample3.png

After overlaying the routing grid, and performing some pattern matching to determine the layout:
sample4.png

Some explanation of the final image is necessary:

  • The fine red grid is an attempt at automatically superimposing the original routing grid.
  • The green pins were placed by dead reckoning, and represent the terminals to known features in a cell (e.g. the four transistors).
  • The red lines represent the connectivity information extracted by pattern matching each routing cell against a set of idealized shapes.
  • The yellow squares are were design rule checks failed, and a fix was made, which needs to be manually checked.

The whole of one block can be seen here:
https://www.dropbox.com/s/gig5p2nn0b667 ... 140802.png

And the analysis code (definitely a work in progress) is in GitHub.
https://github.com/hoglet67/TubeULA

I'm posting this now for a few of reasons:

  • I don't really like doing things behind closed doors. It's feedback from other folk, and their ideas, that keep me going.
  • I'm at the point where I'm convinced this is eventually going to work, i.e. the number of errors in extracted connectivity is getting close to zero.
  • There are likely to be many opportunities for others to help out, such as helping to check annotated portions of the array for connection errors.

Anyone interested?

Dave
Last edited by hoglet on Wed Aug 06, 2014 6:03 pm, edited 4 times in total.

PhilYoung
Posts: 189
Joined: Sun Jun 12, 2011 4:55 pm

Re: Tube ULA Reverse Engineering

Postby PhilYoung » Tue Aug 05, 2014 9:40 pm

Hi,

Maybe you could see if there has been any more progress with this:

http://visual6502.org/wiki/index.php?title=Acorn

Cheers,

Phil Young

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Tue Aug 05, 2014 9:46 pm

Hi Phil,

PhilYoung wrote:Maybe you could see if there has been any more progress with this:
http://visual6502.org/wiki/index.php?title=Acorn

That page was last edited over three years ago. Who would know the latest status?

Mark H., do you what happened to the samples you donated? Did you ever see any die photos?

Dave

User avatar
1024MAK
Posts: 5980
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Tube ULA Reverse Engineering

Postby 1024MAK » Tue Aug 05, 2014 11:46 pm

Dave, you left out two steps... [-X
12 - write a book about it
13 - get the book published

:mrgreen:

Oh, best of luck 8)

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

PhilYoung
Posts: 189
Joined: Sun Jun 12, 2011 4:55 pm

Re: Tube ULA Reverse Engineering

Postby PhilYoung » Wed Aug 06, 2014 7:14 am

hoglet wrote:Hi Phil,

PhilYoung wrote:Maybe you could see if there has been any more progress with this:
http://visual6502.org/wiki/index.php?title=Acorn

That page was last edited over three years ago. Who would know the latest status?

Mark H., do you what happened to the samples you donated? Did you ever see any die photos?

Dave


Good point, it looks like the main page hasn't been updated for nearly a year as well. And I suppose with the drawing you have you can essentially leap-frog their process (for the Ferranti ULA at least).

Cheers,

Phil Young

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Wed Aug 06, 2014 7:47 am

PhilYoung wrote:Good point, it looks like the main page hasn't been updated for nearly a year as well. And I suppose with the drawing you have you can essentially leap-frog their process (for the Ferranti ULA at least).

It's possible the same technique would work well on die photos as well. There are some samples of photos of the Electron ULA here:
http://www.cl.cam.ac.uk/~atm26/acorn/el ... sic_1a.png
(Taken by Theo Marketto from a die that Mark H. provided)
asic_1a.png

Processing this a bit in GIMP yields:
asic_1a_gimped.png

There are the same strong vertical and horizontal features that would allow a grid to be accurately aligned. The cells patterns would need to be changed, but it would be interesting to try.

For the Electron ULA, I've only seen these photo fragments, not a complete die. If anyone is aware of any other ULA die photos, please let me know.

I guess the point I'm trying to make is that I'm hoping the toolkit we end up would be usable (eventually) to recover more than just the Tube ULA.

Dave

s1paulr
Posts: 207
Joined: Mon May 21, 2012 11:27 am
Location: Huntingdon

Re: Tube ULA Reverse Engineering

Postby s1paulr » Wed Aug 06, 2014 9:09 am

Wow Dave, that is a Herculean project. It truly puts my measly efforts into perspective =D>

Good luck with it and please keep us updated on how it goes.

Paul

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Wed Aug 06, 2014 11:50 am

You're doing a splendid job Dave, and thanks for opening this thread.

One quick point: you probably won't only find 2-NOR gates, most likely you will also find inverters, and 3-NOR and 4-NOR.

On the visual6502 project progress, there's a bottleneck in the deprocessing and photography, and another bottleneck in the polygon capture. A programmatic image-processing approach is a massive step forward. I too hope that any successful approach with the checkplot might also be a good basis for tackling images of chips. I believe we do have high-res images of an Electron ULA - in fact, of two versions, photos taken I think by Theo Markettos and stitching by Christian Sattler. It's possible they are not quite high-res enough. This link is indexed by Google so I think it should be OK to publish:
http://uxul.org/~noname/visual6502/ULA-12C021M/

(I'm not aware of any attempt or indeed any expressed interest in the serial ULA or video ULA.)

On the Beeb816 tube verilog, it did work well enough to run Elite[1], but not well enough I think to do file access in BASIC. Subsequently flynnjs found and fixed some issues with it - but no patch yet.
viewtopic.php?p=81490#p81490

Cheers
Ed

[1] I'm no longer sure we did run Elite through our Tube. I might have confused the Tube adventure with the 65816 adventure.
Last edited by BigEd on Sun Nov 02, 2014 4:51 pm, edited 1 time in total.

User avatar
danielj
Posts: 4524
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester

Re: Tube ULA Reverse Engineering

Postby danielj » Wed Aug 06, 2014 1:39 pm

Dave, this is great. Also really pleased that Steve F's been happy to help out, getting that scanned at a useful resolution and assembled must have been rather a big job (that said, knowing the way University Professors do these things, PhD student A was probably called in with Professor feigning inability and said student took pity and did it..).

Happy to lend a hand checking things - although might need that hand held a little bit whilst getting my eye in on what I'm actually looking at!

d.

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Wed Aug 06, 2014 4:16 pm

(Note that the Electron ULA uses some diagonal routing which breaks up the grid)
Attachments
electron-ula-diagonals.png
From http://www.cl.cam.ac.uk/~atm26/acorn/electron/ula/asic_3.JPG

User avatar
flynnjs
Posts: 653
Joined: Tue Jul 06, 2010 9:33 pm

Re: Tube ULA Reverse Engineering

Postby flynnjs » Wed Aug 06, 2014 7:11 pm

I'm sniffing around after playing with Ed's code.
My fixes aren't yet enough for me to be comfortable to release everything as I still had some non working bits.

Happy to help dig in on this too.

User avatar
retroclinic
Posts: 3011
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Tube ULA Reverse Engineering

Postby retroclinic » Wed Aug 06, 2014 8:18 pm

Not heard anything since I donated the Tube ULA. Good work on the original check plot though, it's just a shame Steve Furber can't dig out the original schematic.

Mark.
Image

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Wed Aug 06, 2014 8:36 pm

I've been looking at the peripheral cells this evening, trying to map them back to pins on the package.

Here's the package pinout from the 6502 second processor service manual:
pinout.png

I've looked at some of the peripheral cell logic around the edge of the die, and there seem only about 5 different configurations being used:
- An 16mA output with a 5K pullup
- An 16mA open collector output (no pullup)
- A totem pole tristate output
- A one transistor input
- A two transistor input (used with the tristate output)
- A three transistor input which uses a common base transistor

The die has 64 pads, and I think this is how they are mapped:
PeripheralCells.png

And the same as a PDF:
PeripheralCells.zip
(96.41 KiB) Downloaded 40 times

The next step is to determine the cell location (X,Y) where each of these signals enters the core of the array, and then enter these locations as fixed pins into the layout extraction software. If I do this, I don't think I need to bother any further about the peripheral cells.

[ I've spotted one place where transistors in an unused peripheral cell seem to be used as an inverter. So I might also have to manually deal with a few exceptions like this. ]

Dave

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Sun Aug 10, 2014 9:22 pm

Hi all,

I'm continuing to make slow but steady progress with this latest obsession. :lol:

I've pretty much completed steps (6) and (7) now:
hoglet wrote:6. Manually identify the pin name of each peripheral cell, its configuration, and where the signals enter the core. It's easier to do this manually, as there are only 40 pins, and that saves having to write code that deals with the additional variability (and orientations) of the peripheral cells. There's plenty of documentation around that gives the Tube ULA pinout.

7. Generate a transistor level netlist for the whole design from this cell connectivity data and where the 40 (ish) external signals enter the core.

To do this, I've had to run the cell extraction tool over the nine separate block images, then effectively glue these back together into a single monster cell array, and then extend the code to trace the connectivity (with knowledge of where the cross-unders are, etc.).

In the netlist extraction I've tried to add as much checking as I could think of, and it's flagging quite a few unexpected shorts to the positive power supply rail (VS).

I've uploaded images of the the nine blocks annotated with the extracted nets here:
https://www.dropbox.com/sh/n8r2dwm1c2hl ... HxbT-lQlka

If any spots any mistakes with the extraction, then please let me know.

Here's a small fragment of the netlist I'm generating, in a format I just made up. Pins are Emitter, Base, Collector.

Code: Select all

TR B00_C17_T1(N826, N827, N427);
TR B00_C17_T2(N826, N811, N427);
TR B00_C17_T3(N840, N427, N827);
TR B00_C17_T4(N840, N825, N827);
CS B00_C17(N840, N826, N865, GND);
RES B00_C17_RLA(N427, VSS);
RES B00_C17_RCS(N865, VSS);
RES B00_C17_RLB(N827, VSS);
TR B00_C18_T1(N913, N698, N908);
TR B00_C18_T2(N913, N319, N908);
TR B00_C18_T3(N955, N320, N887);
TR B00_C18_T4(N955, N909, N887);
CS B00_C18(N955, N913, N991, GND);
RES B00_C18_RLA(N908, VSS);
RES B00_C18_RCS(N991, VSS);
RES B00_C18_RLB(N887, VSS);
TR B00_C19_T1(N1071, N321, N912);
TR B00_C19_T2(N1071, N987, N912);
TR B00_C19_T3(N1110, N1041, N1021);
TR B00_C19_T4(N1110, N450, N1021);
CS B00_C19(N1110, N1071, N1139, GND);

Next steps are to:
- Continue to identify and fix issues with the extraction.
- Write some code to try to recognise patterns of transistors that form NOR gates.

Dave

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Mon Aug 11, 2014 12:38 pm

Here are a few relevant diagrams from Chris Smith's excellent book:
Attachments
ULA6000-layout.png
The ULA cell layout (rotated)
ULA6000-schematic.png
Kit of parts in each ULA cell - enough for two NOR2 or a NOR4
CML-NOR-gate.png
NOR gate in CML implementation

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Mon Aug 11, 2014 7:04 pm

Thanks for POSTing those diagrams Ed.

Chris's Smith's book is proving very useful for this endeavour.

I've been thinking about the extracting gates from transistors. It looks like the current mode logic (CML) topologies are so limited that all you would have to do is identify groups of N transistors joined at the emitters and collectors, and replace these by N input NOR gates.

There's probably more checking that I'll try to do, like checking the emitters are connected to a current source, and the collectors to a pullup resistor.

But that's going to be my first attempt anyway.

I finish work tomorrow for a couple of weeks, so I should get more time to spend on this. It's one of the things I'll be dabbling with at the Acorn Hackfest at the weekend.

Dave
Last edited by hoglet on Mon Aug 11, 2014 7:09 pm, edited 1 time in total.

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Mon Aug 11, 2014 7:07 pm

That sounds right to me - check some simplifying assumptions, and you're left with only a few cases, all of which are NOR gates. And you've some free time to do it in - excellent!

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Tue Aug 12, 2014 7:10 pm

I now have my first gate level netlist of the whole design.

I'd love a way to turn this into a schematic.

Is anyone aware of any software the will take a gate level netlist (in any format) and lay the gates out into a single large schematic sheet?

Dave

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Tue Aug 12, 2014 7:18 pm

That's a hard problem. The expensive chip design software from Synopsys used to have a go.

Is it worth retaining the x,y locations of each gate output and using that to place the gates? Doesn't solve the problem of wiring it up. But there's a fair chance that the layout follows a functional organisation, to some degree.

Ed

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Tue Aug 12, 2014 8:03 pm

Hi Ed,

BigEd wrote:That's a hard problem. The expensive chip design software from Synopsys used to have a go.

I actually used that quite a bit in the early 1990's.

BigEd wrote:Is it worth retaining the x,y locations of each gate output and using that to place the gates? Doesn't solve the problem of wiring it up. But there's a fair chance that the layout follows a functional organisation, to some degree.

That's a good idea.

I'm now able to find pairs of cross-coupled gates. What's interesting is that quite a few seem to have more than two inputs. It would be great to see a copy of the Ferranti ULA library documentation. Did Chris ever manage to find this?

There are 346 pairs of cross coupled gates in total. Mark (Retroclinic) counted 208 registers just in the FIFOs (link here). 346 pairs doesn't seem enough, as according to Chris's book a register would be 3 pairs. Unless they used a more efficient FIFO implementation that used gated latches, but this would still need 2 pairs per latch.

Based on this, I think I've probably made a mistake somewhere.... :lol:

Dave
Last edited by hoglet on Tue Aug 12, 2014 8:18 pm, edited 1 time in total.

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Tue Aug 12, 2014 8:14 pm

I think you can make a FIFO mostly from latches, which are cheaper than flops, so maybe that's what happened? We'll soon find out!

Great result by the way!

User avatar
roland
Posts: 2683
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Tube ULA Reverse Engineering

Postby roland » Tue Aug 12, 2014 8:53 pm

I understand the principle of what you are doing, but this is a bit too complicated for me to support you. I really have a lot of respect for your knowledge.

[ where is a deep bow icon? ]

Keep up this good work!
256K + 6502 Inside
MAN WOMAN :shock:

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Tue Aug 12, 2014 9:42 pm

Here's a few more statistics:

The ULA as a whole has 990 Cells, which gives a total of 3690 transistors.

Of these 3690 transistors, 805 have the base and emitter unconnected.

So that leaves 3155 used transistors.

Mapping to gates gives the following distribution:

Code: Select all

95      1 input NOR Gates
1318    2 input NOR Gates
53      3 input NOR Gates
33      4 input NOR Gates
12      5 input NOR Gates
1       6 input NOR Gates
4       8 input NOR Gates

If you count the total number of input pins on the above, it comes to 3120.

The difference is because I'm currently ignoring 35 transistors because they have shorts to VS.

Of these gates above, 346 * 2 = 692 form cross-couples pairs, and 5 seem to feed back to themselves.

Dave

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Tue Aug 12, 2014 10:12 pm

Here's a nice diagram from the 6502 second processor service manual:
tubeblock.PNG

I count 34 bytes of registers, which is 272 bits.

Dave

User avatar
BigEd
Posts: 1081
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Postby BigEd » Wed Aug 13, 2014 6:40 am

An inverting gate feeds back to itself? Would want to proof-read the connectivity for that.

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am

Re: Tube ULA Reverse Engineering

Postby poink » Wed Aug 13, 2014 9:43 am

hoglet wrote:Is anyone aware of any software the will take a gate level netlist (in any format) and lay the gates out into a single large schematic sheet?

http://www.graphviz.org/ probably can. Specify the interconnections, and it'll draw you a diagram, likely not the prettiest thing (depending on how much fiddling you do defining the node shapes etc.,), but it'll minimise overlaps and will probably be good enough to make it readable.

User avatar
jgharston
Posts: 2387
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Tube ULA Reverse Engineering

Postby jgharston » Wed Aug 13, 2014 1:46 pm

hoglet wrote:I count 34 bytes of registers, which is 272 bits.
Except you've omitted the status flags, so that's another 16 bits.

Client -> Host
Reg 1: 24 byte FIFO
Reg 2: 1 byte
Reg 3: 2 byte FIFO
Reg 4: 1 byte
Status 1: 2 bits
Status 2: 2 bits
Status 3: 2 bits
Status 4: 2 bits

Host -> Client
Reg 1: 1 byte
Reg 2: 1 byte
Reg 3: 2 byte FIFO
Reg 4: 1 byte
Status 1: 2 bits
Status 2: 2 bits
Status 3: 2 bits
Status 4: 2 bits

Host <-> Client
Control: 6 bits (except the appnote says this is a byte)

36 bytes = 288 bits.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Wed Aug 13, 2014 2:25 pm

poink wrote:http://www.graphviz.org/ probably can. Specify the interconnections, and it'll draw you a diagram, likely not the prettiest thing (depending on how much fiddling you do defining the node shapes etc.,), but it'll minimise overlaps and will probably be good enough to make it readable.

Thanks for this, it looks just the ticket if I can figure out the "dot" language syntax. A few examples wouldn't go amiss.

Dave

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Wed Aug 13, 2014 2:27 pm

jgharston wrote:
hoglet wrote:I count 34 bytes of registers, which is 272 bits.
Except you've omitted the status flags, so that's another 16 bits.

Well spotted.

For the 24 byte FIFO, there must also somewhere be read and write addresses, which would be another 10 bits.

Dave

User avatar
hoglet
Posts: 5872
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Tube ULA Reverse Engineering

Postby hoglet » Wed Aug 13, 2014 3:00 pm

I've spent a couple of hours adding extraction overrides to fix all the errors that my DRC checking logging was flagging. This includes the 5 "self coupled" gates, which were in fact all extraction errors.

I am slightly concerned that there will be a number of further extraction errors lurking, that don't result in DRC errors, but just subtly change the logic.

With this batch of extraction errors fixed, I'm now finding 354 cross-coupled gate pairs. I was wondering whether most of these were gated transparent latches, so I wrote to code to try to match the following 4 gate pattern:
latch.PNG

The result is that 291 latches were recognised. This number is starting to get close to what we would expect, but it actually a bit on the low side.

What I have found is the PD and HD busses are immediately latched, and this is the only place they go.

Code: Select all

Cross coupled gate pair: N826(2) and N426(5) Found latch: gate=N112; data=PD7IN; q=N826; nq=N426
Cross coupled gate pair: N1727(2) and N1409(2) Found latch: gate=N112; data=PD6IN; q=N1727; nq=N1409
Cross coupled gate pair: N2148(2) and N1825(2) Found latch: gate=N112; data=PD5IN; q=N2148; nq=N1825
Cross coupled gate pair: N2573(2) and N2247(2) Found latch: gate=N112; data=PD4IN; q=N2573; nq=N2247
Cross coupled gate pair: N2704(2) and N2671(2) Found latch: gate=N112; data=PD3IN; q=N2704; nq=N2671
Cross coupled gate pair: N3416(2) and PRST(6) Found latch: gate=N112; data=PD2IN; q=N3416; nq=PRST
Cross coupled gate pair: N3839(2) and N3513(2) Found latch: gate=N112; data=PD1IN; q=N3839; nq=N3513
Cross coupled gate pair: N4257(2) and N3934(2) Found latch: gate=N112; data=PD0IN; q=N4257; nq=N3934
Cross coupled gate pair: N699(2) and N812(2) Found latch: gate=N26; data=HD7IN; q=N699; nq=N812
Cross coupled gate pair: N1548(2) and N1722(2) Found latch: gate=N26; data=HD6IN; q=N1548; nq=N1722
Cross coupled gate pair: N1967(2) and N2143(2) Found latch: gate=N26; data=HD5IN; q=N1967; nq=N2143
Cross coupled gate pair: N2390(2) and N2568(2) Found latch: gate=N26; data=HD4IN; q=N2390; nq=N2568
Cross coupled gate pair: N2812(2) and N2990(2) Found latch: gate=N26; data=HD3IN; q=N2812; nq=N2990
Cross coupled gate pair: N3234(2) and N3411(2) Found latch: gate=N26; data=HD2IN; q=N3234; nq=N3411
Cross coupled gate pair: N3657(2) and N3834(2) Found latch: gate=N26; data=HD1IN; q=N3657; nq=N3834
Cross coupled gate pair: N4075(2) and N4253(2) Found latch: gate=N26; data=HD0IN; q=N4075; nq=N4253

You can follow these forward, and they fan out to 4 latches:

Code: Select all

Cross coupled gate pair: N1992(2) and N1993(2) Found latch: gate=N591; data=N1825; q=N1992; nq=N1993
Cross coupled gate pair: N2008(2) and N2015(2) Found latch: gate=N822; data=N1825; q=N2008; nq=N2015
Cross coupled gate pair: N2011(2) and N2010(2) Found latch: gate=N806; data=N1825; q=N2011; nq=N2010
Cross coupled gate pair: N2052(2) and N2012(2) Found latch: gate=N807; data=N1825; q=N2052; nq=N2012
Cross coupled gate pair: N2148(2) and N1825(2) Found latch: gate=N112; data=PD5IN; q=N2148; nq=N1825

So this looks like the input of the 4 separate host to tube registers.

I need to look at what the remaining cross-coupled gate pairs are, if they are not transparent latches.

I'll try and post the a version of the netlist later today, in case anyone else is interested in looking over it.

Dave


Return to “hardware”

Who is online

Users browsing this forum: Bing [Bot], dp11 and 4 guests