UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
535 Views
Registered: ‎07-10-2013

DSP48E2 Primitive Improper Simulation Behavior

Jump to solution

Using Vivado v22018.3, following some unexpected simulation results involving DSP48E2 primitives in a larger design, a simple Verilog test bench was constructed to concentrate on verifying the behavior of a single DSP48E2.

The test used involves applying data values to the A and B inputs, with AluMode = 0, CarryIn (and CarryInSel) = 0, and OpMode = 3 (i.e., WMux, ZMux and YMux are 0, and XMux is 2'b11).  Per UG579(v1.7) p.29, Pout should equal Z+W+X+Y+CIn.  With The XMux control set to 2'b11, the A:B data should be selected by the XMux (p.28), so that Pout should be a copy of the data being provided in to the A:B inputs.

This is in fact what happens when the relevant input controls are configured to use no (0) pipeline registers, with the outputs (P reg, etc.) also configured to use no pipeline registers.  However, if the coding is changed to have all of the relevant input controls utilize one level of pipelining, the P data produced is no longer a clone of the A:B input data, and is instead 0.

Some experimentation has shown that the expected behavior does result when all of the relevant input controls utilize one level of pipelining, except for the following attributes, which need to be 0 for proper operation: BCASCREG, BREG, CARRYINSELREG and OPMODEREG.  

The test bench uses a `define to allow changing just the values of those four attributes, with no other changes made to the coding.  Again, when all four specify no pipelining, the expected reuslts are seen, while when they specify use of pipelining, the expected results are not seen.  As far as can be determined, everything is in place in the code to allow either case to work properly, e.g., proper attention to the control inputs' clock enables, etc.

The archived test bench project can be provided.

Only Xilinx employees need respond to this post.

FourCtrlRegsUnclocked.png
FourCtrlRegsClocked.png
0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
360 Views
Registered: ‎07-10-2013

Re: DSP48E2 Primitive Improper Simulation Behavior

Jump to solution

Per Naveen's help in getting this resolved (SR#10459230), the issue turned out to be the GSR signal that is asserted at the beginning of the simulation (refer to UG900), which affected the DSP48E2 behavior when pipelining registers were enabled, but which had no effect when pipelining registers were not enabled.

3 Replies
Explorer
Explorer
499 Views
Registered: ‎07-10-2013

Re: DSP48E2 Primitive Improper Simulation Behavior

Jump to solution

After a bit more experimentation involving the values for the BCASCREG, BREG, CARRYINSELREG and OPMODEREG attributes, the following has been noted:

a) If BCASCREG and BREG have different values (e.g., one is 0, the other is 1), the compilation fails.  This is in line with what UG579(v1.7) indicates on p. 53, that for  values such as 0 and 1, both attributes need to have the same value.  However, compilation does not fail when the CARRYINSELREG and OPMODEREG attributes have different values (e.g., one is 0, the other is 1), inspite of what is indicated on p.36, that both of those attributes must also have the same value as each other.

b) When BCASCREG and BREG are both 1, no values for CARRYINSELREG and OPMODEREG are seen to result in the expected behavior.

c) When BCASCREG and BREG are both 0, the expected behavior is seen when OPMODEREG is 0, and not seen when OPMODEREG is 1, with the value of CARRYINSELREG making no difference.

0 Kudos
Explorer
Explorer
361 Views
Registered: ‎07-10-2013

Re: DSP48E2 Primitive Improper Simulation Behavior

Jump to solution

Per Naveen's help in getting this resolved (SR#10459230), the issue turned out to be the GSR signal that is asserted at the beginning of the simulation (refer to UG900), which affected the DSP48E2 behavior when pipelining registers were enabled, but which had no effect when pipelining registers were not enabled.

Xilinx Employee
Xilinx Employee
330 Views
Registered: ‎06-13-2018

Re: DSP48E2 Primitive Improper Simulation Behavior

Jump to solution

Hello @chsdkj 

Additional to your comments, The glbl.v file declares the global GSR and GTS signals and automatically pulses GSR for 100 ns

You need to modify your test bench in such a way that the input comes after 100ns. This you can do in 3 ways:

  1. Putting a reset signal in the test bench.
  2. Increase the clock cycle in such a way that the input comes after 100ns.
  3. stimulus to input till 100ns should be 0.

Hope this information will help you.

Regards,

Naveen

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------

0 Kudos