HOME    COMMUNITY    BLOGS & FORUMS    Breaking The Three Laws
Breaking The Three Laws
  • About

    Breaking the Three Laws is dedicated to discussing technically challenging ASIC prototyping problems and sharing solutions.
  • About the Author

    Michael (Mick) Posner joined Synopsys in 1994 and is currently Director of Product Marketing for Synopsys' DesignWare USB Solutions. Previously, he was the Director of Product Marketing for Physical (FPGA-based) Prototyping and has held various product marketing, technical marketing manager and application consultant positions at Synopsys. He holds a Bachelor Degree in Electronic and Computer Engineering from the University of Brighton, England.

Partitioning Poser #1

Posted by Doug Amos on November 10th, 2011

There are those who say that one should partition so that only sequential eements are allowed to appear at the FPGA edges, thus simplifying the timing and constraints at the FPGA pins.

This is an excellent goal but one that we can not always reach.

We often need to partition combinatorial paths across FPGA boundaries and then we need to ensure good time constraints for the synthesis and, especially, for the P&R for each end of the path. Don’t forget, when implemented in the individual source and destination FPGAs, each part of the path is considered in isolation. The synthesis and P&R tools have no knowledge of the other end of the path and will assume by default that the signals on the stub that they can see have an entire clock period  to propagate (minus set-up or hold for the FF). In reality this is never the case and so we need to apply good timing constraints for these stubs. This is achieved by time budgeting the path to allocate an appropriate portion of the full path propagation delay to each stub. This is automated in tools like the Certify tool that I know and love. When the path runs across three or more FPGAs with the middle FPGAs possibly acting only as feedthroughs then the task becomes really tricky.

We can talk about time budgeting of combinatorial paths in a future blog but in the meantime, I have a poser for you around the best way to partition an example of a inter-FPGA combinatorial path.

 The simplified example in the diagram below, with a mux feeding multiple sources from two source FPGAs into a separate destination FPGA, is not as uncommon as we’d like to hope. After all, many bus standards used in SoCs are actually complex mux’es, and bus sources and destinations are often partitioned into different FPGAs.

Here, then, is a good example of how partition has happened at a multiplexer. We can see that the sources for the mux are in two separate FPGAs and the destination is in a third. The next task is to assign the multiplexer. The question for you is; where is the best place to put the multiplexer, including how and why?

Please use the comment box below to give us your replies.

I’ll explain my favourite answer in our next blog in any case.

All the best,


  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • LinkedIn

6 Responses to “Partitioning Poser #1”

  1. Minh-Duc says:

    Well, at first glance, it appears that FPGA C is the only place we can assign the mux to, since in case of assignment to A and B, we would get a some hopping paths spreading over 3 FPGAs. But if we plit the big mux into 3 muxes (1 in A to multiplex source1 and source2, 1 in B to multiplex source 3 and source 4, and 1 in C to select the previous 2 mux outputs) then we can reduce the number of board traces from 4 to 2.

    I guess, this decomposition feature in Certify is your favorite?

  2. Keith Reeder says:

    I’ll take a stab at it…I’d place the mux in FPGA C. Timing constraints and tools more easily deal with paths that end in clocked logic/nodes. It’s more difficult to properly constrain paths that end in combinational logic/nodes.

  3. Doug Amos says:

    Aaaaah, Minh-Duc, you are spot on and, yes, Certify can help with splitting the mux. Do you use that feature yourself? Even many experienced Certify users are not aware of it.
    I’ll pop a quick blog post to explain more.

  4. Doug Amos says:

    Hi Keith,
    You are quite right; partioning at combinatorial boundaries requires new timing constraints at the IO. I’ll post something more about timing budgeting soon.

  5. Howard says:

    I’m tempted to give a “timing constraint” answer that concerns not only the mux but the control logic to the mux. I would break the 4:1 mux into two 2:1 muxes at the output of FPGA A and FPGA B using only one control bit and then use a 2:1 mux at the input of FPGA C using the second control bit. In this fashion I can easily describe timing contraints based on input and output constraints.

  6. Doug Amos says:

    Perfect. and as Minh-Duc says in his reply above, Certify just happens to have a feature that makes that a lot easier. There’s still the question of time budgeting the constraints. I’m in the middle of writing the next blog post about that.
    Thanks for your reply.