Re: [Discuss OpenCPI] Zynq HDL Primitive Modification
I made the same modifications, and will be included in OpenCPI release 1.7
or sooner. We're still in the process of transitioning the project from
GitHub to GitLab. When the GitLab project is released to the public with
OpenCPI 1.6 it will include a new contributing guide which layouts the
steps necessary to push changes back to the community.
Looks like your running into the same problems I had to run through. Can
you elaborate a little more on your setup? In a previous email you
mentioned you created an RCC platform based on Xilinx 2017.4. Did you
updated the stock firmware and have that running on Pluto? Are you still
utilizing the USB device functionality orr are you using it in standalone
mode?
Aaron
On Thu, Jan 9, 2020 at 9:08 AM Brian Padalino <bpadalino_at_gmail.com> wrote:
> I figured out a missing piece of my ADALM-PLUTO puzzle. I was getting
> placing errors about IO which couldn't be placed in an empty assembly. It
> turned out that the zynq_ps instantiation was using some generics that
> didn't work for the device, specifically:
>
> - C_PACKAGE_NAME
> - C_DQ_WIDTH
> - C_DQS_WIDTH
> - C_DM_WIDTH
>
> I added the following generics to the zynq_ps entity:
>
> - DQ_WIDTH : positive := 32
> - PACKAGE_NAME : string := "clg484"
>
> I then made the following changes to the instantiation:
>
> C_DQ_WIDTH => DQ_WIDTH,
> C_DQS_WIDTH => DQ_WIDTH/8,
> C_DM_WIDTH => DQ_WIDTH/8,
> C_PACKAGE_NAME => PACKAGE_NAME
>
> I don't know if this is the best way to do it, but it seemed to work for me
> to allow for the old stuff to still work while giving me the ability to
> over ride it. Best practice might be to make the PACKAGE_NAME into an
> enumerated type since a string is too generic especially with no checking.
>
> So, to the real question, what is the preferred method for contributing
> some of these changes back to the community? And, are there issues seen
> with what I did here? Does it follow your best practices or should things
> be modified?
>
> Thanks,
> Brian
>
Received on Thu Jan 09 2020 - 16:29:59 CST
This archive was generated by hypermail 2.3.0
: Fri Jun 05 2026 - 08:45:25 CDT