Quartus II and the funny synthesis attributes

Altera_Forum · ‎07-20-2011

Hi everyone,

Last week I noticed some funny results after the implementation of my desing in Quartus II 11.0. Inside it there are two simple register chains, each one made up of three registers of 18 bit width, which I use as two delay chains of three clock cycles. I modelled them in VHDL (as well as the rest of the components of my design) by means of an array of std_logic_vector signals and a basic process. I think the exact code is irrelevant; it works well and Quartus infers properly the delay chain, so I won't include it in this post (it is long enough).

The funny thing is that I realized that after the 'fitter' process, Quartus decided to implement the two delay chains by means of one altshift_taps megafunction (that's not a problem) inside one M9k (that is a problem). As you may think, this is a total waste of memory, because only 108 bits of the entire memory block are used.

So I surfed over documentation, and finally I found information about the synthesis attributes supported by Quartus II (see Quartus II help page, section "VHDL Synthesis Attributes and Directives"). I have assigned the attribute 'ramstyle' to several language objects and elements (the signal which modelates the delay chain, its type, and even the whole component that instantiates it) setting it to a value "logic", i.e.,

attribute ramstyle : string;

attribute ramstyle of MULTI_NCO : component is "logic";

and despite that, Quartus II keeps on implementing the two delay chains as dedicated memory blocks (M9k). Could anyone suggest any solution or idea to fix this issue? I need to reduce the amount of memory occupied by my design for commercial/contractual reasons, and obviously, this is a good way to do it.

I appreciate your time guys, thank you.

Altera_Forum · ‎07-20-2011

Ive had exactly this issue, with much worse problems. I had a single bit x7 registers in behavioural code, and it would take 1 M9k per filter I generated (which was 32!!!!). The problem is the altshift_taps megafunction, because it has a habit of using M9Ks for no good reason.

The reply I got from mysupport:

"i have however discovered a solution using the analysis and synthesis options, more settings, and setting auto shift register replacement to “off”, by default this is “auto”. you can navigate to the option, in assignments, settings, analysis & synthesis setting, more settings. auto shift registers to “off”

alternatively you can simply add the following line to your qsf file.

set_global_assignment -name auto_shift_register_recognition off"

This should stop it creating altshift_taps and eating all your m9ks

Altera_Forum · ‎07-20-2011

Also, if you get unconfortable turning them off globally, you can do this instead:

set_global_assignment -name AUTO_SHIFT_REGISTER_RECOGNITION -entity <entity name> <value>

Altera_Forum · ‎07-20-2011

Wow Tricky, I'm really amazed for your quick reply. I'm going to check it out. Thank you!

Altera_Forum · ‎07-20-2011

Besides the .qsf syntax, I go to the Hierarchy Browser, find the hierarchy that's problematic, and right-click -> Locate -> Assignment Editor. The AE comes up with the full entity name populated in the top Filter bar. I copy that and Paste it into the To column, then select the assignment Auto Shift Register Replacement and set the Value to Off.

Note that synthesis should be smart about this, i.e. it may do this at first when the design has open M9Ks, but as you add more memory, these should get demoted back to using logic.

Altera_Forum · ‎07-21-2011

That's funny, I had the exact problem two days ago. In a design I have I'm using 5 instances of the exact same entity. In one of them a shift function is synthesized as a altshift_taps in an M9K while the other 4 only use logic. The M9K implementation doesn't pass timing requirements while the others do...

I started using the assignment editor to fix the problem, but I don't like it because I'm sure one day the VHDL code will be reused in another project and we'll forget to put the assignment back. I could leave a comment in the code, but who reads comments... :D

So I used another solution instead, which is to give instructions to the synthesizer through VHDL attributes. Like you I had so luck with the ramstyle attribute, but this one works very well:

	--! Altera synthesizer instuctions attribute
attribute altera_attribute : string;
	--! Instruct synthesizer not to use altshift_taps for shift registers in this entity
attribute altera_attribute of RTL: architecture is "-name AUTO_SHIFT_REGISTER_RECOGNITION OFF";

Please note that you must apply the attribute to the architecture, not the entity.

Altera_Forum · ‎07-21-2011

Thank you for your replies guys, the problem is solved. I used the VHDL attribute I had already defined, but changed it from "ramstyle" to "altera_attribute" (just as Daixiwen indicated), and applied it to the architecture of the tricky component. The code looks like this:

attribute altera_attribute : string;

attribute altera_attribute of PIPE_struct : architecture is "-name AUTO_SHIFT_REGISTER_RECOGNITION OFF";

After a long compilation, the problem was gone! So thank you very much again; I must say I'm pleased with your fast replies.

Best regards,

Pablo L.S.

GRADIANT

Altera_Forum · ‎07-21-2011

Daixiwen - very nice solution, as it allows hierarchical assignments normally applied in the Assignment Editor/.qsf to be put into the HDL. I generally prefer the assignment editor because I can search/sort easily, but the portability is much better in the HDL. Thanks for bringing it up. (That might be worth a separate, lone post so more read it.)