UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor amattila313
Visitor
2,003 Views
Registered: ‎10-11-2014

Designing for longevity, Vivado tool and IP life cycle

I'm designing a product that is hopefully maintained for more than 10 years. 

How should I take this into account when choosing to use tools in the Vivado suite?

How to create a design in such a way  it requires minimal changes when moving forward to newer devices and Vivado (or insert new name) versions? 

 

I had a bad experience when moving from ISE (and XPS) to Vivado with most of my design dying. 

The pessimist in me says, use HDL only. 

 

However I can see benefits from IP library, IP integrator,Vivado HLS , System generator.  

The question is should I dare to use them. 

 

 

0 Kudos
11 Replies
Scholar austin
Scholar
1,950 Views
Registered: ‎02-27-2008

Re: Designing for longevity, Vivado tool and IP life cycle

Good question,

 

As nothing is forward or backward compatible in any hardware synthesis flow (not just FPGA design), designing for maintainability is a challenge.

 

Yes, if everything is pure verilog/VHDL sources you own the sources to, that is the best solution.  Next best is using IP directly related to necessary features (like clock wizard).  These IP are least disruptive as they tend to no longer be changing (no requests to add or change anything).

 

Moving to a new device may only require small edits (like DSP48E1 to DSP48E2).

 

Note that some customers, in some markets, such as safety critical systems, must be able to demonstrate all source code is visible, tracked, and vetted in order to certify their system.  If they cannot see the source code, how are they able to evaluate the failure modes?  They cannot.

 

You may use TCL commands, such as write_verilog, at various places in the tool flow to capture what IP can be delivered as a source code.

 

Archiving the project requires great discipline.  When I did that, I would take the PC that the bitstream was generated on, make backups of all files, and then put that  machine in a closet (big sign DONT TOUCH!).  Worst case if that PC failed when I went to use it, I would fix it, restore the and restore the files.

Austin Lesea
Principal Engineer
Xilinx San Jose
Scholar drjohnsmith
Scholar
1,926 Views
Registered: ‎07-09-2009

Re: Designing for longevity, Vivado tool and IP life cycle

An interesting problem

 

The move from ISE to vivado is still an on going pain.

   the list of useful things ISE could do that vivado still can't is well addressed in  other forums,

 

Even something like the Spartan 6, which has been announced I think will be around for another 10 years,

     but is only supported on ISE. What is ISE going to run on in 5 years ? 

           hopefully virtual machines with windows 7 will be possible in 2023 for a mid life upgrade to the code.

 

The simpler one keep things, the easier it is to backup / re create.

   

As per Austin, I've been involved in designs where things are critical.

    at a point in the project, a new machine is made, and clean install of every thing to prove it can make the chip.

       then a snap shot of the disk is made, and put in safe off site, 

 

Even then, 7 years later, we found that we could not get the licence to run  !! Thankfully Xilinx sorted us out..

 

K I S S...   

 

 

 

 

 

Scholar markcurry
Scholar
1,872 Views
Registered: ‎09-16-2009

Re: Designing for longevity, Vivado tool and IP life cycle

@amattila313 -

 

I'm in a similar industry where our product is often on the market for similar time periods.  We often are still building FPGAs on products that have been on the market for 5 years (and that's already after a significant development time). 

 

We are also a very strong advocate of using HDL only.  There's many reasons for this, but among them is IP availability and use.  We CANNOT tolerate any forced upgrades of IP.  It's just not maintainable for our products. 

 

So, for us, we can use Xilinx IP, with caveats.  Those caveats being we must remove all the "cruft" that the various Xilinx solutions heft on top of (the usually good quality) underlying RTL. It pains us that we must put significant effort in this task of removing the ancillary clutter, and searching for the golden code.  And it hoists this effort independently on each customer, instead of solving once in the factory. 

 

