LPM DIVIDE behaves differently between simulation and implementation

Hi,

If you check the simulation, the 0xFF..FFF4FF is under 010139F1A9h.

However in signal tap, you're checking under 010131CEB9h.

May be use other trigger condition to trigger the 0xFF..FFF4FF under 010139F1A9h, may be use transitional.

Thanks,

Regards,

Sheng

Hi Sheng, thank you for the answer. The 0xFF..FFF4FF (quotient) output is under 010139F1A9h (denominator) and 7FFFFA7872h (numerator) in the simulation because I've simulated the divider standalone in order to check its behavior feeding the IP only with those operands. In HW the divider is part of a more complex design and it is fed in pipeline with a stream of operands. That's the reason why in SignalTap you also see the subsequent operands, but the 0xFF..FFF4FE is the result of the first two operands of the stream, that are the same of the simulation:

Hi,

Pipeline will add latency. Could you simulate the whole complex design with pipeline instead of just divider standalone? What will be seen?

Thanks,

Regards,

Sheng

Hi Sheng.

The number of pipeline stages is a parameter of the divider and I use the same value both in the simulation and in the implementation. There are no differences. The entire complex design is impossibile to simulate due to its size. What can I do is to simulate and implement a simple one only with the divider and an operands generator inside, monitoring the outputs both in simulation and in signaltap. I think that I'll see the same behavior. Il post the results here in the next days.

Hi,

Understood that. Please let me know whether simple one only with the divider and an operands generator inside got same simulation and signal tap?

Thanks,

Regards,

Sheng

Hi Sheng, I've implemented a simple module which instantiates the LPM_DIVIDER only and a process that feeds the divider with 1000 couples of operands. As I expected, I've seen the same strange behavior of the implemented module which is different from the simulation when the quotient is negative. The following figure show this difference:

I've taken into consideration only the first division of the sequence, since the problem is the same also in the subsequent divisions. Operands:

Numerator = FFFFFFEC82000000h = -83718307840d; Denominator = 000000000Bh = 11d.

Quotient (SignalTap) = FFFFFFFE3A5D1745h = -7610755259d; Remainder (SignalTap) = 0000000009h = 9d.

Quotient (Simulation) = FFFFFFFE3A5D1746h = -7610755258d; Remainder (Simulation) = 7FFFFFFFFEh = -2d.

If can be of some help, I've implemented the module on a ARRIA10 FPGA (10AX066K4F35I3SG) using the following version of Quartus Prime: Quartus Prime Version 20.1.1 Build 720 11/11/2020 Patches 1.02std SJ Standard Edition.

Thank you,

Marco

Hi,

Could you provide the project file for taking a look?

Thanks,

Regards,

Sheng

Hi Sheng,

since the ARRIA10 board is a custom board, I've done another project using the Intel MAX10 FPGA Development kit and simply instantiated the lpm_divide_self_operands_gen.vhd in the top module. I've checked again the outputs of the divider with signal tap, confirming that also with that device I see the same behavior. I attached the whole project (I deleted the ./db subfolder otherwise the compressed file would have been more than 23MB allowed for the attachments). There is also the signal tap inside the project, which shows the following, triggering with operands_counter = 1:

Considering this, I don't think it's an issue of the device.

Hi,

Possible provide the testbench as well for simulation?

Thanks,

Regards,

Sheng

Yes, of course. Here it is.