https://lists.librecores.org/pipermail/symbiflow/2021-December/000049.html

Hello,

I am attempting to build FonTamSOC targeting NexysA7.

However, symbiflow_synth fails with ERROR: Incorrect period value at the end of the logs.

Steps to reproduce failure:

# clone verilog sources:
git clone https://github.com/fontamsoc/hw.git
git checkout issues/177
cd hw

# prerequisite:
ln -snf pu32-nexys4ddr/litedram/litedram.hex litedram.hex

# synthesize:
symbiflow_synth -t nexys4ddr -v pu32-nexys4ddr/nexys4ddr.v -d artix7
-p xc7a100tcsg324-1 -x pu32-nexys4ddr/nexys4ddr.xdc &>/dev/null

tail nexys4ddr_synth.log

The error seems to come from
https://github.com/SymbiFlow/yosys-symbiflow-plugins/blob/master/sdc-plugin/sdc.cc#L153

I'm guessing that the error is coming from line 4 of your .xdc file but the
current output doesn't really give you enough information to know or
confirm that. I recommend logging a bug on either symbiflow-examples or
yosys-symbiflow-plugins with your reproduction instructions and output you
have provided.

Next steps would probably be to improve the error message with the value it
thinks is invalid. The code also doesn't seem to know the difference
between the create_clock command getting invalid value for -period and the
command not getting a -period argument all together.

Second step would be to figure out how to create / throw the error message
so it reports the file and line number where the issue is found.

Hope that helps,

Tim 'mithro' Ansell

