If you don't simulate it, it won't work.
And if you only simulate part of it, the part you don't simulate will be the part that doesn't work.
We have learned this lesson time and time again; it keeps proving itself. Design tools have evolved to the point were you can easily design something with a level of complexity that exceeds your ability to comprehend. The natural alternative is to breadboard, or prototype. However, we are in a competitive (sponsored research) environment where the costs, in time and money, for prototyping are prohibitive. We need to get it "right", or at least close enough, on the first try.
Our primary simulation language is Verilog, and our primary simulation environment is the VeriBest VBVLG package.
We also have an old copy of Cadence's Verilog, as well as various VHDL simulators, and at least one version of SPICE available for analog simulation. Further, we have Modsim-II, a rather clean object-oriented simulation language. And various other odd bits. Talk to Mike if you want to do something odd.
The balance of this section addresses Verilog and VBVLG-based simulation.
Where do Verilog models come from? The undisputed best place to get models is from the silicon manufacturers themselves, who provide the models for free as an incentive for you to use their parts.
Did you buy that? If so, I have some swamp-land in Florida to sell you... The "undisputed" part is actually true. I have never met a user that did not agree that models should come from the manufacturers, and that they should be free. Everyone believes that this is the way it should be, except for the manufacturers. If they have models, they are secret and you will never see them. Or, if you can get at them, the manufacturers want $$$ for them!
Analog models are a little easier to come by, but Verilog models are a very pricey commodity. There are third-party model makers, which typically sell *subscriptions* to their services. You don't actually get the models; you get to use them, for as long as you continue to pay. And you don't actually get to see inside the models (that's a secret!), so it is hard to tell whether your simulation is failing because of your design or their model. And worst of all, it costs $$$. This is the killer for us. Model makers are asking for a slice of your profit; that is why models are priced as they are. We *don't* make a profit! We don't sell a product! And thus we can rarely afford to buy into commercial models.
So where are you supposed to get models from? Walk down the hall, into the washroom, and look over the sink...
We are building up a collection of models, both as a consequence of a bit of Web-gathering, and as a result of in-house model writing. Most of the models are temporarily hiding in J:\cleo_lib\verilog_src. Make copies of what you need into your \hdl folder, and connect them to your simulation in the Top.sup file.
One of the folders that you will find in J:\cleo_lib\verilog_src is named "bad_verilog". These are a collection of models that were translated from a previous simulation package into Verilog. While there are a lot of models, many of them don't work. It is a very difficult judgment call as to what to do here. Use a model that may not work, and check it carefully, or make a model yourself that may also be wrong, or simply not simulate that part and incur the curse at the beginning of this section.
If you do find models in J:\cleo_lib\verilog_src that appear to be wrong (with the exception of the bad_verilog ones), please let Mike know, as he is trying to maintain a reasonable set.
You may find something out there that is fairly close to what you need. Don't be shy about leveraging off of an existing model to write your own. However, keep in mind that you are writing what you expect the device to do. You will also be studying your simulation, based on the same knowledge (or lack thereof). If you really want to make a decent model, you will need someone else to review it for you. And you can make that task a lot easier by building a testbench (next section).
How do you apply signals (stimulus) to drive a simulation? The superficial answer is to create another module and connect it to your design. The stimulus module then computes the what+when, and drives your module accordingly.
The down-side of a distinct stimulus module lies in defining what is the scope of the design with respect to fabrication. The design-part is what you want to build; the stimulus-part is simply an abstraction used to assist in the simulation.
We have been getting around this, and the fact that the VeriBest simulation package does not seem to provide a clean stimulus input mechanism (they are just more hdl models like everything else) by creating "smart connectors". Rather than simply creating dummy models for connectors, which by virtue of their nominal construction are little more than behavior-free metal and plastic, we have hidden our stimulus functions in the connector models. In cases where multiple connectors need to coordinate their activities, "common block" models have been created to hold the shared variables.
Mike can show you how to do this.
A special case in favor of explicit stimulus modules exists for testing models themselves. A well written model should also have a well written stimulus and testing module, or testbench, written to show off the functions of the model, and to allow other people to confirm that the model is doing what it should. Some of the models in J:\cleo_lib\verilog_src have testbenches; all should (someday). If you write a model, you should write a testbench for it.
At present, the only simulation-related documentation that we tend to maintain, in the design (2.2.5) 3 ring notebooks are screen plots of waveforms.4.6) layout