nothing to do here
This commit is contained in:
parent
e5f9d55af1
commit
b5458a0152
|
@ -1,146 +0,0 @@
|
|||
.\" $Id: libpat.3,v 1.1 2002/03/08 13:51:02 fred Exp $
|
||||
.\" @(#)pat.2 106 Sep 30 1996 UPMC; Pirouz BAZARGAN SABET
|
||||
.TH LIBPAT 3 "October 1, 1997" "ASIM/LIP6" "cao\-vlsi reference manual"
|
||||
|
||||
.so man1/alc_origin.1
|
||||
.SH NAME
|
||||
.PP
|
||||
\fBPAT\fP \- Generic pattern data structure
|
||||
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBPAT\fP is a generic data structure supporting vlsi concepts.
|
||||
It allows representation of a sequence of simulation patterns in a data
|
||||
structure.
|
||||
|
||||
.PP
|
||||
The goal of \fBPAT\fP is to define an ad hoc single data structure (object),
|
||||
with well known fixed meaning for each concept manipulated in pattern
|
||||
description. So any tools that needs to access simulation patterns can be
|
||||
build upon it, using these structures.
|
||||
|
||||
.PP
|
||||
For each object (data structure), a set of functions has been defined in order
|
||||
to add, delete or access it. These functions are defined in a low\-level library
|
||||
\fIlibPat106.a\fP. Some other functions are higher level. They are defined in a
|
||||
high\-level library \fIlibPhl106.a\fP. There are also some parsers\-drivers.
|
||||
A parser reads a pattern description file in a given format and build up a
|
||||
complete \fBPAT\fP data base. A driver creates a text file in a given format
|
||||
from a \fBPAT\fP data base. A \fBpat\fP format parser\-driver is available
|
||||
in the \fIlibPpt106.a\fP library.
|
||||
|
||||
.PP
|
||||
Pattern description envolves the following notions (for further details see
|
||||
pat(5)):
|
||||
|
||||
.TP 20
|
||||
\fIinput\fP
|
||||
port controlled by the user
|
||||
.TP 20
|
||||
\fIoutput\fP
|
||||
signal or port observed by the user
|
||||
.TP 20
|
||||
\fIinitialization\fP
|
||||
forcing the value of a register
|
||||
.TP 20
|
||||
\fIpattern sequence\fP
|
||||
list of values to be forced on inputs or to be checked as the result of the
|
||||
simulation on outputs
|
||||
|
||||
.PP
|
||||
The input\-output list is represented by two data structures: \fIpagrp\fP
|
||||
contains informations relative to actual or virtual arraies and, \fIpaiol\fP
|
||||
represents a one\-bit input\-output. Both are simply chained lists. However,
|
||||
to make a more efficient access to \fIpaiol\fP structures, they are organized
|
||||
in a table. So, a \fIpaiol\fP can also be addressed using an offset.
|
||||
|
||||
.PP
|
||||
Another group of data structures is used to represent a pattern. \fIpaini\fP
|
||||
contains values to be forced into registers before processing the pattern.
|
||||
An event (a modification of value) on an input\-output is given by a
|
||||
\fIpaevt\fP structure. A third structure, \fIpapat\fP gathers all information
|
||||
concerning a pattern (including initializations \- \fIpaini\fP \- and events \-
|
||||
\fIpaevt\fP).
|
||||
|
||||
.PP
|
||||
A \fIpacom\fP is used to represent a comment.
|
||||
|
||||
.PP
|
||||
Finally, all these structures can be accessed through a unique structure,
|
||||
\fIpaseq\fP, designed to represent a complete sequence of simulation patterns.
|
||||
|
||||
.SH ORGANIZATION
|
||||
.PP
|
||||
In order to use \fBPAT\fP, concepts on use of libraries are needed. And, since
|
||||
these libraries are under development, the code is subject to change.
|
||||
|
||||
.PP
|
||||
To enable work, a static version of each library is always present for the
|
||||
user. Libraries and header files are suffixed by a number (the library's
|
||||
version). The programmer can prefer to work with an earlier version of a
|
||||
library rather than the most recent one. However, it is recommended to adapt
|
||||
softwares to libraries as soon as possible in order to spotlight potential
|
||||
compatibility problems before old libraries are removed.
|
||||
|
||||
.PP
|
||||
A \fImakefile\fP is necessary for all \fBPAT\fP applications.
|
||||
This is required because any soft must be easily recompilable, and knowing
|
||||
the needed libraries for a \fBPAT\fP based program is not an easy matter.
|
||||
It can't be achieved by an other way, so do use \fImakefile\fP.
|
||||
|
||||
.PP
|
||||
In terms of software organization, \fBPAT\fP is splitted into two libraries
|
||||
for the basic functions, a header file for structures and variable declarations
|
||||
and, up to now, one parser\-driver library for \fBpat\fP format.
|
||||
|
||||
.PP
|
||||
It is to be noticed that library's version number is incremented when, at least,
|
||||
one function composing the library has been modified. Therefore, \fBPAT\fP
|
||||
libraries may evolve independently form each other.
|
||||
|
||||
.PP
|
||||
Here follows the list of the libraries and their contents.
|
||||
|
||||
.TP 20
|
||||
libPat106.a:
|
||||
\fBpat_addpaseq, pat_addpagrp,\fP
|
||||
\fBpat_addpaiol, pat_addpapat,\fP
|
||||
\fBpat_addpaevt, pat_addpaini,\fP
|
||||
\fBpat_addpacom, pat_frepaini,\fP
|
||||
\fBpat_frepaiol, pat_frepacom,\fP
|
||||
\fBpat_frepapat, pat_frepaevt,\fP
|
||||
\fBpat_crtpaiol\fP
|
||||
|
||||
.TP 20
|
||||
libPhl106.a:
|
||||
\fBpat_debug, pat_getcount\fP
|
||||
|
||||
.TP 20
|
||||
libPpt106.a:
|
||||
\fBpat_lodpaseq, pat_savpaseq,\fP
|
||||
\fBpat_drvpat, pat_prspat\fP
|
||||
|
||||
.PP
|
||||
The libraries are organized in such a way that no cycle can appear through
|
||||
calls. It means that, if in a given library a function calls another function
|
||||
in another library, then none of the functions of this one does call any
|
||||
function that belongs to the first library.
|
||||
|
||||
.SH EXAMPLE
|
||||
.PP
|
||||
In order to use \fBPAT\fP libraries, one needs something like this in its
|
||||
\fImakefile\fP:
|
||||
|
||||
.RS
|
||||
HEADER = -I/labo/include
|
||||
.br
|
||||
LIB = -L/labo/lib -lPat106 -lPhl106 -lPpt106 -lMut315
|
||||
.RE
|
||||
|
||||
.SH SEE ALSO
|
||||
.PP
|
||||
mbk(1), pat(5)
|
||||
|
||||
|
||||
.so man1/alc_bug_report.1
|
||||
|
|
@ -1 +0,0 @@
|
|||
map f :%s/"m\(..\)...\.h"/"m\1.h"/g
|
Loading…
Reference in New Issue