RE: [sv-ec] Ambiguous Program Block Port Assignments??

Hello All,

I'd like to introduce Mantis item #890, which I entered
after Cliff wrote this mail in September.

    http://www.eda.org/svdb/bug_view_page.php?bug_id=0000890

There is a detailed proposal entered in the usual MS Word format.

Here is the description of the problem, copied-and-pasted from
the Mantis Item description field:

***

The current LRM sections on program and clocking blocks
have a few ambiguities that should be addressed to ensure
consistent behavior across implementations.

The first set of ambiguities is concerned with the timing
of when program code samples and drives clocking block
outputs back into the design. The upshot is that *any*
assignment made to a clocking block output or inout in
a time unit at which a clock edge appears shall be
propagated into the design in the NBA region, after all
active and reactive processing is finished. It doesn't
matter if the assignment to the clocking block output
was made before or after the clocking event has occured,
as long as it is in the same time unit as the clocking
event.

The next set of ambiguities is related to what the behavior
of a program and clocking block should be in case 
assignments are made to clocking block outputs at time
units inbetween clock edges. Currently the LRM is silent
on this topic, and the behavior of such code must be 
defined.

Lastly, there are ambiguities present when there is no
clocking block present in a program block, and direct
assignments or drives are made to program ports from
program code. Clarifications are introduced to help
specify what the behavior of such constructs should be. 

***

Happy Reading!

Best regards,
Doug

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Clifford E. Cummings
> Sent: Thursday, September 01, 2005 4:50 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] Ambiguous Program Block Port Assignments??
> 
> Subject: Ambiguous Program Block Port Assignments??
> 
> Hi, All -
> 
> Next spec ambiguity?? - Program block ports
> 
> Attached is a small working example: porttest.v
> 
> =============
> 
> This example works with both ModelSim 6.1a and VCS version 2005.06
> 
> In default compile mode, the program block is making 
> assignments to the 
> program block ports (which also correspond to the device ports) using 
> nonblocking assignments.
> 
> =============
> 
> If you use the compile switch +define+P1, the program block will make 
> assignments to the same ports using blocking assignments. Since the 
> declarations are part of the program block, could they be considered 
> program block variables that can be assigned using blocking 
> assignments (??)
> 
> This example works with ModelSim 6.1a but fails with VCS 
> version 2005.06. 
> VCS notes that a "Design variable can only be driven through and 
> nonblocking assignment within a program." I'm not sure which 
> implementation 
> is "right" but I would like to make sure that all 
> implementations recognize 
> the same syntax. I would like to get this fixed real quick before 
> implementations diverge on the standard.
> 
> =============
> 
> If you use the compile switch +define+P2, the program block will make 
> assignments to an intermediate program variable that is then 
> driven to the 
> port through a continuous assignment. Of course, we cannot 
> use nonblocking 
> assignments with a continuous assignment so how should this work?
> 
> This example works with ModelSim 6.1a but fails with VCS 
> version 2005.06. 
> VCS again notes that a "Design variable can only be driven 
> through and 
> nonblocking assignment within a program." Are continuous 
> assignments to 
> program ports that drive design inputs illegal??
> 
> =============
> 
> Regards - Cliff
> 
> 
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training
>