Using HDL Devices in Out-of-tree Projects
I am making an assembly of an HDL device that I created in my own project
outside of opencpi.
I am running into a problem that states:
Worker <name> was not found in any of the component libraries built for
zynq
If I go to the directory (hdl/devices/<name>.hdl), I can build just fine.
At the end, it says it's creating symbolic links and, indeed, I see links
in hdl/devices/lib/hdl/zynq pointing to vhd, v, and edf files.
I tried playing around with OCPI_COMPONENT_LIBRARY_PATH, and
OCPI_PROJECT_PATH environment variables, but to no avail. I also tried
searching other repositories for doing this, but I couldn't find many other
people implementing OpenCPI devices/assemblies/projects.
I don't quite understand what needs to be in place for an assembly in the
same project to be able to use an HDL device in the same project.
Can someone shed some light on this for me? Just a link to an example
out-of-tree would probably be enough.
Thanks,
Brian
Hi Brian,
If I understand the problem correctly, the issue is that HDL devices cannot
be instanced in assemblies. They can only be instanced in containers (which
encapsulate assemblies) or platform configurations (which are instanced
alongside assemblies).
An example of a container instance for the e31x platform:
https://gitlab.com/opencpi/osp/ocpi.osp.e3xx/-/blob/develop/hdl/assemblies/empty/cnt_e31x_mimo_xcvr_filter.xml
An example of a platform configuration instance for the e31x platform:
https://gitlab.com/opencpi/osp/ocpi.osp.e3xx/-/blob/develop/hdl/platforms/e31x/cfg_1rx_1tx_mode_2_cmos.xml
Hope this helps.
Thanks,
Brandon
On Wed, Apr 22, 2020 at 6:48 PM Brian Padalino bpadalino@gmail.com wrote:
I am making an assembly of an HDL device that I created in my own project
outside of opencpi.
I am running into a problem that states:
Worker <name> was not found in any of the component libraries built for
zynq
If I go to the directory (hdl/devices/<name>.hdl), I can build just fine.
At the end, it says it's creating symbolic links and, indeed, I see links
in hdl/devices/lib/hdl/zynq pointing to vhd, v, and edf files.
I tried playing around with OCPI_COMPONENT_LIBRARY_PATH, and
OCPI_PROJECT_PATH environment variables, but to no avail. I also tried
searching other repositories for doing this, but I couldn't find many other
people implementing OpenCPI devices/assemblies/projects.
I don't quite understand what needs to be in place for an assembly in the
same project to be able to use an HDL device in the same project.
Can someone shed some light on this for me? Just a link to an example
out-of-tree would probably be enough.
Thanks,
Brian
Hey Brandon,
On Thu, Apr 23, 2020 at 10:37 AM Brandon Luquette bluquette@geontech.com
wrote:
Hi Brian,
If I understand the problem correctly, the issue is that HDL devices
cannot be instanced in assemblies. They can only be instanced in containers
(which encapsulate assemblies) or platform configurations (which are
instanced alongside assemblies).
An example of a container instance for the e31x platform:
An example of a platform configuration instance for the e31x platform:
Hope this helps.
Yes, thanks. It seems I got confused about devices versus components. I
am making something that is more like a component (does not connect to
external pins by itself) and not a device (connects to external pins).
I'm going to refactor and try to make it a component.
Thanks for the insight.
Brian
On Thu, Apr 23, 2020 at 10:47 AM Brian Padalino bpadalino@gmail.com wrote:
Hey Brandon,
On Thu, Apr 23, 2020 at 10:37 AM Brandon Luquette bluquette@geontech.com
wrote:
Hi Brian,
If I understand the problem correctly, the issue is that HDL devices
cannot be instanced in assemblies. They can only be instanced in containers
(which encapsulate assemblies) or platform configurations (which are
instanced alongside assemblies).
An example of a container instance for the e31x platform:
An example of a platform configuration instance for the e31x platform:
Hope this helps.
Yes, thanks. It seems I got confused about devices versus components. I
am making something that is more like a component (does not connect to
external pins by itself) and not a device (connects to external pins).
I'm going to refactor and try to make it a component.
So I made it a component, but something new is happening. It seems the
names of my EDIF netlists have an '_rv' attached to it. I did a comparison
between the mfsk_mapper.hdl in the opencpi project, and I can't understand
why that worker netlist is called mfsk_mapper.edf when mine is called
<name>_rv.edf.
Has anyone got any information on why it's called _rv instead of just what
hte name of the device is?
Thanks,
Brian
THis is probably because your XML says it is device?
On 4/23/20 1:23 PM, Brian Padalino wrote:
On Thu, Apr 23, 2020 at 10:47 AM Brian Padalino bpadalino@gmail.com wrote:
Hey Brandon,
On Thu, Apr 23, 2020 at 10:37 AM Brandon Luquette bluquette@geontech.com
wrote:Hi Brian,
If I understand the problem correctly, the issue is that HDL devices
cannot be instanced in assemblies. They can only be instanced in containers
(which encapsulate assemblies) or platform configurations (which are
instanced alongside assemblies).An example of a container instance for the e31x platform:
An example of a platform configuration instance for the e31x platform:
Hope this helps.
Yes, thanks. It seems I got confused about devices versus components. I
am making something that is more like a component (does not connect to
external pins by itself) and not a device (connects to external pins).I'm going to refactor and try to make it a component.
So I made it a component, but something new is happening. It seems the
names of my EDIF netlists have an '_rv' attached to it. I did a comparison
between the mfsk_mapper.hdl in the opencpi project, and I can't understand
why that worker netlist is called mfsk_mapper.edf when mine is called
<name>_rv.edf.
Has anyone got any information on why it's called _rv instead of just what
hte name of the device is?
Thanks,
Brian
On Thu, Apr 23, 2020 at 1:29 PM James Kulp jek@parera.com wrote:
THis is probably because your XML says it is device?
Wow, thanks. HdlWorker versus HdlDevice.
Brian
An HTML attachment was scrubbed...
URL: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20200423/e4a0757f/attachment.html
On 4/23/20 1:35 PM, Brian Padalino wrote:
On Thu, Apr 23, 2020 at 1:29 PM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:
THis is probably because your XML says it is device?
Wow, thanks. HdlWorker versus HdlDevice.
Brian
For anyone who cares, this happens because HDL workers actually fall
into three categories indicating where they may be instanced in the design.
Application workers are only instanced in the HDL Assembly, and for
various reasons, the generated HDL assembly code is actually in Verilog.
Device workers are only instanced in platform configurations and
containers, and, for various reasons, the generated HDL assembly at that
level is VHDL.
Adapter workers (inserted automatically) may be instanced in either
place and are thus generated for both types of instantiations.
The _rv cores/edfs are for VHDL instantiation, whereas the cores/edfs
without the suffix are for Verilog instantiation.
So application workers use the HdlWorker XML tag.
Device workers use the HdlDevice XML tag.
Adapter workers use the HdlImplementation XML tag.
Jim