File: sim_setups.html

package info (click to toggle)
sch-rnd 1.0.10-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 17,696 kB
  • sloc: ansic: 119,120; awk: 1,502; makefile: 1,421; sh: 1,404; yacc: 905; lex: 172; xml: 160
file content (134 lines) | stat: -rw-r--r-- 3,955 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title> pcb-rnd - list of file formats </title>
	<meta http-equiv="Content-Type" content="text/html;charset=us-ascii">
	<link rel="stylesheet" type="text/css" href="../default.css">
</head>
<body>

<h1> pcb-rnd User Manual: Appendix </h1>
<p>
<h2> config subtree: plugins/sim/setups </h2>
<p>
The sim/setups subtree describes one or more 
<a href="../06_features/simulation/index.html">high level simulation setups</a>
In a project.lht, the subtree is typically placed like this:
<pre>
ha:coraleda-project-v1 {
 li:sch-rnd-conf-v1 {
  ha:overwrite {
   ha:plugins {
    ha:sim {
     li:setups {
     <i>(subtree described in this document)</i>
     }
    }
   }
  }
 }
}
</pre>
<p>
Note: in this document <i>italic</i> marks variable, user assigned data. The
format is case sensitive.
<p>
The <b>setups</b> list contains one or more hash nodes, each describing
a simulation setup. The name of the node is the name of the simulation setup.
The overall structure of a simulation setup hash node is:
<pre>
ha:<i>name</i> {
 test_bench = <i>bench_name</i>
 li:mods {
  <i>(mods subtree)</i>
 }
 li:output {
  <i>(output subtree)</i>
 }
}
</pre>

<h3> the mods subtree </h3>
<p>
The mods subtree contains one or more modifications, each is a hash node with
its name determinign what kind of modification is done; thus the name must
be one of the <a href="../06_features/simulation/fields.html">predefined
modifications</a>, e.g. <b>add</b>.
<p>
Example modifications:
<pre>
ha:edit_attr {
 type = <i>comp</i>
 name = <i>R2</i>
 key = <i>blobb</i>
 value = <i>hello</i>
}
ha:omit {
 type = <i>comp</i>
 name = <i>R3</i>
}
ha:disconn {
 comp = <i>R12</i>
 port = <i>1</i>
}
ha:add {
 device = <i>V</i>
 ac_value = <i>3.3</i>
 value = <i>0.2</i>
 name = <i>V3</i>
 tdf = <i>pulse</i>
 pos = <i>R1-1</i>
 neg = <i>R2-2</i>
 ha:tdf_params {
  V1 = <i>0.2</i>
  V2 = <i>0.8</i>
  TD = <i>4</i>
 }
}
</pre>

<h4> edit_attr </h4>
<p>
Type is either comp, port or net and specifies the type of the target object
in the abstract model to edit. Name is the address of the object: for comp(onent)
and net(work) it's the name of the object, for port it's componetname-portname.
Key is the attribute key to edit, value is the new value of the attribute. If
the attribute doesn't exist, it is created.

<h4> omit </h4>
<p>
Mark a component or network omitting. Type is the same as in edit_attr, but
shall be either comp or port. Name is the same as in edit_attr. A component
or network omitted means it is not exported (and this is visually indicated
on the sheet).

<h4> disconn </h4>
<p>
Disconnect a port from its net; comp specifies the name of the component,
port specifies the name of the port.

<h4> add </h4>
<p>
Add a new component to the abstract model. Name is optional; when not
specified, it is autogenerated. Using an explicit name is useful when
the component needs to be referneced, e.g. in some of the analysis for
feeding in the test signal.
<p>
pos and neg are the address (network name or comp-port name) of the
positive and negative port connection of the new component. If neg is
not specified, GND is assumed.
<p>
The device field is the name of the device type to add, e.g. V for voltage source;
see the <a href="../06_features/simulation/fields.html">device types list.</a>
That table also specifies whether ac_value and tdf may be used.
<p>
The value field is the DC value for sources or the component value
for passives. When available (e.g. for sources), ac_value is the optional
AC component, which also identifies which source is used for feeding in
AC signal.
<p>
Some component types permit using time-dependant-functions (TDF). For those,
the type of the tdf can be specified in the tdf field and parameters of
the tdf specified in the ha:tdf_params subtree. If no tdf field is specified,
it is assumed to be <i>none</i>.