home | products | downloads | support | online store | about us | search

 

Home
 

     

Products
 Online store
Universities
Search
About us
White paper


Download Latest
Software

Product Comparison


Build Notes
Enhancements


Support
Simili FAQ
Contact us
Report a bug


Known problems and solutions


Resources/Links

 

 

 

 

 


 

   

This white paper provides a brief glimpse into issues in digital Hardware Description Language (HDL) simulation techniques at a very basic level and discuss their merits. This paper will also talk about technology choices made within VHDL Simili. The paper is organized as follows

Overview:

Most digital logic simulators are composed of two major units. These are the "kernel" and the "execution" units. There is also a dependency on a third unit which is the "compiler" that compiles HDL models into a format that allows the "kernel" and the "execution" unit to actually make use of the model. The compiler can be viewed simply as a translator and will not be discussed much in this paper (we will just assume that a compiler exists).

Kernel:

The "kernel" is responsible for managing and scheduling the various simulation events. For example, if a signal is assigned a new value with a delay, usually, it becomes the responsibility of the kernel to update the value at the proper time, and if as a result of the update, additional tasks need to be performed, these tasks shall be triggered.

Execution unit:

The "execution" unit is responsible for simply executing tasks (when directed by the kernel). As a result of execution of tasks, events may be scheduled with the "kernel". A typical example of this is the execution of a VHDL process. The compiled version of the VHDL process is executed and as a result new values may be scheduled on to the drivers of the signals being assigned in the process.

The technologies involved in the design and construction are very diverse. We can classify the technologies into three broad categories.

  1. Interpreted
  2. Translation compiled
  3. Direct compiled

An "Interpreted" simulator consists of an interpreting engine that interprets bits and pieces of the language as it encounters them.  Essentially, the interpreter is making decisions such as  "if the next statement is an if statement, then do ...". However, interpreters do not have to be as naive as the previous example indicates. Depending on the technology used in performing interpretation, interpretation can be as fast as the other two methods outlines (although very difficult to achieve). The ZEOS technology we have invented is proof of that.

"Translation compiled" technologies involved translating the HDL Code into a host language (which is usually C/C++). This translated HDL code is then compiled into machine language using a compiler that is built for the host language. This has the potential to create the fastest "execution units". The VHDL compiler essentially takes full advantage of all the machine level optimizations built into the host compiler (which are usually very mature). However, this method also has certain disadvantages. There is a reliance on an external C/C++ compiler (involving licensing issues, portability, the limitations of the host compiler, etc.), debugging is made more difficult, and compile times are usually very large compared to other methods. Also, designed badly, this may not produce a very fast execution unit.

"Direct compiled" technology seems to be the most popular technology today. Simulators using this technology translate HDL code directly to machine instructions of the host CPU. This technology overcomes some of the disadvantages of the "translation compiled" method. In theory this method should provide the "best of all worlds" -- fast compile time, very fast execution, good debugging capabilities, etc. However, as evidenced by most commercial products released using this technology, they tend to do slightly better (or sometimes worse) than well designed "interpreted" compilers. The main reason is that most vendors' HDL compilers have not yet attained the maturity of a typical C/C++ compiler in being able to take advantage of machine instructions. In the long run though, this method should produce the best results (as the code generation smarts improve in the tool).

Event vs. Cycle Based:

Coupled with the design of the "kernel" and the "execution unit", there is also a variation in how, what and when something gets simulated. There are two broad categories -- "Event Driven" and "Cycle Based" -- with possible hybrids. An event driven simulator typically tends to be faithful to the semantics set forth by the HDL. Essentially, at every time unit, the "kernel" de-queues any events that are due at that time unit which in turn trigger actions for the "execution" unit which in turn may schedule new events with the "kernel". This cycle continues until there is nothing more to do at the current time -- in practice, it is not unusual to see hundreds of such iterations at a given simulation time. The kernel then advances time to the next simulation time (or to the next earliest scheduled event). Typical event driven simulators also place little or no restriction on what language constructs are legal making them very versatile.

The other variety is "Cycle Based" which analyzes the HDL design and partitions the design into synchronous and asynchronous tasks. A majority of the hardware described within the HDL design tends to be synchronous to just a few signals (for example clocks, enables, etc.). The idea behind cycle-based-simulation is to reduce the number of iterations a typical event-driven-simulator goes through to arrive at the final values at the outputs. This is achieved by evaluating all tasks only on the event boundaries. For example the entire circuit that is dependent on a given clock domain only needs to be executed (in the proper order) once for most designs. Done properly, this can result in huge performance gains (in the order of 10 to 100x). However, this is not without its flaws. A typical cycle-based-simulator places a very large set of restrictions on the coding style and restricts the set of language constructs that are legal for it (but, this is also true of HDL synthesis tools). A second disadvantage is that you cannot perform timing simulation without resorting to an event-driven simulator, or using a static timing analysis tool in conjunction with a cycle-based-simulator. Even though, a cycle-based-simulator strives to achieve the same effective results as an event-driven simulator, sometimes this is not the case. So, most people who use cycle-based-simulators, also end up using an event-driven simulation to ensure that the results are the same. Cycle-based simulation is a boon for very very large simulations which could easily take months to simulate using even the fastest event driven simulator.

VHDL Simili introduces ZEOS technology:

VHDL Simili is an event-driven simulator with a high performance interpreted execution unit. For Symphony EDA, VHDL Simili is a launching pad for other yet to be announced technologies. We have developed a unique language interpretation technology called ZEOS (acronym for ZEro Overhead Stack). This technology overcomes many of the problems with typical interpreted-style simulators by making interpretation extremely fast while preserving all the benefits of an interpreter (flexibility, processor independence, etc.). The ZEOS technology achieves performance results that rival (or even beat) direct-compiled simulators. We cannot go into the details of this technology as of yet. We will publish another white paper on this topic sometime in the future. We will leave the performance of the tool as a testimonial of the technology.

So, why did we chose an interpreted style when the direct-compiled technology has some obvious performance advantages? First, we believed that we could achieve similar performance with a really good interpreted technology. Second, we did not believe that using a direct-compiled technology is the miracle-solution needed to improve performance. Other simulator vendors' experience may differ from ours but our experience has shown that for most large simulations, the kernel is the bottleneck in performance. We have seen the "kernel" consume up to 80% of the total runtime on some large simulations. Since such a disproportionate amount of time is spent in the simulation kernel, the overall simulation speed will improve only slightly by removing the disadvantages of interpreted execution unit. Also, since most commonly used packages have already been accelerated with special care, the advantage gained by going direct compiled is diminished on most designs.

Our plans for this simulator include going "Direct-Compiled" in the not so distant future but we believe that we have to make strides in the "kernel" technology first. Even though the "kernel" technology is very competitive with other commercial VHDL simulators, we think that this can be vastly improved upon. We also believe that this is a natural evolution of a VHDL simulator (from our point of view).

Additional reading:

Use the following links get more information

 

Send mail to webmaster@symphonyeda.com with questions or comments about this web site.
Copyright 1999-2010 Symphony EDA