Mon Nov 4 12:59:00 GMT 2002
Fundamental changes in the compile and link step for
building simulation tools would significantly improve
modeling and design of whole systems. This note explores
that idea briefly.
Flaws in available tools for simulation of systems limit
the usefulness of simulation methodologies in system
design. I write this to explore interest in simulation
tool methodologies. In recent times, my energies
focused on IC design and verification. My work has more
than once led to simulation of multiple, large ICs in a
single simulation context. Uniformly, the multiple IC
simulation problem is greatly exasperated by limitations
in current tools. I want to encourage development on
tool issues that could greatly expand the role
simulation of multiple ICs plays in system design.
Significant progress in this area ought to improve
modeling and design of whole systems.
Typically, a simulation model of a large IC is developed
by a team of designers over a 6-12 month period.
Multiple ICs developed by a variety of teams inevitably
lead to models that overlap in their usage of names for
objects. In all my past attempts, building a single
simulation of multiple IC models could only be achieved
by absolute elimination of overlapping name usage. That
is, each model had to be rewritten by renaming objects
to force uniqueness of names. Touching IC models to
fix tool limitations is a fundamentally flawed approach
to the multiple IC modeling problem. Once a model has
been certified by a design team for fabrication of a
device, any touching of the model destroys its
integrity. What, then, are the tool changes needed?
Although there are numerous tools associated with this
area, my looking at tools leads beyond the primary tools
to system tools used for building the primary tools.
What I see as limiting simulations in a fundamental way
is the compiling and linking step (e.g., gcc). The
compiler should support linking of independently
developed modules with their extern name spaces
referenced to libraries that differ with each module.
Currently, gcc allocates some priority sequence for
searching libraries to resolve names and the first one
that matches gets used. Tagging module object files with
library search sequence information seems like one way
to fix the problem of multiple name spaces. It is
possible that this is not fixable by merely a change in
the compile/link tool and that some kernel changes need
to accompany the change in the compile/link tool.
I am not an expert in designing compilers, but my usage
of them convinces me that flaws in available compilers
prevent important design methodologies from emerging.
If you who maintain gcc find this idea interesting,
please contact me for additional discussion.
More information about the Gcc-bugs