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_at_geontech.com
Geon Technologies, LLC
On Thu, Dec 5, 2019 at 10:46 AM Walters Dominic A via discuss <
discuss_at_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_at_dstl.gov.uk"
>
Received on Thu Dec 05 2019 - 16:33:41 CST