FPGA to ASIC

        - one lonesome software engineer's trek into the darkness


Warts and all

Stacks Image 266

Concealed traps for the unwary


So I spent most of this Saturday trying to figure out why, when I went from a 0.35µm process to a 0.18µm process, I got the very-strange-looking layout to the right It is pretty apparent that something is wrong, the power rail appears to be carrying both VDD and GND, which is generally a recipe for the magic smoke to emerge from the device in question.

After much online googling, poring over the documentation, even an attempt to parse the technology file (which is around 14000 lines of text, for the uninitiated), I finally broke down and emailed Tim again.

I was gently informed that I'd mixed up the technologies when loading the design into Magic. There's a "load.tcl" script that I'd been blindly using to read the LEF (technology library) file and DEF (design) files. The technology file is, obviously enough, specific to the technology…

I was also advised to set the grid appropriately (the settings for layout are, again, obviously technology-dependent), so that needed a change as well.

In the end, I created a ~/lib/asic folder on my machine, and have started to put standardised scripts in there, meaning there's no need to remember to copy the right one to the right place before doing something, and I've adopted the naming convention of appending the technology to the end of the filename, so I now have 'load.018' and 'load.035' - that ought to prevent similar mistakes in the future. Every cloud and all that…

"Mind the Gap"


So then I ran through the verification process, seeing if I could get a 0.18µm process to pass the LVS test. Again, I have a script for the extraction of all the spice data, so I ran that, then ran my script that invokes netgen and performs an LVS test:
#!/bin/tcsh 
#
if ($# < 1) then
	echo "Usage: ng "
	exit
endif

set design = $argv[1]
cp ~/lib/setup.tcl .

netgen -batch lvs layout/$design.spice "synthesis/$design.spc $design"
… which sadly failed with the log that you can see if you disclose the below tab. One thing that immediately strikes you on looking at the netgen output is that all the nets that are missing are supposed to be connected to ground. Hmmm..
Qrouter doesn't connect together the GND and VDD rails that the standard cells use, that's a manual task in Magic after the routing is complete, so I took another look at the layout I'd told netgen to compare, and lo and behold, there was a 1-pixel gap between one of the GND rail the cells were connected to, and the extension that I'd painted in with Magic to bus all the GND rails together on the left.

That it's on the left is easy to understand - I typically define a box once by clicking on the lower-left corner with the left mouse button, then set the upper-right extent by moving to where I want that corner to be and clicking with the right mouse button. I then use that box for all the rails coming out of both the left and right sides of the design, finally joining all the left side extensions together, and then joining all the right-side extensions together.

The thing is that you place the box for any given rail using the left mouse button again to define the lower-left corner, and the idea is to match up the box you're placing with the rail that you're connecting to - this is easy when the rail is on the right side, because the point you're defining is right next to the end of the rail. On the left side of the cell though, you're defining the box by clicking on a pixel that's a long way away from where the connection is (because you click to define the lower-left corner, and the box you're defining joins the rail on its right-hand side). It's therefore marginally more difficult to align it correctly, and I'd got one of them off-by-one.

Try, Try again.


Anyway, fixing my error, re-running the extraction, and then re-invoking netgen gave me the desired "Result: Circuits match uniquely" message from netgen. In this case, the tools worked perfectly to draw my attention to exactly where the problem was, and it was a quick fix to make.

So now, I have a verified 0.18µm flow as well, at least on the SPI part of the design. For the interested, the dimensions of the cell (which are mainly down to the 128 registers that I've defined that are currently implemented using D Flip-flops) are 800 by 580 microns, or just under half a square millimetre.
[Back]