WP_Term Object
    [term_id] => 1012
    [name] => Concept Engineering
    [slug] => concept-engineering
    [term_group] => 0
    [term_taxonomy_id] => 1012
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 32
    [filter] => raw
    [cat_ID] => 1012
    [category_count] => 32
    [category_description] => 
    [cat_name] => Concept Engineering
    [category_nicename] => concept-engineering
    [category_parent] => 157
    [is_post] => 1

Concept: From Schematics to Debug

Concept: From Schematics to Debug
by Paul McLellan on 02-05-2015 at 7:00 am

 In the late 1990s I was the VP Engineering at Ambit Design Systems. We had a synthesis product (called BuildGates, nobody ever forgot the name). Both our own engineers and our customers wanted to be able to take a look at the gate-level netlist that was generated from their RTL. We used a product from a company called Concept Engineering based in Freiburg, as opposed to Munich where almost all other German EDA is centered. This would take the netlist, place all the inputs on the left, all the outputs on the right and then run a placement algorithm (probably pretty similar to P&R placement) on the netlist to decide where to put the gates and then run a router (probably pretty different from P&R routing) to put all the wires in with the idea of making the final result as pretty and readable as possible. This worked really well on moderate sized designs but since BuildGates could take 1M gate designs and synthesize them flat, it didn’t work too well on that sort of design—but then there is no good way to display a million gate netlist well.We had an OEM agreement with them to ship this product, now called NLview, to our customers. So, as it turns out did everyone in EDA who needed a schematic viewer (except Synopsys who needed it a decade earlier). That business still exists and whenever in EDA you see an automatically generated schematic that is probably what you are looking at. They then extended the technology so it was possible to look at hierarchical designs, Verilog, SystemVerilog, VHDL. Then transistor level designs in SPICE. Basically take pretty much any input and display it in a way that was both pretty (didn’t look like a rat’s nest) and effective for an engineer trying to follow his or her way around the design. It turns out that this is perfect for the modern design style that is largely assembling IP blocks. One problem with most IP blocks is that they come from another part of the company or from a 3rd party. No matter what the format, the block can be displayed in a way that makes it easy for an engineer to move around the design, up and down the hierarchy and so on, to get an understanding of the block. Paths can be traced, drawn in different colors and so on. There is full cross-probing between the graphical display and the input and the levels of the hierarchy.But they went further and added a lot of debug features to create a product called StarVision Pro that makes debugging a design a lot easier than starting from just the opaque input file. Cones from inputs or specific pins can be traced, critical paths can be excised from a netlist and written out in SPICE for detailed simulation and a lot more capabilities that an engineer trying to understand and debug an IP block requires.There is a lot of capability for analyzing the clock, highlighting the clock trees and highlighting all the domain crossings from one clock to another. At the transistor level, where the netlist can be incredibly complex due to parasitics, there are features to prune the netlist, merge capacitance and resistance when they are small, automatic recognition of gates from transistor structures and even creating hierarchy out of flat netlists. Basically, they can read in a transistor-level netlist and make it a lot more intelligible to the designer without losing accuracy. Moderately large blocks can be read straight in fast, huge blocks can be pre-processed into a binary format in an overnight batch mode and then the binary loads almost instantaneously.