Subject: Re: Inferring FPGA Hardware Features?
From: VhdlCohen@aol.com
Date: Sun Jul 15 2001 - 14:11:06 PDT
In a message dated 7/14/01 10:07:54 AM Pacific Daylight Time,
kcoffman@sos.net writes:
> <<One of the topics we touched on a few years ago was allowing pragmas to
> make use of explicit FPGA features. One of the things that drives me nuts
> is to know there is a hardware feature available that I can't explicitly
> make use of. The best example is clock enable, I'd love to be able to
> assign a signal to a flip flop clock enable input. For example: (* signal1
> attribute clock_enable*). This group seems more open to allowing closer
> ties to the underlying hardware, do you folks feel like revisiting this
> topic? Other features include reset/preset/global clock/sector clock, etc.
> I don't think the spec needs to define all potential features, but should
> allow this mechanism and tie down a few common ones.>>
The concept is good, but I see issues with such pragmas or attributes.
1. At what point do we say "we covered everything that needs to be covered"?
2. Aren't these attributes technology dependent? Currently vendors support
define
technology dependent attributes. For Example, Synplify defines Actel
specific Attributes and Directives
such as "syn_useenables Prevents generation of registers with clock
enable pins for 54SX designs. ",
"syn_keep (D) Prevents the internal signal from being removed during
synthesis and optimization.
syn_maxfan Sets a fanout limit for an individual input port or register
output.
syn_netlist_hierarchy Determines whether the EDIF output netlist is flat or
hierarchical.
syn_noarrayports Prevents the ports in the EDIF output netlist from being
grouped into arrays, and leaves them as individual signals.
syn_noclockbuf Turns off the automatic insertion of clock buffers.
syn_noprune (D) Controls the automatic removal of instances that have
outputs that are not driven. "
.. And for Altera
"altera_auto_use_eab Automatically implements large RAMs and ROMs as
extended array blocks (EABs) for FLEX10K and ACEX designs.
altera_auto_use_esb Automatically implements large RAMs and ROMs as
PTERMs in extended system blocks (ESBs) for APEX20K designs.
altera_chip_pin_lc Specifies pin locations for Altera I/Os.
altera_implement_in_eab Implements a logic design unit as extended array
blocks (EABs) for FLEX10K and ACEX designs.
altera_implement_in_esb Implements a logic design unit as a PTERM in an
extended system block (ESB) in APEX designs.
altera_io_opendrain Sets open-drain mode for output and bidirectional
ports in APEX20KE architectures. "
Those are just examples, the list is quite extensive (see Synplify help file
under "attribute" for a complete list supported as of today).
On the other hand, there are atributes that are common that are in our spec,
like
"full_case (D) Specifies that a Verilog case statement has covered all
possible cases.
parallel_case (D) Specifies a parallel multiplexed structure in a Verilog
case statement, rather than a priority-encoded structure. "
So the question really is: Do we want to sort out a "common" set of
attributes that are useful for FPGA? This is not an easy task. Will it
ever be complete?
Vendors may also wish to provide specific tailorability into their tools
(thru pragmas/attributes) to be competitive. Is it our job to define this
set?
------------------------------------------------------------------------------
--------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Component Design by Example ... a Step-by-Step Process Using
VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
--------------------------------------
This archive was generated by hypermail 2b28 : Sun Jul 15 2001 - 14:27:45 PDT