3
\$\begingroup\$

I have an combinational entity that is implemented with a lot of combinational logic. Synthesis (using Xilinx ISE) indicates:

Maximum combinational path delay: 62.367ns

When placed into a synchronous (clocked) design, the maximum frequency the entire system (clock domain) can operate at is only ~16 MHz. Essentially this one component would drive the entire system's maximum clock rate down.

What I want to do, is wrap this combinational component up in some synchronous logic (with start input, done output), that essentially "waits" on the propagation delay of the async component. Basically it just latches in the input, waits N clock cycles, and then latches the output to a register. However, after synthesis ISE still says Maximum Frequency: 16.975MHz.

How do I get ISE to ignore the propagation delay of this device? Or, how else can I attack this?

EDIT:

I mean combinational instead of asynchronous.

This is part of a homework assignment. We previously were to implement a factorial module in each of "iterative", "low-latency" (combinational), and "high-throughput" (registered stages). Now we're using the first two of those in IP cores for Xilinx XPS system builder. The synchronous implementation was a piece of cake to get working (probably because that's how it should be done!) Of course, the timing constraints aren't met for the low-latency version, so I have to add logic to address this.

Now that I know the term is "Multicycle Path", the following resources are helpful:

\$\endgroup\$
1
  • \$\begingroup\$ Do you mean synchronous or sequential? \$\endgroup\$ Commented Aug 4, 2013 at 21:08

1 Answer 1

Reset to default
4
\$\begingroup\$

I assume that you mean that you have a combinational (not asynchronous) logic which represents critical timing path which limits the frequency, right?

Your Static Timing Analysis (STA) tool have no idea that you allow this component to spend several clock cycles before you expect to get a valid output. Synthesis still thinks that the propagation from the input stage to the output stage should take place in a single clock cycle. It makes its best to optimize this path, but still, the propagation delay is too long.

You have several options:

  1. The best option in such cases is to split the combinational path into few smaller path, and add register for sampling the intermediate results of the reduced paths. This will reduce the propagation delays, but will add latency - you will get the valid output delayed by the number of sampling stages.
  2. If you do not want to mess with this logic (it is too complex, or it is "silicon proven", or any other reason), you can do what you did: add sampling stages before and after the logic, and add additional control logic which knows how many cycles to wait for the valid data (and not allow the inputs to change). However, you must communicate such an unusual intent to all the tools. Information like this was given a general name: "design constraints". Now, I don't know how to specify design constraints for your FPGA (I think it will not take you more than 10 minutes to understand how). What constraint do you need to add? These kind of combinational paths which take more than one cycle are called "multi-cyle-paths" (MCPs). Find it in the documentation of your FPGA\IDE.

NOTE: there is yet another design constraint which may help you - "false path" (FP). When you define some path as FP, no tool will try to derive any timing for this path. This is useful for DFT stuff, clock muxes etc. However, even you may be tempted to use it in this case (FPs are much more simple to define properly than MCPs), don't do it! MCPs constraints must be validated by formal tools, therefore if you define MCP as FP you are masking many potential bugs.

\$\endgroup\$
7
  • 2
    \$\begingroup\$ +1 Yes, the Xilinx tools will let you specify a multi-cycle constraint and that is the right way to handle this situation. The details are well documented by Xilinx. \$\endgroup\$ Commented Aug 4, 2013 at 20:53
  • \$\begingroup\$ "Multi-cycle-path" was the term I was looking for -- we were never taught any of this, and I'm not sure it was apparent that this would come up. A suggestion to Disable the "Treat timing closure failure as error" option was made, but that sounds like a Bad Idea (tm). \$\endgroup\$ Commented Aug 4, 2013 at 21:08
  • \$\begingroup\$ I will certainly go and research this "Multi-cycle-path" option. If anyone has any quick pointers they'd be willing to share, I'd greatly appreciate it as I've spent days on this issue. \$\endgroup\$ Commented Aug 4, 2013 at 21:09
  • \$\begingroup\$ Are you undergrad? I've never heard about undergrad courses having such a complex and interesting assignments! \$\endgroup\$ Commented Aug 4, 2013 at 21:11
  • \$\begingroup\$ The documentation of the tool you're using will surely cover the topic of MCPs. Maybe it won't cover all, but it will definitely be enough \$\endgroup\$ Commented Aug 4, 2013 at 21:13

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.