0000608: 16.14.2 clocking block value resolution

EDA.org Mantis

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Date Submitted

Last Update

0000608

[SystemVerilog P1800] SV-EC

major

2005-03-24 11:36

2007-04-06 11:10

Reporter

Steven Sharp

View Status

public

Assigned To

Priority

immediate

Resolution

open

Status

closed

Product Version

Summary

0000608: 16.14.2 clocking block value resolution

Description

I am filing this erratum for another reviewer:

There are some issues with the value resolution semantics as defined by section 16.14.2 which specify that if the same clocking output is driven more than once in the same time slice it produces an error and sets the value to 'x.

Although we can appreciate the desire to catch issues with multiple drivers we disagree that this is an appropriate mechanism to achieve that goal. Managing multiple drivers occurs over a much broader set of objects and should have a broader solution. Such a broad solution would fit well within SystemVerilog, but this particular mechanism does not.

Another issue with this is the meaning of the same simulation time . In particular, is this the time when the output is assigned by the clocking drive or when the clocking drive applies its value to the underlying signal? If the former, than what should happen if at different times a clocking drive was applied at ##5 and ##3 units later another different value was applied at ##2? If the latter, then what should happen if the clocking event occurs more than once in a time-slice? Or is this all intended to only apply to the situation where the clocking-drive is zero-delay?

Another minor issue is that the conflict value is defined for 2-state and 4-state, but not for reals.

Additional Information

Closed on Mar/5/2007. unanimously. Covered by 0000890.
Updated Status/CLOSED

Tags

No tags attached.

Type

Errata

Attached Files

Relationships

Notes
(0003579) mehdi_mohtashemi (manager) 2007-04-06 11:10	Closed on Mar/5/2007. unanimously. Covered by mantis 890.

Issue History
Date Modified	Username	Field	Change
2005-03-24 11:36	Steven Sharp	New Issue
2005-03-24 11:36	Steven Sharp	Type	=> Errata
2005-04-13 08:11	chas	Priority	normal => immediate
2007-04-06 11:10	mehdi_mohtashemi	Note Added: 0003579
2007-04-06 11:10	mehdi_mohtashemi	Status	new => closed
2007-04-06 11:10	mehdi_mohtashemi	Additional Information Updated

Mantis 1.1.7[^]