FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 11-17-2007, 09:52 PM
Tommy Thorn
Guest
 
Posts: n/a
Default 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
Reply With Quote
  #2 (permalink)  
Old 11-17-2007, 11:48 PM
KJ
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"


"Tommy Thorn" <[email protected]> wrote in message
news:[email protected]m...
>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


Reply With Quote
  #3 (permalink)  
Old 11-18-2007, 12:21 AM
Hal Murray
Guest
 
Posts: n/a
Default Re: 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 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.

Reply With Quote
  #4 (permalink)  
Old 11-18-2007, 02:12 AM
KJ
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"


"Hal Murray" <[email protected]> wrote in message
news:[email protected] ...
>
>>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


Reply With Quote
  #5 (permalink)  
Old 11-18-2007, 03:52 AM
rickman
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"

On Nov 17, 9:12 pm, "KJ" <[email protected]> wrote:
> "Hal Murray" <[email protected]> wrote in message
>
> news:[email protected] ...
>
> >>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.
Reply With Quote
  #6 (permalink)  
Old 11-18-2007, 05:49 AM
Hal Murray
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"


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

Reply With Quote
  #7 (permalink)  
Old 11-18-2007, 09:55 AM
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"

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

What?
Reply With Quote
  #8 (permalink)  
Old 11-18-2007, 07:00 PM
KJ
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"


"rickman" <[email protected]> wrote in message
news:[email protected]...
> On Nov 17, 9:12 pm, "KJ" <[email protected]> wrote:
>> "Hal Murray" <[email protected]> wrote in
>> message
>>
>> news:[email protected] ...
>>

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


Reply With Quote
  #9 (permalink)  
Old 11-18-2007, 07:03 PM
KJ
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"


"Hal Murray" <[email protected]> wrote in message
news:[email protected]
>
>
> 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


Reply With Quote
  #10 (permalink)  
Old 11-18-2007, 07:34 PM
mk
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"

On Sun, 18 Nov 2007 14:03:09 -0500, "KJ" <[email protected]>
wrote:

>
>"Hal Murray" <[email protected]> wrote in message
>news:[email protected]
>>
>>
>> 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.
Reply With Quote
  #11 (permalink)  
Old 11-19-2007, 02:39 AM
Tommy Thorn
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"

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] <= data;
addr_reg <= addr;
end

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

endmodule
Reply With Quote
  #12 (permalink)  
Old 11-19-2007, 09:20 AM
glen herrmannsfeldt
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"

Tommy Thorn wrote:

(snip)

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


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

Reply With Quote
  #13 (permalink)  
Old 11-19-2007, 03:47 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Quartus II warning: "pass-through logic has been added"

Tommy Thorn wrote:
> 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?


http://www.altera.com/support/exampl...g/ver_ram.html
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there anyway to pass "arguments" to a Verilog testbench? mrfirmware Verilog 1 07-24-2007 11:04 PM
[Q] Xilinx Webpack warning message "Cannot apply TIMESPEC TS_WR_CPLD" [email protected] FPGA 1 02-28-2007 01:12 AM
In NCVerilog, how do I suppress "$readmem warning: words less than that given by address bounds"? Mr. Ken FPGA 0 08-03-2006 12:36 PM
Strange warning "WARNING:MapLib:701 - Signal P_GPIO_3 connected to top level port P_GPIO_3 has been removed." VSP FPGA 2 09-06-2005 04:53 PM
SystemVerilog: "logic" or "ulogic?" Cliff Cummings Verilog 1 09-20-2003 11:55 PM


All times are GMT +1. The time now is 02:33 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved