- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Folks,
We've been facing a Recovery/Removal Issue with DDR3 memPHY hard IP.
Notice that the relationship required is 0.004 (4 picoseconds) which is not feasible.
The approach that we took on this project which is different from example designs is to create a internal signal and use that as a global reset on the project (we call it reset_generator).
On other projects we would have a real reset and a false path on it, so this issue would never appear.
But since we cannot set false path to this generated reset because it`s shared among a lot of other modules that we need to evaluate recovery/removal - we don't know what to do.
For now we've decided to ignore this error - does anyone have a better solution?
- Tags:
- memphy
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Do you set any global resource for the reset_n_reg signal ?
I am coping the PHY Reset Recovery and Removal guideline from the EMIF handbook. It says you can improve the timing either way.
PHY Reset Recovery and Removal
A common cause for reset timing violations in UniPHY designs is the selection of a global or regional
clock network for a reset signal.
The UniPHY IP does not require any dedicated clock networks for reset signals. Only UniPHY PLL
outputs require clock networks, and any other PHY signal using clock networks may result in timing
violations.
You can correct such timing violations by:
• Setting the Global Signal logic assignment to Off for the problem path (using the Assignment Editor),
or
• Adjusting the logic placement (using the Assignment Editor or Chip Planner)
![](/skins/images/607B1757615CC3D714FA9723ADFD6109/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page