why exhaustive sim

You can get the idea from the size of this process that exhaustive sim is not
a simple job. It's not simple. The process it replaces wasn't simple, either.

What did you always have to do to test your software?
1. Isolate your system.
2. Write a driver.
3. Write test scripts that exercise your requirements.

What do you have when you are done? Very minimal coverage.

You may have covered your requirements, but the work required to cover every 
line of code is excessive. Exhaustive sim is meant to quickly and easily
cover every line of code in a variety of scenarios. 

But...The initial work still must be done:
1. Isolate your system.
   You must cut your block from the system. One or two clicks in SDL88 mode is
   all the work required. Assuming the data has been correctly located,
   there will be no errors.
2. Write a driver.
   Your generated test environment is completely stupid. It will send out any
   signal in any order at any time. You may choose to make your generated test 
   environment smarter to avoid time-wasting unlikely scenarios. This is by no
   means necessary. The dumber your environment is, the more rigorous it is.
3. Write test scripts that exercise your requirements.
   Exhaustive sim does require a Target MSC if you want to save Success cases.
   You can run Exhaustive sim without a Target MSC, but it will only seek out
   cases that actually break the simulation. 

The idea is to Exhaustively sim with a Target MSC and generate many success
scenarios. When done carefully, the scenarios will demonstrate every way to
mimic the results of the Target MSC. Care must be taken in the design of the
test environment FSM, and when setting the Exhaustive sim options.

Exaustive sim is meant for blocks that have already been debugged to the
best of the engineer's ability. Exhaustive sim is not a shortcut for the
debugging process. It is meant to quickly generate a large number of MSCs
(that can be used as test scripts), and guarantee a high level of coverage.

how to exhaustively sim

1. Each person will cut their FA from a larger model by selecting their block
   (using the SDL88 Framwork Tool) and then Tools..Generate..Test Environment.
   This will delete all other blocks in the System and create a Test Environment
   block. All your signals will connect to it. Save your new system locally.

2. Select Tools..SDL & MSC Simulator. This will bring up the Launcher Tool.

3. Select Build..Build. Fix any errors. Dos command: gsmcomp model

4. Select Build..Execute. This will bring up the Simulator Tool.
   Dos command: geodesim model -b (the -b blocks the GUI from appearing).

5. Startup all the processes by firing each available start signal until 
   they are all in the WAIT state.

6. Select File..Scenario..Save As..and save this scenario. This is your 
   model_init scenario. This will get Sourced in the next step, and will get 
   called every time the Simulator Tool starts up. It can be more complex.
   If you select Execute..Init the Simulator Tool is returned to its initial
   state, which means you will need to manually Source this file by typing
   'Source model_init.scn' in the Command Line Box of the Simulator Tool.
   A larger model_init scenario will limit the scale of the exhaustive sim,
   thus making the exhaustive simulation faster but reducing the number of 
   scenarios explored.

7. One time only: Create a file called model.startup. Include the line
   'Source model_init.scn'.

8. Hit the Start MSC button and step through your model as in your scenario.
   The Framework Tool will display the MSC as you create it. 

9. Quit the Simulator Tool. Close the Launcher Tool. Dos command: quit
   Close the Launcher Tool. From the framework view, name and Save the MSC. 
   This is your Success MSC.

10.Delete several signals to create your Target MSC. Name it and Save it.
   Your Target MSC is the target of the exhaustive sim. Any scenario that
   contains every signal in your Target MSC will be saved as a Success Scenario
   in a file named model.target.s1.scn (or something like that). The more 
   signals you erase from the success MSC to get to the target MSC, the more 
   �freedom� you give the simulator in �filling the blanks�.

11.Select your Target MSC. Edit..MSC Simulation Properties. 
   Set Goal radio button to Search (Search ignores unexpected signals).
   Set Time radio button to Global.

12.Select Tools..SDL & MSC Simulator to bring up the Launcher Tool.
   Dos command: gsmcomp model -msc target

13. You should have your model and your Target MSC loaded into the Launcher.
    Select Build..Build. There should be no errors.
    Select Build..Execute to get the Simulator Tool.
    Dos command: geodesim model.

14.Execute..Verify..
   Leave the Mode radio button on Breadth.
   Uncheck Cut on error. Uncheck Cut on success. Set the Success limit.
   (typically 100 to 1000 based on how many test cases you want). 
   Set the �halt� check box (means the exhaustive simulation stops when 
   the 100/1000 successes have been found). Click on the Verify Button. 
   Begin. BATCH command (or Command Line): verify

15.The Simulator Tool upper textbox will list all the options set for this
   exhaustive simulation. All these options can be changed in the 
   Command Line Box of the Simulator Tool.
   The simulation may be running for a long time. You can observe the 
   creation of success scenarios using the Windows Explorer (files with names
   model.target.s*.scn). If you look at the Task manager, you should see the 
   simulator consume most of the resources of the computer (95%+). While the 
   simulator works, it will also create a trace in the trace window, for
   example: 8192 states, 20400 transitions, 12 depth, 1454 breadth.
   When the Simulator Tool displays additional information such as:
   Number of states, Number of errors, Number of success.. It is done.

16.Look at the SCN files produced, and check the date and time. The files
   just created should be converted into MSCs. Load the scenario, hit the
   Start MSC button and then Redo ALL. Name it and Save it.   
   Dos commands (or Command Line):
   define msc_fly true
   init
   source filename.x10.scn
   msc x10
   This will create a file called x10.msc and load it into the Framework Tool.
   Note this MSC should match the target MSC (just be more complete).

NOTES

Each scenario will start with the model_init scenario.
A Success Scenario is one that starts with the model_init scenario and includes
every other signal in the Target MSC (in the same order as well). There may be
other signals mixed in, but every Target signal must be there to be a Success.
A Exception Scenario starts with the model_init scenario and ends with an
some sort of exception: division by 0, array out of bound, send to multiple or
nonexistent receiver. To fix this, the Test Environment FSM can be made smarter,
so that it will reply with a certain signal rather than any signal, or you can
fix your FSM to handle/ignore the exception condition.

The 'Try Exhaustive' button is used to find queueing problems. If a process is 
hogging all the CPU time, certain queues will build up. Limiting queue size can
solve the problem for simulation purposes. 'Try Exhaustive' uses Depth Mode and 
Depth Mode produces some very convoluted scenarios, so it should not be used for
exhaustive sim. A better way to determine queue sizes would be to create a watch
on length(queue) and observe how they grow in Random Sim.

The file geodesm.startup is found in VERILOG\OG_SDL\examples\geode_sm\. This file
contains lots of useful aliases and commands that can be used in the Command Line.
If this file is kept in your default directory, it will get called when the 
Simulator Tool starts up.

The file geodesim.but is found in VERILOG\OG_SDL\lib\geode_sm\. This file defines
the scripts that are invoked when a Simulator Tool button is clicked. You can keep
a copy in your default directory to change the behavior of the buttons.

View..Hierarchy will open the Hierarchy Browser. CLick on the + symbols to reveal
all the processes. You can see how much coverage the exhaustive sim has obtained. 
The COV button will show all the states and transitions not yet covered.
The state-shaped button will cause all states to be displayed, along with how many
times it has been covered. The transition-shaped button will cause all transitions
to be displayed, along with how many times it has been covered. The Basic Blocks
button will open up a floating window with various selections that will display
more detailed block coverage rates in the Simulator Tool upper textbox.