Sub-module not found after changing parameter through chparam in a foreach loop - yosys

I am trying to synthesize a module for different values of a parameter. I am changing the parameter with a foreach loop in tcl and passing the updated parameter to the top module using -chparam tag in the hierarchy command. It works for the first iteration of the loop. However, in the second iteration, it shows the error that one of the sub-modules is not found.
I have written a simple module (written in test.sv) to demonstrate the problem.
module top #(parameter N = 8)(
input [N-1:0] x,
output y
);
isZero #(.N(N)) isZero_inst(
.x(x),
.y(y)
);
endmodule
module isZero #(parameter N = 8)(
input [N-1:0] x,
output y
);
assign y = |x;
endmodule
I am using the following tcl command (written in test.tcl):
yosys -import
read_verilog -defer -sv test.sv
foreach N [list 4 8] {
hierarchy -check -top top -chparam N $N
procs; opt;
flatten; opt;
techmap; opt;
abc; opt;
clean; opt;
opt_clean -purge
write_verilog -noattr -noexpr test_${N}_syn.v
}
It generates the first file: test_4_syn.v. However, in the second iteration, it shows the error:
Module `\isZero' referenced in module `\top' in cell `\isZero_inst' is not part of the design.
For completeness: I am using the following command to run the tcl file:
yosys -c test.tcl

hierarchy is the main part of elaboration, and IIRC will purge non-parameterised versions of parameterised modules.
The design command is a good way of dealing with this without re-running read_verilog. e.g.:
yosys -import
read_verilog -defer -sv test.sv
design -stash test
foreach N [list 4 8] {
design -load test
hierarchy -check -top top -chparam N $N
procs; opt;
flatten; opt;
techmap; opt;
abc; opt;
clean; opt;
opt_clean -purge
write_verilog -noattr -noexpr test_${N}_syn.v
}

I solved it by moving the read_verilog inside the foreach loop with -overwrite tag (without -overwrite Yosys would generate redefinition of module error). This is how the tcl file looks now:
foreach N [list 4 8] {
read_verilog -overwrite -defer -sv test.sv
hierarchy -check -top top -chparam N $N
procs; opt;
flatten; opt;
techmap; opt;
abc; opt;
clean; opt;
opt_clean -purge
write_verilog -noattr -noexpr test_${N}_syn.v
}
I am not sure if this is the proper approach, but it works. I know that in Synopsys Design Compiler the files are read only once.

Related

Vivado doesn't recognize cell in EDIF file generated by Yosys

