Functional Simulation and Modelling

PDF Print E-mail
Written by Graham Stoney   

Most of my engineering experience has been working in hardware/software co-design environments where the big-picture team goal is to design one or more different systems, while sub teams design the hardware (often including one or more ASICs integrating much of the functionality) and software.

I'm so big on simulation and modelling, that one company gave me some modelling clay as a leaving gift with a label saying To be used for System Modelling. But seriously, high-level simulation and modelling can save valuable time at integration, especially if you're building a complex system with multiple components and/or ASICs. If you're designing a complex system including a component such as an ASIC, I recommend building a functional non-timing-accurate model in a high-level language like C or C++, using a tool kit like Open System C.

You may wonder what the point is of building a functional simulation that's not timing accurate when chances are you're doing most of your ASIC design in VHDL, and why you would want to use a language like C or C++ when VHDL is already capable of algorithmic or functional modelling. The answer is that there are a number of advantages to using this approach:

  • Focusing on functional aspects and ignoring timing allows you to build a simpler model, which is available earlier in the development cycle.

  • Using a traditional software-oriented language makes your model available to a much wider audience. Simulating VHDL usually requires software licences that are only available to the ASIC development team, which drastically reduces the benefits of functional modelling in a co-design environment.

  • With a little forward planning involving some design-for-testability ideas, the functional model can be integrated into the software application long before the actual ASIC is available. This allows integration testing and integration problems to be tackled much earlier in the development cycle.

  • The functional model provides an independent reference against which to compare the ASIC design.

  • If designed with appropriate instrumentation hooks, the functional model can be used to generate functional test vectors. When integrated with the software application, the resulting test vectors represent real-world functional tests, rather than just the ASIC developer's best guesses at what the application will actually do.

One of the most successful System+ASIC projects that I worked on used this approach, and it worked brilliantly. We were able to debug and integrate the application software with the functional ASIC model weeks before the actual chip arrived. All the integration testing was done before fabrication, which also meant the architecture was thoroughly validated. When the chip was finally available, all I had to do was recompile with the appropriate driver and had software module tests for major functionality running the afternoon I got the chip on a board.

The effort involved in building a separate functional model of a chip is non-trivial, so it needs to be factored into the schedule and resourced appropriately with engineers familiar with both software engineering and ASIC design. Ultimately the goal is to reduce overall system development effort by eliminating extra tape-outs and avoiding the nightmare-ish integration problems often associated with complex System+ASIC co-developments.



Social Bookmark this page:Reddit! Del.icio.us! Google! Live! Facebook! StumbleUpon! Spurl! Yahoo! Ask!
 

Add your comment

Your name:
Your email:
Subject:
Comment:

Sponsored Links