Re: Verilog-AMS LRM committee meeting - 19th July 2007 - More MS fixes

[resend]

David Miller wrote:
> The updated document the chapter 8 can be found here:
>
> http://www.eda-stds.org/verilog-ams/htmlpages/public-docs/merged_mixedsig.pdf 
>
I think the following might be confusing -

    /*8.3.6 Concurrency*/
    /Verilog-AMS provides synchronization between the continuous and
    discrete domains./
    /Simulation in the discrete domain proceeds in integer multiples of
    the digital tick. This/
    /is the smallest value of the second argument of the `timescale
    directive (see Section 19.8/
    /in IEEE 1364-2005 Verilog HDL). Thus, values calculated in the
    digital domain shall be/
    /constant between digital ticks and can only change at digital ticks. /

Drivers in A2Ds are active off-tick, and (should) appear in a 
delta-cycle of  the real time rounded to the nearest tick - i.e. a tick 
spans a period of real time and there can be any number of  delta cycles 
spread out within it. The actual restriction is that digital simulators 
cannot schedule events below the resolution of a tick. E.g. with a 
`timescale of 1ps/1ps then the digital simulator can only schedule with 
an accuracy of 0.5ps/,/ but it could be activated from an A2D at (say)  
123.07ps, if the simulator then schedules a #1 delay (1ns) the time at 
which that occurs would be 124.00ps, a #0 delay event happens at 
123.07ps - and it would appear to be in a delta cycle of the tick at 
123.00ps in the digital domain (the tick spans 122.5ps to 123.5ps).

So I would change the text by striking the last sentence:

    /*8.3.6 Concurrency*
    Verilog-AMS provides synchronization between the continuous and
    discrete domains.
    Simulation in the discrete domain proceeds in integer multiples of
    the digital tick. This
    is the smallest value of the second argument of the `timescale
    directive (see Section 19.8
    in IEEE 1364-2005 Verilog HDL). Thus, values calculated in the
    digital domain shall be
    constant between digital ticks and can only change at digital ticks./

A related old issue is that event scheduling should be rounded to the 
nearest tick and not rounded up, so I'd also make the following changes:

    /*8.3.6.1 Analog event appearing in a digital event control*
    In this case, an analog event, such as cross or timer, appears in an
    @() statement in the
    digital context.
    /

        /Examples:/

            /always begin/
            /@(cross(V(x) - 5.5,1))/
            /n = 1;/
            /end/

    /When it is determined the event has occurred in the analog domain,
    the statements under
    the event control shall be scheduled in the digital domain at the
    largest _nearest_ digital time tick
    smaller than or equal to the time of the analog event. This event
    shall not be schedule_d_ in
    the digital domain earlier than the _last or_ current digital event
    (see Section 9.2.3), _however it may appear to be in a delta cycle
    belonging to a tick started at an earlier or later time_./

    /_Zero-delay scheduling is not rounded, so in the case where the
    digital event causes the another event on the digital to analog
    boundary with zero delay, it will be handled at the current analog
    time._/

Rounding up or down rather than to the nearest tick introduces more 
timing error, e.g. with a 1ps tick the maximum scheduling error is 0.5ps 
with nearest while it is 1ps with round-up. The zero-delay scheduling 
text is required so that signals just passing through (say) continuous 
assignments do not incur unnecessary delays.

Can you make those changes?

Regards,
Kev.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.