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

Hi Kevin,
Yes, those changes seem to be okay. I will go ahead and place them in the re-work.

Cheers...
Dave

K. Cameron wrote:
> 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 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.
> 

-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================

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