0
\$\begingroup\$

I am trying to compile a project and it takes a very long time to route. - ISE 14.3

In my main module, I am using a package where I have declared an array of constants. These constants use functions that I have declared in another package.

As far as I know, the synthesis tool precomputes these contant values and stores them as a LUT or block RAM before synthesis.

But I am wondering if using this package is creating routing issues. dev util

The constant package looks like this: sine table

the function real_to_sfixed is defined in a fixed point library that in turn calls few more functions

the table is used as: sine read

\$\endgroup\$
  • \$\begingroup\$ How long is "very long"? Are you comparing it to a previous similar project? Also what goal is the PAR stage prioritising and what effor level is PAR using (found in Project Navigator by right click on "Place & Route" process and selecting "Design Goals & Strategies" and "Process Properties")? \$\endgroup\$ – Xcodo Jun 30 '15 at 8:27
  • \$\begingroup\$ ya i am comparing to the previous implementation where i did not use a fix point library and my package was only made up of signed vectors. The strategy is a balanced strategy and and the problem is i am getting a failed timing constraint on the signal that reads from the package \$\endgroup\$ – Sai Gautam Jun 30 '15 at 8:32
  • \$\begingroup\$ So you are right that the tools put the constants into LUTs and block RAM. During synthesis, XST finds constants and synthesises them as ROMs (read-only memories) then decides whether to use LUTs or block RAM in the advanced synthesis (and throws information messages like INFO:Xst:3043). \$\endgroup\$ – Xcodo Jun 30 '15 at 8:41
  • 1
    \$\begingroup\$ The router is most likely having trouble because the retrieval of contants requires routing from lots of different slices (you should be able to see in the timing report). You could try pipelining your data flow so that the required constants are loaded on one clock cycle and used on the next, which would split the timing requirements up (at the cost of registers). \$\endgroup\$ – Xcodo Jun 30 '15 at 8:44
  • \$\begingroup\$ @Xcodo thank you for that i had the same feeling...but im not sure how to register or pipe,line constants.. \$\endgroup\$ – Sai Gautam Jun 30 '15 at 8:48
1
\$\begingroup\$

It is likely the double-subscript is causing synthesis to infer distributed memory rather than memory blocks. I would combine the selecting bits from N_int and sine_counter_d1 into a single signal addr and use this as the index within SINE_TABLE(addr). A synthesis report (not even P&R) should show the improvement.

I don't know VHDL, in verilog I'd do something like

wire [8:0] addr = { N_int[x:y], sine_counter_d1 };
...
   sine <= SINE_TABLE[addr];

You will need to tweak the constant loading to follow the same pattern. Spending hours laying out sea-of-gates to do what could be pushed into a memory is a good way to waste P&R time.

\$\endgroup\$
  • \$\begingroup\$ will try that. I tried associating ram style as block to SINE_TABLE. this doesnt work \$\endgroup\$ – Sai Gautam Jun 30 '15 at 11:45
  • \$\begingroup\$ i tried splitting it into many RAMS but it still doesnt infer block ram \$\endgroup\$ – Sai Gautam Jun 30 '15 at 12:54
  • \$\begingroup\$ does the repeated use of the function real_to_sfixed which is defined in another package, hinder inference of block ram? \$\endgroup\$ – Sai Gautam Jun 30 '15 at 15:19
  • \$\begingroup\$ no difference, it should be coming out as constants after synthesis \$\endgroup\$ – shuckc Jul 3 '15 at 11:28
  • \$\begingroup\$ Thank you. I recognized the problem. Device level utilization doesnt show usage of BRAM/FIFO. But on analysing synthesis report, It showed that the signal I was using was being inferred as block RAM \$\endgroup\$ – Sai Gautam Jul 6 '15 at 7:34

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.