PAT(5)

πŸ“¦ version 5.1.1, in fedora 43, fedora 44

🌈 PAT(5) β€” cao-vlsi reference manual

okay so bestie, welcome to PAT(5), page five of the cao-vlsi reference manual πŸ’– this one is all about the pattern description format and honestly? it's giving very organized, very main character. let's get into it.


πŸ¦‹ ORIGIN

so this software belongs to the ALLIANCE CAD SYSTEM, which was developed by the ASIM team at the LIP6 laboratory of UniversitΓ© Pierre et Marie CURIE, in Paris, France πŸ‡«πŸ‡·βœ¨ iconic behavior.


πŸ’– NAME

PAT β€” the Pattern description format πŸŽ€


✨ DESCRIPTION

so pat is a specific format used to describe simulation patterns, no cap. the whole point is that pat was designed to represent, indifferently, both the patterns you wanna simulate and the results of that simulation πŸ”₯. it offers the possibility of:

  • specifying the input list of the circuit: the signals to be controlled during the simulation by the user. for a circuit described in VHDL, these are considered as input:
    • external ports of the mode in.
    • guarded external ports of the mode inout (declared with the reserved word bus).
  • specifying the output list of the circuit: the signals to be observed during the simulation. for a circuit described in VHDL, these are considered as output:
    • external ports of the mode out (declared either with or without the reserved word bus).
    • external ports of the mode inout (declared either with or without the reserved word bus).
    • internal signals of a hierarchical description.
    • internal signals of a behavioural description (declared as bus, register or simple signal).
  • specifying a read-write format for inputs and outputs.
  • forcing the value of each input.
  • checking the resulted value on each output.
  • changing the value of an internal register (a guarded internal signal of kind register in a behavioural description).
  • saving the state of the circuit.

🌸 THE FORMAT

a pattern file written in pat format splits into two parts, bestie: the declaration block and the description block πŸ’…. the instruction begin marks the end of the declaration and the beginning of the description block. the instruction end; marks the end of the file. periodt.

the declaration block is a set of input-output declaration statements. and listen β€” the order of these declarations is important ⚠️. in the description block, values get associated with an input-output in the order of their declaration. that is, the first value goes with the first declared input-output, and the last value goes with the last one. no skipping, no shuffling.

a declaration statement has one of the two following forms:

mode input_output_name [format] [spy_option];
mode group_name (input_output_name, ...) [format] [spy_option];

the second form lets you give a name to a group of signals 🫢. this group of signals is called a virtual array. and using this grouping possibility, great care must be taken, fr fr: two guarded outputs (of kind bus) can be grouped only if their guard expression are exactly the same. like, exactly exactly.

  • inputs β€” an external port of the mode in must be declared with the mode in. a guarded external port of the mode inout must be declared with the mode inout.
  • outputs β€” an external port (guarded or not) of the mode out must be declared with the mode out. an unguarded external port of the mode inout must be declared with the mode out. a guarded external port of the mode inout must be declared with the mode inout. an internal signal (simple or guarded of kind bus) of a behavioural or structural description must be declared with the mode signal. an internal register (guarded signal of kind register) is to be declared with mode register.

the format specifies the format under which values associated with an input-output must be read or written. legal formats are X for hexadecimal, O for octal and, B for binary. the binary format is the default format ✨.

the input_output_name is used to identify the input-output signal. for an external port, the signalΒ΄s identifier added, if the signal is an array, to its constraint (the range of the array) constitutes the input-output name. for an internal signal the input_output_name is made from the concatenation of the access_path and the signalΒ΄s name (identifier and if needed constraint). the access_path is a string representing the instance where the signal is declared. it is a list of instance names separated by . (dot) πŸ‘‘

the spy option (keyword spy) may be used for outputs (out port, inout port, internal signal). this option makes one additional pattern be printed in the result file each time an event occurs on this signal during the simulation and the corresponding pattern (with this event date) has been omitted in the input pattern file πŸ‘€.

putting one or several additional ; (semicolon) at the end of an input-output declaration makes one or several blank columns (up to 15) be printed in the result file after the input-output's value 🌸.


πŸŽ€ the description block

the description block is a series of pattern description statements. each pattern is a list of values preceded by a date and optionally by a label.