(since I can't file issues with https://github.com/antmicro/yosys-symbiflow-plugins, filed here).

Once the Andmicro branch is rebased to head of this repository, it is easier for places that now use yosys-symbiflow-plugins head to switch to the Antmicro fork.

Also since now the plugin is working, even if it is not 'complete' yet, consider actually continuing the development on this upstream repository to further simplify the dependency management for people who want to play with it.

One of the latest commits (c613a35) added the install -D command.

After that change building the plugins on macOS fails in the https://github.com/litex-hub/litex-conda-eda repository.

The BSD's install -d seems to have a similar meaning to the GNU's install -D but I'm not sure about that:

     -d      Create directories.  Missing parent directories are created as required.

It'd be great if the script could either have install used universally to both implementations or simply have the commands replaced in the commit with install as a fail-over for macOS.

This is in relation to YosysHQ/yosys#3078 where I was told that the debug output of Yosys is just misleading, i.e. the problem should be elsewhere in the toolchain.

Given the following Verilog input:

module Top(
           output [5:2] LED
           );

   assign LED[5:2] = 4'b1101;
endmodule

I am synthesizing for the Nexys A7 50T dev board with a Xilinx xc7a50tcsg324 FPGA. I connect LED[5:2] to the LEDs on board with the following XDC:

set_property -dict { PACKAGE_PIN J13   IOSTANDARD LVCMOS33 } [get_ports { LED[2] }];
set_property -dict { PACKAGE_PIN N14   IOSTANDARD LVCMOS33 } [get_ports { LED[3] }];
set_property -dict { PACKAGE_PIN R18   IOSTANDARD LVCMOS33 } [get_ports { LED[4] }];
set_property -dict { PACKAGE_PIN V17   IOSTANDARD LVCMOS33 } [get_ports { LED[5] }];

If I synthesize this with Vivado, LEDs 2, 4 and 5 light up, as expected. If I synthesize this with Symbiflow, instead only LED 2 lights up.

Full reproducer is at https://github.com/gergoerdi/yosys-symbiflow-plugins-issue-144/tree/81f4cd6878574614f08269e44ec8df72a857c640

Example module

module anon_module 

   (
    output logic                                    all_done 
    );

   typedef struct packed {
     logic                      a;
     logic                      b;
   } typedef_struct_thing;

   typedef_struct_thing [50:0]   data;  

   struct packed {
     logic a;
     logic [100:0]      b;
   } [200:0] anon_struct;
     

   always_comb begin
     data[0].a = 0; //ok
     anon_struct[0].a = 0; // Not ok
     all_done = anon_struct.a;
   end

endmodule : anon_module

This example will fail to be read into yosys. Specifically it lacks the information added by add_multirange_attribute both multirange inputs are totally empty in the case of anon_struct, but are filled in for data. Giving a typedef name to the anon struct also fixes the issue.

I don't see any documentation on how to perform a local install (i.e. under /usr/local).

If I run make, most of the sub-builds succeed generating .so files, although I get this error (@hzeller ?):

In file included from uhdmastshared.h:4,
                 from UhdmAst.h:8,
                 from uhdmsurelogastfrontend.cc:22:
uhdmastreport.h:9:10: fatal error: uhdm/uhdm.h: No such file or directory
    9 | #include <uhdm/uhdm.h>
      |          ^~~~~~~~~~~~~
compilation terminated.

When I try sudo make install, I get

make -C fasm-plugin install
make[1]: Entering directory '/home/tcal/SymbiFlow/yosys-f4pga-plugins/fasm-plugin'
../Makefile_plugin.common:47: *** "Didn't find 'yosys-config' under '/'".  Stop.
make[1]: Leaving directory '/home/tcal/SymbiFlow/yosys-f4pga-plugins/fasm-plugin'
make: *** [Makefile:37: install_fasm] Error 2

This seems to be some strange interaction between sudo and the calculation of YOSYS_PATH in Makefile_plugin.common. I do have both /usr/local/bin/yosys and /usr/local/bin/yosys-config, so YOSYS_PATH should be /usr/local. At my command line, sudo which yosys returns nothing, even though sudo echo $PATH contains /usr/local/bin.

A workaround is to run sudo make install YOSYS_PATH=/usr/local, but it seems something is broken.

The XDC constraint file can contain dictionaries of properties to enable for a given port:

set_property -dict { LOC A1 IOSTANDARD LVCMOS33 } [get_ports {port}]

Currently the XDC plugin is not yet able to parse dictionaries.

It seems that the test_full_adder for ql-qlf plugin fails due to a Yosys/ABC instability. Different builds from the same commit yields in different type and count of LUTs inferred for the comparator case on PP3 architecture.

Since this change in yosys, it is not possible to build the plugins.

Related upstream issue: YosysHQ/yosys#2173
Related fork merge: SymbiFlow/yosys#80

It seems that some sdc solutions (like Quartus and Vivado) support the optional -add argument to create_clock, see below;

create_clock -add -name clk100mhz_i -period 10.00 -waveform {0 5} [get_ports {clk100mhz_i}];

https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/tafs/tafs/tcl_pkg_sdc_ver_1.5_cmd_create_clock.htm

create_clock [-h | -help] [-long_help] [-add] [-name <clock_name>] -period <value> [-waveform <edge_list>] [<targets>]

...

   -add       Adds clock to a node with an existing clock

...

The semantics are described as;

If a clock with the same name is already assigned to a given target, the create_clock command will overwrite the existing clock. If a clock with a different name exists on the given target, the create_clock command will be ignored unless the -add option is used. The -add option can be used to assign multiple clocks to a pin or port.

We should make sure we have tests for;

• Using create_clock with the same name on a given pin/port replaces the existing clock.
• Using create_clock with a different name on given pin/port the result is ignored (but we should issue a highly visible warning that this is occuring).
• Using create_clock with -add is able to assign multiple clocks to a given pin/port.

It is likely with the current semantics people do things like;

• Step 1 - Select all pins and set constraint A
• Step 2 - Select some pins and override the existing constraint A with a different constraint B

PR #57 has been created to fix the reported problem.
This is needed to the 200T designs to work with SymbiFlow, but the problem is in fact in VPR as it sweeps the netlist and invalidates an SDC that was originally valid.

https://github.com/SymbiFlow/actions/tree/main/checks

Many public XDC files provide get_ports arguments in curly brackets:
https://github.com/Digilent/digilent-xdc/blob/master/Arty-A7-35-Master.xdc#L7

Currently, support for this feature is missing / incomplete. The following XDC file:

set_property PACKAGE_PIN E3 [get_ports { clk }]
set_property IOSTANDARD LVCMOS33 [get_ports { clk }]
create_clock -period 10.0 clk

causes the following error during the Yosys synthesis step:

...
7.38.3. Continuing TECHMAP pass.
Using template $paramod\$lut\WIDTH=1\LUT=2'01 for cells of type $lut.
No more expansions possible.
7.39. Executing XILINX_DFFOPT pass (optimize FF control signal usage).
Optimizing FFs in top.
7.40. Executing OPT_LUT_INS pass (discard unused LUT inputs).
Optimizing LUTs in top.
Removed 0 unused cells and 2 unused wires.
8. Executing HIERARCHY pass (managing design hierarchy).
8.1. Analyzing design hierarchy..
Top module:  \top
8.2. Analyzing design hierarchy..
Top module:  \top
Removed 0 unused modules.
set_property PACKAGE_PIN E3 [get_ports { clk }]
set_property IOSTANDARD LVCMOS33 [get_ports { clk }]
create_clock -period 10.0 clk
Warning: Couldn't find port matching  clk
ERROR: set_property IO_LOC_PAIRS: Incorrect number of arguments.

After removing the curly brackets, everything works as intended:

set_property PACKAGE_PIN E3 [get_ports clk]
set_property IOSTANDARD LVCMOS33 [get_ports clk]
create_clock -period 10.0 clk

When an error is reported, it should include information about what is wrong.

See the following examples which could be improved;

• https://github.com/SymbiFlow/yosys-symbiflow-plugins/blob/91d7db03ddbee23f9ff91f395de1692a37e51362/sdc-plugin/sdc.cc#L130

  log_cmd_error("Found only %i arguments but a minimum of 3 are required\n", args.size());

• https://github.com/SymbiFlow/yosys-symbiflow-plugins/blob/91d7db03ddbee23f9ff91f395de1692a37e51362/sdc-plugin/sdc.cc#L153

  log_cmd_error("Found non-positive period value of %f, periods must be positive and greater than zero\n", period);

  (It should also be noted that this code does not differentiate between a period not being provided and a period of zero or negative value being provided.)

When LOCing a port to a specific PAD, the XDC can have to different forms

1. set_property LOC A1 [get_ports {port}]
2. set_property PACKAGE_PIN A1 [get_ports {port}]

Case 1 is handled, while case 2 is missing, causing the port to remain unconstrained.

All the plugins should have nice documentation published on Sphinx.

Currently VPR will not pull FF into IO to improve timing. the VPR XML will allow dff macro to be directly instantiated into the Verilog code. Need to add support for the dffr macro.

Example

module NAME
(
//...
output reg [1 : 0] signal_a,
//...
)
always @(posedge sys_clk or negedge rst_b)
begin
if(!rst_b)
signal_a <= 0;
else
signal_a <= signal_a_next;
end

always @(*)
    begin
    signal_a_next = /* the signal is formed based on signals from some other internal flip-flops */
    end 

Since there is no logic between last flip-flops and output port we need these FFs (“signal_a”) to be placed in the IO FF and as result setup time of the output signal should be more consistent.

I think we may have a conceptual mismatch with how Vivado treats clock objects. The clock object on both sides of a IBUF and BUFG are the same clock object. So for example, there should really just be 1 clock clk, which has multiple netss that are on that clock. PLL's / MMCM's and BUFGCTRL's do split clock definitions because the underlying properties of the clock change across the elements.

Clock objects have properties (e.g. waveform, period, is generated)
Clocks can have relationships to each other (e.g. false path, jitter, https://docs.verilogtorouting.org/en/latest/vpr/sdc_commands/#set-max-delay-set-min-delay)
Nets may have a clock object they are associated with. The propagation step should associate nets with their clocks as needed (e.g. propagate through IBUF/BUFG).
Some cells (PLL/MMCM) define generated clocks using a relationship between the source clock and output clock. The propagate through PLL/MMCM should generate these related clocks.

The propagation that occurs should probably be something akin too:

• Does this element change the clock -> No:

  • If the output net has no explicit clock membership, mark the net as being part of the same clock

• Does this element change the clock -> Yes:

  • If the output net has an explicit clock definition, do nothing
  • If the output net has no explicit clock definition, create a new generated clock with the new properties based on the elements configuration (e.g. PLL creates a new clock with period X, waveform Y Z).

Both yosys and VPR report githash and version when used:

yosys:

 Yosys 0.9+932 (git sha1 8fe9c84e, clang 8.0.1-3+build1 -fPIC -Os)

VPR:

Version: 8.0.0-rc1+21df3a5d0
Revision: v8.0.0_rc1_1532_g92e57c2d0_127_g7b9b69d0e_428_g1c5263d74_290_g3b3182dd7-636-g21df3a5d0
Compiled: 2020-02-10T14:02:51
Compiler: Clang 7.0.1 on Linux-5.2.17-1rodete3-amd64 x86_64

The yosys XDC and FASM plugins should do something similar.

The SDC commands used in the auto-generated XDC PR are:

• create_clock
• set_false_path
• set_max_delay
• set_clock_groups
• get_clocks

create_clock is already supported in the SDC plugin, however the target net is wrapped in the get_nets command which needs to be handled.

In the first approach all the set_false_path and set_max_delay and set_clock_groups commands shall simply be forwarded to the output SDC and passed 'as is' to VPR.

It's a TCL thing. When a port is retrieved using eg. [get_ports A[10]] the TCL parser treats the port index in square brackets as another TCL command and fails there. This prevents us from using stock XDC files. A workaround for that is to specify the port like [get_ports {A[10]}].

A fix may be doing some kind of pre-processing of XDCs prior to feeding them to the Yosys' TCL interpreter.

XDC plugin should set default value of DRIVE property if IOSTANDARD property is set.

SDC information should be imported into Yosys from XDC and attached to the right entities.
Next the information should propagate across PLL, BUF, MCMM primitives.
Finally, the SDC information should be exported from Yosys in form of an SDC file.

Currently the build-and-test.sh script uses echos to add travis sections.
This could be done with nice utlity functions added to the common travis script, like https://github.com/litex-hub/litex-conda-packages/blob/9b201004a699af707afc0745e57a06c223e4f545/.travis/common.sh#L32-L43

Running tests that compare against golden files are sensitive to the particular yosys the golden files have been produces with, as they often contain generated names that are dependent on the circumstances.

For instance, running

make test_design_introspection

on my machine results gets a different result for the cells compared to the golden file

< {$abc$1984$lut$not$aiger1983$1} {$auto$alumacc.cc:485:replace_alu$1385.slice[0].carry4} {$auto$alumacc.cc:485:replace_alu$1385.slice[1].carry4} {$auto$alumacc.cc:485:replace_alu$1385.slice[2].carry4} {$auto$alumacc.cc:485:replace_alu$1385.slice[3].carry4} {$auto$alumacc.cc:485:replace_alu$1385.slice[4].carry4} {$auto$alumacc.cc:485:replace_alu$1385.slice[5].carry4} {$auto$alumacc.cc:485:replace_alu$1385.slice[6].carry4} {$auto$simplemap.cc:420:simplemap_dff$1471} {$auto$simplemap.cc:420:simplemap_dff$1472} {$auto$simplemap.cc:420:simplemap_dff$1473} {$auto$simplemap.cc:420:simplemap_dff$1474} {$auto$simplemap.cc:420:simplemap_dff$1475} {$auto$simplemap.cc:420:simplemap_dff$1476} {$auto$simplemap.cc:420:simplemap_dff$1477} {$auto$simplemap.cc:420:simplemap_dff$1478} {$auto$simplemap.cc:420:simplemap_dff$1479} {$auto$simplemap.cc:420:simplemap_dff$1480} {$auto$simplemap.cc:420:simplemap_dff$1481} {$auto$simplemap.cc:420:simplemap_dff$1482} {$auto$simplemap.cc:420:simplemap_dff$1483} {$auto$simplemap.cc:420:simplemap_dff$1484} {$auto$simplemap.cc:420:simplemap_dff$1485} {$auto$simplemap.cc:420:simplemap_dff$1486} {$auto$simplemap.cc:420:simplemap_dff$1487} {$auto$simplemap.cc:420:simplemap_dff$1488} {$auto$simplemap.cc:420:simplemap_dff$1489} {$auto$simplemap.cc:420:simplemap_dff$1490} {$auto$simplemap.cc:420:simplemap_dff$1491} {$auto$simplemap.cc:420:simplemap_dff$1492} {$auto$simplemap.cc:420:simplemap_dff$1493} {$auto$simplemap.cc:420:simplemap_dff$1494} {$auto$simplemap.cc:420:simplemap_dff$1495} {$auto$simplemap.cc:420:simplemap_dff$1496} {$iopadmap$top.clk} OBUFTDS_2 OBUF_6 OBUF_7 OBUF_OUT bottom_inst.OBUF_10 bottom_inst.OBUF_11 bottom_inst.OBUF_9 bottom_intermediate_inst.OBUF_8
---
> {$abc$2067$lut$not$aiger2066$1} {$auto$alumacc.cc:485:replace_alu$1466.slice[0].carry4} {$auto$alumacc.cc:485:replace_alu$1466.slice[1].carry4} {$auto$alumacc.cc:485:replace_alu$1466.slice[2].carry4} {$auto$alumacc.cc:485:replace_alu$1466.slice[3].carry4} {$auto$alumacc.cc:485:replace_alu$1466.slice[4].carry4} {$auto$alumacc.cc:485:replace_alu$1466.slice[5].carry4} {$auto$alumacc.cc:485:replace_alu$1466.slice[6].carry4} {$auto$simplemap.cc:420:simplemap_dff$1552} {$auto$simplemap.cc:420:simplemap_dff$1553} {$auto$simplemap.cc:420:simplemap_dff$1554} {$auto$simplemap.cc:420:simplemap_dff$1555} {$auto$simplemap.cc:420:simplemap_dff$1556} {$auto$simplemap.cc:420:simplemap_dff$1557} {$auto$simplemap.cc:420:simplemap_dff$1558} {$auto$simplemap.cc:420:simplemap_dff$1559} {$auto$simplemap.cc:420:simplemap_dff$1560} {$auto$simplemap.cc:420:simplemap_dff$1561} {$auto$simplemap.cc:420:simplemap_dff$1562} {$auto$simplemap.cc:420:simplemap_dff$1563} {$auto$simplemap.cc:420:simplemap_dff$1564} {$auto$simplemap.cc:420:simplemap_dff$1565} {$auto$simplemap.cc:420:simplemap_dff$1566} {$auto$simplemap.cc:420:simplemap_dff$1567} {$auto$simplemap.cc:420:simplemap_dff$1568} {$auto$simplemap.cc:420:simplemap_dff$1569} {$auto$simplemap.cc:420:simplemap_dff$1570} {$auto$simplemap.cc:420:simplemap_dff$1571} {$auto$simplemap.cc:420:simplemap_dff$1572} {$auto$simplemap.cc:420:simplemap_dff$1573} {$auto$simplemap.cc:420:simplemap_dff$1574} {$auto$simplemap.cc:420:simplemap_dff$1575} {$auto$simplemap.cc:420:simplemap_dff$1576} {$auto$simplemap.cc:420:simplemap_dff$1577} {$iopadmap$top.clk} OBUFTDS_2 OBUF_6 OBUF_7 OBUF_OUT bottom_inst.OBUF_10 bottom_inst.OBUF_11 bottom_inst.OBUF_9 bottom_intermediate_inst.OBUF_8

So to compare, these should probably scrub the individual names, so that a comparison can just focus on the structure of the output.

Current Makefile fails when used in Windows conda enviroment.
yosys-config outputs:

> yosys-config --cxx
x86_64-w64-mingw32-g++
> yosys-config --cxxflags
-Wall -Wextra -ggdb -IC:/Users/user/Miniconda3/share/yosys/include -MD -D_YOSYS_ -IC:/Users/user/Miniconda3/include -std=c++11 -Os -D_POSIX_SOURCE -DYOSYS_WIN32_UNIX_DIR -DYOSYS_ENABLE_GLOB -DYOSYS_ENABLE_ABC
> yosys-config --ldlibs
-static -lstdc++ -lm

I attach patch with minimal changes needed to have successful build.
win_build.txt

The symbiflow-arch-defs PR f4pga/f4pga-arch-defs#1321 causes the following assertion failure:

#terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)

when the target file_xc7_tests_ddr_ddr_uart_arty_artix7-xc7a50t-virt-xc7a50t-test_top.eblif is built. It is unclear if this is a latent yosys bug or a latent XDC plugin bug.

@tmichalak: Ideas?

The objective is to divide the functionalities of the current SDC plugin into 2 optionally 3 separate plugins:

1. 'sdc' -- The part which reads SDC into the Yosys attributes, i.e. read_sdc and write_sdc
2. 'propagate-constraints' -- The part which propagates the constraints in the Yosys attributes across things like clock buffers and similar, i.e. propagate_clocks (and maybe future things like generate_pll_config or something?)
3. (optionally) 'pcf' -- In case we end up wanting a read_pcf or read_other_timing_constraint_format plugins which pull data into the same Yosys attributes.

In the current SDC plugin implementation the clock information is not assigned to parameters but kept in a separate Clocks class object. The object would have to be global in order to work for all timing related plugins or the clock information would have to be stored in the RTLIL::Wire parameters in form of extra parameters.

Should there potentially be a test for this?

Originally posted by @mithro in #9 (comment)

The plugins support as a part of yosys to use in windows?

Currently the get_count and select_to_tcl_list commands are implemented as separate plugins.
Since they are used to get information about the design it makes sense to integrate them into the design_introspection plugin.

Currently if the file that is read with the read_xdc command contains an unknown command no error is reported.
This is caused by the fact that read_xdc makes use of the unknown args procedure and implements the handler which returns the string of the called command surrounded by square bracket.
We need to make sure commands that are not number will error out.

@mkurc-ant -- this may be a packaging issue -- I'm using yosys and yosys-symbiflow-plugins packages from litex-hub -- I get an error from Yosys:

ERROR: Can't load module `./dsp_ff': /media/tim/GIT/google/CFU-Playground/env/conda/envs/cfu-common/bin/../share/yosys/plugins/dsp_ff.so: cannot open shared object file: No such file or directory

but there is a file

/media/tim/GIT/google/CFU-Playground/env/conda/envs/cfu-common/bin/../share/yosys/plugins/dsp-ff.so

(note dsp_ff.so vs dsp-ff.so)

With the clock propagation enhancements done in #54, the resulting SDC does not take into account the output clock from BUFGs connected to the PLL outputs.

This causes VPR to not correctly constrain clock signals, resulting in higher run-time and an nan CPD, such as in the following example:

PLLE2_ADV #(
        .CLKFBOUT_MULT(4'd12),
        .CLKIN1_PERIOD(10.0),
        .CLKOUT0_DIVIDE(5'd20),
        .CLKOUT0_PHASE(1'd0),
        .CLKOUT1_DIVIDE(3'd5),
        .CLKOUT1_PHASE(1'd0),
        .CLKOUT2_DIVIDE(3'd5),
        .CLKOUT2_PHASE(7'd90),
        .CLKOUT3_DIVIDE(3'd6),
        .CLKOUT3_PHASE(1'd0),
        .CLKOUT4_DIVIDE(6'd48),
        .CLKOUT4_PHASE(1'd0),
        .DIVCLK_DIVIDE(1'd1),
        .REF_JITTER1(0.01),
        .STARTUP_WAIT("FALSE")
) PLLE2_ADV (
        .CLKFBIN(pll_fb),
        .CLKIN1(crg_clkin),
        .RST(reset7),
        .CLKFBOUT(pll_fb),
        .CLKOUT0(crg_clkout0),
        .CLKOUT1(crg_clkout1),
        .CLKOUT2(crg_clkout2),
        .CLKOUT3(crg_clkout3),
        .CLKOUT4(crg_clkout4),
        .LOCKED(crg_locked)
);


BUFG BUFG(
        .I(crg_clkout0),
        .O(crg_clkout_buf0)
);

BUFG BUFG_1(
        .I(crg_clkout1),
        .O(crg_clkout_buf1)
);

BUFG BUFG_2(
        .I(crg_clkout2),
        .O(crg_clkout_buf2)
);

BUFG BUFG_3(
        .I(crg_clkout3),
        .O(crg_clkout_buf3)
);

BUFG BUFG_4(
        .I(crg_clkout4),
        .O(crg_clkout_buf4)
);

Resulting SDC:

create_clock -period 16.6667 -waveform {0 8.33333} crg_clkout0
create_clock -period 5 -waveform {0 2.5} crg_clkout3
create_clock -period 40 -waveform {0 20} crg_clkout4

This example is taken from the LiteX mini design, for which the crg_clkout1 and crg_clkout2 clock nets are unconnected, therefore they do not end up in the SDC, and this is expected.

The problem though is that the correct SDC for VPR should have also the crg_clkoutN_bufN clocks as well.
I notice also that the clock constraint for the input clock net to the PLL is missing as well.

It should atleast list what plugins are in this repository.

Getting logical nets out of Yosys is more tricky, we might need to examine cell connections.
The current implementation return wires, but a net may consist of multiple wires.

This affects PLL phase parameters. Instead of eg. 90.0 it has to be specified as 90000. This makes eg. LiteX generated verilog files not work.
We need to create an XDC plugin that will perform the required computations and set the values on the required parameters, which end up in eblif, instead of having to add some verilog functions during techmap translation.
Xilinx describes the dynamic reconfiguration in PLLs and MMCMs in a document

The current implementation of the SDC plugin holds RTLIL objects between TCL commands. Because of this, changes to those pointers (e.g. techmap passes, etc) cause those pointers to become invalid.

Test case for the SDC plugin attached: test.zip

I'm using the version hosted in litex-hub's conda repo thing.

I must say, I'm a bit mystified by something. In that version, with the environment set up using conda, tcl scripts using get_count work fine.

But when I set it up manually by compiling both yosys and the plugins, I get this error:

ERROR: TCL interpreter returned an error: invalid command name "get_count"

Curiously, the xdc plugin works fine even when compiled from scratch. I thought I might be using the wrong version for get_count, so I checked the shared objects on the conda installation and well, it appears that the symbol is only there in xdc.so still.

(eos-s3) [root@334715b73679 plugins]# nm get_count.so  | grep -i tcl
                 U Tcl_Eval
                 U Tcl_ListObjAppendElement
                 U Tcl_NewListObj
                 U Tcl_NewStringObj
                 U Tcl_SetObjResult
                 U _ZN5Yosys20yosys_get_tcl_interpEv
(eos-s3) [root@334715b73679 plugins]# nm xdc.so  | grep -i tcl
                 U Tcl_Eval
                 U Tcl_EvalFile
                 U Tcl_GetStringResult
                 U Tcl_SetResult
00000000000060c0 t _ZN12_GLOBAL__N_127register_in_tcl_interpreterERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
                 U _ZN5Yosys20yosys_get_tcl_interpEv

So uh, my question is, how does get_count work in the Tcl scripts for conda without registering itself?

Currently some of the test cases in f4pga-examples fail when using SystemVerilog plugin:

• #288
• hello-l
• hello-k
• litex_sata
• litex_linux
• picosoc
• #289

package new_packge;
typedef struct packed {
    logic [128:0] a;
    logic [4:0]   b;
    logic         c;
    logic         d;
    logic         e;
} zzz;
endpackage : new_package;


module module_a
  #(
    parameter type TYPE_PARAMETER = new_package::zzz,
    )
  (
   input TYPE_PARAMETER input_struct,
   output TYPE_PARAMETER output_struct,
   input clk,

   );

  always_ff @(posedge clk) begin
    output_struct <= input_struct;
  end


endmodule : module_a

I started off fixing this bug by adding the required vpiTypeParameter handler in the process_object function, but it runs into an issue with the AST in Yosys.

    case vpiTypeParameter:
        process_parameter();
        break;

Yosys by default expects it's parameters to have a defined size. It fails in UhdmAst.cc:278. The wire_node->simplify call into Yosys tries to run detectSignWidthWorker(width_hint, sign_hint, found_real); on an AST_WIRETYPE and fails.

    while (wire_node->simplify(true, false, false, 1, -1, false, false)) {
    }

The sdc-plugin uses log_cmd_error to report a number of issues, see;
https://github.com/SymbiFlow/yosys-symbiflow-plugins/blob/91d7db03ddbee23f9ff91f395de1692a37e51362/sdc-plugin/sdc.cc#L130
and
https://github.com/SymbiFlow/yosys-symbiflow-plugins/blob/91d7db03ddbee23f9ff91f395de1692a37e51362/sdc-plugin/sdc.cc#L153

However it seems that log_cmd_error doesn't provide a lot of information about what caused the error. Most importantly in the sdc-plugin it does not report the file and line number in the sdc file which causes the issue.

It is unclear to me if log_cmd_error needs to be improved or if a different function should be called instead.

Currently get_ports is doesn't support the selection mechanism as all other introspection commands.
This is due to the fact that the select command doesn't distinguish bus indexes in the wire name.
The index part has to be extracted and removed when the selection is executed, but restored during the selection extraction.
Things to fix:

• get_ports port_name[index]
• get_ports port_name*
• get_ports port_name -filter {attr == value}

The XDC plugins fails to annotate I/O bufs if they are not connected directly to the top-level port. For example, for design like that the annotation works fine:

module top (output wire top_o);

OBUF buf (
.I(some_signal),
.O(top_o)
);

...

endmodule

But for this one it does not provided that the intermediate_wire doesn't get optimized by Yosys:

module top (output wire top_o);

wire intermediate_wire;
assign top_o = intermediate_wire;

OBUF buf (
.I(some_signal),
.O(intermediate_wire)
);

...

endmodule

The XDC plugin should traverse from the top-level port down (or up) to any cell and annotate it if it is an IO buffer. Right now it considers only direct connections.

Can anyone figure out this.

TARGET="arty_35" make -C fpga
make[1]: Entering directory '/home/tahmed/TalhaUpdated/picofoxy/fpga'
cd build/arty_35 && symbiflow_synth -t Picofoxy -v /home/tahmed/TalhaUpdated/picofoxy/fpga/Picofoxy.v /home/tahmed/TalhaUpdated/picofoxy/fpga/PLL_8MHz.v /home/tahmed/TalhaUpdated/picofoxy/fpga/clk_wiz_0_clk_wiz.v   -d artix7 -p xc7a35tcsg324-1 -x ~/picofoxy/fpga/arty.xdc 2>&1 > /dev/null
ERROR: set_property IO_LOC_PAIRS: Incorrect number of arguments.
make[1]: *** [Makefile:53: build/arty_35/Picofoxy.eblif] Error 1
make[1]: Leaving directory '/home/tahmed/TalhaUpdated/picofoxy/fpga'
make: *** [Makefile:22: bitstream] Error 2