Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

Constraining Megafunction Outputs

My design consists of a main entity (I'll call it "X") which talks with a memory that has unregistered data outputs. The data outputs from the memory enter X and are flopped after traveling through some combinational logic. For the purpose of prototyping my design, I instantiated both X and the memory on a Stratix II FPGA.

The memory I've used is dual-port RAM on the M-RAM in my Stratix II device. I used the altsyncram megafunction to do this.

The problem I now have is that accesses to the memory get corrupted at random times. I think this is because I did not provide proper timing constraints for the combinational path between the memory and X. To do so, I used the following approach:

1. I opened up my design in Chip Editor. I could find the RAM instantiation and see the Q data outputs from the memory. I then traced the path to the inputs on X.

2. I noted down the complete paths of both endpoints and added them to a TCL file as arguments to the command set_max_delay:

--- Quote Start ---

set_max_delay -from <memory_data_output> -to <input_of_flop_in_X_after_some_combinational_logic> 50

--- Quote End ---

(The set_max_delay command will constrain the combinational path). 50 is an example value I've used. I would like the tool to fit in the delay from the memory to X plus the delay of the intermediate combinational logic into this time.

3. I ran the quartus_sta utility with my TCL file as an argument. Unfortunately, I find that the tool is unable to find the memory data output nodes.

4. To double-check, I also used the get_keepers, get_nodes, get_pins, get_cells commands at the altsyncram instantiation. It turns out that I can only see the data and address inputs of the altsyncram.

Now, my question: does the fact that Quartus is unable to find the data output nodes of the altsyncram block have something to do with its being a megafunction? Does Altera somehow make the internal pins of the megafunction invisible?

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    The timing analysis you need to do is from register to register (or more generally, from keeper to keeper). When you do not register RAM block outputs, the read paths for the RAM block go from the RAM block's registered inputs to the first register after the RAM block output (which would also be after the combinational logic in your case). You should not be using max delays for these paths. Use proper clock constraint(s) and report the timing from the RAM input to the registers after the combinational logic. When you look at the details of the data arrival path, you will see that the timing goes through the RAM block through the Q outputs.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    1) 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.)