Yosys gives syntax error on 2d interface - yosys

I get "syntax error" on 2D interface declaration in Yosys, even with the "-sv" flag.
Is there a way to make Yosys accept the next syntax?
module somename #(
parameter WDT = 3,
parameter CNT = 2
) (
input [WDT-1:0] in_a [CNT-1:0],
output [WDT-1:0] out_b [CNT-1:0]
);
Thanks!

Yosys's read_verilog -sv only supports a tiny subset of SystemVerilog. Array ports are not supported.
If you have access to the Verific library then you can build Yosys with Verific support and use that to read SystemVerilog sources:
verific -sv test.sv
verific -import somename

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

Can I avoid opt_merge from removing a BUF? (Yosys tri-state workaround)

I know yosys has limited tri-state support, but I'm looking for a possible workaround.
The following circuit:
module TBUF2
(
inout SALIDA1,
inout SALIDA2,
input OE,
output C);
assign SALIDA1=OE ? 1'b0 : 1'bZ;
assign SALIDA2=OE ? 1'b0 : 1'bZ;
wire e;
assign e=SALIDA1 & SALIDA2;
assign C=e;
endmodule
Is interpreted as:
TBUF2 parsed tree
Note that when OE is 0 C=SALIDA1 and SALIDA2.
During the opt pass, the opt_merge pass removes $2 mux and generates:
TBUF2 optimized
This breaks the circuit (when OE is 0 then C=SALIDA1). I realize this is because yosys/ABC doesn't really understand the consequences of the "1'z" input.
Is it possible to keep muxes that meet the following criteria?:
1) At least one input is 1'Z
2) Its output drives an inout pin
Here is the script to reproduce it:
read_verilog tbuf2.v
proc
show -format dot -prefix tbuf2_01
opt
show -format dot -prefix tbuf2_02
Convert the tristate buffer $mux cells to $tribuf cells by running the tribuf command after proc and before running any opt commands.

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.

Find and Replace an operation in Verilog using Yosys

I am trying to see if Yosys fits my requirements or no.
What i want to do is to find an operation in Verilog code (e.g. temp = 16*val1 + 8*val2 ) and replace this with another op like ( temp = val1 << 4 + val2 << 3 ).
Which parts i need to learn & use from Yosys? if anyone knows the set of command to use, can he/she please let me know to boost my learning curve ?
Thanks.
For example consider the following verilog input (test.v):
module test(input [7:0] val1, val2, output [7:0] temp);
assign temp = 16*val1 + 8*val2;
endmodule
The command yosys -p 'prep; opt -full; show' test.v will produce the following circuit diagram:
And the output written to the console contains this:
3.1. Executing OPT_EXPR pass (perform const folding).
Replacing multiply-by-16 cell `$mul$test.v:2$1' in module `\test' with shift-by-4.
Replacing multiply-by-8 cell `$mul$test.v:2$2' in module `\test' with shift-by-3.
Replacing $shl cell `$mul$test.v:2$1' (B=3'100, SHR=-4) in module `test' with fixed wiring: { \val1 [3:0] 4'0000 }
Replacing $shl cell `$mul$test.v:2$2' (B=2'11, SHR=-3) in module `test' with fixed wiring: { \val2 [4:0] 3'000 }
The two lines reading Replacing multiply-by-* cell are the transformation you mentioned. The two lines after that replace the constant shift operations with wiring, using {val1[3:0], 4'b0000} and {val2[4:0], 3'b000} as inputs for the adder.
This is done in the opt_expr pass. See passes/opt/opt_expr.cc for its source code to see how it's done.

How to store a result to a variable in HP OpenVMS DCL?

I want to save the output of a program to a variable.
I use the following approach ,but fail.
$ PIPE RUN TEST | DEFINE/JOB VALUE #SYS$PIPE
$ x = f$logical("VALUE")
I got an error:%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
\WORLD\
reference :
How to assign the output of a program to a variable in a DCL com script on VMS?
The usual way to do this is to write the output to a file and read from the file and put that into a DCL symbol (or logical). Although not obvious, you can do this with the PIPE command was well:
$ pipe r 2words
hello world
$ pipe r 2words |(read sys$pipe line ; line=""""+line+"""" ; def/job value &line )
$ sh log value
"VALUE" = "hello world" (LNM$JOB_85AB4440)
$
IF you are able to change the program, add some code to it to write the required values into symbols or logicals (see LIB$ routines)
If you can modify the program, using LIB$SET_SYMBOL in the program defines a DCL symbol (what you are calling a variable) for DCL. That's the cleanest way to do this. If it really needs to be a logical, then there are system calls that define logicals.