Unsupported primitives FD, FDR, FDS (Xilinx)

[rodrigomelo9]

I am new with Yosys and after read #448, I found an ERROR. Maybe was discussed in the past (I found nothing related). If not and if desired to solve, I want to help. Please, point me in what to do :P and ask for extra information if needed.

Steps to reproduce the issue

In this repo I added a file (hdl/primitives.v) and Yosys scripts to run with Spartan 6 and Series 7 (examples/s6micro/primitives.ys and examples/zybo/primitives.ys).

Expected behavior

Finish the synthesis without an ERROR or at least using a BlackBox cell model if unsupported?

Actual behavior

It fails with the following ERROR:

2.3.1. Analyzing design hierarchy..
Top module:  \primitives
ERROR: Module `\FD' referenced in module `\primitives' in cell `\inst3' is not part of the design.

If you comment instantiations, it also fails with FDS and FDR.

Extra information

I was playing with Xilinx examples provided in the UG687 (XST User Guide for V6, S6 and Series 7 devices). There some examples used these primitives and failed with Yosys. These works with ISE (xst):

=========================================================================
*                            Design Summary                             *
=========================================================================

Top Level Output File Name         : primitives.ngc

Primitive and Black Box Usage:
------------------------------
# FlipFlops/Latches                : 3
#      FD                          : 1
#      FDR                         : 1
#      FDS                         : 1
# Clock Buffers                    : 1
#      BUFGP                       : 1
# IO Buffers                       : 7
#      IBUF                        : 4
#      OBUF                        : 3

Device utilization summary:
---------------------------

Selected Device : 6slx4tqg144-3 


Slice Logic Utilization: 

Slice Logic Distribution: 
 Number of LUT Flip Flop pairs used:      0
   Number with an unused Flip Flop:       0  out of      0         
   Number with an unused LUT:             0  out of      0         
   Number of fully used LUT-FF pairs:     0  out of      0         
   Number of unique control sets:         2

IO Utilization: 
 Number of IOs:                           8
 Number of bonded IOBs:                   8  out of    102     7%  
    IOB Flip Flops/Latches:               3

Specific Feature Utilization:
 Number of BUFG/BUFGCTRLs:                1  out of     16     6%

These primitives are described in UG616 (Spartan-6 Libraries Guide for
Schematic Designs) instead of UG615 (which I understand that are the supported). I know, the title says For Schematic but obviously they can also be used with HDL and could be more Xilinx code using it over there :P

[mwkmwkmwk]

That is correct — we only support the HDL primitive library at the moment. In general, trying to use yosys for synthesis and then bypassing the synthesis (ie. the whole point of yosys) by using schematic entry primitives doesn't sound like a common use case.

The primitives that are in the schematic entry library but not the HDL library are not really primitives — they're either macros that expand to multiple primitives (like the counter "primitives") or dumbed down versions of other primitives (eg. FDR is a dumbed down FDRE — the CE input is hardwired to 1). IMO the correct way to support them in yosys would be to make a Verilog file implementing them in terms of the actual primitives (or just as open-coded processes etc and let them go through synthesis), and make synth_xilinx auto-include that file into the user design.

[rodrigomelo9]

In general, trying to use yosys for synthesis and then bypassing the synthesis (ie. the whole point of yosys) by using schematic entry primitives doesn't sound like a common use case.

Yes, I agree, the issue was thinking in legacy code from Xilinx, because several times they use primitives for FFs in their code.

I don't know, what do you think? Does it have sense to support them? (make a Verilog implementation which uses the actual primitive and the inclusion in synth_xilinx seems easy to implement) or a waste of time? The issue can be closed if no sense (but maybe could be added a legend somewhere in the main README about the support of only HDL primitives or something similar :P).

Thanks for your time.

[mwkmwkmwk]

I don't know, what do you think? Does it have sense to support them? (make a Verilog implementation which uses the actual primitive and the inclusion in synth_xilinx seems easy to implement) or a waste of time? The issue can be closed if no sense (but maybe could be added a legend somewhere in the main README about the support of only HDL primitives or something similar :P).

It would be nice to support them, but it's a rather low-priority task — if you want to do the work, go ahead.

[rodrigomelo9]

It looks like a good exercise to get started.

I will try to implement at least these three at the beginning :-D

[mithro]

@rodrigomelo9 - FYI The SymbiFlow project has a tool at https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/libraries which is suppose to extract the various "definitions" that Xilinx parts support on the 7 series from the 7 Series Libraries Guide PDF document. It would be nice to have a similar thing for Spartan 6 too...

[rodrigomelo9]

I see, interesting ... :-P

I will take a look ;-)

PS: is a little confusing to me to catch where Yosys finish and Symbiflow begins XD so, work in these things could be helpful.

[mithro]

Yosys is an independent entity owned by Clifford + Symbiotic EDA team.

The "SymbiFlow Project" is a user of the Yosys project. SymbiFlow generates a bunch of configuration information and scripts that can be used with Yosys for doing a fully open source, end-to-end Verilog to Bitstream for a number of commercial FPGAs like the Xilinx 7 series.

I guess you could kind of think of it like the difference between the Linux Kernel and a Linux distro (like Debian). The Linux Kernel is an essential part of making Debian work but also an independent entity used for many other things. Debian takes the Linux Kernel plus things like a C library, init daemon and all the rest to create a complete system for getting work done.

The thing that can make it a little confusing is the FPGA world is a little smaller than the Linux world so there is a much higher overlap between contributors for all these parts :-). Hopefully we will be successful enough in the future to have more specialists!