[SOLVED] problem regarding xilinx multiplier ip core

[achaleus]

Hello edaboard,
after generating xilinx multiplier ip core v11.2 ( release version 14.2, applicaton version p.28xd) width 32x32 bit expecting 64 bit output in which 6 stage pipelining is selected, using mults based multiplication . I am expecting output after 6 clock cycles, but in pdf no where mentioned initial clock latency (which is 1008 clock cycles after I am getting output in my case), whether I done any mistake.. or something ... please suggest.

here I am attaching multiplier pdf of xilinxView attachment mult_gen_ds255.pdf

 

[FvM]

There's surely no "initial clock latency ". I guess you are seeing PLL lock delay after reset.

 

[achaleus]

There's surely no "initial clock latency ". I guess you are seeing PLL lock delay after reset.

Thanks for the reply, but I have not used any PLL, I simply generated IP core multiplier and I want to check the output...
even the generated ip core doesnot have any reset. clk,a,b (32x32)are the input and 'p'(64 bit) is the output.

 

[xtcx]

Hello edaboard,
after generating xilinx multiplier ip core v11.2 ( release version 14.2, applicaton version p.28xd) width 32x32 bit expecting 64 bit output in which 6 stage pipelining is selected, using mults based multiplication . I am expecting output after 6 clock cycles, but in pdf no where mentioned initial clock latency (which is 1008 clock cycles after I am getting output in my case), whether I done any mistake.. or something ... please suggest.

here I am attaching multiplier pdf of xilinxView attachment 97238

Initial latency may be expected. Are you using LUT or Mult block?. Lut can eat up more latency. But how does it affect you?. I mean, since it is a pipeline stage Mult, you may not have this impact. Once initial latency passes by, you will get o\p continuously. Provided, it will pick 35x35 Mult in your case and hence it adds few more latency cycles.

I wouldn't consider this as a mistake. If 1008 cycles really bother, then think of tweaking the IP configurations and pipeline stages.

- - - Updated - - -

There's surely no "initial clock latency ". I guess you are seeing PLL lock delay after reset.

The block will have some initial latency, to flush outputs through the LUTs\DSP Slice. DSP Slice should give very little to zero latency, depending on configurations.

But however 1008 cycles might be odd. But still to my surprise....

 

[FvM]

Thanks for the reply, but I have not used any PLL, I simply generated IP core multiplier and I want to check the output...
even the generated ip core doesnot have any reset. clk,a,b (32x32)are the input and 'p'(64 bit) is the output.

I notice that told effectively nothing about your way to test the design. I think it's pointless to guess further.

Initial latency may be expected. Are you using LUT or Mult block?. Lut can eat up more latency. But how does it affect you?. I mean, since it is a pipeline stage Mult, you may not have this impact. Once initial latency passes by, you will get o\p continuously. Provided, it will pick 35x35 Mult in your case and hence it adds few more latency cycles.

I wouldn't consider this as a mistake. If 1008 cycles really bother, then think of tweaking the IP configurations and pipeline stages.

I must confess, I'm unable to relate the explanation to known FPGA behaviour.

 

[achaleus]

Initial latency may be expected. Are you using LUT or Mult block?. Lut can eat up more latency. But how does it affect you?. I mean, since it is a pipeline stage Mult, you may not have this impact. Once initial latency passes by, you will get o\p continuously. Provided, it will pick 35x35 Mult in your case and hence it adds few more latency cycles.

I wouldn't consider this as a mistake. If 1008 cycles really bother, then think of tweaking the IP configurations and pipeline stages.

- - - Updated - - -



The block will have some initial latency, to flush outputs through the LUTs\DSP Slice. DSP Slice should give very little to zero latency, depending on configurations.

But however 1008 cycles might be odd. But still to my surprise....

Thanks xtcx for reply, but there is no further options in generating ip core,, only the input, output width , LUT'S or MULTS and no' of pipelining stages.
they have given 6 being optimum, so I selected 6 pipelining stages,
but in the given pdf they haven't mention any initial clock latency , and yes the initially 1008 clock latency really bothers me in my project

 

[xtcx]

Which type you choose, LUT or MULTS?.

If you really are troubled, try to use a DSP-48 Slice for your multiplication. It has very little latency

 

[achaleus]

Which type you choose, LUT or MULTS?.

If you really are troubled, try to use a DSP-48 Slice for your multiplication. It has very little latency

I used MULTS, by default it is inferring(ip core) DSP-48 blocks,

any suggestion on how to use DSP-48 for multiplication,,, suggestions are greatly accepted

 

[xtcx]

I used MULTS, by default it is inferring(ip core) DSP-48 blocks,

any suggestion on how to use DSP-48 for multiplication,,, suggestions are greatly accepted

okay, first you need to make sure whether are you going to use it through opmode or not. DSP slices have opmode which can be easily used to perform necessary operation. This changes with your device. I am giving a guide her for v4.

Get this link first
https://www.xilinx.com/support/documentation/user_guides/ug073.pdf

Goto page 39. You can find 35x35 multiplier opmode.
Now instantiate a DSP 48 primitive through VHDL\VERILOG. Input your OPMODE and provide your multiplier inputs.
Run a simulation and check the latency.

Remember it is the opmode than decides the operation of a DSP SLice.

- - - Updated - - -

Depending on your device you may or may not have DSP Slices. DSP Slices are not dedicated Multipliers, but it has dedicated multipliers as well.