uninferred due to asynchronous read logic

On May 13, 1:23 pm, Dave <dhsch...@gmail.com> wrote:
On May 13, 3:54 pm, Shannon <sgo...@sbcglobal.net> wrote:





On May 13, 11:33 am, Dave <dhsch...@gmail.com> wrote:

On May 13, 1:51 pm, Shannon <sgo...@sbcglobal.net> wrote:

On May 13, 10:48 am, Shannon <sgo...@sbcglobal.net> wrote:

Ok! Now I'm getting somewhere (at least in my mind...for some reason I
have this picture of a clown on a tiny tricycle peddling furiously but
just going in a little circle)

If you take the template I posted and try to synthesize it all by
itself in Quartus II targeting a Cyclone, you will get the same
warning as I've posted above.  So, to me, this means the warning has
nothing to do with MY use of the DPRAM elsewhere in my code.  The
problem is entirely inside Quartus's own template!  Ok, now with your
help I think we can make this thing infer real RAM.  Any ideas?  It
seems to think the read is asynchronous but in my view the read
behavior is inside a clocked process and the IF .. THEN is
incomplete.  This means it will make a register out of the read port
so that it can hold it's value outside the process.  That process is
clocked so I can't see how it thinks reads are asynchronous.

Shannon

ooopss  I had commented out the 'q_a <= data_a;' lines and it didn't
work.  but when I put them back it correctly infers an altsynchRAM..
However, when I put this back into my project the error returns.  I
guess that means there MUST be something wrong with my code.  It must
be making it create an asynchronous read....grrrrrrr

I'm lost.
Shannon

If it works when it's in its own entity, then maybe you should try
leaving the DPRAM that way, and instantiating it as a component is the
rest of your code. This might help Quartus see things more clearly.
Memory inferring is tricky, and I've found that sometimes the tools
need things a certain way just because, even though you're following
all the rules.

Dave- Hide quoted text -

- Show quoted text -

Excellent idea.  I am doing a direct instantiation right now but if I
understand you correctly, I could somehow complile it into a library
or something and then stick it into my code thereby not letting
Quartus re-synthesize the RAM part.  Ok, it's back to the books to see
how I can do all that!

Shannon

That's a bit more than I meant... I was just meaning to instantiate
your RAM code, like you would in any hierarchical design. Nothing
more. No precompiling anything or any other weirdness.- Hide quoted text -

- Show quoted text -
Click to expand...
ah well then that is what I've been doing from the start. If I take
that exact module and open it as a stand alone project, it synthesizes
and infers a DPRAM as expected. But when I try to synthesize my
entire design of which the DPRAM is just one component, THEN it
decides to UN-infer the RAM. So there has to be something about my
code that gives Quartus the feeling it has to UN-infer this RAM. I
wonder if there is a way to just put brackets around that module and
tell Quartus, "Hey, just synthesize this by itself, infer the RAM and
leave it alone! Then connect it to the rest of my code as indicated
in the component instantiation....er...ah...Please."

Shannon
 
Just to follow up. I opened a service request with Altera on this
issue. This was their response:

Hi Shannon,

We have ever met some similar issues with yours. In those files, we
noticed that this is a bug of the Quartus II Synthesis which will be
fixed in the Quartus II ver8.1.

As a workaround, please kindly try to specify the attribute “noprune”
in the design to preserve the nodes without fan-out. For example, in
the previous cases, this error is related to the address, the
reg_input_addr_a/b.

(VHDL)
attribute noprune: boolean;
attribute noprune of reg_input_addr_a : signal is true;
attribute noprune of reg_input_addr_b : signal is true;

For more information about the format for this attribute, please
kindly refer to page 8-47 in the Chapter 8. Quartus II Integrated
Synthesis, Quartus II Volume 1. You could find it from the following
link.

http://www.altera.com/literature/hb/qts/qts_qii51008.pdf

