Yes, this is very much synthesizable. This is an example of an Implicit FSM.
Bhasker, was my proposal for the VHDL Implicit FSM discussed at the DAC
face-to-face? I can prepare a similar proposal for Verilog too.
Regards,
================================================================
Apurva Kalia Phone: 91-11-8562843 ext 4230
Senior Engineering Manager Fax: 91-11-8562231
Logic Design and Verification e-mail: apurva@cadence.com
Cadence Design Systems (India) v-mail: 91-11-8562843 ext 4230
408-944-7809
================================================================
> From owner-vlog-synth@vhdl.org Mon Jun 29 16:28 IST 1998
> X-Authentication-Warning: server.eda.org: majordom set sender to owner-vlog-synth@vhdl.org using -f
> To: vlog-synth@vhdl.org
> Subject: Re: Edge-sensitive sequential logic
> Reply-To: vlog-synth@eda.org
> Mime-Version: 1.0 (generated by tm-edit 7.106)
> From: Tommy Kelly <tommyk@mekb2.sps.mot.com>
> Date: 29 Jun 1998 11:49:48 +0100
> Lines: 40
> X-Mailer: Gnus v5.4.37/XEmacs 19.16
> Sender: owner-vlog-synth@eda.org
>
> jrh <jrh@hudson.com> writes:
>
> > 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
>