In ISE days, Xilinx accepted this with a nod and wink (and didn't try and hide things so much).  Upon seeing what we were doing, (and noting how straightforward it was), our Xilinx support contacts admitted "That's actually how we do things internally too".

 

In Vivado this is no longer the case.  It's XCI, BD, DCP, OOC, and other silly wizards or you are officially "unsupported".  (and yes, we view IP Integrator as nothing more than a wizard trying to act like a poor schematic capture tool...)

 

Using RTL only has other benefits too.  We lock down IP, however this does NOT imply we must lock down build software.  In fact, we're usually at the cutting edge of Vivado releases.  Our migration from ISE-> Vivado was not difficult at all, and for a while we we working on Xilinx FPGAs that were supported by both ISE, and Vivado.  We had both build flows running nightly on the same FPGA, without issues.  The same can be said for upgrading SW versions, as our build flow in brief is "1.  Read in RTL"  "2. Apply constraints".  "3.  Build".

 

Regards,

 

Mark

Tags (1)
Visitor amattila313
Visitor
1,780 Views
Registered: ‎10-11-2014

Re: Designing for longevity, Vivado tool and IP life cycle

Thanks everyone for the answers.

0 Kudos
1,359 Views
Registered: ‎01-22-2015

Re: Designing for longevity, Vivado tool and IP life cycle

You’ve all got me pondering the “infer vs instantiate” issue again.  For my comments, I will use the example of block-RAM (BRAM) as something that can either be instantiated via use of a Xilinx IP/wizard or infered by copying code from the synthesis user-guide (eg. ug901).

 

I’ve often heard the mantra, “use inference to make code portable”.  However, I assumed this was just pie-in-the-sky stuff for a couple of reason.  First, I thought that use of IP/wizards was sometimes the only way that average-Joes (like me) could configure *all* options for the hardware (eg. BRAM).  That is, I thought that inferring BRAM left decisions for some options up to the synthesis tool (ie. the BRAM was not locked down).  Secondly, there is Austin’s comment that “nothing is forward or backward compatible in any hardware synthesis flow”, which I intepret to mean that the synthesis tools (like IP tools) evolve and may decide differently how to do things as the years go by.

 

-but then, I read the following comments by @markcurry:

 

Using RTL only has other benefits too. We lock down IP …. Our migration from ISE-> Vivado was not difficult at all ….. our build flow in brief is "1. Read in RTL" "2. Apply constraints". "3. Build".

 

Mark’s comments make the strongest case I’ve ever heard for infering everything!  However, Mark then says “we can use Xilinx IP, with caveats … we must remove all the "cruft" … searching for the golden code”.   Is removing the cruft necessary to achieve the awesome code-portability that Mark describes?   Removing the “cruft” seems beyond the capability of average-Joes?

 

So, I’m back to pondering “infer vs instantiate”.   If I am unable or unwilling to remove cruft, am I really making code more portable by simply copying code from ug901 (ie. inferring) rather than using IP wizards (ie. instantiating)?

 

Thanks,

Mark

0 Kudos
Scholar drjohnsmith
Scholar
1,349 Views
Registered: ‎07-09-2009

Re: Designing for longevity, Vivado tool and IP life cycle

It boils down to you choice.

 

Yes IP tools vary over time, 

 

    its not that long ago that the tools had an ip block to make a counter. 25 years ago It used to be the only way of getting counters to fit in tight and fast. You had to instantiate.   

 

20 years ago, the tools improved, such that an inferred counter came out as good as the inferred one. So every one moved over to inferring, and I would not expect anything else now days.

 

When I find a lump of code that has the instantiated counters, I can not re use the code, nor does any current tool recognise the IP so I can not even see how the original IP was set up, if I'm lucky I have the source, and can hack enough to find out what sort of counter they wanted.

 

That does not make the original code wrong for instantiating the IP, it was a choice they made at the time to fit this lump of code to fit into the parts they had at the time.

 

Very general,  if something can be inferred, its best to infer it . The tools , and others, in the future will still be able to read the code, and the tools generally do not get worse at building the best thing from the code.  

 

If something is complex, may be a FFT would be an example, and you have a tool that can make the code for you, then great, but its your compromise.

 

I'd say, a ram / rom, a DSP, are well in the area of inference. 

 

 

 

 

0 Kudos
1,329 Views
Registered: ‎01-22-2015

Re: Designing for longevity, Vivado tool and IP life cycle

@drjohnsmith   Thank you!

 

      ....if something can be inferred, its best to infer it

I think this will be my new mantra.

 

      ...the tools generally do not get worse at building the best thing from the code.

I very much appreciate this comment and others you made about the history of things.

 

Mark

0 Kudos
Scholar markcurry
Scholar
1,307 Views
Registered: ‎09-16-2009

Re: Designing for longevity, Vivado tool and IP life cycle


markg@prosensing.com wrote:

Mark’s comments make the strongest case I’ve ever heard for infering everything!  However, Mark then says “we can use Xilinx IP, with caveats … we must remove all the "cruft" … searching for the golden code”.   Is removing the cruft necessary to achieve the awesome code-portability that Mark describes?   Removing the “cruft” seems beyond the capability of average-Joes?


 


 

"Removing the cruft" isn't usually difficult.  Just tedious.  And Xilinx makes it excessive so.  Digging through the (machine-generated) levels of wrappers the wizards spit out - one can normally find the underlying RTL.  It's usually very good quality code, and often Xilinx has even documented the base IP quite well too.  And digging through the code often gives me insight into how to use the specific IP, and what's happening under the covers.

 

So, it's quite accessible to "average-Joes".  After all, it just RTL.  You know, the industry standard for digital design...

 

But here's the kicker, and why I'm often quite vocal (in these forums, and elsewhere)... Doing the above - exposing the simpler design flow - is considered unsupported by Xilinx.  First they make it more difficult to use their IP, and then when you simplify it, you're officially unsupported.  Beyond frustrating...

 

I'm lucky that I currently work for a larger customer of Xilinx.  Our tech support team understands what we're doing, and (grudgingly) support us.  But I can imagine as a smaller customer, being told to just go pound sand...

 

Regards,

 

Mark

0 Kudos
1,298 Views
Registered: ‎01-22-2015

Re: Designing for longevity, Vivado tool and IP life cycle

@markcurry Thanks!

 

   Digging through the (machine-generated) levels of wrappers the wizards spit out - one can normally find the underlying RTL.

 

I’ve been trying to find the underlying RTL in files that the Vivado wizard spit out for BRAM – without success.  Can you give more description about “digging for RTL”?

 

In general, why are you “digging for RTL” and not using Xilinx-recommended RTL examples from ug901 to infer things?

 

Cheers,

Mark

0 Kudos
Scholar markcurry
Scholar
668 Views
Registered: ‎09-16-2009

Re: Designing for longevity, Vivado tool and IP life cycle

Mark,

 

For low-level things like BRAMs and multipliers I follow the templates and exampled from ug901 fairly closely.  I don't think there's any problem with using inference for those things.  It works, and is supported fine, and I strongly suggest other users should follow these examples.

 

For this thread, I was referring to higher level IPs.  Things like DDR controllers, AXI DMA engines, aurora links, PCIE cores, mblaze subsystem, etc...  Anything which requires a (XCI, DCP, OOC, *_bd.tcl, XCIX ) non-standard, revision-control unfriendly, blindly upgraded, poorly and under specified Xilinx created format blobs.

 

These higher level IP cores - require the digging and reverse engineering I was referring to.

 

Regards,

 

Mark

0 Kudos
646 Views
Registered: ‎01-22-2015

Re: Designing for longevity, Vivado tool and IP life cycle

Thanks again, Mark!

 

I hear your battle-cry for more code portability, but we are soooo dependent on Xilinx.  Even with simple things like BRAM, there are many connections and much glue logic -- the details of which are hidden in the Xilinx synthesis tool.

 

To achieve code portability, I guess we are betting on what will remain constant at Xilinx.  Will it be wizards+blobs or RTL+synthesis?  History indicates that we should bet on RTL+synthesis and we must hope that Xilinx develops their synthesis tool so that backward compatibility is maintained.

 

Anyway, I’m making the move to infer things.  However, I’m a little ashamed to say that I’ll miss the wizards.  They are friendly and a little magical. –and I’ll definitely miss the option to use OOC synthesis.

 

Cheers,

Mark

0 Kudos