Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

How to force lpm_mult to use input REGISTERS on the block?

Hi,

I'm implementing this circuit:

inputA_1,2,3,4 connected to a mux then to Multiplier_M

inputB_1,2,3,4 connected to a mux then to Multiplier_M

I want Multipiler_M to register the inputs and then perform multiplication (total 2 clks)

But:

code of my multiplier:

...

process

begin

if(rising_edge(clk)) then

input_1reg<=input1;

input_2reg<=input2;

end if;

end process

output <= input_1reg*input_2reg;

......

Quartus uses FFs on LEs to implement input_1reg and input_2reg. This leads to some additional routing delay ==> increase clock period. What i want is that the input_1reg and input_2reg are implemented using Registers on the MULTIPLIER block. How to force Quartus to do this?

Thank you very much

Jeff

9 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    From the Quartus handbook, I would expect that that the pipeline registers are packed into the DSP block, already with default auto resister packing. I tested with the VHDL multiplier inference example from Quartus handbook and a Cyclone III. Except for Register Packing = Off, the registers had been packed to DSP block. This is shown only in fitter resource usage and technology map viewer and can be seen from max. frequency results. RTL viewer and also post mapping view show separate registers, but they don't have a location in design, actually.

    So it seems to me, that with default settings the registers are optimized (packed to DSP blocks) as expected. If this isn't the case with your design, additional settings or specific design conditions may prevent this normal behaviour. Instantiating lpm_mult directly achieves location of pipeline registers in DSP block unconditionally, of course.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Hi,

    Thanks for your reply,

    I've created a separate test, Register Packing works.

    But for my actual application, it doesn't work ... I'm playing around with the value of that setting ... there's a routing delay of 1.3 ns before the multiplier ... and the internal registers of block multiplier are bypassed ...

    About: the latency setting of lpm, how do we know what registers are used? input or output? ... I can't find the information from Embedded Mult User Guide ...

    Thanks :)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    When i view the resource details after fitting, i can see configuration of DSP blocks. Only 2 multipliers use on-block registers (register on embedded block) ... Why can't Quartus pack registers onto the other multipilers?

    Newbie Jeff thanks very much for your help ..

    Jeff
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    But for my actual application, it doesn't work

    --- Quote End ---

    Yes, I guessed that, but I don't know which additional condition prevents register packing. I assume, that you did not access inputx_reg additionally, e. g. with SignalTap.

    Did you try a more strict Register Packing option, e. g. sparse? But instantiating lpm_mult must help anyway. As you have a 2 cycles pipeline, lpm_mult would always use both registers.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    I didn't access the input_reg anywhere else ... that's how i implement my multiplier entity. At rising_edge inputx_reg<= inputx; output always <= inputx_reg*inputx_reg.

    I've tried Sparse, and Sparse Auto .. still doesn't work ...

    It's strange that i can't manipulate the resource the way i want ... :|

    Thanks a lot, FvM!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    If you're doing a test design, might the input registers be "identical" for each multiplier? If that's the case, synthesis algorithm might merge all the registers first(since they're duplicates). At that point there is only one register and it gets packed into only one of the multipliers. Just a guess, but since you're seeing it occur on one, it would make sense.

    Go to Assignments -> Settings -> Analysis & Synthesis -> More Settings and set Remove Duplicate Registers to Off and recompile. This should stop any merging. If that does fix it, you probably don't want to turn it off project wide, since removing duplicate registers is often good. You can right-click on the hierarchy, Locate in Assignment Editor, and make an assignment for Remove duplicate Registers = Off on the hierarchy. (you can also do it on the individual registers if you want.) Anyway, just a guess...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Thanks ... the registers are not duplicates ...

    When i don't share the multiplier ==> no mux in the front ... => Quartus can push those input registers of multiplier onto the block ... I guess something restricts Quartus from doing so for other cases

    Jeff
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Cause it works in the simple case, e.g. as in the Quartus Handbook multiplier inference example, incrementally modifying the design should reveal the problem.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    Are you synthesizing for Area? There's a mux restructuring algorithm(you can directly turn it off in Assignments -> Settings -> Analysis & Synthesis) that is very compact and I believe makes use of the carry chains. Most algorithms(Physical Synthesis, register packing, etc.) tend to take a hands-off approach to anything connected to the carry-chain, and this might follow suit. Again, just a guess.

    I would either instantiating the multiplier megafunction and force it rather than spend too much time, and file it as an SR. If you get a resolution, please update the board.