Honored Contributor
Honored Contributor1) There are two registers in the ram, the input registers which are always on, and the output registers which are optional. It sounds like you're bypassing the output registers. Because of this, you will do timing analysis from the input registers. TimeQuest always does timing constraint/analysis between registers. If you just wanted to constrain the output of the RAM to a group of registers, you would have an incomplete constraint, since your total data transfer would be dependent on the delays to/through the RAM.
2) Your RAM and your destination registers are driven by clocks. Are those clocks constrained? If so, you have constraints between those paths. If you want to analyze it, do a report_timing -from *ram_instance*, with both -setup and -hold, and see what the requirements are. Is this correct? 3) Although most paths in a design are properly constrained by just constraining their clocks, some paths do not want the default requirements. These can usually be fixed with multicycles, which are what I recommend using. 4) set_max/min_delay are another option, but I try to avoid them when possible. Multicycles better describe how a transfer is occurring. They can change with frequency(if your clock periods change, you would have to edit every set_max_delay, but not multicycles). And people don't understand set_max_delay enough and cause problems(specificyally that set_max_delay ignores any clock manipulations during analysis, specifically phase shifts.)