I'm attempting to use Yosys to generate an edif file that I then use with Vivado tcl scripting to generate a bitstream for an Artix 7 (xc7a15t) FPGA. However, Vivado seems to have trouble with a few of the cells in the edif file.
When I use the same verilog and constraints file completely in Vivado the bitstream is created fine, and it works as expected when I load it onto the FPGA.
I've modeled my workflow off the example here.
Specifically, I'm using the following shell script as a frontend for the yosys and Vivado commands:
#!/bin/bash
yosys run_yosys.ys
vivado -nolog -nojournal -mode batch -source run_vivado.tcl
run_yosys.ys:
read_verilog top.v
synth_xilinx -edif top.edif -top top
run_vivado.tcl
read_xdc top.xdc
read_edif top.edif
link_design -part xc7a15tftg256-1 -top top
opt_design
place_design
route_design
report_utilization
report_timing
write_bitstream -force top.bit
top.v (simple blinky example):
`default_nettype none
module top (
input wire clk,
output reg led);
reg [24:0] cnt = 25'b0;
always #(posedge clk) begin
cnt <= cnt + 1'b1;
if (cnt == 25'b0) begin
led <= !led;
end
else begin
led <= led;
end
end
endmodule // top
top.xdc:
create_clock -period 25.000 -name clk -waveform {0.000 12.500} [get_ports clk]
set_property -dict {IOSTANDARD LVCMOS33 PACKAGE_PIN N11} [get_ports clk]
set_property -dict {IOSTANDARD LVCMOS33 PACKAGE_PIN D1} [get_ports led]
set_property CONFIG_VOLTAGE 3.3 [current_design]
set_property CFGBVS VCCO [current_design]
The Vivado tcl command opt_design generates the following error:
ERROR: [DRC INBB-3] Black Box Instances: Cell 'GND' of type 'GND/GND' has undefined contents and is considered a black box. The contents of this cell must be defined for opt_design to complete successfully.
I get the same error for cell 'VCC'.
I also get a warning related to this when calling link_design:
CRITICAL WARNING: [Netlist 29-181] Cell 'GND' defined in file 'top.edif' has pin 'Y' which is not valid on primitive 'GND'. Instance 'GND' will be treated as a black box, not an architecture primitive
Am I using Yosys incorrectly here? What's the correct flow for this? I'm new to Yosys, so forgive me if I've missed something obvious.
I'm using Yosys 0.8+147 and Vivado 2017.2
The solution is in the Yosys user manual. Vivado is complaining about the 'VCC' and 'GND' cells, so we must pass the -nogndvcc option to write_edif. As explained in the description for the -nogndvcc option, to do this we must use hilomap to associate VCC and GND with custom drivers. The full xilinx synthesis is achieved with:
synth_xilinx -top top
hilomap -hicell VCC P -locell GND G
write_edif -nogndvcc top.edif

Yosys logic loop falsely detected

I've been testing yosys for some use cases.
Version: Yosys 0.7+200 (git sha1 155a80d, gcc-6.3 6.3.0 -fPIC -Os)
I wrote a simple block which converts gray code to binary:
module gray2bin (gray, bin);
parameter WDT = 3;
input [WDT-1:0] gray;
output [WDT-1:0] bin;
assign bin = {gray[WDT-1], bin[WDT-1:1]^gray[WDT-2:0]};
endmodule
This is an acceptable and valid code in verilog, and there is no loop in it.
It passes compilation and synthesis without any warnings in other tools.
But, when I run in yosys the next commands:
read_verilog gray2bin.v
scc
I get that a logic loop was found:
Found an SCC: $xor$gray2bin.v:11$1
Found 1 SCCs in module gray2bin.
Found 1 SCCs.
The next code, which is equivalent, pass the check:
module gray2bin2 (
gray,
bin
);
parameter WDT = 3;
input [WDT-1:0] gray;
output [WDT-1:0] bin;
assign bin[WDT-1] = gray[WDT-1];
genvar i;
generate
for (i = WDT-2; i>=0; i=i-1) begin : gen_serial_xor
assign bin[i] = bin[i+1]^gray[i];
end
endgenerate
endmodule
Am I missing a flag or synthesis option of some kind?
Using word-wide operators this circuit clearly has a loop (generated with yosys -p 'prep; show' gray2bin.v):
You have to synthesize the circuit to a gate-level representation to get a loop-free version (generated with yosys -p 'synth; splitnets -ports; show' gray2bin.v, the call to splitnets is just there for better visualization):
The answer given by CliffordVienna indeed gives a solution, but I also want to clarify that that it's not suitable to all purposes.
My analysis was done for the purpose of formal verification. Since I replaced the prep to synth to solve the falsely identified logic loops, my formal code got optimized. Wires which I've created that were driven only by the assume property pragma, were removed - this made many assertions redundant.
It's not correct to reduce any logic for the purpose of behavioral verification.
Therefore, if the purpose is to prepare a verification database, I suggest not to use the synth command, but to use a subset of commands the synth command executes.
You can find those commands under:
http://www.clifford.at/yosys/cmd_synth.html
In general, I've used all the commands specified in the above link that do not optimize logic:
hierarchy -check
proc
check
wreduce
alumacc
fsm
memory -nomap
memory_map
techmap
abc -fast
hierarchy -check
stat
check
And everything works as expected.

What are the useful attributes that can be used with passes in Yosys?

What are the most useful attributes that can be used with passes in Yosys?
Also, I was wondering if you could give me an example to set 'keep_hierarchy' for a specific module (namely "counter") using 'setattr'.
The README File contains a list of the most prominent attributes. (Section "Verilog Attributes and non-standard features".)
Regarding keep_hierarchy and setattr: Consider the following example code.
module test(input A, B, output X, Y);
test_and and_inst (.A(A), .B(B), .O(X));
test_xor xor_inst (.A(A), .B(B), .O(Y));
endmodule
module test_and(input A, B, output O);
assign O = A & B;
endmodule
module test_xor(input A, B, output O);
assign O = A ^ B;
endmodule
Obviously the following would just display a schematic with a $and and a $xor gate:
yosys -p 'prep; flatten; opt -purge; show test' test.v
Now we can prevent flatten from flattening and_inst by setting the keep_hierarchy attribute on the cell:
yosys -p 'prep; setattr -set keep_hierarchy 1 test/and_inst; flatten; opt -purge; show test' test.v
Alternatively we can prevent all instances of test_and to be flattened by simply setting the attribute on the module itself:
yosys -p 'prep; setattr -mod -set keep_hierarchy 1 test_and; flatten; opt -purge; show test' test.v

LLVM ScalarEvolution Pass Cannot Compute Exit Count for Loop Vectorizer

I'm trying to figure out how to run LLVM's built-in loop vectorizer. I have a small program containing an extremely simple loop (I had some output at one point which is why stdio.h is still being included despite never being used):
1 #include <stdio.h>
2
3 unsigned NUM_ELS = 10000;
4
5 int main() {
6 int A[NUM_ELS];
7
8 #pragma clang loop vectorize(enable)
9 for (int i = 0; i < NUM_ELS; ++i) {
10 A[i] = i*2;
11 }
12
13 return 0;
14 }
As you can see, it does nothing at all useful; I just need the for loop to be vectorizable. I'm compiling it to LLVM bytecode with
clang -emit-llvm -O0 -c loop1.c -o loop1.bc
llvm-dis -f loop1.bc
Then I'm applying the vectorizer with
opt -loop-vectorize -force-vector-width=4 -S -debug loop1.ll
However, the debug output gives me this:
LV: Checking a loop in "main" from loop1.bc
LV: Loop hints: force=? width=4 unroll=0
LV: Found a loop: for.cond
LV: SCEV could not compute the loop exit count.
LV: Not vectorizing: Cannot prove legality.
I've dug around in the LLVM source a bit, and it looks like SCEV comes from the ScalarEvolution pass, which has the task of (among other things) counting the number of back edges back to the loop condition, which in this case (if I'm not mistaken) should be the trip count minus the first trip (so 9,999 in this case). I've run this pass on a much larger benchmark and it gives me the exact same error at every loop, so I'm guessing it isn't the loop itself, but that I'm not giving it enough information.
I've spent quite a bit of time combing through the documentation and Google results to find an example of a full opt command using this transformation, but have been unsuccessful so far; I'd appreciate any hints as to what I may be missing (I'm new to vectorizing code so it could be something very obvious).
Thank you,
Stephen
vectorization depends on number of other optimization which needs to be run before. They are not run at all at -O0, therefore you cannot expect that your code would be 'just' vectorized there.
Adding -O2 before -loop-vectorize in opt cmdline would help here (make sure your 'A' array is external / used somehow, otherwise everything will be optimized away).

gcc transformation pass for ackermann

gcc (I tried 4.7.2 on Mac and Linux with -O3 flag) optimizes ackermann function to a single call with a big local stack. An example Ackermann code below:
int ack(int m,int n){
if(m == 0) return n+1;
if(n == 0) return ack(m-1,1);
return ack(m-1,ack(m,n-1));
}
When disassembled, there is only one recursive call to ack function, instead of two calls (I couldn't parse what is going on -ack is now transformed by gcc into a function with 8 arguments, and local stack of 49 int and 9 char). I tried to look up what kind of transformation passes gcc did to optimize Ackermann function to a single call, but didn't find anything of interest. I will appreciate pointers on what major transformation passes gcc performed to convert the deeply recursive Ackermann to a single recursive call. LLVM gcc (I tried v4.2 on mac) doesn't reduce it to single recursive call yet, and is 4x slower with -O3 flag. This optimization seems very interesting.
The first pass is tail-call elimination. GCC does this at most optimization levels. Essentially, all function calls in tail position are transformed into goto's, like this:
int ack(int m, int n) {
begin:
if (m == 0) return n + 1;
if (n == 0) { m -= 1; n = 1; goto begin; }
n = ack(m, n-1); m -= 1; goto begin;
}
Now there is only one recursive call remaining and GCC, at -O3 level only, inlines this for a couple of iterations. Resulting in the huge monster you saw.