different result in testbench with and without dsp

[askhunter]

Hi, I try to simple multiplication, but when i use dsp attribute then  i got different result in simulation .what is the reason of this?

without dsp attribute - attribute use_dsp of sum : signal is "no";

with dsp attribute - attribute use_dsp of sum : signal is "yes";

 

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.types.all;

entity convolution2d is
    port (
        clk, rst : in  std_logic;
        start    : in  std_logic;
        window   : in  frame9;
        done     : out std_logic;
        pixel    : out pixel8
    );
end convolution2d;

architecture rtl of convolution2d is
    constant mask : mask_9 := (-1, -1, -1, -1, 8, -1, -1, -1, -1);
    signal sum : integer:=0;
    
    attribute use_dsp : string;
    attribute use_dsp of sum : signal is "yes";
begin
    
    -- iterative way

    process(clk) is

        --variable tick : std_logic:='0';
    begin
        done<='0';
        if rising_edge(clk) then
            if start = '1' then
                sum <= 0;
                for n in 0 to 2 loop
                    for k in 0 to 2 loop
                         sum <= sum + (to_integer(unsigned(window(n*3 + k))) * mask(n*3 + k));
                    end loop;
                end loop;
                done<='1';
                pixel <= std_logic_vector(to_unsigned(sum, 8));
            end if;
        end if;
    end process;
end rtl;

"

[askhunter]

first : without dsp attribute - attribute use_dsp of sum : signal is "no";

second image : with dsp attribute - attribute use_dsp of sum : signal is "yes";

[zygot]

@askhunter

I suggest that you read UG479 to see what the DSP48E blocks do. Then read UG901 to see what the use_dsp attributes do. Reading the recipe doesn't always help improve the cooking but it never hurts.

A long time ago having signed multipliers in hardware was a big deal for FPGA developers. For the past decade or so these have become integrated into more complicated and useful 'DSP' blocks. The DSP nomenclature is a holdover from the days, long before IEEE floating point hardware was available, when having a fast multiplier in hardware meant that you could do some fun stuff in a micro-controller that you couldn't do with software routines. These days the lines are blurry. Most FPGA devices have some really fast hardware features, block ram and DSP blocks ( depending on how they are used ) being the most useful for grinding out mathematical algorithms. By the way, the DSP blocks can be useful for more than multiply-add operations. 

[askhunter]

53 minutes ago, zygot said:

@askhunter

I suggest that you read UG479 to see what the DSP48E blocks do. Then read UG901 to see what the use_dsp attributes do. Reading the recipe doesn't always help improve the cooking but it never hurts.

A long time ago having signed multipliers in hardware was a big deal for FPGA developers. For the past decade or so these have become integrated into more complicated and useful 'DSP' blocks. The DSP nomenclature is a holdover from the days, long before IEEE floating point hardware was available, when having a fast multiplier in hardware meant that you could do some fun stuff in a micro-controller that you couldn't do with software routines. These days the lines are blurry. Most FPGA devices have some really fast hardware features, block ram and DSP blocks ( depending on how they are used ) being the most useful for grinding out mathematical algorithms. By the way, the DSP blocks can be useful for more than multiply-add operations. 

thank you for interesting. Actually, I read this documentation but this has so many detail and i'am very newbie in fpga. so i didn't understand mostly. even so I'll read it again.

[zygot]

@askhunter

Tip if you want to notify someone that you are responding to a post type @and the first few letters of their username. A selection of usernames will appear in a popup window to choose from. If you just type @ and the whole name you won't get the desired result. I confess that I'm not an expert on using the features of this site but I did figure out this one.

As to understanding all of the Xilinx documentation what yo are doing is correct. Speed-read though a document to get a general sense of what's being presented and don't worry about the things that you don't grasp. Just being familiar with what information is where will help with a specific question later. The DSP48E is a very complicated piece of hardware. You only understand how complicated by trying to instantiate it as a UNISIM component to implement a particular algorithm. I've done this and it take time. You understand by doing; one step at a time.

In your case I'm assuming that you are starting with someone else's code and trying to modify it. This approach takes a difficult task and turns it into an extremely difficult task.

[edit] Vivado uses the multipliers in a seamless way when you specify a multiply in your HDL code. It takes care of a lot of little details, such as that the multipliers are signed 18-bit. There are a LOT of options with the DSP48E blocks. Once you start making decisions for Vivado, by say, using the use_dsp attribute in your code you are taking on responsibility for more of those details... so you had better understand how the DSP48E blocks work. Trust me, even after you have figured out all of the necessary behaviors of the DSP48E blocks it doesn't get easier as you will have to contend with routing issues that might dramatically reduce your data rates. This is a general rule for using FPGA device resources. You can use the IP wizards to help construct a component that's useful for your needs or do it yourself in HDL code and assume the responsibility for getting all of the details and constraints right.

 

[zygot]

Let me offer a suggestion to all newbies, regardless of how smart you are, before trying to do FPGA development.

1. Read all of the user guides for the FPGA device resources that you are likely to be using. These will include the SelectIO, Clocking,  CLB , and memory guides at a minimum. [edit] also read the AC switching part of the device data sheet. Like it or not what you are doing in FPGA development is digital design and you need to have a sense of how design decisions affect timing.
2. Read the Vivado user guides for design entry, constraints, simulation, timing closure, and debugging.
3. Understand that even though various Zynq devices are based on certain FPGA families the documentation tends to be unique for these devices.

You will be overwhelmed with all of the 'basic' information. Spend a week or so running though all of the basic documentation, spending more time on specific topics each read-through. The object isn't to memorize or understand everything but to get a general feel for how Xilinx presents its information. You can also learn stuff that you will miss in specific IP documentation by using the simulation, but only if you are careful to read all of the simulator messages. This is complicated stuff and the tools, even when they behave as described in the reference material is even more complicated. The purpose of doing this is to get a general feel for how the devices work and specific use limitations and how the tools work. It will take a year or so before you start becoming competent at it if you are a normal human.