• 0
Sign in to follow this  
newkid_old

Implementation Strategies

Question

I have a design that fails timing with a negative THS as well as 1 of my nets not being routed.  I use the default strategy.  In reading in the Xilinx forums I see that you can choose other strategies so my question is if I change my strategy is it possible my design will succeed in timing and route my net?

Share this post


Link to post
Share on other sites

6 answers to this question

Recommended Posts

  • 0

Hi,

it may help to close timing. But most likely it's a dead end, for several reasons:

  • P&R is at the end of the design process. It fails here but the root cause lies somewhere else
  • most likely (blind guess, assuming from the nature of the question that you're not a power user), the problem lies in the constraints. Specifically, a missing "false_path" to timing-uncritical IOs like switches or LEDs. This can be a timing killer, because it leads to an impossible job for the tool.
  • inserting pipeline registers will most likely fix it. In most cases (no closed loops, no rigid latency constraints) it's fairly easy to insert single-cycle delays across a "cut plane" through the design, leaving the functionality unchanged.
  • Regardless of the strategy, check that "register rebalancing" option is enabled
  • even if you manage to close timing once by tool options, the design will be difficult to work with, long P&R times and no guarantee of success. When squeezing a commercial, large volume design into the smallest possible device this may be worth the trouble, but not during R&D unless the design is "pushing the envelope".

 

Edited by xc6lx45

Share this post


Link to post
Share on other sites
  • 0
12 hours ago, newkid_old said:

if I change my strategy is it possible my design will succeed in timing

From my experience the answer is *yes*. That's a qualified yes. I've been able to complete a project by changing the default strategy but not always. You should experiment with the options available with ISE, Vivado, Quartus..etc.

I have to say that I am not disagreeing with anything that @xc6lx45has posted just prior to this one. Most often designs that fail to meet timing need to have fundamental changes made to get success. This sometimes means pipelining ( I should say additional pipelining as this should be in mind as you craft your combinational logic ), re-structuring your design, lessening the width of internal busses, moving logic to DSP or BRAM etc. It depends on design complexity, clock rates, how much of the device resources are being utilized etc.

In the commercial setting, and sometimes in the informal project setting a difficult project that finally gets implemented robustly will fail after a design change later on. You should be comfortable with and have experience with all of the strategies on hand because this is the phase where things get difficult and there is usually a lot of pressure to finish. This topic is not esoteric but totally practical for most people using programmable logic. For some projects that have to work over a wide temperature range simply rebuilding a configuration bitstream without making changes to the source can land you in the land of timing closure. I've been there.

P.S. Changing the default settings for the Synthesis or Place and Route tools is never a Magic Bullet and for most "hobby" projects will not help ( because it's your design choices and skill ). ISE, Vivado and Quartus all have tool that will run a number of strategy scenarios and suggest possible modifications to the default settings. Often the results are disappointing but sometimes it leads to insight as to how you might tweak your design for better performance and feature creep. If you are clueless as to what the tools are doing playing with tool settings blindly is a very frustrating game of Whack-A-Mole that you will tire of quickly.

Edited by zygot

Share this post


Link to post
Share on other sites
  • 0
9 hours ago, xc6lx45 said:

most likely (blind guess, assuming from the nature of the question that you're not a power user), the problem lies in the constraints

Just a comment here: For designs with dense, complicated combinatorial logic, or high clock rates It is usually necessary to provide the Synthesis and Place & Route tools with good constraints in order to achieve timing and a robust implementation.  One thing that the FPGA vendors don't want to hear from their important customers is that the tools just can't implement a design ( unless of course it requires resources that the target device doesn't have or more resources than it has ). The behavior of all of the toolsets from every FPGA vendor that I've used all will dutifully try and meet timing constraints but will always come to a conclusion and report a successful implementation even when there are a ton of failing timing paths. You really don't want it to chug away for a few days only to report the same result do you? Writing good constraints is not the end-all of timing solutions. Also, timing constraints are a sub-set of relevant constraints that can get you to where you need to be. Still, a big design may have to be re-worked to fit a particular device even if you hand place parts of your logic.

You can't train your tools to behave the way that your want them to but they can train you to create better design constructs and communicate better in the language that it understands...

Share this post


Link to post
Share on other sites
  • 0

Thanks for the input.  I will try different combinations of Synthesis strategies and Implementation strategies.  This is my first major project with FPGAs.  A couple questions came up in reading both of your posts:

1.  Where do I find the "Register Balancing" option?

2.  My design was originally a single channel design for testing but now its going to multiple channels with the same logic re-used.  Is there a strategy that targets the re-use of logic?

 

Cheers

Share this post


Link to post
Share on other sites
  • 0

>> Is there a strategy that targets the re-use of logic?

this is a slightly different question, but can help the tools with timing:
Sometimes I need to replicate logic that starts with an input register on the same data for all instances (e.g. multiple blocks using identical high-frequency counters as internal timebase).
The tools will recognize them as logically equivalent and try to use one shared register. This is bad, when the downstream logic is timing-critical. In this case, I can manually flag the register as "DONT'T TOUCH" so the replicas are preserved and placed closer to the critical logic.
Optimization would eventually reach the same conclusion after thinking long and hard.
There is a "-keep-equivalent-registers" option that makes this the default.

The "rebalancing" option is under Synthesis options "-retiming".

Share this post


Link to post
Share on other sites
  • 0

@xc6lx45

Here's why I really like your last post on this subject. Between the lines I read: "Asking someone to resolve your issue is risky because every design is different and the issues created for a particular implementation is different and the best solution is different". This concept is even more true when the advice comes from someone who can't possibly understand all of the particulars of your project.

Sure, there might be responses with general guidelines and testimonials of past experiences but the burden of understanding, and responsibility,  is still yours. The gold in your advice is this: Have you learned about....?

I understand the desire to save time but.. use that Xilinx Documentation Navigator and get to know something about your tools. Try out the timing explorer, or whatever your tool calls it, and see what the tool comes up with as Synthesis and Place & Route strategies for improving your timing closure. Be teachable.. even by Vivado. 

I can say with confidence that whatever you do to get today's project ills resolved will be unlikely to solve tomorrow's project ills. Till someone can put experience into a pill this is the best advice you will get ( assuming that you aren't just solving an unwanted problem and have no interest in doing future FPGA development. )

As an aside this thread opens a point of frustration that never seems to be addressed adequately. Some constraints and tool guide commands can be inserted into HDL source as pragmas and some have to use alternate means like constraints files, TCL, or GUI project settings... Vendors, is it really too much to expect that one day your tools could be more user friendly?

Edited by zygot

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this