Quartus II warning: "pass-through logic has been added"

If the design functions as you want it to and meets your performance requirements then what needs to be 'fixed'? Not every warning needs to be addressed as a design change, many should really just be 'note', not 'warning'. The comments in the template generated code, seem to indicate that this is how they intend it to work. If that is not exactly the function you want then don't use the template, code it to function how you need it to work.

KJ

The usual reason for getting rid of warnings is so you don't have to think about them next time.

Another reason is so that you don't miss an important one because it's lost in the clutter.

Both of those are just 'motherhood and apple pie' statements though. Quartus will generate a 'warning' when it inserts a buffer to redrive a signal for whatever reason. Do you change the design so that the buffer doesn't get inserted? The answer there depends on performance. If the design meets the timing requirements and has adequate margin then you're best off leaving the design as is (thereby leaving the warning). In the OP's case of the RAM, he can probably change the function of the RAM to avoid use of the pass-thru mode and get rid of the warning, but if his design requires that mode of operation for whatever reason then he's broken the function of his design but gotten rid of the warning....bad tradeoff in my opinion. Don't break function to get rid of warnings.

The nature of warnings should be understood. If the warning is a symptom of a design issue then they should be fixed; if not they can be either left alone or possibly fixed so they don't cause clutter...as long as cleaning clutter does not compromise function or performance.

KJ

But aren't you making an assumption that "the design functions as you want"? The OP may not have complained that it did not simulate correctly or that it did not meet performance. However, he is clearly concerned that it is not implementing as he requires.

"Is it even possible to infer Single Port RAM? (I care because I want to pack two single port rams into one M4K block)." This sounds like it is not working as he wants it to. But then I don't think he should be using two single port rams. If I understand what he is doing, he may be asking the tool to be smarter than it is. Perhaps he needs to use a dual port ram and tie the high order address line high for one port and low for the other. Then the two ports should function as two single port rams with half the number of words.

I guess you go to a different church than I do.

I'd claim that if they can't be "fixed" without breaking the design, then the tools are broken. I'm happy to add something to the code to tell the tools that I know about this case.

I want warnings when I might be doing something wrong or even slightly fishy.

Leaving them alone is not a sensible approach if there are more than a few. The clutter gets in the way of finding important warnings.

What?

The OP said nothing about the function being incorrect, since he is designing it he is responsible for job #1 which is getting the function correct. To quote from the OP, the concern is...

"Warning: Inferred RAM node "ram~0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design."

The addition of pass-through logic being added to match behaviour is a 'good' thing. What is the alternative? Not adding the logic and creating something that functions differently?

KJ

So do I, but one must deal with overly chatterly tools at times.

The original post's complaint is....

"Warning: Inferred RAM node "ram~0" from synchronous design logic. Pass-through logic has been added to match the read-during-write behavior of the original design."

Post your sensible approach that does not change the function.

KJ

Not that I'm advocating it but in this specific case the solution might be to modify the design so that it doesn't do "read-during-write" which the underlying memory doesn't support. RDW probably isn't needed, most probably it makes the resulting design larger and slower because of the added logic. Unless it is absolutely needed for lower latency it can be removed by changing the design.

What has happend to c.a.f? Only rickman was even close to being on the ball.

Altera agree that I've found a bug and sent me a temporary workaround (I haven't yet tested it):

module single_port_ram ( input [(DATA_WIDTH-1):0] data, input [(ADDR_WIDTH-1):0] addr, input we, clk, output [(DATA_WIDTH-1):0] q );

parameter DATA_WIDTH = 8; parameter ADDR_WIDTH = 6;

// Declare the RAM variable reg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0]; reg [ADDR_WIDTH-1:0] addr_reg;

always @ (posedge clk) begin // Write if (we) ram[addr]

(snip)

I thought pass through logic was for a FIFO (and presumably for the two port RAM used to generate it) when it currently has no data. New data written must then immediately be available at the output.

If you don't need that ability (in either FIFO or RAM) turn the option off. Or is it something completely different?

-- glen