Honored Contributor
Honored ContributorI downloaded and tried to run report_timing on the input pins, but nothing came back. I think the input DDR registers were being synthesized out, so I hooked up some input pins to datain_h/l. (Seems like that would affect the output, but I didn't look at it too closely).
After compiling, I see: 1) You're doing a same-edge capture, via a multicycle hold of 0. That's a good idea when you don't have a PLL compensating for the clock tree, e.g. the clock path will be much longer than the data path, so using the same edge to capture works well. 2) The setup relationship is 0ns and hold is -5ns, which is half the clock period, or exactly the data period. Looks good. 3) After compiling, the setup slack is ~0.6 and hold is ~2ns(at the slow corner). So you're meeting timing. In the Resource Property Editor, the Input Delay from Pin to Array is 0, which means it is as fast as it can be. That is correct, since making it slower would only make the setup timing worse, so I don't see a reason to change it. (I looked quickly in the Assignment Editor and could not see an assignment for this. I'm really scratching my head. The Fine Grained control is a separate "half step" delay that is really small and either on or off. I don't know why there isn't a D1 delay chain assignment. Perhaps file an SR? I'm not looking into it more right now because as of right now, the fitter is doing the right thing setting this to 0.
