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

I tried asking this in the Altera forum, but to no avail.

The crux of my question is why the template that Quatus itself
suggests results in a warning and how to fix that?

For portability and readability I strongly prefer infering memory, but
I seem to be having a very hard time getting Quartus II 7.2 to behave
as expected. Quartus own template (pick edit -> insert template ->
single port ram. The code included below) when translated produces
this warning:

"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."

Indeed, the template is pass-through, but that is be directly
supported by the M4K memory blocks in the context I'm using (no mixed
port sizes or clocks).

The setting "Add Pass-Through Logic to Inferred RAMs" defaults to
"On", but I don't understand that option. It seems to me that setting
it to "Off" would instruct Quartus II to infer logic that doesn't
implement exactly what the Verilog specifies and would certainly cause
a discrepancy when simulated with Icarus Verilog.


To make matters even more entertaining, the online help disagrees with
this template. Notably, the memory update is using a non-blocking
assignment

if (we) ram[addr] <= data

and that doesn't infer the pass-through logic.

Unfortunately, both infers Simple Dual RAM according to the Analysis &
Synthesis RAM Summary.

Is it even possible to infer Single Port RAM? (I care because I want
to pack two single port rams into one M4K block).

Help appreciated,
Tommy

.... code below ....

// Quartus II Verilog Template
// Single port RAM with single read/write address

module single_port_ram
(
input [(DATA_WIDTH-1):0] data,
input [(ADDR_WIDTH-1):0] addr,
input we, clk,
output reg [(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];

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

// Read returns NEW data at addr if we == 1'b1. This is the
// natural behavior of TriMatrix memory blocks in Single Port
// mode
q <= ram[addr];
end

endmodule

"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message 
news:c657aada-8565-4ce8-a4c9-257914aff3b8@d21g2000prf.googlegroups.com...
>I tried asking this in the Altera forum, but to no avail.
>
> The crux of my question is why the template that Quatus itself
> suggests results in a warning and how to fix that?
>
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

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

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message 
news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net...
>
>>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 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 

On Nov 17, 9:12 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Hal Murray" <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote in message
>
> news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net...
>
> >>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 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.

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.

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

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

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

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.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

>Both of those are just 'motherhood and apple pie' statements...

What?

"rickman" <gnuarm@gmail.com> wrote in message 
news:b79b7e6e-7cc1-4501-9a8e-92e7f6b84f6a@l1g2000hsa.googlegroups.com...
> On Nov 17, 9:12 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>> "Hal Murray" <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote in 
>> message
>>
>> news:i7adnXA_7OEPGKLanZ2dnUVZ_ujinZ2d@megapath.net...
>>
>
> 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.
>
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 

"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message 
news:LL6dne-J2bj1T6LanZ2dnUVZ_trinZ2d@megapath.net...
>
>
> I want warnings when I might be doing something wrong or even slightly 
> fishy.
>
So do I, but one must deal with overly chatterly tools at times.

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

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 

On Sun, 18 Nov 2007 14:03:09 -0500, "KJ" <kkjennings@sbcglobal.net>
wrote:

>
>"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message 
>news:LL6dne-J2bj1T6LanZ2dnUVZ_trinZ2d@megapath.net...
>>
>>
>> I want warnings when I might be doing something wrong or even slightly 
>> fishy.
>>
>So do I, but one must deal with overly chatterly tools at times.
>
>> 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.
>>
>
>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.

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.