Interpreting 1364.1-2002 5.2.2.1: Edge FF's with async jam l

J

John Vickers

Guest
This is about the possible valid interpretations of certain verilog code
according to the RTL synthesis standard (IEEE Std 1364.1-2002), rather than
the interpretation under the EDS standard (IEEE Std 1364-2001).

I think I'm happy with the use of translate_on/translate_off and 'force'
to model a 74LS74-style D-FF with asynchronous set and reset consistently
in both simulation and synthesis.


Now 5.2.2.1 of the RTL synthesis standard says:

always @( posedge <condA> or negedge <condB> or nededge <condC> or ...
posedge <Clock> )
// Any sequence of edge events can be in event list.
if (<condA>) // Positive polarity since *posedge* <condA>.
// ... <asynchronous logic>

[...]

So *any* asynchronous logic (not involving 'x' or 'z') is valid here ?
In particular, are assignments of non-constant values valid ?


These are questions about the synthesis standard itself, rather than about
the behaviour or capabilities of any particular synthesis tool.


Assuming that the following module description:
- is synthesisable /according to the synthesis standard/
- has a synthesis for some synthesis tool

Is this module description description guaranteed (or even likely) to
be consistent between synthesis and simulation ?

module jam( clk, j, d, dj, q );
input clk, j, d, dj;
output q; reg q;

always @(posedge clk or posedge j )
if( j )
q <= dj; // In Synthesis, While j asserted, q follows dj
else
q <= d; // Normal posedge-triggered load

// synopsys translate_off
always @(j or dj)
if( j ) force q = dj;
else release q;
// synopsys translate_on

endmodule


The final question is:
Are there any real synthesis tools which will synthesize this the way I expect ?


Regards,

John Vickers.
 
On Wed, 26 May 2004 18:58:53 +0100, John Vickers <john@xza5.com>
wrote:

This is about the possible valid interpretations of certain verilog code
according to the RTL synthesis standard (IEEE Std 1364.1-2002), rather than
the interpretation under the EDS standard (IEEE Std 1364-2001).

I think I'm happy with the use of translate_on/translate_off and 'force'
to model a 74LS74-style D-FF with asynchronous set and reset consistently
in both simulation and synthesis.
Click to expand...
I think the following would be a better model for the 74LS74 cell:

always @(negedge PRE or negedge CLR or posedge CLK)
if (!PRE)
Q<= 1'b1;
else if (!CLR)
Q<= 1'b0;
else
Q<= D;

The only difference is that this assumes you have a cell where async
SET overrides CLEAR if they are both on. 74LS74 has no such spec and
it is undefined what happens. One issue with synthesis is that some of
the synthesis output behavior depends on what's in your cell library
for these interesting cases.

In terms of 1364.1, I am pretty sure people didn't imagine how those
comments would be interpreted. I think that's one case which we have
missed during the review. If you notice all the examples are assigning
constant values for async cases, partly because that's how the real
hardware behaves in almost all cases. Hopefully there'll be a
clarification in 1364.1-2007 :-(

Now 5.2.2.1 of the RTL synthesis standard says:

always @( posedge <condA> or negedge <condB> or nededge <condC> or ...
posedge <Clock> )
// Any sequence of edge events can be in event list.
if (<condA>) // Positive polarity since *posedge* <condA>.
// ... <asynchronous logic

[...]

So *any* asynchronous logic (not involving 'x' or 'z') is valid here ?
In particular, are assignments of non-constant values valid ?


These are questions about the synthesis standard itself, rather than about
the behaviour or capabilities of any particular synthesis tool.


Assuming that the following module description:
- is synthesisable /according to the synthesis standard/
- has a synthesis for some synthesis tool

Is this module description description guaranteed (or even likely) to
be consistent between synthesis and simulation ?

module jam( clk, j, d, dj, q );
input clk, j, d, dj;
output q; reg q;

always @(posedge clk or posedge j )
if( j )
q <= dj; // In Synthesis, While j asserted, q follows dj
else
q <= d; // Normal posedge-triggered load

// synopsys translate_off
always @(j or dj)
if( j ) force q = dj;
else release q;
// synopsys translate_on

endmodule


The final question is:
Are there any real synthesis tools which will synthesize this the way I expect ?


Regards,

John Vickers.
Click to expand...
 
kal wrote:
[...]
I think the following would be a better model for the 74LS74 cell:

always @(negedge PRE or negedge CLR or posedge CLK)
if (!PRE)
Q<= 1'b1;
else if (!CLR)
Q<= 1'b0;
else
Q<= D;

The only difference is that this assumes you have a cell where async
SET overrides CLEAR if they are both on. 74LS74 has no such spec
Click to expand...
:) I thought of writing 74HC74, which /does/ specify that preset
overrides clear on the Q output...

and
it is undefined what happens. One issue with synthesis is that some of
the synthesis output behavior depends on what's in your cell library
for these interesting cases.

In terms of 1364.1, I am pretty sure people didn't imagine how those
comments would be interpreted. I think that's one case which we have
missed during the review. If you notice all the examples are assigning
constant values for async cases, partly because that's how the real
hardware behaves in almost all cases. Hopefully there'll be a
clarification in 1364.1-2007 :-(
Click to expand...
So, in synthesis, you would seek to forbid assignments of non-constants
under asynchronous controls, right ?

Would the required constants have to be immediate constants ?
Or would any expression that can in principle be found to be
a constant by examining the whole design be OK ?

The example I give could perhaps be synthesised
- to a target with suitable four input multiplexors as primitives,
- by creating combinatorial logic driving the Set/Reset controls
of a set/reset D-FF:

set = d & j;
reset = ~d & j;

74HC192 is an up-down counter with jam load.

Now 5.2.2.1 of the RTL synthesis standard says:
always @( posedge <condA> or negedge <condB> or nededge <condC> or ...
posedge <Clock> )
// Any sequence of edge events can be in event list.
if (<condA>) // Positive polarity since *posedge* <condA>.
// ... <asynchronous logic
Click to expand...
[...]

module jam( clk, j, d, dj, q );
input clk, j, d, dj;
output q; reg q;

always @(posedge clk or posedge j )
if( j )
q <= dj; // In Synthesis, While j asserted, q follows dj
else
q <= d; // Normal posedge-triggered load

// synopsys translate_off
always @(j or dj)
if( j ) force q = dj;
else release q;
// synopsys translate_on

endmodule
Click to expand...
 
In article <1cbab09mfo6so0ndg4udd2vgjuqoljgv2m@4ax.com>,
kal <kal@dspia.deletethis.com> wrote:
I think the following would be a better model for the 74LS74 cell:

always @(negedge PRE or negedge CLR or posedge CLK)
if (!PRE)
Q<= 1'b1;
else if (!CLR)
Q<= 1'b0;
else
Q<= D;
Click to expand...
What is supposed to happen if PRE and CLR start off low, then PRE rises?
We would expect the flop to reset, but the rising edge of PRE does not
trigger the always block. In fact, the flop DOES reset, but _synchronously_!!!

This model is not correct. The only way to model this correctly is with
assign/deassign, as shown earlier.

This is one place where VHDL gets it right.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top