Hey Mark, Yeah, I guess I could manually force the locations of the two offending shift-regs to stop the combination, but the problem SRLs seem to be a fairly arbitrary selection of those in the design. I don't really want to have to start constraining at the LUT level if I can help it. But maybe I'll try and see if the problem goes away, or just emerges somewhere else.
Hi Dave, I have been through all the planAhead options, as well as the fast_runtime.opt settings in the base package (I've been using both flows) and (tried to) set everything to optimize for speed. The -lt option to me seems like it should control the behaviour I'm seeing, but it doesn't seem to. I'm using pblocks, but have been almost exclusively been constraining only rams/dsps. As above, I'm about to try forcing the placements. I haven't run resynth netlist on my simulink design, but equivalent register removal is turned off in planAhead and some of the signals it appears to be LUT-combining belong to different pcores, so I thought that planahead settings should be enough. (obviously I could be wrong). In any case, I didn't think this was an equivalent register removal problem. It's not like multiple copies of the same register are being merged at the expense of fanout, just a 2-clock data delay inside an X-engine might be merged with a 2-clock delay of some data signal in an FFT. But again, maybe I'm understanding the options wrong, so I'll try resynthing the netlist and see if that helps. Thanks for your help, both. Jack On Thu Dec 04 2014 at 19:18:35 David MacMahon <dav...@astro.berkeley.edu> wrote: > Hi, Jack, > > Are the tools are optimizing for area instead of speed? Are you using > Pblocks? > > I don't know if this is relevant to your situation, but I've run into > annoyances when the tools use "equivalent register removal" to save a few > flip-flops but end up causing fan-out/routing issues. That can be turned > off, but it's a synthesis option so if you want to apply it to a System > Generator netlist, you have to use the "resynth_netlist" Matlab function > from the casper library to re-synthesize the entire netlist. > > Dave > > On Dec 4, 2014, at 10:48 AM, Jack Hickish wrote: > > > Hi all, > > > > This is something I've been fighting with for a while now, and I wonder > if anyone on this maillist has any insight (because I'm pretty sure I may > just be doing something wrong with the tools). > > > > The problem: > > I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz. > However, every now and then I'll make a small change to the design and the > compile will fail timing catastrophically, with paths failing sometimes > with -2 ns (or worse) slack. > > When I look at the failing path(s), the delays are usually ~80% routing. > I'll see a signal take a huge detour to use a shift register in some > arbitrary location on the chip. Upon closer inspection of the relevant SRL, > it appears that the LUT concerned is being used for two signal paths, one > on the O5 output, one on the O6. The result seems to be that it is poorly > placed for both it's roles. > > > > I'm only using ~50% of the slices and about 30% of the registers / luts > on the FPGA, and there are plenty of sensibly located SLICEMs the placer > could use if it so desired. I've switched lut combining off (with the -lt > flag), in planahead which doesn't seem to have made any difference. > > > > Can anyone offer me any words of advice / wisdom which might reduce my > confusion at what's going on (or, even better, help me solve the problem)? > > > > Despairingly yours, > > Jack > > > > > >
