asyncvlsi / act Goto Github PK
View Code? Open in Web Editor NEWACT hardware description language and core tools.
Home Page: http://avlsi.csl.yale.edu/act
License: GNU General Public License v2.0
act's People
Contributors
Stargazers
Watchers
Forkers
kangjiangnudt ocakgun cecijyx olerichter alj17 hoxid nbingham1 lincb jbemmel rad68 henryheffan ominux bics-rug 00mjk ifquant simrit1 isaeldiaz thomasjagielski mfkiwl jpt4 ronsheelyact's Issues
Nice Project!
You should do yourself a favor and write it in rust. And dont forget to start collecting rain water. Those two advices have fairly equivalent value in my view. For now.
support for 64bit ints in miniscm
Describe the bug
when running prsim, and I use integers with more 32bit while invocing the scheme interpreter it will only use the first 32bits
To Reproduce
take the 3 files attached and run prsim 64.prs and then source 64.prsim while walking past 32 bits it will give:
Value must be `0', `1', or `X'
Execution aborted.
Stack trace:
called from: assert
called from: begin
called from: let
called from: assert-var-bit
called from: begin
called from: cond
called from: assert-one-bit
called from: letrec
called from: assert-var-int
called from: source
Expected behavior
same behavior as for numbers >32bit
like assert-var-int "t.x" 32 75808
Additional context
I tired fixing it myself, but yea i am not there yet haha
The "A first ACT tutorial" link is broken
Describe the bug
Following the ACT tutorial link (http://avlsi.csl.yale.edu/act/doku.php?id=tutorial:basicprs) leads to a page proclaiming
DokuWiki Setup Error
The datadir ('pages') at /home/avlsi_wiki/data_act/pages is not found, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer?
To Reproduce
above
ACT source
N/A
Expected behavior
Obvious
Screenshots
above
Computer setup (please complete the following information):
Firefox & Safari both agree
Additional context
N/A
pfet shows error for violating nfet max width, perhaps integer overflow as well
Describe the bug
Act incorrectly errors against the maximum nfet width limit when writing the netlist for a pfet transistor for the skywater 130 open source pdk.
Here are the relevent global.conf rules (whole file posted below)
int min_width 12
int min_length 5
int max_n_width 3333
int max_p_width 233
$ prs2net -Tsky130 -DDUT=true -DLAYOUT=true -DPRSIM=false -p "wchb<>" wchb.act
...
In expanding wchb<> (wchb.act:17)
FATAL: Device #13: pfet width (12) exceeds maximum limit (3333)
To Reproduce
Steps to reproduce the behavior:
- Use the ACT source included below.
- Run the following sequence of commands
prs2net -Tsky130 -DDUT=true -DLAYOUT=true -DPRSIM=false -p "wchb<>" wchb.act
- Observe that the above error occurs.
ACT source
global.conf
begin act
string_table dev_flavors "svt" "lvt" "hvt" "mvt"
int max_recurse_depth 1000
string_table spec_types "exclhi" "excllo" "mk_exclhi" "mk_excllo"
string_table prs_attr "i:s:after" "i:s:keeper" "i:s:iskeeper" "i:s:isckeeper" "r:+:loadcap" "i:M:oresis" "i:s:output" "r:s:N_reff" "r:s:P_reff" "i:s:weak" "i:s:unstab" "i:s:comb"
string_table instance_attr "i:s:pos_x" "i:s:pos_y" "i:s:size_x" "i:s:size_y" "i:s:autokeeper" "i:s:iscomb"
string mangle_chars ":()<>[],{}.""
string mangle_letter "_"
end
begin net
string name "scmos"
string_table ext_devs "nfet" "pfet"
string_table ext_map "nfet_svt" "pfet_svt"
string spice_path_sep ":"
int std_p_width 14
int std_p_length 5
int std_n_width 12
int std_n_length 5
int min_width 12
int min_length 5
int max_n_width 3333
int max_p_width 233
int stat_p_width 14
int stat_p_length 5
int stat_n_width 12
int stat_n_length 5
int fet_spacing_diffonly 12
int fet_spacing_diffcontact 12
int fet_diff_overhang 10
real p_n_ratio 2.0
real weak_to_strong_ratio 0.1
real lambda 0.03
real default_load_cap 1.0
string extra_fet_string ""
int disable_keepers 0
int discrete_length 0
int swap_source_drain 0
int use_subckt_models 1
int fold_pfet_width 0
int fold_nfet_width 0
int ignore_loadcap 1
int emit_parasitics 0
string pfet_svt "sky130_fd_pr__pfet_01v8"
string pfet_lvt "sky130_fd_pr__pfet_01v8_lvt"
string pfet_hvt "sky130_fd_pr__pfet_01v8_hvt"
string pfet_hvt "sky130_fd_pr__pfet_01v8_mvt"
string nfet_svt "sky130_fd_pr__nfet_01v8"
string nfet_lvt "sky130_fd_pr__nfet_01v8_lvt"
string nfet_hvt "sky130_fd_pr__nfet_01v8_hvt"
string nfet_hvt "sky130_fd_pr__nfet_01v8_mvt"
string global_vdd "Vdd"
string global_gnd "GND"
string local_vdd "VddN"
string local_gnd "GNDN"
begin sizing
int unit_n 5
int p_n_mode 0
end
end
begin lint
real Vdd 1.8
int verbose 0
real slewrate_fast_threshold 200.0
real slewrate_slow_threshold 20.0
real V_high 1.5
real V_low 0.3
int max_print 100
int show_frequency 1
string filter_results ""
real hysteresis 0.0
real skip_initial_time 0.0
real reset_sync_time 20.0e-9
end
begin lvp
real Vtn 0.3
real Vtp 1.5
real WeakByWidth 3.1
real NResetPStat 5.0
real PResetNStat 20.0
real CombThreshold 2.0
real StateThreshold 0.8
end
wchb.act
export deftype globals <: int<6> (bool Vdd, GND, vpsub, vnsub, Reset, _Reset, pReset, sReset, _pReset, _sReset)
{
sReset = Reset;
_sReset = _Reset;
}
export template <pint N>
deftype c1of <: int (bool d[N])
{
}
export template <pint N>
defchan e1of <: chan(int) (bool d[N]; bool e)
{
}
export defproc wchb(globals g; e1of<2> L, R)
{
c1of<2> _R;
bool Rv;
prs<g.Vdd, g.GND>
{
g._sReset & R.e & L.e & L.d[0] -> _R.d[0]-
g._sReset & R.e & L.e & L.d[1] -> _R.d[1]-
g._sReset & Rv -> L.e-
~g._pReset | ~R.e & ~L.e & ~L.d[0] -> _R.d[0]+
~g._pReset | ~R.e & ~L.e & ~L.d[1] -> _R.d[1]+
~g._pReset | ~Rv -> L.e+
~_R.d[0] -> R.d[0]+
_R.d[0] -> R.d[0]-
~_R.d[1] -> R.d[1]+
_R.d[1] -> R.d[1]-
~_R.d[0]|~_R.d[1] -> Rv+
_R.d[0]&_R.d[1] -> Rv-
}
}
globals g;
e1of<2> L, R;
wchb dut(g, L, R);
Expected behavior
prs2net should complete without errors
Computer setup (please complete the following information):
$ lsb_release -a
LSB Version: core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 21.04
Release: 21.04
Codename: hirsute
$ g++ --version
g++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0
aflat doesn't generate rules for pass transistors
defproc test(bool a, b, c, x, y)
{
prs {
passn(a, b, c)
x -> y-
}
}
test t;
$aflat tmp.act
"t.x"->"t.y"-
prsim: promt does not appear
Describe the bug
when starting prsim without anything the promt does not appear
To Reproduce
Steps to reproduce the behavior:
compile fresh of the git both mac or centos
run prsim
get an unresponsive terminal
Expected behavior
EDIT: should it display usage, or should there be a promt, i am a bit confused at the moment
Screenshots
If applicable, add screenshots to help explain your problem.
Computer setup (please complete the following information):
- centos7 with gcc7.3
- macos 10.15 with clang 12.0.0
- grace
Old loop styles don't generate parser errors
defproc test(bool a[10], b[10], c, d)
{
(;i:10:
prs {
a[i] => b[i]-
}
)
prs {
(|:i:10: a[i] ) => c-
}
}
test t;
$ aflat test.act
"t.a[0]"->"t.b[0]"-
~("t.a[0]")->"t.b[0]"+
"t.a[1]"->"t.b[1]"-
~("t.a[1]")->"t.b[1]"+
"t.a[2]"->"t.b[2]"-
~("t.a[2]")->"t.b[2]"+
"t.a[3]"->"t.b[3]"-
~("t.a[3]")->"t.b[3]"+
"t.a[4]"->"t.b[4]"-
~("t.a[4]")->"t.b[4]"+
"t.a[5]"->"t.b[5]"-
~("t.a[5]")->"t.b[5]"+
"t.a[6]"->"t.b[6]"-
~("t.a[6]")->"t.b[6]"+
"t.a[7]"->"t.b[7]"-
~("t.a[7]")->"t.b[7]"+
"t.a[8]"->"t.b[8]"-
~("t.a[8]")->"t.b[8]"+
"t.a[9]"->"t.b[9]"-
~("t.a[9]")->"t.b[9]"+
"t.a[0]"|"t.a[1]"|"t.a[2]"|"t.a[3]"|"t.a[4]"|"t.a[5]"|"t.a[6]"|"t.a[7]"|"t.a[8]"|"t.a[9]"->"t.c"-
~("t.a[0]"|"t.a[1]"|"t.a[2]"|"t.a[3]"|"t.a[4]"|"t.a[5]"|"t.a[6]"|"t.a[7]"|"t.a[8]"|"t.a[9]")->"t.c"+
Initial configuration does not seem to work
There appears to be a circular dependency, whereby the configure script fails to create a config script in the scripts directory because there is no config script in the scripts directory.
More specifically, the check script called by the configure script fails with:
line 16: /Users/dmz/misc-repos/act/scripts/config: No such file or directory
Configuration file location and options need to be cleaned up and documented
/opt/cad$ echo $ACT_HOME
/opt/cad
/opt/cad$ ls -l
total 20
drwxr-xr-x 15 4096 Aug 2 13:19 act
drwxr-xr-x 2 4096 Aug 3 11:37 bin
drwxr-xr-x 3 4096 Aug 3 11:42 conf
drwxr-xr-x 3 4096 Aug 2 22:05 include
drwxr-xr-x 2 4096 Aug 3 10:48 lib
/opt/cad$ cd conf/
/opt/cad/conf$ ls -l
total 12
drwxr-xr-x 2 4096 Aug 3 11:39 generic
drwxr-xr-x 2 4096 Aug 3 13:23 st28
-rw-r--r-- 1 2086 Aug 3 13:26 st28.conf
/opt/cad/conf$ cd st28/
/opt/cad/conf/st28$ ls -l
total 16
-rw-r--r-- 1 59 Aug 3 13:23 extract.conf
-rw-r--r-- 1 3292 Aug 3 13:23 global.conf
-rw-r--r-- 1 59 Aug 3 13:23 lint.conf
-rw-r--r-- 1 2086 Aug 3 11:38 prs2net.conf
None of these work
/opt/cad/conf$ pushd
~/act/test/prs/clk_mult_dadda___64_64_6______bits /opt/cad/conf
~/act/test/prs/clk_mult_dadda___64_64_6______bits$ prs2net -C st28 -p'testbench<>' test.act
FATAL: Could not open configuration file `st28.conf' for reading.
~/act/test/prs/clk_mult_dadda___64_64_6______bits$ prs2net -T st28 -p'testbench<>' test.act
FATAL: Could not open configuration file `global.conf' for reading.
~/act/test/prs/clk_mult_dadda___64_64_6______bits$ prs2net -T /opt/cad/conf/st28 -p'testbench<>' test.act
FATAL: Could not open configuration file `global.conf' for reading.
nbingham@Lira:~/act/test/prs/clk_mult_dadda___64_64_6______bits$ prs2net -p "testbench<>" -Tst28 test.act
prs2net: invalid option -- 'T'
Unknown option.
Usage: prs2net [-dltBR] [-C <conf>] [-p <proc>] [-o <file>] <act>
-C <conf> Configuration file name
-c <cells> Cell file name
-t Only emit top-level cell (no sub-cells)
-p <proc> Emit process <proc>
-o <file> Save result to <file> rather than stdout
-d Emit parasitic source/drain diffusion area/perimeters with fets
-B Turn of black-box mode. Assume empty act process is an externally specified file
-l LVS netlist; ignore all load capacitances
-S Enable shared long-channel devices in staticizers
This is the one that works.
prs2net -Tst28 -p "testbench<>" test.act
Infinite loop, likely in compute_max_reff()
prs2net never completes. Likely an infinite loop in compute_max_reff()
To Reproduce
Steps to reproduce the behavior:
- Use the ACT source included below.
- Run the following sequence of commands (please provide exact running instructions, preferably on Linux)
prs2net -B -p "test<>" test.act
- Observe that prs2net never completes.
ACT source
export deftype globals <: int<6> (bool Vdd, GND, vpsub, vnsub, Reset, _Reset, pReset, sReset, _pReset, _sReset)
{
sReset = Reset;
_sReset = _Reset;
}
preal PN = 2.0;
export deftype pair <: int (bool d[2])
{
}
defproc test(globals g; pair A[4], B[4], Z, I[4], P[10])
{
pint Na = 4;
pint psz = 18;
pint sz = 6;
preal n2 = 2.0*sz;
preal n4 = 4.0*sz;
preal p2 = 2.0*PN*sz;
preal p4 = 4.0*PN*sz;
pint Dp[8];
pair e0p, e0n, es0p, es0n, e1p, e1n, es1p, es1n;
pint Col[Na+4];
Col[0] = 0;
Dp[0] = 1;
Dp[1] = 1;
Dp[Na+1] = 1;
Dp[Na+2] = 1;
Dp[Na+3] = 0;
(i:2..Na: Dp[i] = 2; )
(i:(Na+3): Col[i+1] = Col[i]+Dp[i]; )
(i:Na:
prs <g.Vdd, g.GND>
{
[keeper=0] passp<PN*psz>(e0p.d[0], A[i].d[1], P[Col[i]].d[1])
[keeper=0] passn<psz>(e0p.d[1], A[i].d[1], P[Col[i]].d[1])
[keeper=0] passp<PN*psz>(e0n.d[0], A[i].d[0], P[Col[i]].d[1])
[keeper=0] passn<psz>(e0n.d[1], A[i].d[0], P[Col[i]].d[1])
[keeper=0] passp<PN*psz>(es0p.d[0], A[i].d[1], P[Col[i+1]].d[1])
[keeper=0] passn<psz>(es0p.d[1], A[i].d[1], P[Col[i+1]].d[1])
[keeper=0] passp<PN*psz>(es0n.d[0], A[i].d[0], P[Col[i+1]].d[1])
[keeper=0] passn<psz>(es0n.d[1], A[i].d[0], P[Col[i+1]].d[1])
[keeper=0] passp<PN*psz>(e1p.d[0], A[i].d[1], P[Col[i+2]+Dp[i+2]-1].d[1])
[keeper=0] passn<psz>(e1p.d[1], A[i].d[1], P[Col[i+2]+Dp[i+2]-1].d[1])
[keeper=0] passp<PN*psz>(e1n.d[0], A[i].d[0], P[Col[i+2]+Dp[i+2]-1].d[1])
[keeper=0] passn<psz>(e1n.d[1], A[i].d[0], P[Col[i+2]+Dp[i+2]-1].d[1])
[keeper=0] passp<PN*psz>(es1p.d[0], A[i].d[1], P[Col[i+3]+Dp[i+3]-1].d[1])
[keeper=0] passn<psz>(es1p.d[1], A[i].d[1], P[Col[i+3]+Dp[i+3]-1].d[1])
[keeper=0] passp<PN*psz>(es1n.d[0], A[i].d[0], P[Col[i+3]+Dp[i+3]-1].d[1])
[keeper=0] passn<psz>(es1n.d[1], A[i].d[0], P[Col[i+3]+Dp[i+3]-1].d[1])
[keeper=0] passp<PN*psz>(e0p.d[0], A[i].d[0], P[Col[i]].d[0])
[keeper=0] passn<psz>(e0p.d[1], A[i].d[0], P[Col[i]].d[0])
[keeper=0] passp<PN*psz>(e0n.d[0], A[i].d[1], P[Col[i]].d[0])
[keeper=0] passn<psz>(e0n.d[1], A[i].d[1], P[Col[i]].d[0])
[keeper=0] passp<PN*psz>(es0p.d[0], A[i].d[0], P[Col[i+1]].d[0])
[keeper=0] passn<psz>(es0p.d[1], A[i].d[0], P[Col[i+1]].d[0])
[keeper=0] passp<PN*psz>(es0n.d[0], A[i].d[1], P[Col[i+1]].d[0])
[keeper=0] passn<psz>(es0n.d[1], A[i].d[1], P[Col[i+1]].d[0])
[keeper=0] passp<PN*psz>(e1p.d[0], A[i].d[0], P[Col[i+2]+Dp[i+2]-1].d[0])
[keeper=0] passn<psz>(e1p.d[1], A[i].d[0], P[Col[i+2]+Dp[i+2]-1].d[0])
[keeper=0] passp<PN*psz>(e1n.d[0], A[i].d[1], P[Col[i+2]+Dp[i+2]-1].d[0])
[keeper=0] passn<psz>(e1n.d[1], A[i].d[1], P[Col[i+2]+Dp[i+2]-1].d[0])
[keeper=0] passp<PN*psz>(es1p.d[0], A[i].d[0], P[Col[i+3]+Dp[i+3]-1].d[0])
[keeper=0] passn<psz>(es1p.d[1], A[i].d[0], P[Col[i+3]+Dp[i+3]-1].d[0])
[keeper=0] passp<PN*psz>(es1n.d[0], A[i].d[1], P[Col[i+3]+Dp[i+3]-1].d[0])
[keeper=0] passn<psz>(es1n.d[1], A[i].d[1], P[Col[i+3]+Dp[i+3]-1].d[0])
}
)
(i:(Na+1):
[ i = 0 ->
prs <g.Vdd, g.GND>
{
[keeper=0] e0p.d[0]<n2> & e0n.d[0] -> P[Col[i]].d[1]-
[keeper=0] ~e0p.d[1]<p2> & ~e0n.d[1] -> P[Col[i]].d[0]+
[keeper=0] e1p.d[0]<n2> & e1n.d[0] -> P[Col[i+2]+Dp[i+2]-1].d[1]-
[keeper=0] ~e1p.d[1]<p2> & ~e1n.d[1] -> P[Col[i+2]+Dp[i+2]-1].d[0]+
}
[] i > 0 ->
[ i = Na ->
prs <g.Vdd, g.GND>
{
[keeper=0] es0p.d[0]<n2> & es0n.d[0] -> P[Col[i]].d[1]-
[keeper=0] ~es0p.d[1]<p2> & ~es0n.d[1] -> P[Col[i]].d[0]+
[keeper=0] es1p.d[0]<n2> & es1n.d[0] -> P[Col[i+2]+Dp[i+2]-1].d[1]-
[keeper=0] ~es1p.d[1]<p2> & ~es1n.d[1] -> P[Col[i+2]+Dp[i+2]-1].d[0]+
}
[] i < Na ->
prs <g.Vdd, g.GND>
{
[keeper=0] e0p.d[0]<n4> & e0n.d[0] & es0p.d[0] & es0n.d[0] -> P[Col[i]].d[1]-
[keeper=0] ~e0p.d[1]<p4> & ~e0n.d[1] & ~es0p.d[1] & ~es0n.d[1] -> P[Col[i]].d[0]+
[keeper=0] e1p.d[0]<n4> & e1n.d[0] & es1p.d[0] & es1n.d[0] -> P[Col[i+2]+Dp[i+2]-1].d[1]-
[keeper=0] ~e1p.d[1]<p4> & ~e1n.d[1] & ~es1p.d[1] & ~es1n.d[1] -> P[Col[i+2]+Dp[i+2]-1].d[0]+
}
]
]
)
}
test mult;
Expected behavior
prs2net should complete with the compiled spice file.
Computer setup (please complete the following information):
Operating System: Red Hat Enterprise Linux Server 7.7 (Maipo)
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.7:GA:server
Kernel: Linux 3.10.0-1062.31.2.el7.x86_64
Architecture: x86-64
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
ACT violates DEF syntax with DO 0 in TRACKS statement
Describe the bug
Interact creates the following two lines in _out.def
TRACKS X 4200 DO 0 STEP 3200 LAYER met5 ;
TRACKS Y 5840 DO 1 STEP 3200 LAYER met5 ;
and DEF syntax does not allow DO 0
To Reproduce
interact -ref=1 -Tsky130 -DPRSIM=false -DDUT=true
interact> source interact.conf
WARNING: new cells generated; please update your cell library.
(Use ckt:cell-save to see the new cells.) New cell names are:
g0n_0x0
ERROR (DEFPARS-6525): The DO number 0 in TRACK is invalid.
The number value has to be greater than 0. Specify the valid syntax and try again. Error in file _out.def at line 27, on token ;.
Update the def file before parsing the file again.
DEF parser returns an error!
ACT source
test.act
export deftype globals(bool Vdd, GND, Reset, _Reset, pReset, sReset, _pReset, _sReset) {
Reset = sReset;
_Reset = _sReset;
}
defproc testbench(globals g; bool a, b)
{
prs <g.Vdd, g.GND>
{
a<6> -> b-
~a<12> -> b+
}
}
globals g;
bool a, b;
testbench dut(g, a, b);
interact.conf
act:read "test.act"
act:expand
act:top testbench
ckt:cell-map
ckt:cell-save "cells.act"
ckt:map
load-scm "phydb.scm"
phydb:create 1.8 1 "output.lef"
act:layout:rect
Expected behavior
Interact should skip the metal 5 layer if there are no tracks to emit.
Computer setup (please complete the following information):
No LSB modules are available.
Ubuntu 22.04.3 LTS
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
actflow git commit 744b3fd0e2d70b2af185db40fec8611f323445ad
Additional context
If you need it, I can send you the layout.conf file I'm using for sky130 as well.
Canonical Name Issue
This is another canonical name bug. prs2net is choosing different names for the same signal in two places of the spice output. This causes them to be disconnected.
To Reproduce
prs2net -p'myproc3<>' test.act
ACT source (test.act)
defchan mytype <: chan(int) (bool d)
{
}
defchan mytype2 <: chan(int) (mytype c)
{
}
defproc myproc1(bool a, b)
{
prs
{
a => b-
}
}
defproc myproc2(bool a; mytype2 A; mytype B)
{
A.c.d = B.d;
prs
{
a => B.d-
}
}
defproc myproc3(mytype A)
{
mytype2 B;
mytype C;
B.c = A;
myproc2 x(, B, C);
myproc1 y(C.d);
}
myproc3 tst;
Expected behavior
On line 53 and 54 of the generated spice file:
xy C_ad y_ab myproc1
xx x_aa A_ad myproc2
C_ad and A_ad should be connected.
Computer setup
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Buffer Overflow in prs2net for 64-bit Multiplier
Buffer overflow when attempting to spice a 64-bit dadda multiplier.
git clone https://github.com/nbingham1/act.git
cd act
git checkout new_act
git submodule update --init --recursive
cd deps
make
cd ..
source setup.py
./build.py clk mult dadda
cd test/prs/clk_mult_dadda___64_64_6______bits/
prs2net -Tst28 -DDUT=true -DLAYOUT=true -DPRSIM=false -B -p "testbench<>" test.act
*** buffer overflow detected ***: prs2net terminated
Aborted (core dumped)
Transistor length doesn't support pint expressions
Describe the bug
When using a pint expression to set the transistor length, aflat produces a parse error about transistor flavor. Notice that replacing "B" with 20 does not produce this error.
To Reproduce
Steps to reproduce the behavior:
- Use the ACT source included below.
- Run the following sequence of commands:
aflat test.act - Observe that the following parse error occurs.
Parse error: Could not parse entire file.
Error parsing production rule: unknown transistor flavor
File `test.act', line: 8, col: 9.
Exception: number=1, message -none-
FATAL: Uncaught exception
ACT source
test.act:
pint A = 6;
pint B = 20;
defproc test()
{
bool a, b;
prs {
a<A,B> -> b-
~a<A,B> -> b+
}
}
test t;
Expected behavior
aflat succeeds and emits the flattened prs.
Computer setup (please complete the following information):
Ubuntu 20.10
gcc 10.2.0
GNU Make 4.3
ACT commit a75aa48
prs2net has erroneous message for positive labels used in a distributed shared gate network
Describe the bug
unexpected error message for shared gate network
To Reproduce
Steps to reproduce the behavior:
- Use the ACT source included below.
prs2net -p'test<>' temp.act- produces an error message
FATAL: @-expression with unknown label 'x'
ACT source
temp.act
defproc test() {
bool a, b, c;
prs {
~a -> @x+
}
(;i:2:
prs {
@x & ~b -> c+
}
)
}
test t;
Expected behavior
expected netlist output
Computer setup (please complete the following information):
g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0
LSB Version: core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 20.10
Release: 20.10
Codename: groovy
Additional context
inverting the sense of the label works properly
At least one node required for subcircuit test
Describe the bug
prs2net creates stubs in the spice file for empty processes. Xyce does not allow empty processes. The following is the simplest example, but this most often shows up in templated processes like delay lines. For example, a delay line of length 0.
To Reproduce
Steps to reproduce the behavior:
- Use the ACT source included below.
prs2net -Tsky130 -p 'test<>' test.act > test.spi- Observe the following spice file
*
*---- act defproc: test<> -----
* raw ports:
*
.subckt test
*.POWER VDD Vdd
*.POWER GND GND
*.POWER NSUB GND
*.POWER PSUB Vdd
.ends
*---- end of process: test<> -----
Xyce test.spi- Observe
Netlist error in file test.spi at or near line 5
At least one node required for subcircuit test
ACT source
export defproc test()
{
prs {
}
}
test dut;
Expected behavior
prs2net should create an empty spice file
Computer setup (please complete the following information):
$ lsb_release -a; g++ --version
LSB Version: core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 21.04
Release: 21.04
Codename: hirsute
g++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
aflat ignores exclhi and excllo
defproc test(bool a, b)
{
spec {
exclhi(a, b)
}
prs
{
a => b-
}
}
test t;
$ aflat tmp.act
"t.a"->"t.b"-
~("t.a")->"t.b"+
aflat clobbers pass transistor flags
defproc test(bool a, b, c, x, y)
{
prs {
[after=0] passp(a, b, c)
[unstab=1] passn(a, b, c)
[after=0] x -> y-
[unstab=1] ~x -> y+
}
}
test t;
$ aflat test.act
after 0 ~"t.a" & "t.b" -> "t.c"+
after 0 "t.a" & ~"t.b" -> "t.c"-
after 0 "t.x"->"t.y"-
unstab ~"t.x"->"t.y"+
[act2v] add flag to enable compatiblilty mode with cadence xelcium/spectre netlister and simulatior plus innovus/virtuoso
@rmanohar I will implement it but i wanted to get your ok/opinion first. also any wishes for the char that i use as flag?
Describe the bug
cadence xelium/spectre and for some parts innovus does not understand or creates problems using the verilog from act2v:
- the signal names can not contain dots so eg. 'buffer.in.a' it confuses the tool as it interprets it as a hierarchy and does not find the instances/modules, the escape slash in front of the name is ignored :/ .
- some parts of virtuoso need '[ ]' mangled/removed/changed, so a name 'buffer.in.d[1].d[0]' would create problems as to tool starts escaping them inconsistently and therefor cuts connections. innovus is fine, it ignores the brackets and just treats them as a name.
- the AMS xelcium simulator does not understand multiline signal specifications so
output signal1;
reg signal1;
needs to be
output reg signal1;
- (is minor) global signals (we dont use them) are defined as
globals.<signalname>it does not understandtop.<signalname>
options for later
2. i thought to make it readable and more user friendly in virtuoso (if every single bus signal is separate we have top level module definitions with 10k signals) to do a conversion like this:
as virtuoso really only understands one dimensional arrays:
if its a uniform nested array signal like blub.d[].d[].blub resort them into a one dimensional with the and change to name to blub.d[dimA].d[dimB].blub [dimA*dimB] and do the mapping simply lowest level as least significant
# if we have a aMx1of2<32> called in t have (X = .,Y = [,Z = ] is a place holders for mangling)
module buffer (in_Xa, in_Xd_Y32_Z_Xd_Y2_Z)
input in_Xa;
input in_Xd_Y32_Z_Xd_Y2_Z [64];
with:
in.d[0].d[0] => in_Xd_Y32_Z_Xd_Y2_Z[0]
in.d[0].d[1] => in_Xd_Y32_Z_Xd_Y2_Z[1]
in.d[1].d[0] => in_Xd_Y32_Z_Xd_Y2_Z[2]
...
Work around
- and 2. we currently fix by regex as a quick fix
for 3. i will see if i can fix it in the code otherwise one of my team it put on regex+python and I fix all of it after tape out as a patch:)
scope.cc, line 940 Assertion: !aes->isend()
template <pint in[2][1]>
defproc test()
{
}
pint X[1];
pint Y[1];
X[0] = 0; Y[0] = 0;
test<{X, Y}> tmp;
$ aflat tmp.act
Assertion failed, file scope.cc, line 940
Assertion: !aes->isend()
ERR: This should have been caught earlier
Technology config file doesn't support absolute path
Someone may need to edit the config files or use their own. However, the group directory isn't writeable (for good reason). It might be a good idea for the -T option to support absolute paths so that people can point the tools to their own config files.
defproc test(bool a, b)
{
prs {
a => b-
}
}
test t;
$ pwd
/home/eb823/cad/conf/generic
$ ls -l
total 2
-rw-r--r-- 1 59 Aug 10 15:52 extract.conf
-rw-r--r-- 1 3292 Aug 10 15:52 global.conf
-rw-r--r-- 1 59 Aug 10 15:52 lint.conf
-rw-r--r-- 1 59 Aug 10 15:52 prs2net.conf
$ echo $ACT_HOME
/home/eb823/cad
$ prs2net -T/home/eb823/cad/conf/generic -p'test<>' tmp.act
FATAL: Could not open configuration file `global.conf' for reading.
binary constants in v2act
Describe the bug
a) v2act_quote ( transform/v2act/v2act_quote.sed ) should be for handling more than 9 bits :) (i added a + after the first number bracket) proposed fixs/\([0-9]+\)'b\([01][01][01]*\)/\1'b"\2"/g
b) because v2act_quote.sed is marked as a target in the makefile it is deleted if you run make realclean
so it needs to be restored from git, Wanted behaviour: dont delete this target
c) the binary numbers are read LSB to MSB should be MSB to LSB:
module blk0(out);
output [7:0] out;
assign out = 8'b00111100;
endmodule
results in
export defproc blk0 (syn::sdtexprchan<1> out[8])
{
/*--- types ---*/
source_GND src_GND_0;
source_GND src_GND_1;
source_GND src_GND_2;
source_GND src_GND_3;
source_Vdd src_Vdd_0;
source_Vdd src_Vdd_1;
source_Vdd src_Vdd_2;
source_Vdd src_Vdd_3;
/*--- connections ---*/
out[7]=src_GND_0.out;
out[6]=src_GND_1.out;
out[5]=src_Vdd_0.out;
out[4]=src_Vdd_1.out;
out[3]=src_Vdd_2.out;
out[2]=src_Vdd_3.out;
out[1]=src_GND_2.out;
out[0]=src_GND_3.out;
}
but should be wanted behaviour
export defproc blk0 (syn::sdtexprchan<1> out[8])
{
/*--- types ---*/
source_GND src_GND_0;
source_GND src_GND_1;
source_GND src_GND_2;
source_GND src_GND_3;
source_Vdd src_Vdd_0;
source_Vdd src_Vdd_1;
source_Vdd src_Vdd_2;
source_Vdd src_Vdd_3;
/*--- connections ---*/
out[7]=src_GND_3.out;
out[6]=src_GND_2.out;
out[5]=src_Vdd_3.out;
out[4]=src_Vdd_2.out;
out[3]=src_Vdd_1.out;
out[2]=src_Vdd_0.out;
out[1]=src_GND_1.out;
out[0]=src_GND_0.out;
}
prs2net Signal connections to Vdd or GND don't work
This seems like it may be an intentional thing, mandating a tie-down cell? If so, prs2net should emit a warning.
b.c.d[0] = g.Vdd;
Warning: node "xdut.xdut.sub_ab_ac_ad_50_6" has no DC path to ground
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.