My top level verilog module declares signals for the four LEDs on the myStorm ice40 board, which are labelled "LED1-LED4".
module top (
output [4:1] LED
);
assign LED = 4'b1010;
endmodule
I use the same numbering in the .pcf file:
set_io LED[1] 37
set_io LED[2] 38
set_io LED[3] 39
set_io LED[4] 41
But in the .blif output, yosys has renumbered the signals:
.model top
.inputs
.outputs LED[0] LED[1] LED[2] LED[3]
...
so arachne-pnr complains:
top.pcf:4: fatal error: no port `LED[4]' in top-level module `top'
Does yosys expect that top level vector ports are always numbered from zero?
The reason for this is that the Yosys BLIF back-end was not using the hints for start offset and direction (upto/downto) stored in a Yosys Wire object for generating the single-bit net names.
This is now fixed in commit 5c2c78e2dd. Thanks for bringing this to my attention.
Update to latest git head of Yosys and you should get the results that you are expecting.
Related
I am using yosys to synthesize using the synth_ice40 command which calls ABC as well. In my Verilog code, I have used (* keep *) wire wire_1; Yosys does not optimize this but when it comes to ABC, it removes these unused wires. Is there anything equivalent to (* keep *) which could be used in Verilog which ABC does not optimize and remove the certain wires?
Any help would be appreciated.
Thanks,
Log:
`.44.2. Continuing TECHMAP pass.
No more expansions possible.
Removed 0 unused cells and 3 unused wires.
2.45. Executing OPT_LUT pass (optimize LUTs).
Discovering LUTs.
Number of LUTs: 1
2-LUT 1
Eliminating LUTs.
Number of LUTs: 1
2-LUT 1
Combining LUTs.
Number of LUTs: 1
2-LUT 1
Eliminated 0 LUTs.
Combined 0 LUTs.
<suppressed ~2 debug messages>
2.46. Executing TECHMAP pass (map to technology primitives).
2.46.1. Executing Verilog-2005 frontend: /usr/local/bin/../share/yosys/ice40/cells_map.v
Parsing Verilog input from /usr/local/bin/../share/yosys/ice40/cells_map.v' to AST representation. Generating RTLIL representation for module $lut'.
Successfully finished Verilog frontend.
2.46.2. Continuing TECHMAP pass.
Using template $paramod$lut\WIDTH=2\LUT=4'1000 for cells of type $lut.
No more expansions possible.
<suppressed ~14 debug messages>
Removed 0 unused cells and 2 unused wires.`
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
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.
Consider the example:
read_verilog ./tests/simple/fsm.v
synth -flatten -top fsm_test
abc -g AND
write_aiger -ascii -symbols hoho.aag
The resulting AIGER file contains input variable clk, which is dangling.
Is it possible to avoid introducing such clock input into AIGER?
Thanks.
Not automatically. The following options exist:
Simply use the SystemVerilog $global_clock feature to avoid having a clock input at all. Use always #($global_clock) instead of always #(posedge clk) and then remove the clk input from your design.
Remove the clock input near the end of your synthesis script. I.e. right before calling write_aiger call something like delete -input fsm_test/clk. This will turn the clock signal into a dangling wire internal to the module. You should avoid doing that before running a lot of optimization commands, or you risk Yosys optimizing away all your FFs. But doing that near the end of your script should be fine.
You can combine 2. with mapping your FFs to $ff/$_FF_ cells (the kind of FF cells generated by $global_clock-blocks). The advantage of this approach is that it makes the clk wire truly unused, so there is no risk of optimizations messing with your FFs because they have an undriven clock input. I've now added a dff2ff.v techmap file in commit e7a984a that simplifies this a bit.
Script for option 2:
read_verilog ./tests/simple/fsm.v
synth -flatten -top fsm_test
abc -g AND
delete -input fsm_test/clk
write_aiger -ascii -symbols hoho.aag
Script for option 3 (requires Yosys git commit e7a984a or later):
read_verilog ./tests/simple/fsm.v
hierarchy -top fsm_test
proc
techmap -map +/dff2ff.v
delete fsm_test/clk
synth -flatten
abc -g AND
write_aiger -ascii -symbols hoho.aag
I am new to this domain.
I want to transmit data using GFSK modulation using GNU Radio which response to the following specifications :
Deviation : +/-2,4 kHz +0,2%
Modulation index : 2
Filter index : 0.5 BT
Bitrate : 2400 bit/s
I want to transmit this data (data is in HEXA):
Preamble : 55 55
Synchro : F6 72
L-field ( data + CRC) : 20
Please start with the gr-digital (part of GNU Radio dist) GFSK Mod block. Take a peek at the source python, and then you'll want to look at the gr-analog frequency_modulation.h source for details about FM, specifically frequency deviation. For some reason, the doxygen output does not generate the embedded formula, which is why looking at the header file is suggested.
Then I suggest you do some simple experiments in GNU Radio Companion to better understand the GFSK Mod block.
Hope this helps.
I have based on this example of FSK transmitter, https://nccgroup.github.io/RFTM/fsk_transmitter.html
so you need juste to put the value of BT equal to 0.5 to make a GFSK transmitter. And everthing works correctely.