How L2I got started
I'll be honest. After using logic simulators for a number of years I wanted to write one. This was in the days before VHDL was popular and I thought I could do better. Well it seems that many Engineers have one logic simulator in them!
Many logic simulators back in the mid eighties had a number annoying features to the regular user. These were:
-
Test vector generation languages were generally rather poor with limited looping and parameterized hierarchy. Since generating simulation stimulation sequences generally took as long or longer than constructing the design itself. what was needed was something with the full power of a regular programming language.
-
The process of compiling the test (or simulation stimulus) input was usually quite separate from the simulation run in a way which meant that very few simulators allowed the simulation stimulus to be conditional to the state of the circuit. In practice this meant the poor user had to work out by trial and error
that, say, the circuit needed 1247.5 clocks to get it into a good state for the next test. This problem was often the single most time consuming element in a design. What was needed was the capability to say "clock until state xyz" where xyz was an internal circuit condition.
-
While ASIC houses usually recommended simulators and documented what to do release a design to them the cacophony of requirements and multitude of simulator options usually meant that customers design data bases had to be reworked before they could be used. Often the most trivial details required long simulation re-runs
and re-submissions. What was needed was a way to electronically check the final release simulation to make sure everything was unambiguously in place.
-
Simulators were not portable. Often only one computing environment was supported. What was needed was something very easy to port. It would need to be practical on a small PC with DOS as well as a UNIX platform.
-
Performance was often painfully slow and due to some quite simple problems. These usually included some combination of the following:
-
Inability to control modeling detail easily.
-
Inability to dynamically turn off trace output when it was not needed causing much unnecessary file IO.
-
Large compiled design data bases which caused frequent page faults. Some simulators required more than 5KB per gate instance!
At the time I was design center manager for ES2 in London. We were struggling to process and ship several customer designs per week. If the format and content of the designs could be fixed it would be possible to fully automate the back end data processing.
Just for fun I wrote L2I (Low Level Interface) in my spare time to try and resolve all these issues. It was called Low Level Interface because it did not contain a schematic entry package. The idea was that it would be free to all users and stimulate design business for the company.
How did L2I work out?
A Sun and PC version of the tool ran well. The Sun version was used on a design with a very large number of clocks which would have been impractical on our other simulators. The L2I manual was in reasonable shape:
The company however, which was gaining substantial revenue from software sales, decided not to distribute it. In retrospect this was clearly the right thing to do.
Some of the concepts in L2I lived on. ES2's "Solo" design tools were adapted to have a release mode to regularize design releases. Automatic data processing was developed in the design centers. They also beefed up the simulation stimulus language to give it many of the capabilities of L2I.
Later (much later) L2I was revamped into "CHDL" by Matt Campbell and myself. This expanded the basic concept into a mixed mode simulator and was embedded in C++ rather than Pascal. It is still in use by Obsidian Technology today.
Finally, I had a lot of fun writing it!
Page created by: rh@ot1.com
Changes last made on: 02/08/06
HomePage