2
\$\begingroup\$

I am trying to learn more about the performance of different routings in my design using Xilinx ISE. I've figured out how to move logic around by changing which CLB/Slice holds which piece of using the User Constraint file. Is there a way to manipulate the routing? Or, at the very least somewhere I can get it to give me a text description of the routing paths?

Further details: I have implemented a simple AND gate in a spartan3E_100 and moved around the IOBs and the LUT which holds the logic. Every time I do so I look in the FPGA editor and the chosen routing is completely different. I'm sure it figures out the optimal but what I would like to do is modify the routing then look at how the performance changes. Is that possible? Second, is there any way to get a text description of the routing similar to the the info given in the UCF/PCF file?

\$\endgroup\$
  • 1
    \$\begingroup\$ There is explicit randomization in the build process, so designs that fail to reach timings can be retried with a different random seed. The optimizer can easily paint itself into a corner, and a fully deterministic process would behave equally bad on every compilation then, rather than distributing this statistically over all attempts. For simple designs that will always fit, that is suboptimal, but once you reach 50% utilization, this becomes important. \$\endgroup\$ – Simon Richter Jul 7 '16 at 15:53
3
\$\begingroup\$

Explicit 'hands-on' control of the routing sounds like a good idea, but it isn't.

Think back to the days when assembler programmers could squeeze a little bit more performance out of an algorithm by using manual assembly code instead of a compiler. There's only so much complexity you can think your way through. As the target becomes more complex, branch-prediction tables, multiple cores, deep execution pipelines, microthreading, that becomes impractical. I am writing here as somebody who wrote assembly code for a TI C6000 DSP, 8 execution units and a 5 deep pipeline for memory load/save, nightmare!

Only enthusiastic hobbyists write assembler these days, people who want to get the job done learn how to constrain, and to help, the compiler.

Anyhow, routing involves multiple resource types (long lines, half lines, straight through a mux, adjacent local lines, to mention but a few), multiple timing constraints (only a few of which are critical) and a lot of both.

The bottom line is that if you are laying out a single D latch, you can probably see your way round the routing. If you are doing anything of a worthwhile size, then you do not want to be, and cannot be, driving the routing directly. What you want to be doing is constraining, and helping, the routing optimiser. How?

Understand your timing constraints. Understand which are critical, and which are not. Don't over constrain for safety, the router is already taking account of worst case process with worst case voltage and temperature, that's why the timing tables are so humungeous. If you over-constrain, the router will struggle more. Only tightly constrain the critical lines.

Use floorplanning, this is where you can intervene with a bit of human 'I can see what I want' expertise. The placer doesn't always get it right. If the router fails, see what the placer has done, and if necessary, move some blocks from 'stupid' positions for a more sensible placing. Then let the router run again. Iterate that cycle, but let the router do its own thing.

\$\endgroup\$
1
\$\begingroup\$

Mostly all algorithms are heuristic and non-deterministic. You give a constraint into the problem solver, e.g. minimum frequency, and the tool will find a mapping, placement and routing for your problem. There are many many parameters which can be changed, so there is no easy algorithm to try all combinations / possibilities...

Giving additional constraints like IOB locations, makes the 'search' more complex so runtime will increase, while it can help in some cases to set a good algorithm starting point. But in most cases over constrained designs are not good.

Maybe the Xilinx Design Language (XDL) format contains routing information, but normally, this information is considered secret to the vendor.

Further reading:

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.