cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
331 Views
Registered: ‎02-17-2020

Missing UPWS errors?

Jump to solution

Hello!

I'm trying to close timing on a design using the part xcuv5p-flva2014-3-e using vivado 2018.3. The design has a lot of instantiated DSP48E2 without using the M-register (but P, B,C and AD or A), and I am targetting the max frequnecy of thoose for my design. When i read the DS923 my interpretation is that the max frequency for the DSP48E2 is 635 MHz (about 1575 ps) for this case (page 37). However, if I constrain my clock period to lower than that I get no WPWS timing errors as I expect. Have I missunderstood something, or is this a bug in the software?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
167 Views
Registered: ‎01-23-2009

Re: Missing UPWS errors?

Jump to solution

Then I suppose that there should be some pretty deterministic paths showing up as ordinary timing paths

Yes

with delays relating to the frequencies in the document I referred in this threads first post

Somewhat. The timing information in the datasheets isn't always 100% accurate; the timing results from the tool may disagree somewhat (or in some cases, even a fair bit). Whenever there is a discrepency, the numbers reported in the tool supercede the numbers from the datasheet.

The router can't have many options for paths inside the DSP blocks

In fact, it has only one option for each connection. The architecture of the DSP is still the same as previous generations (with whatever improvements have been added), it is just the timing representation that has changed. Therefore the connections between these "subcells" are the same connections that always existed within the DSP48; the connections within the DSP48 are still fixed based solely on the mode of the DSP48 (not on any "router" variability).

Is it not then strange that I have an implentation that has a minimum slack of 16 ps with a constrain on my clk of 1570 ps if the maximum frequency for this case should be 635 MHz (about 1575 ps)?

Not really. As I mentioned above, the timing numbers in the datasheet and the tool may be slightly different, and, ultimately it is the numbers from the tool that matter. In the case of the old representations of the DSP (for previous families) since  the pulse width check was done as a single check (the maximum frequency which is the same as the minimum period), it was easy to get the exact same number in both places. But now the timing models are different between the two - the tool uses the subcell model and the documentation uses the old monolithic DSP48 model - so there is no guarantee that the numbers will be the same. In this case, the tool says it runs slightly faster than the datasheet says (by 21ps) - that's fine... The tool is always right.

Avrum

View solution in original post

5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
293 Views
Registered: ‎05-14-2008

Re: Missing UPWS errors?

Jump to solution
The Fmax on that table is the performance data for DSP48, not a max frequency limitation. There is no "min period" check for the DSP48 clock. -vivian
-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
256 Views
Registered: ‎02-17-2020

Re: Missing UPWS errors?

Jump to solution

I suppose I expected the same behaviour as for earlier families e.g. virtex4, 6 and 7.

A maximum frequency and minimum period is not so much different to my my mind.

0 Kudos
Highlighted
Guide
Guide
213 Views
Registered: ‎01-23-2009

Re: Missing UPWS errors?

Jump to solution

Interesting...

In the older technologies, it was as you described; the DSP48 was considered a single cell - from the timing point of view it was indivisible. Any path that started outside and ended inside the cell or paths that started inside and ended outside the cell were timed, but internal paths (say from the AREG to the PREG) were not treated as timing paths. The way that these were timed was by a pulse width check - depending on which registers (AREG, BREG, MREG, PREG, and the control registers) were enabled and a bit about what mode it was in (if it was hard wired) a "maximum frequency" was defined for that operating mode, and this was treated as a "minimum pulse width" for the DSP48 cell.

However in UltraScale+, this is no longer the case (I haven't checked UltraScale). In UltraScale+ the DSP48E2 is a collection of internal cells - basically the DSP48 is broken into (logical) sub-modules of "stuff around the inputs (including the input registers)", "stuff around the pre-adder (including the ADREG and DREG)", "stuff around the multiplier (inluding the MREG)" and "stuff around the outputs (including the PREG)" (and some others). These blocks are all seen by the tool as separate blocks (from the timing point of view). Therefore, the timing of paths that involve them are done "normally" - each sub-block has its own timing arcs and these show up in timing reports.  I suspect that no individual cell has more than one register in series, and hence there is no need for a "pulse width" check anymore; all static timing paths are done from cell to cell.

Avrum

Highlighted
Visitor
Visitor
187 Views
Registered: ‎02-17-2020

Re: Missing UPWS errors?

Jump to solution

Thanks for that insightful explanation!

Then I suppose that there should be some pretty deterministic paths showing up as ordinary timing paths, with delays relating to the frequencies in the document I referred in this threads first post. The router can't have many options for paths inside the DSP blocks.

Is it not then strange that I have an implentation that has a minimum slack of 16 ps with a constrain on my clk of 1570 ps if the maximum frequency for this case should be 635 MHz (about 1575 ps)?

0 Kudos
Highlighted
Guide
Guide
168 Views
Registered: ‎01-23-2009

Re: Missing UPWS errors?

Jump to solution

Then I suppose that there should be some pretty deterministic paths showing up as ordinary timing paths

Yes

with delays relating to the frequencies in the document I referred in this threads first post

Somewhat. The timing information in the datasheets isn't always 100% accurate; the timing results from the tool may disagree somewhat (or in some cases, even a fair bit). Whenever there is a discrepency, the numbers reported in the tool supercede the numbers from the datasheet.

The router can't have many options for paths inside the DSP blocks

In fact, it has only one option for each connection. The architecture of the DSP is still the same as previous generations (with whatever improvements have been added), it is just the timing representation that has changed. Therefore the connections between these "subcells" are the same connections that always existed within the DSP48; the connections within the DSP48 are still fixed based solely on the mode of the DSP48 (not on any "router" variability).

Is it not then strange that I have an implentation that has a minimum slack of 16 ps with a constrain on my clk of 1570 ps if the maximum frequency for this case should be 635 MHz (about 1575 ps)?

Not really. As I mentioned above, the timing numbers in the datasheet and the tool may be slightly different, and, ultimately it is the numbers from the tool that matter. In the case of the old representations of the DSP (for previous families) since  the pulse width check was done as a single check (the maximum frequency which is the same as the minimum period), it was easy to get the exact same number in both places. But now the timing models are different between the two - the tool uses the subcell model and the documentation uses the old monolithic DSP48 model - so there is no guarantee that the numbers will be the same. In this case, the tool says it runs slightly faster than the datasheet says (by 21ps) - that's fine... The tool is always right.

Avrum

View solution in original post