02-01-2017 02:03 AM - edited 02-01-2017 02:05 AM
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:
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
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 ?
02-01-2017 09:25 AM
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.
02-04-2017 01:38 PM
@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?
02-04-2017 02:26 PM
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...
02-04-2017 02:33 PM
@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?
02-04-2017 02:51 PM
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...