Subject: Re: Attributes & Synthesis Pragmas
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Wed Oct 24 2001 - 23:48:59 PDT
Synopsys also has the following directives:
state_vector vector_name
enum enum_name
return_port_name port_name
template
async_set_reset "signal_name_list"
async_set_reset_local block_label "signal_name_list"
async_set_reset_local_all "block_label_list"
sync_set_reset "signal_name_list"
sync_set_reset_local block_label "signal_name_list"
sync_set_reset_local_all "block_label_list"
one_cold "signal_name_list"
one_hot "signal_name_list"
dc_script_begin
dc_script_end
infer_multibit "signal_name_list"
dont_infer_multibit "signal_name_list"
label identifier
resource identifier
label_applies_to LABEL
Shalom
"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 //
> //*****************************************************************//
-- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 **************************************************************************
This archive was generated by hypermail 2b28 : Wed Oct 24 2001 - 23:58:01 PDT