cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
5,077 Views
Registered: ‎03-27-2014

hard time moving to "out-of-context" synthesis

I still am not using the "OOC" approach because I think the time required to upgrade my IPs would be much greater than re-synthesizing everything all the time (even though I'm talking about large designs here). 

 

I did give it a try though, and I probably was missing some "HD.PARTPIN_LOC" constraints, because my I/O buffers were simply gone.

 

My point is: 

 

  • OOC synthesis buys us some synthesis time, because we are not re-synthesizing the whole thing all the time, but that is only 20% of the time for me, 80% is spent in implementation. So only "out-of-context implementation" would buy me an incredible amount of time but I'm certain this will be a pain to achieve :). Could you elaborate on the steps involved to reach a working "OOC implementation"?
  • assuming we register internal I/O interfaces within a core, the whole implementation should be OK
  • proper "OOC" timing constraints for I/O interfaces should be provided because some paths will be critical (DSP paths & stuff..), but I can't find any documentation. I can see that IPs like the Xilinx FIFO come with an "OOC" timing constraint that looks like this:

 

create_clock -name "s_axi_aclk" -period 5.0 [get_ports s_axi_aclk]
set_property HD.CLK_SRC BUFGCTRL_X0Y0 [get_ports s_axi_aclk]

1: I guess the first command is used for "OOC" timing analysis; that means implementation will fail to meet the whole requirement if this is missing please correct me on this 

2: Is the second command here to make sure "s_axi_aclk" is not removed between two "OOC" cores? please correct me on this

 

  •  assuming 2/ is right, let's say I have some I/O ports in my custom core, if set_property HD.PARTPIN_LOC is missing, then the I/O buffering (like BUFG, IDDR, ODDR) will be removed. What should HD.PARTPIN_LOC look like? HD.PARTPIN_LOC is also architecture dependent so that means my "OOC" implementation is only guaranteed for a particular board. If that is true then this is totally pointless to me

overall, I feel like Vivado has become so slow now (2014 vs 2016, sorry to say so but that is true) that I would rather be using a huge and expensive machine capable of implementing within dozens of minutes, than wasting my time understanding how to achieve out of context implementation. Prove me wrong ?

G.W.,
NIST - Time Frequency metrology
0 Kudos
5 Replies
Highlighted
Scholar
Scholar
5,037 Views
Registered: ‎09-16-2009

Re: hard time moving to "out-of-context" synthesis

G.W.

 

We actively avoid any OOC methodology.  It's basically just the age-old "bottom up" build flow that's existed, well forever.  The twist is basically just a cache of prebuilt low-level blocks that don't need to be recompiled.  Ho-hum.  The pain of maintaining a bottom up build flow, for us, is just not ANYWHERE near the short build time improvements that OOC gains.

 

We prefer to just build "top down" where we throw the entire RTL design at the tool, and let it go.

 

We're actually fairly happy with Vivado performance.  It's leaps and bounds better than ISE.  Of course it can always be faster.  But things will have to be much worse for us to consider any bottom-up design flows, with all the pain involved.

 

Regards,

 

Mark

0 Kudos
Highlighted
Teacher
Teacher
4,977 Views
Registered: ‎03-31-2012

Re: hard time moving to "out-of-context" synthesis

@markcurry alas 2016.4 seems to enforce full ooc. I haven't had the time to figure how to make it top down yet. Did you try 2016.4 yet?

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Scholar
Scholar
4,969 Views
Registered: ‎09-16-2009

Re: hard time moving to "out-of-context" synthesis

We're running 2016.4.  But probably haven't generated any new IP yet, so haven't noticed the lack of OOC.  (All our existing RTL - including other Xilinx IP is building fine).

 

This will be absolutely horrible if true.  We'll be yelling (loudly) if there's not a way to turn this off.  Completely dumb and non-productive - actively putting up barriers to prevent us from doing work.  Not good at all...

 

-Mark

0 Kudos
Highlighted
Teacher
Teacher
4,966 Views
Registered: ‎03-31-2012

Re: hard time moving to "out-of-context" synthesis

@markcurry everything builds fine but in my flow synthesis first does an ooc step where it compiles everything separately into dcps and then does a top level run. Haven't you seen that in your runs?

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Scholar
Scholar
4,962 Views
Registered: ‎09-16-2009

Re: hard time moving to "out-of-context" synthesis

@muzaffer

 

We extract all the RTL from Global (Non-OOC) IP.  Only RTL is checked into our revision control.  We throw away all the DCP/XCI/XCIX/other junk.  (Well, we sometimes archive off the whole IP generation run into a tar.gz file or similar - just for reference).

 

So, using only RTL, the tools don't have much wiggle room to mess things up...

 

Regards,

 

Mark

0 Kudos