Just my .02$ Viktor Pracht: >> We can do the same thing. Some of our stuff is >> metadata, and when the metadata is missing (for instance from an >> import of existing code), then we just default to something sensible. >> Lots of our stuff is auto-generated code that describes the >> interconnects between modules. The most important part of this, to >> me, is the interconnecting glue modules that tie other blocks >> together, because this is the place where I make the most mistakes. > >All semantically relevant data will be stored as Verilog code. This is an >important difference between our case and a GUI editor: the 2D layout of >the schematic is thrown away for synthesis, while the layout of a GUI is >one of the most important parts.
Now, why do we want to lock the IDE down to a specific language such as Verilog? To me it makes much more sense if the IDE could operate on a higher level with modules and signals between them. This concept would be extended to VHDL as well. As for input we write parser libs for the languages we want that converts to a internally used hardware model. Whenever we want to serialise the model into either a Verilog or VHDL file we just convert the model. Important to remember that the goal of HIDE is not a drag and drop Verilog editor, but an efficient way of connecting modules together. If you want to edit the behaviour of a single module. -- Life on the earth might be expensive, but it includes an annual free trip around the sun. Kenneth Østby http://langly.org _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
