> Several quick comments.1) This would be a "synchronous reset".
> For it to be asynchronous you would need reset defined in the
> always sensitivity list.
That's what I was saying. The example in the draft standard
says, erroneously, that the following is a *synchronous* reset:
always @(posedge CLOCK or posedge RESET)
> 2) Last I checked "Tasks" are not synthesizable constructs.
In Synopsys' design compiler, they are.
But, with respect, both of these are kind of beside the point.
The point is, should the following be synthesizable?
always @(posedge clock)
begin
...
@(posedge clock) ...
...
end
The tasks in the example were merely the way in which the
original comp.lang.verilog poster chose to create the above
construct. And, had the tasks contained only combinational
logic, they would have been fine.
It's the "@(posedge ...)" within an "always @(posedge ...)"
which concerns me. Synplicity, apparently, says "that's fine".
Synopsys (and the draft standard) say "don't be ridiculous".
Should the standard take a stand on this? At the moment, it
(the standard) would seem to regard Synplicity as providing
superset (i.e. non-standard) functionality. And I'm still not
convinced that it is a wisely conceived superset.
t