Bill, > Ok, I wont rewrite anything that exists. Right now, I need solid=20 > hierarchical netlisting. I read through some of the gnetlist code.=20 > It's nicely written. However, it's missing the data structures I'm use=20 > to for netlist manipulation, and I feel that makes it much harder to=20 > work with the data. > > Here's a quick one-liner about each class in the database schema:
[ . . . . snip! . . . .] The datastructure you propose to accomplish your goal is nice. HOwever, I am still a little confused about what the prog does. Note that I am not an ASIC guru. Here are my questions: * Where does your tool fit into the flow? After gschem but before gnetlist? If so, how is hierarchy determined from the .sch files? Or is it bolted onto the side of gschem? In that case, is hierarchy info also stored into the .sch files? Or is it an extension of gnetlist? If so, how can one use it to view hierarchy? * What does the UI look like? Is it an add-on to gschem which enhances your ability to follow nets through hierarchy? Or is the UI something totally different? * As for DRC capability, what are the desired errors to search for? Carlos's has most of the biggies, it seem to me. (Again, I am not an ASIC guru, so I may be missing something important.) > To make a long story shorter, I think it's a bad idea to ever loose=20 > hierarchy info. The hier class keeps track of the original structure,=20 > even if we've flattened a design. So my question is then: how to hold hierarchy info when you export the design as sch + .sym files? Should it just be a FILE= attribute in a .sym file pointing to the lower level schematic block? Or is there something more to it than that? Thanks, Stuart
