Logic Lock Regions - are they allowed to overspill?

[Altera_Forum]

Right, bit of a complicated story - Ill try and keep it short. 

 I have a project where we need to run an overnight 12seed run to hopefully get a single good build (Stratix 4, 70% logic, 90% memory and 80% dsp utilisation, with 1 clock domain at 368MHz). So to help with this, there are lots of logic lock regions. This was building succesfully until we made some design changes, now timing misses with the same regions by between 200-400ps.  To counter this, I took the regions with the worst paths, and let them float over a 12 seed run. most of the seeds came back with some pretty hideous timing failures (-1ns was common) but one came back with a worse case of 140ns, and most of the failures in this build under 50ps, So I wanted to take these regions, lock them down and then run another 12 seeds with the new locked regions.  But apparently it hasnt actually put the locked areas into these regions. You can see on the Chip planner that while plenty of logic is within the region, some of it has spilt over and outside the region. This isnt neccesarily a problem, but when I try and build the design on it's own with these new regions it says It cant find some of the nets listed in the SDC file for a multicycle path, probably because it has been unable to fit the entity in the new region (odd, because it didnt complain in the origional DSE run).  So Im wondering now if this is a DSE bug, or theres something Im missing changing the regions from AUTO/FLOATING to FIXED/LOCKED. Im having to use Quartus 10.1  Has anyone had any similar experiences, or anyone got any tips on how I can make this meet timing?

[Altera_Forum]

DSE isn't anything more than a shell that launches Quartus compiles, so I don't think it's a bug with that. There seem to be two separate issues: 

The logic spilling over.  The SDC not taking. Are you applying the multicycles to nets or to keepers(registers?). I would recommend the latter, as those names should be consistent.

[Altera_Forum]

Actually - it was an error adding some keepers to a collection, that then have false paths set on them - but no matter. Problem is it cannot find the keeper.  

 I did think that about DSE, but I dont understand why it builds fine set to auto/float, and when I lock it it complains it cannot find the keeper.

[Altera_Forum]

It's probably worth trying to figure out where the registers went. Were they merged with another register? Did Physical Synthesis move them? Assuming the destination register is still there, do a report_timing to the destination register and see what registers now drive it compared to what drove it in the old project.

[Altera_Forum]

Can I run a report timing if the fitter has failed? 

Where do I do this - Im not v experienced with back end timing and fit/logic lock. This project was already created, Im just messing with it.

[Altera_Forum]

You said it, but I kind of missed that it errored out. I'm kind of surprised, as that usually shouldn't occur. 

Launch TimeQuest, and go to Netlist pulldown, Create Timing Netlist. Then choose the Post-Synthesis Netlist. This is basically the netlist after synthesis that was passed to the fitter. Ignore the actual timing numbers, as the design hasn't been fit, but you can use report_timing to trace forward/back from a destination. Note that you would want to also open an old design that fit and probably do the same thing. For example, in the old design do a report_timing -from {*register_name_that_disappear*}. That report will show the destinations it feeds. Then take one of those destination registers and do a "report_timing -to {*destination_register_name*}. It should come back and show the registers that feed that one, including the one you want.  After that, run the same command in the failing design, and you shouldn't see the source register anymore. The question is, where did it go? (This may not be obvious, but basically the design is able to do the same functionality without that register/s, so it's somehow doing something else.) Note that you could do a similar analysis in the Tools -> Netlist Viewers -> Post Map Technology Viewer. The problem is that this is purely a GUI tracing tool, so it can be a little cumbersome, but if you're not familiar with TimeQuest it may be easier.  Taking a stab in the dark, the register in question may get merged with another register that has identical behavior. In the working design the other register takes on the name of the one you're interested in, but in the failing design the register you're interested in gets merged into the other register. You could try Assignments -> Settings -> Analysis & Synthesis -> More Settings -> Remove Duplicate Registers and set it to Off. (Synthesis shouldn't merge two registers if one has a multicycle and the other does not, so I didn't think this was it, but maybe because you're using collections something went wrong...)