SSDoc.tioga
Copyright Ó 1987 by Xerox Corporation. All rights reserved.
Created by Bertrand Serlet September 29, 1987 10:21:51 pm PDT
Bertrand Serlet September 29, 1987 11:54:33 pm PDT
Jean Gastinel September 30, 1987 4:32:06 pm PDT
SS
SS
SS
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
System Simulation
Abstract: This document describes how the System Simulation is going to work.
Keywords: System Simulation, Dragon
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304



Dragon Project - For Internal Xerox Use Only
1. To Do List
Remove all references to explicit directories in Generation programs.
BIC.df should be renamed something like BIC1.df, and BIC2.df should be called BIC.df!
DisplayController.df should be the name used for the display controller.
Work on the PortModel?
Write PortModels for the machine (e.g. PBus).
Probably ~2/6 man/weeks.
Someone has to write a tool that captures vectors so that when the system simulation crashes, the test vectors of the faulty chip(s) can be given as input for the relevant designer(s).
Probably 1/2 man/weeks.
Provide the Chips!
2. Instructions for the designers
1. Provide a df File
FOR chip IN [BIC2, IOBridge, SmallCache, ArbBasic25, MemoryController, DisplayController]:
A df file named chip.df containing :
1- A file containing a icon containing the whole chip, pads included. This icon might point to code (when there is a top-level eval proc) or to the real chip. The smaller the .dale file, the better. The smaller the amount of schematics to extract, the better.
2 -An install file named chip.install that installs just the .bcds necessary for simulation and the minimal portion of the design aids they require. Not install of DAUSer, please.
2. Changes in the design
When the design reaches a stable point where it is worth having the System Simulation updated, a .core file might be generated; the df file should be SModelled and Verified; finally the SSS should be warned of its existence.
3. Changes in the file names
They should not happen.
3. Instructions for the SSS
1. Installing System Simulation in a new directory (or machine!)
Everything should lie in the same directory !
Invoke Bringover SS.df, BringSystem, possibly BringDATools, and then MakeSystem.
2. Tracking Changes
in Cedar: When Cedar changes sufficiently BringEnvironment (or QBE) should be invoked. Then BringDATools and MakeSystem.
in DATools: Invoke BringDATools then MakeSystem.
in Chips: Bringover of that Chip, then MakeSystem. Should only be done when the chip is in a coherent way!
4. Bits of Wisdom from having spend months Extracting/Simulating the EU/IFU
One of the most important things is to be able to do System Simulation on different directories/machines. The reasons are multiple:
It is a good idea to block a machine for System Simulation other than a personal Dorado. Personal Dorado are required to read the mail, program, makedo, and a thousand other things. With a simulation running, you can't rollback, gfi's are a problem, the machine is sluggish, and worst of all viewers locking happens frequently ...
If there is somewhere a reference version that simulates, and if the current version does not simulate, it might be useful to go back to the reference version and compare results or files.
The SSS responsability will have to be shared between several people.
Using several machines in parallel greatly accelerates the whole process.
Several people (ultimately all designers) will have to do system simulation.
When starting an overnight task, it is worth spending 10 minutes watching the beginning of the RollBackAnd to see if everything starts properly.
Keep a log of errors of changes, errors and fixes.
Appendix
SSS = System Simulation Shepherd