cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
markus.offergeld
Explorer
Explorer
10,074 Views
Registered: ‎02-28-2011

Timing Problems with DSP48 block > 18 bits

Jump to solution

Hi all,

 

I am currently testing HDL Coder to generate Code (previously system Generator) and I am running into the following issue:

 

If I have a multiplier in my design which uses more than the natural DSP48 bitwidth (18x18bits), my timimg becomes very poor compared to the same System Generator design. In ym case i multiply FIX_36_18 with FIX_18_14 and FIX_18_14 result. The resource usage in the System Generator shows 2 DSP blocks used.

In both my designs the Inputs of that multiplier are registered and the output pipeline is set to 2.

Synthesis of Sysgen design show over 300MHz, while the HDL Coder design only shows 106MHz! My target is 100Mhz and compiling with such estimation will be very painful. I tried once and got a timing error after 20h!. Sysgen design compiles in about 1h with no timign errors.

 

Here is the timing report of the HDL Coder design (worst path happens to be at that multiplier):

 

 Timing constraint: Default period analysis for Clock 'IPCORE_CLK'
  Clock period: 9.388ns (frequency: 106.522MHz)
  Total number of paths / destination ports: 7436861895 / 70455
-------------------------------------------------------------------------
Delay:               9.388ns (Levels of Logic = 6)
  Source:            ALSTOM_DSC_HDL/u_dsc_design_v7_dsc_top_pcore_dut_inst/u_DSC_TOP/u_ALSTOMDSCControlsForIndustrialSVC/u_Synchronization/u_ThreePhaseWLSE/u_Estimation/u_MatrixMult1/u_MultPlus/b41_1_16 (FF)
  Destination:       ALSTOM_DSC_HDL/u_dsc_design_v7_dsc_top_pcore_dut_inst/u_DSC_TOP/u_ALSTOMDSCControlsForIndustrialSVC/u_Synchronization/u_ThreePhaseWLSE/u_Estimation/u_MatrixMult1/u_MultPlus/Product7_out1_1_16 (FF)
  Source Clock:      IPCORE_CLK rising
  Destination Clock: IPCORE_CLK rising
 
 Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
    ----------------------------------------  ------------
     FDCE:C->Q             2   0.317   0.344  u_MatrixMult1/u_MultPlus/b41_1_16 (u_MatrixMult1/u_MultPlus/b41_1_16)
     DSP48E1:A16->PCOUT47    1   3.314   0.000  u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp (u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp_PCOUT_to_Mmult_Product3_mul_temp1_PCIN_47)
     DSP48E1:PCIN47->PCOUT47    1   1.427   0.000  u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp1 (u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp1_PCOUT_to_Mmult_Product3_mul_temp2_PCIN_47)
     DSP48E1:PCIN47->PCOUT47    1   1.427   0.000  u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp2 (u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp2_PCOUT_to_Mmult_Product3_mul_temp3_PCIN_47)
     DSP48E1:PCIN47->P12    2   1.349   0.431  u_MatrixMult1/u_MultPlus/Mmult_Product3_mul_temp3 (u_MatrixMult1/u_MultPlus/Product3_mul_temp<46>)
     LUT2:I0->O           17   0.061   0.656  u_MatrixMult1/u_MultPlus/Product3_mul_temp[53]_Product3_mul_temp[52]_AND_5215_o_SW0 (N24)
     LUT6:I2->O            1   0.061   0.000  u_MatrixMult1/u_MultPlus/Mmux_Product3_out119 (u_MatrixMult1/u_MultPlus/Product3_out1<0>)
     FDCE:D                   -0.002          u_MatrixMult1/u_MultPlus/Product3_out1_1_0
    ----------------------------------------
    Total                      9.388ns (7.956ns logic, 1.432ns route)
                                       (84.7% logic, 15.3% route)

 

It looks like the design uses more DSPs and also does not distribute the delays between the DSP chain.

How can I force EDK 14.5 to move around the delays?

How else can I improve timing in this case?

 

Regards Markus

 

 

0 Kudos
1 Solution

Accepted Solutions
markus.offergeld
Explorer
Explorer
17,335 Views
Registered: ‎02-28-2011

After we found this thread: http://forums.xilinx.com/t5/Synthesis/How-to-enable-DSP48-pipeline-registers-without-instantiate/td-p/326425 we experimented and it seems that the (default) asynchronous reset of HDL Coder is the problem

 

Regards Markus

View solution in original post

0 Kudos
1 Reply
markus.offergeld
Explorer
Explorer
17,336 Views
Registered: ‎02-28-2011

After we found this thread: http://forums.xilinx.com/t5/Synthesis/How-to-enable-DSP48-pipeline-registers-without-instantiate/td-p/326425 we experimented and it seems that the (default) asynchronous reset of HDL Coder is the problem

 

Regards Markus

View solution in original post

0 Kudos