Timing Analysis

[px1983]

Hi,

Recently I updated original design from 245MHz clock domain to 333MHz domain. After some design modification, the Timing Check for Setup Time and Hold Time is OK, but there are still "Component Switching Limit" fails for some DSP48E1(See Behind). How to improve my design? Thanks in advance.

Xi

 Component Switching Limit Checks: TS_bc_ltg_i_mmcm_ddr_i_clkout0 = PERIOD TIMEGRP "bc_ltg_i_mmcm_ddr_i_clkout0"
         TS_i_clk_f1_ddr_100m_p / 3.33333333 HIGH 50%;
 --------------------------------------------------------------------------------
 Slack: -0.805ns (period - min period limit)
   Period: 3.000ns
   Min period limit: 3.805ns (262.812MHz) (Tdspper_AREG_PREG_MULT)
   Physical resource: b_fpga_i/i_lpusch/i_lpusch_sbd/i_lpusch_sbd_ctr_rd/sp1xrownb/DSP48E1/CLK
   Logical resource: b_fpga_i/i_lpusch/i_lpusch_sbd/i_lpusch_sbd_ctr_rd/sp1xrownb/DSP48E1/CLK
   Location pin: DSP48_X5Y88.CLK
   Clock network: ddr3_clk_mem_i

[htsvn · Accepted solution]

Hi,

The component switching limit analysis is done in addition to the traditional setup and

hold analysis. This analysis ensures that the operating frequency of the device component

is not exceeded and within device specifications.

Please refer to the Datasheet of the device that you are using. Check 

Refer to Maximum Frequency table.

Good Luck.

[px1983]

After resort to DS152, solve this issue using MREG for DSP48. Thanks.

[samcossais]

I have the same kind of problem but with a Spartan-6 LXT and checking data sheet didn't solve mine.

Here is the error :

---

Component Switching Limit Checks: TS_sclkx4 = PERIOD TIMEGRP "sclkx4_TNM" 160 MHz HIGH 50%;

Slack: -0.869ns (period - min period limit)

Period:
6.250ns
Min period limit:
7.119ns (140.469MHz) (Tdspper_OPMODEREG_CARRYOUTREG)
Physical resource:
dbf_block/sum_sigma_2nd_stage/sigma_acc_dsp/blk00000003/CLK
Logical resource:
dbf_block/sum_sigma_2nd_stage/sigma_acc_dsp/blk00000003/CLK
Location pin:
DSP48_X1Y32.CLK
Clock network:
sclkx4

---

There is only one DSP with this error in my design, the one I use as an accumulator. Actually it takes a result via its PCIN input from a previous DSP PCOUT (this one using PREG), and then accumulates this data every 2 cycles, which requires a dynamic change of OPMODE : PCIN / PCIN+P / PCIN / PCIN+P / ...

I used to do that with a previous deisgn using a Virtex-6 and with an another one using a Spartan-6 but @120MHz. This time I work @160MHz.

I made de DSP instantiation by using the DSP macro IP (it's very useful for me when I decide to migrate a design on a different device). I checked all the registers inside DSP I could add (in expert mode) : SEL + PREG. I activated a global SCLR control.

I didn't find it anywhere so I'm wondering, is Tdspper_OPMODEREG_CARRYOUTREG an expected timing constraint ? I'm not intending to use the CARRYOUT signal neither actually.

[ajmirg]

Are you using ISE 13.4?

If yes, these Component Switching Limit should be correct for the mode you are using. Please check the attributes of the DSP48 in FPGA Editor and let us know why you think Tdspper_OPMODEREG_CARRYOUTREG is not a relevant check.

[samcossais]

Yes I am using 13.4

I'll check in FPGA editor ASAP.

It is not that I really think Tdspper_OPMODEREG_CARRYOUTREG is not a relevant check, the first problem is that I don't even know what it is because I can't find it in the data sheet.

Now from the name, I assume it has something to do with the fact I use OPMODEREG dynamically, which is actually true, but also CARRYOUTREG. However I don't use the port for the latter, even if the DSP macro seems to have enabled its register (through the corresponding DSP48A1 attribute).

[danbo.liang]

Dear px1983,

How do you using MREG for DSP48?

In UCF? or in FPGA Editor?

thanks!

[samcossais]

Well, it's very simple, you just need to set the attribute MREG to 1 when instantiating the DSP48A1 primitive (in your verilog or vhdl file), or set it in the DSP macro IP if you use this one

---

danbo.liang wrote:

Dear px1983,

How do you using MREG for DSP48?

In UCF? or in FPGA Editor?

thanks!

---

.

[samcossais]

---

samcossais wrote:

Yes I am using 13.4

I'll check in FPGA editor ASAP.

It is not that I really think Tdspper_OPMODEREG_CARRYOUTREG is not a relevant check, the first problem is that I don't even know what it is because I can't find it in the data sheet.

Now from the name, I assume it has something to do with the fact I use OPMODEREG dynamically, which is actually true, but also CARRYOUTREG. However I don't use the port for the latter, even if the DSP macro seems to have enabled its register (through the corresponding DSP48A1 attribute).

---

This message is addressed to the Xilinx staff.

I was able to solve the problem. It appears that there is a bug in the DSP Macro IP and in timing analysis, can you please correct it ? The problem is described below.

Also the timing spec Tdspper_OPMODEREG_CARRYOUTREG for which I am told to check the data sheet is not actually in it. Would you mind adding it ?

   ** DSP Macro IP / timing analysis bug description :

---

My interpretation of Tdspper_OPMODEREG_CARRYOUTREG was actually correct, as it is related to the dynamic use of ports OPMODE and CARRYOUT when their respective register inside DSP is activated.

However, in my DSP Macro IP setting, I don't use CARRYOUT. Here are the non default settings activated :

Instruction 0: PCIN
Instruction 1: PCIN+P
Enable SEL (OPMODE) reg and P reg
SCLR = global

Now when I check the verilog file generated with this IP, I find in the DSP48A1 instance that the value of attribute CARRYOUTREG is set to 1. This is obviously a bug in DSP Macro IP.

Now even if CARRYOUTREG is set to 1, it shouldn't generate a timing error as CARRYOUT is not connected. This is I think a bug in timing analysis.

---

I have used the DSP primitive for quite a long time and I don't think I'm making a mistake here.

So could you please check this out ?

[eteam00]

Sam,

If you want to report a bug, you should open a webcase.

-- Bob Elkind