WARP Project Forums - Wireless Open-Access Research Platform

That's the right procedure; you have repositories setup correctly if the XPS flow ran to the point of a timing failure.

How many failing paths were there? And which constraints failed? This info is printed in the timing report towards the end of implementation/xflow.log.

One parameter you can tweak is the placer cost table. This acts like a seed for the place/route process. It's set by the "-t X" (for integer X) in the map section of etc/fast_runtime.opt.

It's also worth noting you can use the SDK to modify the MAC C code without re-building the hardware project in XPS. The SDK_Workspace folder in the reference design archive includes the output of a pre-built hardware project. The software compilation flow will use this hardware project data to write a bitstream with updated software.

Sorry, I know that's frustrating. I've iterated on the XPS design 10's of times in the last few weeks without failing timing. We used to have more timing failures. I've added pipeline registers to critical paths in the PHY cores as they failed, which helped a lot.

The failing constraint here is the 160MHz clock used by most of the FPGA logic. 49 paths missing by up to 1nsec is a surprisingly big failure. The Timing Analyzer can pinpoint the failing paths. You can run the Timing Analyzer from ISE Design Tools -> 64-bit Tools, choose Open Design, then direct it to <xps project>/implementation/system.ncd & system.pcf.  The "Timing -> Run Analysis" default report options will show the worst timing paths.