On Thursday 04 November 2004 09:05 am, Tom Hawkins wrote: > Actually, I am no longer considering XML. �A custom ASCII > format works much better. �But not EDIF/VHDL/Verilog. �These > formats are overly complex, and yet ironically, they still > can not convey some netlist aspects that are important.
They are overly complex only because they contain features that you don't use. If you really want it to be a standard interchange format, it must have those features. You need to be able to translate from "that format" to "your format" and back again without loss. Under "that format" I am obviously including the above three. Now add MAST, Spectre, ADS (HP), CAZM, IBIS, and the many incompatible SPICE formats. After serving on a Verilog committee, and looking at the available formats, I believe VHDL comes closest to being the best format. The reason is that there are fewer important missing features, and it leads to a more reasonable extension mechanism. There is nothing stopping the Verilog committee from adding the very important separate "entity" "architecture" feature, but they don't seem to be going that way. Aesthetically, I like Verilog better. I would like it even better if it used curlys instead of begin-end. When I say "without loss" I mean exactly that. It might be easy to interpret that as "without significant loss", but that isn't good enough. For example: resistor #(.r=1k) r1 (a b), r2(c d); is not the same as: resistor #(.r=1k) r1 (a b); resistor #(.r=1k) r2 (c d); I would love it if the free tools could standardize on one format, so simulation, schematic, layout, and synthesis could all use the same format. I see it as being so close, yet so far. It is so close if we take an existing format and add extensions. It is so far if we try to invent something new. Considering everything else, ugly syntax is not a factor. My recommendation is to start with VHDL, and add new top level keywords to introduce blocks containing layout and schematic information. If we take this approach, it is not necessary for any tool to support the whole language, provided that it doesn't barf on the portions it doesn't use. For example, a layout program could ignore behavioral information, and a simulator could ignore schematic drawing information. The simple free simulators that we have now could ignore layout information, but having it in the format opens the way to use it eventually. > formats are overly complex, and yet ironically, they still > can not convey some netlist aspects that are important. So what are those netlist aspects that are important that they cannot convey? Does my suggestion of the new top level keywords solve the problem? If we take the approach of extending a standard format, I suggest that when it works we propose the extensions to the standards committee.
