Is "*" operator Synthesizable in VHDL?

[jeet55]

I'm current working on a project where I need to multiply 2 signals, so my question is , is the "*" operator synthesizable in VHDL? and i'm using ALTERA DE1 FPGA board and if the "*" operator is sythesizable ,how it is implemented? is it done using FPGA fabric or build in DSP/Multiplier blocks.

[nctnico]

Read the synthesis guide. On Xilinx * is supported and will infer a hardware multiplier but you have to take care of things like sign extension.

[Daixiwen]

It is the same on Altera. You can have a look at the "Recommended HDL Coding Styles" chapter in the Quartus manual, volume 1. (grab the PDF while you can, Intel is currently transferring all the contents from the Altera site to theirs and is creating a huge mess).
This chapter will tell you how to write your HDL code to be sure it will use the hardware resources on the FPGA, and what you need to take care about.

[hamster_nz]

Yes - and can be implemented using the DSP blocks, but only as long as your design maps the the underlying resource.

Just be careful what you ask for - take care with the bit sizes of operands, the signed vs unsigned, the latency, the use of accumulators and pipeline latency. For best results, portability, and the ability to see what resources you are using you might want to move your '*' operation into a separate module.

This is some code that allows you to hit the upper limits of throughput & performance for an XILINX 7-series DSP block:

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity inferred_dsp is
    Port ( clk        : in  STD_LOGIC;
           a          : in  STD_LOGIC_VECTOR (17 downto 0);
           b          : in  STD_LOGIC_VECTOR (17 downto 0);
           accumulate : in  STD_LOGIC;
           p          : out  STD_LOGIC_VECTOR (47 downto 0));
end inferred_dsp;

architecture Behavioral of inferred_dsp is
   signal   product1     : signed(35 downto 0);
   signal   accum        : signed(47 downto 0);
   signal   a1           : signed(17 downto 0);
   signal   a2           : signed(17 downto 0);
   signal   b1           : signed(17 downto 0);
   signal   b2           : signed(17 downto 0);
begin
   p <= std_logic_vector(accum);
   
dsp_proc : process(clk)
   begin
      if rising_edge(clk) then
         --------------------------------------------------
         -- This should all be absorbed into the DSP block
         --------------------------------------------------
         if accumulate = '0' then
            accum       <= to_signed(0,48)  + product1;
         else
            accum       <= accum            + product1;
         end if;
         product1 <= a2 * b2;
         a2 <= a1;
         b2 <= b1;
         a1 <= signed(a);
         b1 <= signed(b);
      end if;
   end process;

end Behavioral;


[ejeffrey]

Yes, * can be synthesized and will automatically infer DSP blocks.  However, if in doubt you can always instance one of the multiplication megafunctions.  This makes your code less portable, but has the advantage of being explicit about the specific behavior of the hardware multiplier.  The portability argument is also a bit suspect.  Generally, when moving your code to a new platform you would want to at least check that your code was still matched to the hardware capabilities anyway.

[Siwastaja]

* is such a ridiculously basic and simple function that I totally fail to see why anyone would infer a vendor specific block to implement it.

Yes, I have seen it done a few times. But why? Has anyone ever documented any issues with * operator automatically inferring HW multipliers?

The portability is not the only factor; as said, porting to another FPGA family is a lot of work anyway.

But code readability (and writability) is a bigger factor, IMO.

Do you infer vendor-specific components for + and - operator as well? They require the synthesizer to do vendor-specific things as well (know how to connect the carry lines between the logic elements).

In fact, every line of VHDL implements vendor-specific stuff, that's what they synthesis is all about. You could even do the DFF by inferring it as a component from the Quartus library. Yet that would be disastrous to coding style.

[legacy]

* is such a ridiculously basic and simple function that

the operation's size (how many bits provided by the DSP-slice's function) is the problem.

[Siwastaja]

* is such a ridiculously basic and simple function that

the operation's size (how many bits provided by the DSP-slice's function) is the problem.

Why? VHDL (and Verilog as well, AFAIK) directly covers this by having explicit widths in their data types. They translate directly to the synthesizer.

Did you ever try? What kind of problems did you have?

[Siwastaja]

      if rising_edge(clk) then
         ....
         product1 <= a2 * b2;

ummm, I wouldn't implement a math function within a clocked function 

Wat??

[legacy]

Why? VHDL (and Verilog as well, AFAIK) directly covers this by having explicit widths in their data types. They translate directly to the synthesizer.

the VHDL translates the hardware description language into something that can be synthesized, but during this process the synthesizer needs to consider HOW physically the DSP-slice is implemented in target FPGA, and this has a finite number of bit to implement the multiplication, thus, you can't say that you are going to expect the tool will do all the job like if it was a piece of cake. You'd better consider in this case, HOW it will be synthetized, and you *might* end considering your own tricks to help the synthesizer to do a good job.

[Siwastaja]

So, any documented examples of the synthesizer actually failing to find the number of bits from the * operator, which is the normal industry practice?

[hamster_nz]

* is such a ridiculously basic and simple function that

the operation's size (how many bits provided by the DSP-slice's function) is the problem.

Why? VHDL (and Verilog as well, AFAIK) directly covers this by having explicit widths in their data types. They translate directly to the synthesizer.

Did you ever try? What kind of problems did you have?

This can be summed up in "the tools ensure you get what you asked for, nothing more, nothing less".

If you want to ensure you get a particular implementation you have to ask for it explicitly, hint at it through your code so the tools infer exactly what you want, or just write code and try your luck.

The difference in performance, power and resource usage between a fabric multiplier and DSP multiplier is large enough that for things that matter I don't want to try my luck.

The worst is that the results are not consistent - all you have to do is slightly change your code or use a different set of constants and everything blows up or magically works.

[hamster_nz]

So, any documented examples of the synthesizer actually failing to find the number of bits from the * operator, which is the normal industry practice?

How many 18x18 DSP blocks does it take to calculate a signed 35-bit "y <= x^2"?

People who freely throw '*' around seem to be the ones who use "integers" in their pipelines, and so end up with 32-bit operations.

I had a project that needed 996 multiplier blocks, but my FPGA only had 840 DSP slices. What was I to do?

I was working on a video pipeline being squeezed into the smallest part possible (54 DSPs IIRC).  We chose to implement some of the matrix operations for color space conversion using explicit fabric, multipliers depending on the simplicity of the constants - some constants that could be implemented at the 150MHz pixel clock speed with the same latency as a DSP block, others couldn't.  This freed up DSP blocks for where they were really needed (where neither operands were constants).

Would you implement a x128 operation in a DSP block or the fabric?

Now what if that x128 operation is one of many constants in a multi-tap DSP filter, a filter that can be best implemented using the using DSP block's cascade ports?

Why do you think that the DSP blocks have 50+ page user guides, unlike '*'?

[Siwastaja]

Fair enough. Just a question, how did you control the synthesis when you wanted to implement the multiplication without the DSP slices to free them up for those wider operations - did you write your own multiplier implementation (which would look a bit tedious and wouldn't necessarily be the optimum design for that FPGA fabric), or did you disable mapping * to DSP slices completely compilation-wide, or use some more specific controls in constraints file?

[legacy]

DSP48-based-multiplier, this topic is interesting.

[emece67]

.