SySiDoc.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:05:51 pm PDT
SySi
SySi
SySi
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
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 "Bus Oracle" (what's it's name)?
Probably 1/2 JMF/months.
Write Bus Oracles for the machine (e.g. PBus).
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.
2. Instructions for the designers
1. What to Provide?
A df file with the right name: chip.df. The right names are: Bic, IOBridge, SmallCache, ArbBasic25, MemoryController, DisplayController.
A file named chip.dale containing a chip.icon 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.
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 should 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!)
Its going to be enough of a mess. Everything should lie in the same directory!
Invoke BringSystem, possibly BringDATools, and then MakeSystem.
3. 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. Wisdom from having spend months Extracting/Simulating the EU/IFU
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.
It is going to be important as soon as some cycles will start being done that the System Simulation can be done on different machines.
Appendix
SSS = System Simulation Shepherd