Has anyone forked any Xilinx IP?

[SP]

What is the "recommended" way to do IP forking from Xilinx's repos? Not
for public distribution but to have a modified one for specific
purposes. The modifications are beyond the customisations offered by
generator.

Has anyone done it?

--
Stavros

 

[SP]

SP <sp@orbitalfox.com> wrote:
> Has anyone done it?

In case someone is wondering the same and no better answer comes I have
done the following in Vivado IDE.

* Created a new IP repo from "Manage IP"
* In the "project manager" window I clicked the "IP settings" button.
* Clicked "Add IP".
- Found the IP from Xilinx's repo (Xilinx/Vivado/201x.x/data/ip/)
* Then I could click "Edit in Packager"

Not sure if this is the best way. Kinda worked. I will write and article
about it, but I must know if there are any better ways before I do so.

--
Stavros

 

[Mark Curry]

In article <ls83nl$34c$1@dont-email.me>, SP <sp@orbitalfox.com> wrote:

What is the "recommended" way to do IP forking from Xilinx's repos? Not
for public distribution but to have a modified one for specific
purposes. The modifications are beyond the customisations offered by
generator.

We've had to do it. The general rule is to quickly throw away any use
of Xilinx's "wizards" or other hold-your-hand GUIs. Get to the
straight RTL and just use that. Most of Xilinx's current
IP is unencrypted RTL - although buried deep within wrappers
and other "wizardly" cruft.

(This is generally good advise in any cases for any vendors IP, IMHO.
Throw away the wizards, and GUIs that just get in the way. But I digress).

Now, it's simple. Just edit the RTL as needed and continue.

There's gotchas, and other things that you'll have to work through.
But they're all solvable.

Regards,

Mark

 

[SP]

Mark Curry <gtwrek@sonic.net> wrote:

We've had to do it. The general rule is to quickly throw away any use
of Xilinx's "wizards" or other hold-your-hand GUIs. Get to the
straight RTL and just use that. Most of Xilinx's current
IP is unencrypted RTL - although buried deep within wrappers
and other "wizardly" cruft.

Seems a good advice if one is headed towards in-depth understanding of
the IP they are using. But what about situations where this is not
needed?

Personally I tend to want to be in the fist group, but I am curious for
the other reasons.

I take it you didn't throw away the tcl templates?

> Now, it's simple. Just edit the RTL as needed and continue.

This is the juicy part -- where? How do you re-include these in the rest
of the design? What about keeping it flexible and future proof?

--
Stavros

 

[Mark Curry]

In article <lsigti$lvp$1@dont-email.me>, SP <sp@orbitalfox.com> wrote:

Mark Curry <gtwrek@sonic.net> wrote:
We've had to do it. The general rule is to quickly throw away any use
of Xilinx's "wizards" or other hold-your-hand GUIs. Get to the
straight RTL and just use that. Most of Xilinx's current
IP is unencrypted RTL - although buried deep within wrappers
and other "wizardly" cruft.

Seems a good advice if one is headed towards in-depth understanding of
the IP they are using. But what about situations where this is not
needed?

We only edit Xilinx IP when we're forced to. One case, was to fix a bug
that we just couldn't convince them was indeed a bug. It was just easier
to fix it ourselves.

For another it was to add features that were not present.

Personally I tend to want to be in the fist group, but I am curious for
the other reasons.

I take it you didn't throw away the tcl templates?

"tcl templates"?

Don't even know what you're referring to here. Perhaps something in Vivado?
Either way, we don't use tcl templates. We run vivado in non-project mode
with our own tcl scripts.

Now, it's simple. Just edit the RTL as needed and continue.

This is the juicy part -- where? How do you re-include these in the rest
of the design? What about keeping it flexible and future proof?

We copy over all IP into our revision control repository (regardless of
whether we're editting it or not). This future proofs it against random
updates from the vendor (oh pcore version x.x.x is no longer supported/
available by tool z.z.z...) RTL is RTL.

Regards,

Mark