- one lonesome software engineer's trek into the darkness

Running the tutorial

He has a simple design (map9v3) which he runs through the entire QFlow process, and he guides you through what to expect and explains what's going on. That's the subject of this entry…
Stacks Image 86
The assumption here is that all the tools are installed, and the working directory is set up as indicated to the right. The three directories will automatically be used by Qflow, the design is in 'source', and the 'load.tcl' is the script provided to load the LEF and DEF files at a later stage of the tutorial. The directory structures isn't *required* per se, but it makes life easier to separate (by stage) the large number of files created during the whole run.

The entire process is managed by QFlow, so to do a complete run, simply make sure you're in the top-level directory (where '.' is in the directory tree above), and type:
qflow synthesize place route map9v3
This will produce an enormous amount of output, and as part of the process will graphically show the placement progress as greywolf goes about its business. This simple design synthesizes, places, and routes in only a few seconds, but complex designs can take a lot longer.

Tim has vetted this tutorial so that it ought to just run and always pass, but typically each of the stages {'synthesize', 'place', 'route'} would be done in isolation, once the previous stage was successful. Running Qflow creates qflow_vars.sh (used to preserve Qflow's state) and qflow_exec.sh (which is what is run). If invoked with just a design argument, Qflow will create the 'exec' file with all the stages commented out, and the designer can proceed by uncommenting stages as needed.

Once the entire process has completed, you ought to see a line at the bottom of the log output saying that the Final state was 'no failed routes'. At this point it is ok to move on to verification of the routed design.
Preparing for Verification
The goal here is to use Magic to add the power rails (which are not added by default during synthesis) so we can have a real circuit ready to be verified using Layout Vs Synthesis testing (LVS). The steps are as follows (white text is typed into the unix shell, yellow text is typed into the Magic console):
cd layout
source load.tcl
writeall force map9v3
Once you have typed 'source load.tcl' into magic, you can put the mouse over the graphical window, and type 'v' to automatically pan and zoom the display over the just-loaded cell definition. If you do that, you'll see an image like the below. The various logical blocks are broken out and labelled (DFFSR standing for 'D' flip-flop shift-register', XOR standing for eXclusive OR, etc).
Stacks Image 124
You will, however notice that this presentation doesn't match the image on the opencircuitdesign website. This is because we're looking at the abstract cell views above. To see the physical layout, one must load the physical cell descriptions, which is done using the 'gds' command. First, though, you have to (a) install the GDS cell files, and (b) tell magic whereabouts on your hard disk to read them from.

Fetch the OSU standard cell set and install (by unpacking the .tar.gz archive) into ${prefix}/share/cells - where ${prefix} is the root of all your installed tools - in my case it's /opt/asic so they're installed in /opt/asic/share/cells.

Then add the line 'addpath /opt/asic/share/cells/cadence/lib/source/gds2' to the .magicrc file in the layout directory. Now you'll be able to restart magic from the layout directory and type (in the magic console)
gds read osu035_stdcells.gds2
You'll see a whole load of text scroll up the magic console as it migrates to the physical layout, and then the display will turn to look like…
Stacks Image 132
The hawk-eyed will note that this still doesn't look remotely like the image on Tim's website, in fact it looks even less like the layout on the website than our previous image. The eagle-eyed however, will note that at the top of their screen, it says that the cell loaded is 'iit_stdcells', which isn't the cell we want to see - we're interested in our map9v3 design, so using the cell manager (from the options tab), highlighting 'map9v3' and clicking on load, we then see
Stacks Image 136
Which at least gets us back to our own design. It's still not very like Tim's image though. The reason for that is that we need to:
  • select the whole cell (done, above, you can see the white border around the entire cell) by putting the mouse anywhere in the grey area on the outside of the cell and pressing 's'
  • Then type 'x' to expand the cell definition (or use the 'expand' button in the cell manager window you just opened).
Now the image looks a lot closer to Tim's routed design, vis:
Stacks Image 140
Now that looks pretty good - the physical layout resembles what Tim shows on the website (it's not identical, there are more rows and they're not as long as the one on the website, but it's a pretty good match). The power rails can be seen going in-between the standard cells that are laid out in horizontal rows, and we're ready to link up those rails to each other to make a functional circuit.

To do this, extend the VDD and GND rails out to either end of the circuit by painting 'M1' (metal-1) from the ends of the corresponding bar outwards on the left or right as appropriate, ending up with something that now looks like:
Stacks Image 148
Then select a region of the newly-extended VDD rail with your mouse, and type (without moving the mouse)
l vdd n m1
You will see the 'l' is expanded into 'label' by magic, and the vdd label appears where the box selection was made. Now do the same for the GND rail, selecting a box within the new rail, and then write out the new cell definition (complete with power rails), vis:
l gnd n m1
writeall force map9v3
So now we ought to have a valid operable digital circuit, as defined by our initial verilog file 'map9v3.v'. Now we can start to verify that this is indeed the case. We'll generate a SPICE netlist from the physical connectivity of the circuit, and compare it to a netlist generated from the digital design. They ought to match up, which will tell us that the synthesis completed correctly as far as the physical layout. To start with, get the SPICE netlist from the layout, as well as the simulation files, using the below commands (ignore the fact that some are in orange for now, type them all) and then quit Magic.
extract all
ext2spice scale off
ext2spice renumber off
ext2spice hierarchy on
ext2spice cthresh infinite
ext2spice rthresh infinite
One of the tools we installed is 'netgen', which can be used to test the design netlist vs the laid out netlist. To do this, change to the top-level directory (the one containing 'layout') and launch netgen from the unix console (text in white), and issue the command (in green) within the netgen console
cd ..
lvs layout/map9v3.spice {synthesis/map9v3.spc map9v3}
You'll see a lot of output from the netgen command, and then according to Tim, you should see a line at the end saying 'Result: circuits match uniquely'. Unfortunately for me, that didn't happen - so the next step is to find out why. Looking at the log file, It looks as though there's (at least) a bunch of FILL and 'c' "devices" that differ between the two netlists. The plan will be to compile the known-good linux code and run that through the tutorial - if I can compare the results of the various stages, I can hopefully track down where the Mac port is going wrong. [sigh]