Hope it’s helpful for you.

If the problem persists, please feel free to let me know and to better
assist you, would you please attach the file which could reproduce the
issue?

Thanks for your cooperation.

Best Regards,
Yva

It sounds to me like I'm not alone and this is a known bug. I'm going
to try what they recommend and see if I can get the results I want.

Shannon
 
On May 14, 11:13 am, Shannon <sgo...@sbcglobal.net> wrote:
Just to follow up.  I opened a service request with Altera on this
issue.  This was their response:

Hi Shannon,

We have ever met some similar issues with yours. In those files, we
noticed that this is a bug of the Quartus II Synthesis which will be
fixed in the Quartus II ver8.1.

As a workaround, please kindly try to specify the attribute “noprune”
in the design to preserve the nodes without fan-out. For example, in
the previous cases, this error is related to the address, the
reg_input_addr_a/b.

(VHDL)
attribute noprune: boolean;
attribute noprune of reg_input_addr_a : signal is true;
attribute noprune of reg_input_addr_b : signal is true;

snip
It sounds to me like I'm not alone and this is a known bug.  I'm going
to try what they recommend and see if I can get the results I want.

Shannon
Click to expand...
Sounds suspiciously similar to the work around I mentioned yesterday
where I had to add attributes to keep the address logic from being
mucked with in order to get rid of the unneeded 'pass-thru' logic.

I used the 'syn_preserve' and 'syn_keep' attributes to the read
address signal.

Kevin Jennings
 
On May 14, 8:27 am, KJ <kkjenni...@sbcglobal.net> wrote:
On May 14, 11:13 am, Shannon <sgo...@sbcglobal.net> wrote:





Just to follow up.  I opened a service request with Altera on this
issue.  This was their response:

Hi Shannon,

We have ever met some similar issues with yours. In those files, we
noticed that this is a bug of the Quartus II Synthesis which will be
fixed in the Quartus II ver8.1.

As a workaround, please kindly try to specify the attribute “noprune”
in the design to preserve the nodes without fan-out. For example, in
the previous cases, this error is related to the address, the
reg_input_addr_a/b.

(VHDL)
attribute noprune: boolean;
attribute noprune of reg_input_addr_a : signal is true;
attribute noprune of reg_input_addr_b : signal is true;

snip
It sounds to me like I'm not alone and this is a known bug.  I'm going
to try what they recommend and see if I can get the results I want.

Shannon

Sounds suspiciously similar to the work around I mentioned yesterday
where I had to add attributes to keep the address logic from being
mucked with in order to get rid of the unneeded 'pass-thru' logic.

I used the 'syn_preserve' and 'syn_keep' attributes to the read
address signal.

Kevin Jennings- Hide quoted text -

- Show quoted text -
Click to expand...
I immediatly thought of your post when I saw their response. Only
problem is I have no idea how to apply the "noprune" attribute to the
read signal. That's a new one for me. I see how you could apply it
to a signal but how do you apply it to a port? Do I apply it to the
signal I create at the top level to connect between my component and
the DPRAM component?

Shannon
 
On May 14, 11:45 am, Shannon <sgo...@sbcglobal.net> wrote:
On May 14, 8:27 am, KJ <kkjenni...@sbcglobal.net> wrote:





On May 14, 11:13 am, Shannon <sgo...@sbcglobal.net> wrote:

Just to follow up.  I opened a service request with Altera on this
issue.  This was their response:

Hi Shannon,

We have ever met some similar issues with yours. In those files, we
noticed that this is a bug of the Quartus II Synthesis which will be
fixed in the Quartus II ver8.1.

As a workaround, please kindly try to specify the attribute “noprune”
in the design to preserve the nodes without fan-out. For example, in
the previous cases, this error is related to the address, the
reg_input_addr_a/b.

(VHDL)
attribute noprune: boolean;
attribute noprune of reg_input_addr_a : signal is true;
attribute noprune of reg_input_addr_b : signal is true;

