Classification: UK OFFICIAL

Hi,

I'm trying to use a Xilinx Parameterised Macro for a Synchronous FIFO
inside of an OpenCPI worker.
My design compiles, simulates, and synthesizes in Vivado.
However, when I try to use "ocpidev build" on the worker, I get the
following error:

[Synth 8-4169] error in use clause: package 'vcomponents' not found in
library 'xpm'

I found a related answer record<
https://www.xilinx.com/support/answers/67815.html> on the Xilinx forums
that indicates that to use XPM components, a property in the current Vivado
project needs to be set.
This was already set for a new project that I made in Vivado (I think it
was set the first time I simulated), but I assume that this isn't true for
when OCPI uses Vivado.
The following line of tcl sets this property to enable use of all of the
available FIFOs within XPM:

set_property XPM_LIBRARIES {XPM_FIFO} [current_project]

Is there a way for me to give this tcl line to OCPI to give to Vivado?
Is there a different way to get OCPI to force Vivado to recognise the XPM
library?
Or am I going to have to go down the route of making a design checkpoint
file/finding a non-XPM replacement component?

Thank you for any help you can provide,
D. Walters

"This e-mail and any attachment(s) is intended for the recipient only.
Its unauthorised use,
disclosure, storage or copying is not permitted.  Communications with Dstl
are monitored and/or
recorded for system efficiency and other lawful purposes, including
business intelligence, business
metrics and training.  Any views or opinions expressed in this e-mail do
not necessarily reflect Dstl policy."

"If you are not the intended recipient, please remove it from your system
and notify the author of
the email and centralenq@dstl.gov.uk"

Hi Mr. Walters,

Unfortunately there is no good way to do this in OpenCPI today, but you can
force this to happen for all syntheses/implementations run by OpenCPI.

Temporary/hackish fix:
There is a Tcl file that is run for synthesis (vivado-synth.tcl), and
another for implementation (vivado-impl.tcl). You can just add your
"set_property" command to one or both of these files (depending on when the
property needs to be set) after the "create_project" line.
These files live at 'runtime/hdl-support/xilinx/' in a source build, or
'/opt/opencpi/cdk/include/hdl/' for an RPM build.

Longer-term fixes:
I am not sure which of these two options is a better fix. Option 1 is
simpler and the framework code will be simpler, but won't work for
implementation without even more changes. Option 2 keeps Tcl and VHDL files
logically separated (not sure if this is good or bad) and works for
both.... Either should work.

Option 1
It might make sense to allow Tcl files in the 'SourceFiles' list in your
worker Makefiles. A change to support this would involve changing
add_files_set_lib function (vivado-util.tcl) to process Tcl sources
differently from VHDLs and source them instead of just adding them via
'add_files'. Note: This function is called by VivadoIncludeSources (
vivado.mk). It processes the SourceFiles list, and constructs a Tcl file to
import all source files for a worker.

This would only apply for synthesis since source files are not added in
this way for implementation. If it is necessary to run some Tcl commands
post-synthesis, then other changes or Option 2 might be necessary.

Option 2
Allow users to specify a Tcl script that they would like sourced before
synthesis of a worker or implementation of a container. I do not believe
this should be very difficult.

 1. Add a new argument to vivado-synth.tcl and vivado-impl.tcl (similar
 to the framework's internal 'tcl_imports' argument). Let's just say its
 called 'user_tcl_file', and just contains a single Tcl file to source for
 the current worker/container/etc. In the vivado-synth/impl Tcl files, add
 'source $user_tcl_file' after any checkpoints or 'tcl_imports' are read in
 but before synthesis/implementation.
 2. Add this new argument to the HdlToolCompile and HdlToolDoPlatform
 functions in vivado.mk, and set it to some user-set variable like
 '$(VivadoUserTcl)' or user-tcl.tcl.
 3. Finally, in your worker/assembly makefile:
    - Worker:
       - VivadoUserTcl=<path-to-Tcl-file>
    - Assembly:
       - export VivadoUserTcl=<path-to-Tcl-file>

I hope this helps!
Regards,
David Banks
dbanks@geontech.com
Geon Technologies, LLC

On Thu, Dec 5, 2019 at 10:46 AM Walters Dominic A via discuss <
discuss@lists.opencpi.org> wrote:

Classification: UK OFFICIAL

Hi,

I'm trying to use a Xilinx Parameterised Macro for a Synchronous FIFO
inside of an OpenCPI worker.
My design compiles, simulates, and synthesizes in Vivado.
However, when I try to use "ocpidev build" on the worker, I get the
following error:

[Synth 8-4169] error in use clause: package 'vcomponents' not found in
library 'xpm'

I found a related answer record<
https://www.xilinx.com/support/answers/67815.html> on the Xilinx forums
that indicates that to use XPM components, a property in the current Vivado
project needs to be set.
This was already set for a new project that I made in Vivado (I think it
was set the first time I simulated), but I assume that this isn't true for
when OCPI uses Vivado.
The following line of tcl sets this property to enable use of all of the
available FIFOs within XPM:

set_property XPM_LIBRARIES {XPM_FIFO} [current_project]

Is there a way for me to give this tcl line to OCPI to give to Vivado?
Is there a different way to get OCPI to force Vivado to recognise the XPM
library?
Or am I going to have to go down the route of making a design checkpoint
file/finding a non-XPM replacement component?

Thank you for any help you can provide,
D. Walters

"This e-mail and any attachment(s) is intended for the recipient only.
Its unauthorised use,
disclosure, storage or copying is not permitted.  Communications with Dstl
are monitored and/or
recorded for system efficiency and other lawful purposes, including
business intelligence, business
metrics and training.  Any views or opinions expressed in this e-mail do
not necessarily reflect Dstl policy."

"If you are not the intended recipient, please remove it from your system
and notify the author of
the email and centralenq@dstl.gov.uk"