Subject: Re: Attributes & Synthesis Pragmas
From: Krishna Garlapati (krishna@synplicity.com)
Date: Wed Oct 24 2001 - 12:43:31 PDT
I guess I can help with the Synplify attibutes pertaining
to Verilog. Here is a list of attributes along with
the description:
full_case/parallel_case you all know about this.
syn_black_box Defines a black box for synthesis.
syn_encoding Specifies the encoding style for state
machines.
syn_keep Prevents the internal signal from being removed
during synthesis and optimization.
syn_preserve Prevents sequential optimizations across a
flip-flop boundary during optimization, and preserves the signal.
syn_sharing Specifies resource sharing of operators.
syn_state_machine Determines if the FSM Compiler extracts a
structure as a state machine.
translate_off/translate_on Specifies sections of code to exclude from
synthesis, such as simulation-specific code.
syn_probe Drag a net to ports so that it can be probed.
syn_rom_style specify the style of rom to infer.
syn_ramstyle same as above, but for rams.
syn_noprune Controls the automatic removal of instances that
have outputs that are not driven.
Regards,
- Krishna.
"Clifford E. Cummings" wrote:
>
> Hi, All -
>
> Paul makes a good point. I don't think we were only going to add the
> infinitely abusable full_case and parallel_case directives, but it is time
> to start brain-storming on others.
>
> More attributes should be supported in the Synthesis Standard. I think I
> have been charged with making proposals in this area and I would appreciate
> it if you all would e-mail me a list of code in-line-pragmas that I could
> use as a starting point.
>
> Some that come to mind for Synopsys include:
>
> Synopsys
> infer_mux
> translate_off
> translate_on
> map_to_module
>
> Ben Cohen has been submitting Synplicity pragmas dealing with memory inference.
>
> If anyone knows of additional pragmas in use by various tools, could they
> please send them to me. I really should get working on my assignments so
> Bhasker doesn't think I'm a total loser (right now I think he would not
> user the word "total" ;-)
>
> While we are on the subject, about the term "rtl_synthesis." I know we had
> this discussion over a year ago, but I still wonder why we have prefixed
> synthesis pragmas with "rtl_"
>
> It seems like the biggest reason was so that it would match the VHDL
> synthesis document (a pretty lame reason). We also mentioned that
> "rtl_synthesis" recognized that there might someday be pragmas such as
> "beh_synthesis" (behavioral) or dp_synthesis (data path), etc. To me typing
> the extra characters "rtl_" in anticipation of other synthesis-type pragmas
> still seems silly. I still think a pragma of "synthesis" makes more sense
> as a general purpose synthesis (rtl, behavioral or data path) pragma and
> then later add rtl_synthesis or dp_synthesis pragmas that are specific to
> those tools.
>
> Of course, with any pragma, a vendor could choose to ignore the pragma,
> issue a warning for the pragma or issue an error as they see fit. Perhaps a
> data path tool would only accept pragmas that have been added as dp_synthesis.
>
> Comments?
>
> Regards - Cliff
>
> At 08:28 AM 10/24/01 -0700, you wrote:
> >I'm looking at the set of attributes defined for synthesis. So far, only
> >full_case and parallel_case are defined. There are lots of synthesis
> >pragmas supported by Synopsys and Cadence. Why do only two of them appear
> >as attributes?
> >
> >Paul
>
> //*****************************************************************//
> // Cliff Cummings Phone: 503-641-8446 //
> // Sunburst Design, Inc. FAX: 503-641-8486 //
> // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> // PMB 501 Web: www.sunburst-design.com //
> // Beaverton, OR 97005 //
> // //
> // Expert Verilog, Synthesis and Verification Training //
> //*****************************************************************//
-- - Krishna. Synplicity Inc. (408)215-6152
This archive was generated by hypermail 2b28 : Wed Oct 24 2001 - 12:51:09 PDT