Re: [sv-bc] @* vs. always_comb

ummm... sorry for making this reply too long...

it's just a personal opinion, but if i were to choose from these 7 :

	(1) initial
	(2) always
	(3) always_comb
	(4) always_ff
	(5) always_latch
	(6) always @*
	(7) final


i am *ONLY* going to advise users to use 1, 2 & 3, and that is it.
i have no need for 4, 5, 6 & 7.


to model an asynch. resettable FF (for behavioral code) -

	always @(posedge clk or posedge reset) begin
		if (reset) q[(SIZE - 1):0] <= {SIZE {1'b0}};
		else q[(SIZE - 1):0] <= d[(SIZE - 1):0];
	end

is as good as it can get. it's simple, concise and reflects the actual
intent of what i need for the tool to do. no need for it to do any kind
of checking, it needs to know all that it needs to know from what i have
given or specified.


i find
	always_ff @(posedge clock iff reset==0 or posedge reset) begin
		...
		...
		...
	end


confusing and serves me no real purpose. again, a personal opinion.
just don't make assignments to the same variable from *different*
procedural blocks. i am sure you all know that.


same deal with latches. for example, all i need for an asynch.
resettable LATCH is -

	always @(d or posedge clk or posedge reset) begin
		if (reset) q[(SIZE - 1):0] <= {SIZE {1'b0}};
		else if (clk) q[(SIZE - 1):0] <= d[(SIZE - 1):0];
	end


i have absolutely no need for always_latch. yes, it might save me from
typing in a few extra words, but i think that is it. as a rule: we never
use blocking timing controls inside sequential elements.


also, i am not sure when and where always_ff and always_latch fires, but
i am speculating it must be within the *active* slot, along with it's
gazillion other friends. my understanding (hopefully not flawed) is that
all of


	(3) always_comb
	(4) always_ff
	(5) always_latch


will happen AFTER the "initial" (w/ blocking timing control) and
"always" blocks... meaning somewhat at the end of the active slot, but
before the beginning of the inactive slot ?


till today, i don't fully comprehend all of the intricacies associated
with using "always @*" and consequently, i have maintained my distance
from it. "inferred" sensitivity lists aren't big on my plate. telling a
tool to be automatically sensitive to ALL the signals that it believes
it read within a procedural block - to me, that is a risky game. most of
the time, you want ALL signals on the RHS of assignments + signal
enables within the conditional if-else-if statements, but ...


... that said, i believe using SV's always_comb might be of some
benefit, despite it being somewhat of an older, but wiser brother to
"always @*". always_comb (if it fires AFTER initial and always blocks)
can be useful to catch changing signals at time 0 (kind of similar to
C/C++'s do-while loop where it is guaranteed to execute at least once).



finally, i have absolutely no need for the "final" block.


my conclusion - for me (can't speak for other people) -

	(1) initial			YES, of-course!
	(2) always			YES, of-course!
	(3) always_comb			USE, but judiciously!
	(4) always_ff			NOT necessary!
	(5) always_latch		NOT necessary!
	(6) always @*			NO!
	(7) final			NEVER!


thanks.
-nasim


-- 
----------------------------------------------------------------------
Nasim Hussain           | Life is short,   ---     _ o     _~o     _ o
UltraSPARC Verification |   go wherever  ----    _`\<,   _`\<,   _`\<,
SUN Microsystems, Inc.  |     you want...  ---  ( )/( ) ( )/( ) ( )/( )
work - (408) 720-4927   |
home - (650) 967-7730   |