snip
It sounds to me like I'm not alone and this is a known bug.  I'm going
to try what they recommend and see if I can get the results I want.

Shannon

Sounds suspiciously similar to the work around I mentioned yesterday
where I had to add attributes to keep the address logic from being
mucked with in order to get rid of the unneeded 'pass-thru' logic.

I used the 'syn_preserve' and 'syn_keep' attributes to the read
address signal.

Kevin Jennings- Hide quoted text -

- Show quoted text -

I immediatly thought of your post when I saw their response.  Only
problem is I have no idea how to apply the "noprune" attribute to the
read signal.  That's a new one for me.  I see how you could apply it
to a signal but how do you apply it to a port?  Do I apply it to the
signal I create at the top level to connect between my component and
the DPRAM component?

Shannon- Hide quoted text -

- Show quoted text -
Click to expand...
'signal' attributes apply to entity ports as well. You can add them
in as part of the entity. Quartus will also let you add them in
inside the architecture as well although, technically, this is not
correct.

entity Foo is port(
reg_input_addr_a: std_logic_vector(...);
reg_input_addr_b: std_logic_vector(...));

attribute noprune: boolean;
attribute noprune of reg_input_addr_a : signal is true;
attribute noprune of reg_input_addr_b : signal is true;
end Foo;

Kevin Jennings
 
On May 14, 9:08 am, KJ <kkjenni...@sbcglobal.net> wrote:
On May 14, 11:45 am, Shannon <sgo...@sbcglobal.net> wrote:





On May 14, 8:27 am, KJ <kkjenni...@sbcglobal.net> wrote:

On May 14, 11:13 am, Shannon <sgo...@sbcglobal.net> wrote:

Just to follow up.  I opened a service request with Altera on this
issue.  This was their response:

Hi Shannon,

We have ever met some similar issues with yours. In those files, we
noticed that this is a bug of the Quartus II Synthesis which will be
fixed in the Quartus II ver8.1.

As a workaround, please kindly try to specify the attribute “noprune”
in the design to preserve the nodes without fan-out. For example, in
the previous cases, this error is related to the address, the
reg_input_addr_a/b.

(VHDL)
attribute noprune: boolean;
attribute noprune of reg_input_addr_a : signal is true;
attribute noprune of reg_input_addr_b : signal is true;

snip
It sounds to me like I'm not alone and this is a known bug.  I'm going
to try what they recommend and see if I can get the results I want.

Shannon

Sounds suspiciously similar to the work around I mentioned yesterday
where I had to add attributes to keep the address logic from being
mucked with in order to get rid of the unneeded 'pass-thru' logic.

I used the 'syn_preserve' and 'syn_keep' attributes to the read
address signal.

Kevin Jennings- Hide quoted text -

- Show quoted text -

I immediatly thought of your post when I saw their response.  Only
problem is I have no idea how to apply the "noprune" attribute to the
read signal.  That's a new one for me.  I see how you could apply it
to a signal but how do you apply it to a port?  Do I apply it to the
signal I create at the top level to connect between my component and
the DPRAM component?

Shannon- Hide quoted text -

- Show quoted text -

'signal' attributes apply to entity ports as well.  You can add them
in as part of the entity.  Quartus will also let you add them in
inside the architecture as well although, technically, this is not
correct.

entity Foo is port(
   reg_input_addr_a: std_logic_vector(...);
   reg_input_addr_b: std_logic_vector(...));

   attribute noprune: boolean;
   attribute noprune of reg_input_addr_a : signal is true;
   attribute noprune of reg_input_addr_b : signal is true;
end Foo;

Kevin Jennings- Hide quoted text -

- Show quoted text -
Click to expand...
Thanks. Learn something new many times a day! So far no joy though.
I'm going to "noprune" the heck out of that module until something
happens. hehehe

Shannon
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top