Everyone is always looking for this elusive link from high-level conceptual design to implementation. Also, what is high-level and what is implementation also depends on the team charter. Is it a functional model or timing or a power model? Is the implementation in RTL (Verilog or VHDL) or C, C++ or Java for software? Or is it something more exotic or precise such as Assembly programming or Ada?
There are so many interfaces, tools and approaches proposed. All of them provide a tool-based solution as opposed to a design flow integration. Having been involved in a number of discussions with CAD teams, I feel that there is no single solution. It is really a combination of multiple approaches. Each one solves one part of the design problem. I have listed below the three main solutions. We at Mirabilis Design do provide these solutions as part of our integrated flow.
- The first is the specification document. This is the absolute first level. The design team needs to know what to build. When issues are found during implementation, you can always go back to refer to this. If it is a Word or Framemaker document, then changes are hard to prove. If it is a model which can be easily understood by all and modified using parameters, then validation becomes quicker. The solution is even more powerful when the implementation does not need to download a new software to modify and run these models. Think about the case where these models are embedded in the document. Check this one out- https://www.mirabilisdesign.com/Pages/Demonstrations/performance/analyticalcache/mdi_highpercom_analyticalcache.htm. Think of the possibilities.
2. Generation of test patterns. VCD or another incarnation is something the RTL tools and their users understand very clearly. Generating the specification in this format aids knowledge transfer. The data can be used to generate stimulus or can be used to create the verification test bench. For every verification piece for hardware, an associated software piece is also required. This can be for functionality, power or real-time embedded testing. The golden system model provides the means to test the output. You can generate the expected output to see if they match. If they do not, it provides a opportunity to identify the reason and update either the implementation or the system model.
3. Importing RTL and C code. When you have portions of the code completed, there are really no test systems developed. These blocks can be imported into VisualSim using our graphical wizards. They can replace the matching block in the System model. There is some effort in generating the translation protocol to go between the system model and the RTL/C code. But, it can be simplified in many ways.