On 2/19/2011 1:23 AM, ben cohen wrote:
> The *always_ff * emphasizes the Flip-Flop implementation. I think that
> this is nice. I gave you the details of meaning and checks if a FF is
> not implied.
This idea is nice, but may I propose an alternate?
First, lets add some predefined attributes:
attribute default_clock : STD_ULOGIC;
attribute default_reset : STD_ULOGIC;
attribute default_enable : STD_ULOGIC;
attribute default_reset_value : STD_ULOGIC;
attribute default_clock_edge : STD_ULOGIC;
Attributes can be set on an entity, a process, or a group, or a signal
so I could write a template:
attribute default_clock of ent1 : entity is clk;
attribute default_reset of ent1 : entity is rst;
Where "clk" is the default clock that I want to use on entity ent1.
Then we would have to have a built in operator which could read these
attributes, and create the ff. I could see something like:
r2 <= ZT(r1, 2); or more simply:
r2 <= r1 @ 2;
Which would generate a FF, using the default_clock and default_reset
with a delay of 2 clocks. Since "default_enable" is not defined there
would be no clock enable, default_reset_value would default to '0', and
default_clock_edge would default to '1' or positive edge.
You could set the attribute on a signal, a process, a group, or an
entity, and search for them in that order. If "default_clock" is
undefined, then you get an error.
Yes, this would have to be a "special" operator because the language
currently can't support this.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 24 07:03:46 2011
This archive was generated by hypermail 2.1.8 : Thu Feb 24 2011 - 07:03:51 PST