Why does the NCO block in Signal Processing Blockset perform poorly in HDL synthesis when using HDL Coder (R2009b)?

1 view (last 30 days)
I have a rather large design that uses the NCO block. When I synthesize the design, the critical path is located inside the code generated from the NCO block. I am not able to meet my timing requirements with this design. Is there a way to optimize it?

Accepted Answer

MathWorks Support Team
MathWorks Support Team on 29 Mar 2013
This enhancement has been incorporated in Release 2013a (R2013a). For previous product releases, read below for any possible workarounds:
This is a limitation of the NCO design in the Simulink HDL Coder 1.6 (R2009b).
The NCO was designed to match the Simulink implementation which does not produce optimal code for hardware. There are two steps you can take to optimize the NCO, in it's current implementation (R2009b and earlier) for hardware synthesis:
1) Be sure that the lookup table gets put into a BlockRam (in Xilinx). This is generally done by putting a 'reset none' (via a control file) at the output of the NCO and using the 'register balancing' option in Xilinx ISE. Note putting a 'reset none' at this point in your system may cause HDL simulation problems since an 'X' will be propagated at time=0. If you are building a design with feedback on the data path, following the 'reset none' register, you will see simulation mismatches. This is probably not a problem in implementation since the flip-flop initializes to 0 but this depends on the application.
2) Make sure that the 'register balancing' option is active in Xilinx ISE. This is the Xilinx term for 'retiming' in other tools. See the documentation for your synthesis tool for specific instructions.

More Answers (0)

Categories

Find more on Code Generation in Help Center and File Exchange

Products


Release

R2009b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!