BASIC L2I DOCUMENTATION Version 0 Release 1
======================= ====================
This is a minimal set of user documentation for version 0 of the Low
Level Interface system. It is intended to provide those with a working
knowledge of simulator concepts to gain some experience with the system.
In is not the final documentation and no guarantee of consistency,
accuracy or completeness is implied.
This text has been reproduced via scan and OCR.
Robert Heaton
L2I v0rl Preliminary Page 0.1
CONTENTS
SUBJECT PAGE
Introduction. 0.4
The L2I embedded code language. 0.5
The L2I Simulator. 0.5
Installation on a SUN workstation. 0.6
Example L2I source files:
2 to 4 line decoder {exl.sim} 0.7
An example output for basic L2I 0.8
Divide by 16 counter {ex2.sim} 0.9
A fully releasable version of ex2 {ex3.sim} 0.10
L2I syntax 0.11
Release checks. 0.12
Design Flow. 0.13
User levels. 0.13
L2I source language elements:
Network definition:
DEFIN 1.1
DEFOUT 1.2
DEFIO 1.2
DEFINBUS 1.3
DEFOUTBUS 1.3
DEFIOBUS 1.3
NETSTART 1.4
NETEND 1.5
INST (I) 1.6
DEFMACRO 1.7
ENDMACRO 1.8
MACRO (M) 1.9
XREF 1.10
MODEL-OUT 1.11
Simulation:
TABLE 2.1
SET_SIGNALS (SS,SSS) 2.2
SIM 2.3
DEFVECTOR 2.4
SETVECTOR (SV) 2.5
SETBUS 2.6
CYCLE 2.9
TRACE 2.7
LIST_FANOUTS 2.6
SAVE_STATE 2.10
LOAD_STATE 2.11
OUTPUT ENABLE 2.12
GET_VALUE 2.13
SETARRAY 2.17
DELTA_TIME 2.14
LIST_UNTOGGLED 2.15
READ_NET_LOADS 2.16
HEXINT 2.17
L2I v0r1 Preliminary Page 0.2
Foundry definition:
PACKAGE 3.1
DEFPIN 3.5
DESIGNER 3.4
PHONE-NUMBER 3.2
ADDRESS 3.3
RELEASE 3.6
Base Library elements.
List of elements 4.1
Future features. 5.1
v0rl Preliminary page 0.3
Introduction
INTRODUCTION
The purpose of L2I is to provide a very low cost method of coding and
checking ASIC designs before they are passed to a vendor. L2I is not a
complete CAD package but it does represent a well defined interface
between vendor and customer. Both parties gain from L2I. The customer
gains because he has a low cost low risk path to develops ASIC without
having to make long term CAD decisions. He saves time and money on visits
to vendors because L2I enforces design standards. The vendor gains from
having access to a wide market and by having designs arrive in a standard
form suitable for automatic processing. L2I attempts to reduce the
interaction between ASIC vendors and customers.
L2I consists of an HDL compiler, a simple simulator, test pattern
description constructs, a library and a set of checking routines which are
highly portable and will be supported on a very wide range of platforms
from a PC up. It has been designed with the practical engineer very much
in mind in that a minimal, structured, and a well defined coding route is
supported. Links with a number of low cost schematic capture products are
planned.
The power and flexibility of most design systems can be a positive
disadvantage for good customer to vendor interface. Whereas a wide range
of design checking is available it is usually enforced only by convention
and features which are valuable during development may mask real design
quality problems when the design is released. L2I has a release mode which
attempts to overcome these difficulties placing higher emphasis on design
quality and integrity than on absolute timing accuracy.
Back annotated timing results are provided to the customer by the vendor
for sign off in the normal way but more importantly the vendors software
checks that annotating the timing has not changed the static
functionality. L2I attempts to ensure that this is unlikely to happen.
Most vendors do functional and IO DC parametric testing for samples and
small volume production. L2I in release mode enforces that test patterns
conform to this type of testing,
While L2I has no pretensions as an advanced design tool it does have some
features that are not always found on more expensive HDL / simulation
tools. Functional test patterns for example can be coded using the full
power of the Pascal language allowing while, repeat, for, and procedure
constructs to be utilized. This considerably reduces the tedium of test
sequence generation and can make the resulting code much more readable.
Reducing this effort is valuable because test sequence generation often
takes more effort than coding the netlist. The L2I test constructs are
based on TESTGEN; a mature test pattern language developed by Acorn
Computers Ltd.
Other features include simple behavioral modeling, parameterized macro
cells, and conditional simulation though these are not explored in this
document.
L2I v0rl Preliminary Page 0.4
Introduction
The L2I Embedded code Language
L2I uses a form of input language that has come to be known as embedded
code. In fact its not a language at all but merely a set of predefined and
documented procedures, functions, and variables that are available to the
user from an existing language. (in this case Pascal). As with all
techniques there are advantages and disadvantages. The disadvantage of
embedded code is that the new user may find the syntax a little more
difficult and the syntactic error messages a little more oblique. The
advantage is that the predefined code elements may be freely mixed with
the native language allowing a much increased flexibility over a
conventionally parsed input language.
The L2I system is set up to minimize the need to understand how the user
commands defined in this documentation interact internally. The user
simply writes an L2I source file and runs it. As much care as possible has
been taken to ensure that the source behaves just like a conventional
HDL/TDL source and entry of simple designs does not require knowledge of
the Pascal language. Extensive error checking is included in all L2I
elements and users are given simple, understandable explanations for
errors and inconsistencies. Advanced users on the other hand will have
sufficient interfaces to write certain types of extensions to the language
where this benefits their applications.
The use of embedded code has greatly simplified the implementation of L2I
and this is one of the reasons that it was used. However experience with a
number of other embedded code languages has convinced me that its an
extremely powerful technique for engineering applications generally. The
L2I language supports netlist, test, and foundry specification and so the
user can generally needs to submit just one file.
The L2I Simulator
Apart from using Pascal as an input language the built in simulator is a
fairly conventional event driven gate level simulator. A set of core
routines schedule events that call library models. A library model is
merely a Pascal procedure which has access to the net data base and can
schedule new events. The simulator data base is left very open to the
model writer and features like setup and hold checking, load dependent
delays, and other constructs can be built into models. A number of
special data base access procedures can be provided to library writers to
ease this process. External user Pascal procedures can be linked into the
simulator giving a limited behavioral capability.
The simulator is mainly targeted towards static pattern stimulus and the
full control and procedural power of the Pascal language can be used to
reduce the complexity of test pattern generation.
The v0 simulator lacks a number of features which planned for future
versions such as inertial simulation, and back annotation input. V0 models
do not have load dependent delays.
L2I v0r1 Preliminary Page 0.5
Installation
Sun Installation.
Sun installation can be on 1/2 inch tape or 1/4 inch cartridge. Both
packages come with a release instructions sheet. This is a very simple
installation for demonstration purposes. The release tape is in tar
format and contains files which are current directory relative. To install
the tape take the following actions:
1) Make a new directory using mkdir
2) od to the new directory
3) Type the tar command: "tar xvbf 126 /dev/rstO" for cartridge tape.
or: "tar xvbf 40 /dev/rmtO" for standard tape.
4) Check that the command search path includes the current directory.
5) The installation includes at least 2 examples source files exl.sim
and ex2.sim. Try the installation by typing: "l2i ex1"
NOTE1. L2I normally writes to standard output, Use output redirection to
write the output to a file, for example: "l2i exl >ex1.lst"
NOTE2. Setup requires the Sun PC Pascal compiler.
The release tape includes the following files:
FILE PURPOSE
sim.o The basic L2I object program.
l2i UNIX proc used to compile link and run L2I
userprocs.p Default file for user Pascal procedures.
tmp.sim
sim.h
simdec.h
exl.sim Example source files.
ex2.sim
ex3.sim
L21 v0rl Preliminary Page 0.6
Examples
EXAMPLE ONE: A very simple L2I netlist and simulation source file.
{ FILE: exl.sim 2 to 4 line decoder circuit with comments }
DEFIN(' sl, s0 ');
DEFOUT(' y3, y2, y1, y0'); { Define IO's }
NETSTART; { Start the netlist }
INST('il, inv1, s0, ns0'); { add the inverters to the netlist }
INST('i2, inv1, sl, nsl');
INST('i3, nand2, ns0, nsl, y0'); { add the nand gates to the netlist }
INST('i4, nand2, s0, nsl, y1');
INST('i5, nand2, ns0, sl, Y2');
INST('i6, nand2, s0, sl, y3');
NETEND; { End the netlist }
{ start simulating the netlist }
TABLE('$IOS'); { display the default inputs and outputs }
SIM; { try a sim with no inputs set }
SET_SIGNALS('sl,s0','00'); SIM; { simulate the 4 input combinations }
SS('sl,s0’,’01'); SIM;
SS('sl,s0','10'); SIM;
SS('s1,s0’,’11'); SIM;
End of 2 to 4 line decoder
L2I v0rl Preliminary Page 0.7
Examples
EXAMPLE OUTPUT IN NON-RELEASE MODE
Simulation output follows:
s s y y y y
1 0 3 2 1 0
0.0 u u u u u u
1004.5 0 0 1 1 1 0
2004.5 0 1 1 1 0 1
3004.5 1 0 1 0 1 1
4004.5 1 1 0 1 1 1
#### 5 gates, 8 nets.
#### L2I completed. (not in release mode)
L2I v0rl Preliminary Page 0.3
{EXAMPLE TWO. Divide by 16 counter}
{FILE: ex2.sim divide by 16 ripple counter}
DEFIN('ck ns nr');
DEFOUT('q3 q2 q1 q0'); {define top level IO's}
DEFMACRO('dff'); {start dff macro definition}
DEFIN('d,ck,ns,nr'); DEFOUT('q,nq'); {define macro IO's}
INST('gl,nand3,ns,x4,x2,xl'); {gates that make up the dff}
INST('g2,nand3,xl,nr,ck,x2');
INST('q3,nand3,x2,ck,x4,x3');
INST('q4,nand3,d,nr,x3,x4l);
INST('95,nand3,ns,x2,nq,q');
INST('96,nand3,x3,nr,q,nq');
ENDMACRO; {end the macro definition}
NETSTART; {start main netlist definition}
MACRO('ml,dff,nq0,ck,ns,nr,q0,nq0');
MACRO('m2,dff,nql,nq0,ns,nr,ql,nql');
MACRO('m3,dff,nq2,nql,ns,nr,q2,nq2');
MACRO('m4,dff,nq3,nq3,ns,nr,q3,nq3');
NETEND;
XREF; {generate a cross reference}
TABLE('$IOS');
writeln('clear test'); {a comment}
SET_SIGNALS('ck,ns,nr',' 010'); SIM; {set some sigs and sim}
SS('nr’,’1 '); SIM; {set nr to 1 and sim}
writeln('do some clocks'); {use writeln to comment}
for x := 1 to 35 do {do 35 clocks}
begin
SS('ck’,’1 '); SIM; {set ck high}
SS('ck',' 0'); SIM; {set ck low}
end;
L21 v0rl Preliminary
Examples
EXAMPLE THREE. Divide by 16 counter as a releasable design.
{ FILE: ex3.sim divide by 16 ripple counter }
DEFIN('ck ns nr'); DEFOUT('q3'); {define top level IO's}
RELEASE; {do release checks}
DEFMACRO('dff'); {start dff macro definition}
DEFIN('d,ck,ns,nr'); DEFOUT('q,nq'); {define macro IO's}
INST('gl,nand3,ns,x4,x2,xl'); {gates that make up the dff}
INST('g2,nand3,xl,nr,ck,x2');
INST('g3,nand3,x2,ck,x4,x3');
INST('g4,nand3,d,nr,x3,x4');
INST('g5,nand3,ns,x2,nq,q');
INST('g6,nand3,x3,nr,q,nq');
ENDMACRO; {end the macro definition}
NETSTART; {start main netlist definition}
INST('il,icn0,ck,ick'); {define IO cells}
INST('i2,icn0,ns,ins');
INST('i3,icn0,nr,inr');
INST('i4,ocn0,q3,iq3');
MACRO('ml,dff,nq0,ck,ns,nr,q0,nq0'); {instance the dff's}
MACRO('m2,dff,nql,nqO,ns,nr,ql,nql');
MACRO('m3,dff,nq2,nql,ns,nr,q2,nq2');
MACRO('m4,dff,nq3,nq3,ns,nr,q3,nq3');
NETEND;
TABLE('$IOS');
writeln('clear test'); {a comment}
SET_SIGNALS('ck,ns,nr',' 010 SIM; {set some sigs and sim}
SS('nr','l '); SIM; {set nr to 1 and sim}
writeln('do some clocks'); {use writeln to comment}
for x := 1 to 35 do {do 35 clocks}
begin
SS('ck','1 '); SIM; {set ck high}
SS('ck',' O'); SIM; {set ck low}
end;
{----------------------- Foundry data ----------------------------}
PACKAGE('PDIL14'); {a 14 pin package}
DEFPIN('ck',1); DEFPIN('nr',2); DEFPIN('ns',3); {assign pins}
DEFPIN('q3',5);
DEFPIN('VSS',4); DEFPIN('VDD',14);
DESIGNER('Robert Heaton'); {contact details}
PHONE-NUMBER('0344 525252');
ADDRESS('Mount Lane, Bracknell, BERKS');
L2I v0r1 Preliminary Page 0.10
Syntax
Parameter Syntax
L2I statements are mostly in the form of predefined Pascal procedures,
functions and variables and the L2I main source file has the same syntax
as you would expect to find in the main body of any Pascal program.
However, many L2I constructs have variables which are of type STRING.
Variables are defined in this way so that an arbitrary number of
parameters may be passed at one time. Thus although most of the syntax of
L2I is as Pascal some L2I constructs need further syntactic definition.
Object Definition
name_char 'A’..’Z' | 'a'..'z' | '0'..'9' | '$' | '_' | '.'
name 'a'..'z' | [name_char...]
sig_name name | $name {$ makes signal global}
inst_name name
macro_name name
sep any non name-char
vsep any non value-char
Sig_list sig_name [vsep [vsep] sig_list]
Typically used in statements like DEFIN to
specify a number of signal names. Non valid
name-chars are treated as separators.
Ex 'a,b,c'
'signal_one signal2'
value_char '0' | '1' | 'X' { H, L from vl }
value-list value-char [sep | value-char]
Most commonly used in the SS/SV statements the
value list is a list of valid value characters
L2I is only interested in valid chars so any non-
value-char is treated as a separator.
Ex '010101'
'1 111 000 1'
'1, 000, 1'
NOTE: The default string length is 80 characters and so value lists,
signals lists and fully qualified signals names must not be longer
than this.
Strings cannot be split between lines. This means for example that
all the signals in the DEFIN statement must appear on one line.
Generally where this would be a limitation statements can be
additive in effect and more than one statement can be used.
L2I v0rl Preliminary Page 0.11
Release checks
A number of design integrity/quality checks are performed by L2I. Many
are always done and cannot be turned off by the user because they
represent illegal input to the simulator or nonsensical circuits. In
release mode however checks are much more rigorous and include:
1) Netlist checks such as unconnected inputs, outputs on the same net.
2) Testability in the form of a minimum of toggled nodes.
3) Inertial simulation is turned off to expose bad circuit practice.
4) Foundry information is checked for presence and consistency.
Numbers of pins, positions and number of power pins eta.
5) Errors are generated for the presence of development only statements
like LOAD_STATE.
6) Simulation is checked to be static and within length limits.
7) Tester cycle time/pinout constraints
8) Check that all signals have been initialized.
9) Check that all top level IO's connect to valid IO cells and that
pins have been properly assigned.
L2I v0r1 Preliminary Page 0.12
Design Flow
The design flow used by L2I will normally be as follows:
1) Customer receives and installs tape or floppy.
2) Customer enters and checks main blocks of the design.
3) Customer completes design entry and functional test patterns and checks
the simulation results. After a good run in release mode the customer
can send the source data as a floppy or tape to the vendor.
4) Vendor loads and checks data. Version and release numbers of both the
code and library are checked for validity. The integrity of the data
allows for auto-quoting or auto error letter writing.
5) Vendor converts netlist and test sequence data into a form suitable for
auto layout and back annotated simulation. Vendor checks that
layout and back annotation has not changed function.
6) Back annotated simulation results are returned to the customer for sign
off. Later L2I will accept a timing annotation file.
User levels
Each command is given a user level so that users can easily see weather
individual commands are relevant. As users complete their first design
they gradually increase their user level. The levels are:
0: New users training on small non-hierarchical netlists.
1: Users working on small but practical hierarchical cells.
2: Users comfortable with simple netlist entry and simulation.
3: Users doing more advanced simulations.
4: Users developing whole designs and releasing.
5: Special features.
6: Users writing new model libraries.
7: Developers.
L2I v0r1 Preliminary Page 0.13
HomePage
Page created by: rh@rh1.org
Changes last made on: 02/08/06