uninferred due to asynchronous read logic

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

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

 

[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

 

[KJ]

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;

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

 

[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

 

[KJ]

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

 

[Shannon]

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

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