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: 
Explorer
Explorer
2,266 Views
Registered: ‎05-14-2015

Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

We're using "XPM_MEMORY_SDPRAM" in our design. 

In page 70 of UG974(V2017.2

)(Introduction on XPM_MEMORY_SDPRAM), the following words are mentioned: 

dualport.png

I don't really understand what the recommended constraint is doing. Can somebody help to explain a little?

Where should I put this constraint? the top level .xdc? We used a lot instances of "XPM_MEMORY_SDPRAM"  in our design. Should I add this constraint for each instance? 

 

1 Solution

Accepted Solutions
Moderator
Moderator
3,250 Views
Registered: ‎01-16-2013

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution
Hi All,

One quick update in 2017.4 there is USE_EMBEDDED_CONSTRAINT environment is available with XPM_MEMORY_SDPRAM so tool will automatically take care of extra constraints required.

Please refer latest UG974 page#78
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug974-vivado-ultrascale-libraries.pdf

Thanks,
Yash
7 Replies
Scholar ronnywebers
Scholar
2,242 Views
Registered: ‎10-10-2014

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

good question, ran into the same thing today :-)

 

Also, what 'if the design does NOT take care of avoiding address collision'? Then it doesn't need a constraint ?

 

I wish Xilinx made a good tutorial on constructing constraints, on navigating & querying the design database elements ... really big hole in the doc...

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Historian
Historian
2,228 Views
Registered: ‎01-23-2009

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

It is a horribly convoluted constraint...

 

So, it is a set_false_path, which has a -from and a -through, so it covers paths that start at any object in the -from list, goes through at least one object in the -through list. Since it has no -to list, it can end at any endpoint...

 

Let's start with the -from.

  • It as assuming that clka is the port that brings in the write clock. This is not necessarily true in all cases, and hence this part of the command is not foolproof - you would have to modify it based on your design.
  • But, assuming it is, then it uses the all_fanout from the port (not the clock) - this command traces forward through all combinatorial cells
    • Because it does not contain the -only_cells, it will return pins
    • Because of the -flat, it will be able to traverse through hierarchy to return pins anywhere in the design, not just at the top level
    • Because of  the "-endpoints_only", this will return only pins that qualify as the endpoints of static timing paths 
      • Normally this means the data inputs of clocked cells, but since this is a  clock net, it will return the clock pins
      • This means it should find only the clock pins of clocked elements to which it is attached
  • It then filters these pins for the property "IS_LEAF"
    • This means that the pin must be on a primitive cell, not a hierarchical instance
    • This is redundant since the all_fanout command had the -endpoints_only option
      • By definition a static timing path endpoint pin is a "IS_LEAF" pin

This is a hideous portion of the command. A much better, safer, cleaner way to do this would have been

-from [get_clocks <name_of_clock_driving_write_port>]

 

Now the -through

  • The get_cells -hier * returns all cells anywhere in the design
  • These are then filtered to return only cells of "PRIMITIVE_SUBGROUP" LUTRAM, dram or drom
    • I looked up these PRIMITIVE_SUBGROUP property (UG912)
      • LUTRAM is a distributed selectRAM (the 64x1 or 32x2 SRAM made from slice LUTS)
      • The other two "drom" and "dram" don't seem to exist, so they are wrong
        • They may have been trying to find RTL memories (prior to synthesis) so that the synthesis constraints would work, but the correct subgroup for this is "ram" and "rom" (not "dram" and "drom")
  • Then the command gets all the pins of the returned cells, which gives the -through list

Again, this is a messy gross (and incorrect) set of options. It will work during implementation (since LUTRAM is correct), but not during synthesis (since dram and drom are not correct). But if you correct them to "ram" and "rom" they will probably work,

 

The whole idea here is that distributed RAMs have a user visible static timing path from the write port to the read data since the distributed RAM reads are combinatorial. So lets take the example that the rd_addr is at the value 7, and simply stays there - this will (combinatorially) drive out the value stored in location 7. If you then do a write to location 7 on the write port, which is on the write clock, the contents of location 7 will change. Since the location changed, the new value in 7 will immediately propagate to the read output port. This is a static timing path from write clock to read data.

 

If you make sure that there is no contention - i.e. the write cannot write to a location "near" when the read address is also pointing to the same location, this static timing path is false, and should be declared false. This command (messily and partly incorrectly) does that in spite of the fact that we don't know the names of the instance or instances of distributed RAM inferred by the XPM_MEMORY_SDPRAM macro.

 

Avrum

Historian
Historian
2,226 Views
Registered: ‎01-23-2009

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

Also, what 'if the design does NOT take care of avoiding address collision'? Then it doesn't need a constraint ?

 

If you do not avoid contention then the static timing path from the write clock to the read data is not false, and hence this constraint is not correct to use. Unless the write clock and read clock (that clocks the flip-flop at the end of the static timing path through the read port) are harmonically related, then this is a clock crossing path with an illegal clock crossing (unless you do something funky with the capture flip-flop that makes this legal, but it is hard to imagine what that would be, or why you would want to...)

 

Avrum

Highlighted
Historian
Historian
2,215 Views
Registered: ‎01-23-2009

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

Thinking about this a bit more, I realize that this is an incredibly dangerous constraint to use.

 

As written, it will disable any path from the given clock through any distributed RAM anywhere in the design. That means that if this clock is used as the clock driving the flip-flops of the read address of any distributed RAM (even a synchronous one), the read path will be declared false. It may also disable write timing as well (I have never been clear on what happens if you specify an endpoint of a static timing path as a through point...) So even a perfectly normal synchronous distributed RAM on this clock anywhere in your design will be unconstrained. The tools are even free to infer distributed RAMs, so you may not even know that one exists, and yet you are disabling timing through it.

 

This constraint is WAY too broad (and hence dangerous), and should be removed from any Xilinx documentation.

 

Avrum

Explorer
Explorer
2,194 Views
Registered: ‎05-14-2015

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

@avrumw, Thanks for your detailed analysis. 

 

Instead of using the recommendation from Xilinx documentation, do you think there is an alternative way to constrain "XPM_MEMORY_SDPRAM" ?

0 Kudos
Historian
Historian
2,172 Views
Registered: ‎01-23-2009

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution

Instead of using the recommendation from Xilinx documentation, do you think there is an alternative way to constrain "XPM_MEMORY_SDPRAM" ?

 

As a "blanket" constraint, no. But then again, I am very much a fan of constraining as precisely as possible to avoid accidentally affecting a path that shouldn't be affected..

 

Because an XPM_ is not a module or IP, it cannot have a scoped constraint file (which would be the proper way of dealing with this) - at least I think that is the case (I haven't worked with the XPM).

 

Given that, then I would recommend manually constraining each false path. If you have an XPM_MEMORY_SDPRAM that is used with properly designed FIFO logic, then the paths from flops on the write clock domain to the read capture flip-flops are false. In your design, you will know what those read capture flops are, and hence I would do a specific false path on them

 

set_false_path -from [get_clocks <wr_clk>] -to [get_cells <rd_capture_flops>]

 

Avrum

0 Kudos
Moderator
Moderator
3,251 Views
Registered: ‎01-16-2013

Re: Timing constraint for XPM_MEMORY_SDPRAM

Jump to solution
Hi All,

One quick update in 2017.4 there is USE_EMBEDDED_CONSTRAINT environment is available with XPM_MEMORY_SDPRAM so tool will automatically take care of extra constraints required.

Please refer latest UG974 page#78
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug974-vivado-ultrascale-libraries.pdf

Thanks,
Yash