[date] [label] : list_of_values ;

pattern statements should be ordered with stict growing dates in the series πŸ“ˆ (yes, stict β€” that's the vibe).

the date may be either an absolute date or a relative date. an absolute date is an integer followed by a time unit. a relative date is a + followed by an integer and a time unit (the reference is the date of the previous pattern description statement). legal time units are ps, ns, us and ms ⏰.

  • < 200 ps >, <4500ns>, < 12us > are legal absolute dates.
  • < +200 ps >, <+4500ns>, <+1 us> are legal relative dates.

a label is an identifier (in VHDL syntax). the list_of_values is a set of values. each value is associated with one input-output. the value of rank i corresponds to the i-th input-output. depending on the format, legal values for inputs are:

  • B (binary) β€” 0 and, 1
  • O (octal) β€” 0, 1, 2, 3, 4, 5, 6 and, 7
  • X (hexa.) β€” 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E and, F

for each output the user can predict a value. this brings the simulator to make a comparison between this value and the one calculated during the simulation πŸ”. predicting a * (star) as an output value disables the comparison. values must be preceded by a ? (question mark). the ? can be omitted when using a *. depending on the format, legal values for outputs are:

  • B (binary) β€” 0, 1 and *
  • O (octal) β€” 0, 1, 2, 3, 4, 5, 6, 7 and *
  • X (hexa.) β€” 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F and *

using the binary format ?1 can be replaced by + (plus) and ?0 by - (minus) πŸ’….

Example

in  A (0 to 15) X;
in  B (0 to 15) X;
in  Cin;
out Cout;
signal S (0 to 15) X;
register Accu.A (0 to 15) X;

begin

<   0 ns > pattern_0 : F0F0 0A0A 1 ?0 ?FAFA ?6DE7;
< +10 ns > pattern_1 : 0F0F F6F0 0  +  **** ?54FC;

end;

putting one or several additional ; (semicolon) at the end of a pattern makes one or several blank lines (up to 15) be printed in the result file after the pattern πŸ¦‹.

other statements (called actions) such as changing registers value or saving the state of the circuit can be placed in the description block.

the content of a register can be forced to a user defined value using the following statement:

register_name <= value ;

register_name is a string representing the name of the register to be forced (written in the same form as described above).

value can be given in hexadecimal (X), octal (O) or binary (B) format:

  • Examples β€” X"0FE46", O"0345", B"01010111", "0111000", Β΄0Β΄

the value of the register will be forced to value just before the pattern following the statement is executed ⚑.

the state of the circuit can be saved after all patterns are processed using:

save;

the save; statement must be placed just before the end; instruction. when writing a long sequence of patterns, this feature can be used to split the sequence into several small sequences (with a save statement at the end of each sequence) (see asimut(1)) 🧚.

in pat format a comment begins with either a Β΄#Β΄ (sharp) or a Β΄--Β΄ (two adjacent minus) and extends up to the end of the line. a comment marked by a -- is simply ignored. a comment maked by a # is kept at compile time and reproduced at the same place in the result file πŸ’–.


πŸ’… DIAGNOSTICS

  • Pat does not make the difference between upper and lower case letters. it's not picky like that.
  • when the specified read-write format is O (octal) for an array input-output and the range of the input-output doesnΒ΄t match a multiple of 3, the most significant bits β€” 1 or 2 bits β€” of the value are ignored 😭.
  • when the specified read-write format is X (hexadecimal) for an array input-output and the range of the input-output doesnΒ΄t match a multiple of 4, the most significant bits β€” 1, 2 or 3 bits β€” of the value are ignored 😭.
  • a comment beginning with a # (sharp) placed after the end; statement causes a syntax error πŸ’€.
bestie, that last one? do not do it. the compiler WILL yell at you and it will be embarrassing.

πŸ”₯ SEE ALSO

asimut(1), genpat(1), libpat(3)


πŸŽ€ BUG REPORT

this tool is under development at the ASIM department of the LIP6 laboratory. we need your feedback to improve documentation and tools 🫢 (yes, your feedback, bestie, don't be shy).


and that's the whole page!! brought to you by ASIM/LIP6, dated October 1, 1997 ⭐ β€” yes she's a vintage queen and she still slays πŸ’–πŸ‘‘