ISSUE 659

Edit Proposal  Edit Class, Environment, or Release
Number 659
Category errata
Synopsis 2005/D6, 15.3.3: $fullskew bugs
State proposal
Class errata-discuss
Arrival-DateApr 11 2005
Originator Shalom.Bresticker@freescale.com
Release 2005/D6: 15.3.3
Description
In 15.3.3 $fullskew:

1. The LRM says,

"The default behavior for $fullskew is timer-based. Violations shall be reported
immediately upon an elapse of time after the timestamp event equal to the limit.
It then becomes dormant and reports no more violations, even in response to
timecheck events, until after the next timestamp event. This check shall also
become dormant if it detects a timestamp event when the associated condition is false."

This needs to change to something like the following:

"The default behavior for $fullskew is timer-based. A violation shall be
reported immediately upon elapse of the time limit after the timestamp event if
a timecheck event does not occur in this time, turning the timing check dormant.
However, if a timecheck event does occur within the time limit, then no
violation is reported and the timing check turns dormant immediately.

If a second timestamp event occurs within the time limit, then a new timing
check is activated and no violation is reported on the first.
However, if it detects a conditioned timestamp event when the associated
condition is false, then the timing check turns dormant.

A reference event or data event is a timestamp event and activates a new timing
check, unless it is a timecheck event occuring within the time limit after a
preceding timestamp event.

In the timer-based mode, the remain active flag is ignored."


2. Case 1 says,

" Case 1: Event based flag and remain active flag not set.

The transition at A of CP while MODE is true begins a wait for a negative
transition on CPN, and a violation is reported at B as soon as a period of time
equal to 50 time units has passed. This resets the check and readies it for the
next active transition.

A negative transition on CPN occurs next at C, beginning a wait for a positive
transition on CP while MODE is true. At D a time equal to 70 time units has
passed without a positive edge on CP while MODE is true, so a violation is
reported and the check is again reset to await the next active transition.

A transition on CPN at E also results in a timing violation, as does the
transition at F, because even though CP transitions, MODE is no longer true.
Transitions at G and H also result in timing violations, but not the transition
at I, because it is followed by a positive transition on CP while MODE is true."

Reminder: we decided that Case 1 should be simply, "Event based flag not set."

The first paragraph says,

"a violation is reported at B as soon as a period of time equal to 50 time units has passed."

However, the intent is that 50 timepoints passed WITHOUT a negedge in CPN.
But in the figure, we clearly see that there IS a negedge on CPN before B.
So the figure does not correct show the intended case.
The figure should be redrawn so that there is no negedge on CPN before B.

Next, it says,

"A negative transition on CPN occurs next at C". As mentioned above,
this should appear in the diagram AFTER B. The arrows and vertical lines
showing the time between C and D need to move to the right as well.

Finally, it ends with

"Transitions at G and H also result in timing violations, but not the transition at I, because it is followed by a positive transition on CP while MODE is true."

That positive transition on CP is J. In the current diagram, J is more than
70 timepoints after I. It should be within that time.

Simply moving the CP waveform a little to the right might fix all of these.


3. Case 2 is:

"Case 2: Event based flag set, remain active flag not set.

The transition at A of CP while MODE is true begins a wait for a negative
transition on CPN, and a violation is reported at C on CPN because it occurs
beyond the 50 time unit limit. This transition at C also begins a wait of 70
time units for a positive transition on CP while MODE is true. But for
transitions on CPN at B through H there is no positive transition on CP while
MODE is true, and so no timing violations are reported. The transition at I on
CPN begins a wait of 70 time units, and this is satisfied by the positive
transition on CP at J while MODE is true."

The same comments that C should be after B and J after I hold here too.

The sentence "But for transitions on CPN at B through H" should be
"But for transitions on CPN at C through H".
(The history of this is that in the 1364-2001 draft, it was originally
written "This transition at B also begins a wait of 70 time units.."
and one reviewer noticed that it should be C, but the second place where
B should also be C was missed.)

Note that the same rules about when a new timing check is activated hold
in the event based mode as well as in the timer based mode.


4. I'm getting tired...


5. Case 3:

"Case 3: Event based flag and remain active flag both set.

The transition at A of CP while MODE is true begins a wait for a negative
transition on CPN, and a violation is reported at C on CPN, and it shall also
begin a wait for a positive transition on CP while MODE is true. No such
transition on CP ever takes place after CPN transitions C through H, but no
violations are reported because CP never experiences a positive transition
while MODE is true. Transition I also reports no violation because a positive
transition at I on CP while MODE is true occurs within the 70 time unit skew
limit."

Case 3 actually describes EXACTLY the same value as Case 2.

So what difference does the remain active flag mean here?

I'm not sure whether there is a case where it does make a difference.

Note that in the original proposal, the original version of this flag had
a different role, to determine whether a conditioned timestamp event with
condition false would turn the check dormant or not.


6. The paragraph describing $fullskew in event based mode should be changed
because it says that in this mode, $fullskew is like $skew, which is misleading,
because $skew is unidirectional. And it does not describe the behavior shown
in Case 2, describing when an event is a timestamp and when it is a timecheck
event. The rules are the same as in timer based mode. Case 3 is definitely
not describing a behavior like $skew, which reports multiple violations on
multiple timecheck events.


7. The example for both $fullskew and $timeskew should contain the flags,
such as
$fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, e_b_f, r_a_f);


8. Finally, an easy one: The $skew section says that "$timeskew and $fullskew
shall be used if violation reports are absolutely required". That should be
"should" instead of "shall".

Thank you and good night.

Shalom


Fix
Preliminary proposal, incorporating more corrections and
clarifications, but still does not deal with
remain_active_flag:

In 15.3.3, "$fullskew", CHANGE the text from
text paragraph 3 to the end of the subclause with the following:


"$fullskew is identical to $timeskew except the reference and data events can transition in either order. The first limit is the maximum
time by which the data event can follow the reference event. The second limit is the maximum time by which the reference event can
follow the data event.

The reference event is the timestamp event and the data event is the timecheck event when the reference event precedes the data event.
The data event is the timestamp event and the reference event is the timecheck event when the data event precedes the reference event.

The $fullskew timing check reports a violation only in the following case, where limit is set to limit1 when the reference event
transitions first, and to limit2 when the data event transitions first:

(timecheck time) - (timestamp time) > limit

Simultaneous transitions on the reference and data signals
shall not cause $fullskew to report a timing violation,
even when the skew limit value is zero.
$fullskew shall also not report a violation
if a new timestamp event occurs exactly at the expiration
of the time limit.

The default behavior for $fullskew is timer-based (event based flag not set).
A violation shall be
reported immediately upon elapse of the time limit after the timestamp event if
a timecheck event does not occur in this time, turning the timing check dormant.
However, if a timecheck event does occur within the time limit, then no
violation is reported and the timing check turns dormant immediately.

A second timestamp event occurring within the time limit starts a new
timing window that replaces the first one, with the following exception:
If a false condition
associated with the timestamp event is detected, and the timing check is
active, then the timing check turns dormant.
If the timestamp event has
no condition or has a true condition, and the timing check is dormant,
then the timing check is activated.

A reference event or data event is a timestamp event and starts a new timing
window, unless it is a timecheck event occuring within the time limit after a
preceding timestamp event.

In the timer-based mode, the remain active flag is ignored.

The $fullskew check's default timer-based behavior can be altered to event-based using the event based flag.
In this mode, $fullskew is similar to $skew, in that a violation is reported
not upon elapse of the time limit after the timestamp event (as in timer-based
mode), but rather if a timecheck event occurs after the time limit. Such an
event ends the first timing window and immediately begins a new timing window,
where it acts as the timestamp event of the new window. A timecheck event
within the time limit ends the timing window, turns the timing check dormant,
and no violation is reported.

Example:
$fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, event_based_flag, remain_active_flag);

Case 1: Event based flag not set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at B as soon as
a period of time equal to 50 time units has passed. This resets the check and readies it for the next active transition.

A negative transition on CPN occurs next at C, beginning a wait for a positive transition on CP while MODE is true. At D a time equal to
70 time units has passed without a positive edge on CP while MODE is true, so a violation is reported and the check is again reset to
await the next active transition.

A transition on CPN at E also results in a timing violation, as does the transition at F, because even though CP transitions, MODE is no
longer true. Transitions at G and H also result in timing violations, but not the transition at I, because it is followed by a positive
transition on CP while MODE is true.

Case 2: Event based flag set, remain active flag not set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN
because it occurs beyond the 50 time unit limit. This transition at C also begins a wait of 70 time units for a positive transition on
CP while MODE is true. But for transitions on CPN at C through H there is no positive transition on CP while MODE is true, and so no
timing violations are reported. The transition at I on CPN begins a wait of 70 time units, and this is satisfied by the positive
transition on CP at J while MODE is true.

Case 3: Event based flag and remain active flag both set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN,
and it shall also begin a wait for a positive transition on CP while MODE is true. No such transition on CP ever takes place after CPN
transitions C through H, but no violations are reported because CP never experiences a positive transition while MODE is true.
Transition I also reports no violation because a positive transition at J on CP while MODE is true occurs within the 70 time unit skew
limit."


Also, in 15.3.2, CHANGE

"Simultaneous transitions on the reference and data signals can never cause $timeskew to report a timing violation, even when the skew limit value is zero."

TO

"Simultaneous transitions on the reference and data signals
shall not cause $timeskew to report a timing violation,
even when the skew limit value is zero.
$fullskew shall also not report a violation
if a new timestamp event occurs exactly at the expiration
of the time limit."


Also, in 15.3.1, in the sentence,

"In contrast, the $timeskew and $fullskew checks are timer-based by default, and they shall be used if violation reports are absolutely required and the data event can be very late or even absent altogether."

CHANGE "shall be used" to "should be used".
Audit-Trail
From: Stefen Boyd <stefen@boyd.com>
To: etf-bugs@boyd.com
Cc: yonghao@cadence.com
Subject: Re: errata/659: errata $fullskew bugs
Date: Tue, 12 Apr 2005 14:39:44 -0700

Forwarding since Yonghau wasn't whitelisted yet.

Stefen

-----------------

In general, I agree with the updates. Several comments follow.

Regards,

-Yonghao


On Mon, 2005-04-11 at 16:18, Shalom.Bresticker@freescale.com wrote:
> In 15.3.3 $fullskew:
>
> 1. The LRM says,
>
> "The default behavior for $fullskew is timer-based. Violations shall be
reported
> immediately upon an elapse of time after the timestamp event equal to
the limit.
> It then becomes dormant and reports no more violations, even in response to
> timecheck events, until after the next timestamp event. This check shall
also
> become dormant if it detects a timestamp event when the associated
condition is false."
>
> This needs to change to something like the following:
>
> "The default behavior for $fullskew is timer-based. A violation shall be
> reported immediately upon elapse of the time limit after the timestamp
event if
> a timecheck event does not occur in this time, turning the timing check
dormant.
> However, if a timecheck event does occur within the time limit, then no
> violation is reported and the timing check turns dormant immediately.
>


> If a second timestamp event occurs within the time limit, then a new timing
> check is activated and no violation is reported on the first.
> However, if it detects a conditioned timestamp event when the associated
> condition is false, then the timing check turns dormant.

===> It is possible that the first timing check is already dormant.
Consider the following sequence of events, all within time limit:
timestamp event, timecheck event, timestamp event. The timecheck event
will turn the first timing check dormant. The other thing, even if the
tcheck is dormant already, if a false condition is detected for the
second time stamp event, the (dormant) timing check still need be
updated so that it starts with the new timestamp event. This is
important since the last stamp event will be a reference to determine if
a following ref/data event should start a new timing check or not (see
Shalom's original commment below)

Also I think the term "timing check" in above context is a bit
confusing, since it also refers to the whole timing check task. In other
subsections of this chapter, "timing window" has been used in similar
context. Following is an attempt to rephrase:

"A second timestamp event occurring within the time limit starts a new
timing window that replaces the first one. If the timestamp event has
no condition or has a true condition, and the timing check is dormant,
then the timing check is activated. However, if a false condition
associated with the timestamp event is detected, and the timing check is
active, then the timing check turns dormant."



PS. The "within" in above statement has potential ambiguity. What
happens if the second timestamp event occurs at the time of (first
timestamp event + time limit)? This is the same type of ambiguity
Shalmom mentioned in the last review meeting. The LRM doesn't address
it. But based on the cases of $skew analogous to this, it probably
should be considered inclusive. i.e. the second timestamp event occuring
at the boundary time should start a new timing window to replace the
first one, hence no violation will be reported.



>
> A reference event or data event is a timestamp event and activates a new
timing
> check, unless it is a timecheck event occuring within the time limit after a
> preceding timestamp event.
>

===> It should be noted that, the "within" in above statement is
inclusive. This is made clear by the LRM (see the end of p252 and
beginning of p253). Specifically, if the timecheck event happens at the
time of (timestamp event + time limit), then it will not be treated as a
new timestamp event.

In relation to my previous change, the above can be rephrased as below:

"A reference event or data event is a timestamp event and starts a new
timing window, unless it is a timecheck event occurring within the time
limit after a preceding timestamp event."


> In the timer-based mode, the remain active flag is ignored."
>
>
> 2. Case 1 says,
>
> " Case 1: Event based flag and remain active flag not set.
>
> The transition at A of CP while MODE is true begins a wait for a negative
> transition on CPN, and a violation is reported at B as soon as a period
of time
> equal to 50 time units has passed. This resets the check and readies it
for the
> next active transition.
>
> A negative transition on CPN occurs next at C, beginning a wait for a
positive
> transition on CP while MODE is true. At D a time equal to 70 time units has
> passed without a positive edge on CP while MODE is true, so a violation is
> reported and the check is again reset to await the next active transition.
>
> A transition on CPN at E also results in a timing violation, as does the
> transition at F, because even though CP transitions, MODE is no longer
true.
> Transitions at G and H also result in timing violations, but not the
transition
> at I, because it is followed by a positive transition on CP while MODE
is true."
>
> Reminder: we decided that Case 1 should be simply, "Event based flag not
set."
>
> The first paragraph says,
>
> "a violation is reported at B as soon as a period of time equal to 50
time units has passed."
>
> However, the intent is that 50 timepoints passed WITHOUT a negedge in CPN.
> But in the figure, we clearly see that there IS a negedge on CPN before B.
> So the figure does not correct show the intended case.
> The figure should be redrawn so that there is no negedge on CPN before B.
>
> Next, it says,
>
> "A negative transition on CPN occurs next at C". As mentioned above,
> this should appear in the diagram AFTER B. The arrows and vertical lines
> showing the time between C and D need to move to the right as well.
>
> Finally, it ends with
>
> "Transitions at G and H also result in timing violations, but not the
transition at I, because it is followed by a positive transition on CP
while MODE is true."
>
> That positive transition on CP is J. In the current diagram, J is more than
> 70 timepoints after I. It should be within that time.
>
> Simply moving the CP waveform a little to the right might fix all of these.
>


====> I have updated the diagram to be visually correct, and to reflect
this description.


>
> 3. Case 2 is:
>
> "Case 2: Event based flag set, remain active flag not set.
>
> The transition at A of CP while MODE is true begins a wait for a negative
> transition on CPN, and a violation is reported at C on CPN because it
occurs
> beyond the 50 time unit limit. This transition at C also begins a wait
of 70
> time units for a positive transition on CP while MODE is true. But for
> transitions on CPN at B through H there is no positive transition on CP
while
> MODE is true, and so no timing violations are reported. The transition
at I on
> CPN begins a wait of 70 time units, and this is satisfied by the positive
> transition on CP at J while MODE is true."
>
> The same comments that C should be after B and J after I hold here too.
>
> The sentence "But for transitions on CPN at B through H" should be
> "But for transitions on CPN at C through H".
> (The history of this is that in the 1364-2001 draft, it was originally
> written "This transition at B also begins a wait of 70 time units.."
> and one reviewer noticed that it should be C, but the second place where
> B should also be C was missed.)
>
> Note that the same rules about when a new timing check is activated hold
> in the event based mode as well as in the timer based mode.
>
>
> 4. I'm getting tired...
>
>
> 5. Case 3:
>
> "Case 3: Event based flag and remain active flag both set.
>
> The transition at A of CP while MODE is true begins a wait for a negative
> transition on CPN, and a violation is reported at C on CPN, and it shall
also
> begin a wait for a positive transition on CP while MODE is true. No such
> transition on CP ever takes place after CPN transitions C through H, but no
> violations are reported because CP never experiences a positive transition
> while MODE is true. Transition I also reports no violation because a
positive
> transition at I on CP while MODE is true occurs within the 70 time unit
skew
> limit."
>
> Case 3 actually describes EXACTLY the same value as Case 2.
>
> So what difference does the remain active flag mean here?
>
> I'm not sure whether there is a case where it does make a difference.
>
> Note that in the original proposal, the original version of this flag had
> a different role, to determine whether a conditioned timestamp event with
> condition false would turn the check dormant or not.
>
>


> 6. The paragraph describing $fullskew in event based mode should be changed
> because it says that in this mode, $fullskew is like $skew, which is
misleading,
> because $skew is unidirectional. And it does not describe the behavior shown
> in Case 2, describing when an event is a timestamp and when it is a
timecheck
> event. The rules are the same as in timer based mode. Case 3 is definitely
> not describing a behavior like $skew, which reports multiple violations on
> multiple timecheck events.
>

===> I agree. The behavior of $fullskew in event mode is a new one that
$skew doesn't have, and the second sentence of this paragraph need be
fixed. Aslo in the last sentence of the same paragraph, "$timeskew"
should be "$fullskew", and the rest of the sentence need also be
updated.


>
> 7. The example for both $fullskew and $timeskew should contain the flags,
> such as
> $fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, e_b_f, r_a_f);
>
>
> 8. Finally, an easy one: The $skew section says that "$timeskew and
$fullskew
> shall be used if violation reports are absolutely required". That should be
> "should" instead of "shall".
>
> Thank you and good night.
>
> Shalom
>
>
>

From: Shalom.Bresticker@freescale.com
To: yonghao@cadence.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/659: errata $fullskew bugs
Date: Wed, 13 Apr 2005 10:02:35 +0300 (IDT)

Hi, Yonghao.

My responses:


> In general, I agree with the updates. Several comments follow.
>
> Regards,
>
> -Yonghao
>
>
> On Mon, 2005-04-11 at 16:18, Shalom.Bresticker@freescale.com wrote:
> > In 15.3.3 $fullskew:
> >
> > 1. The LRM says,
> >
> > "The default behavior for $fullskew is timer-based. Violations shall be
> reported
> > immediately upon an elapse of time after the timestamp event equal to
> the limit.
> > It then becomes dormant and reports no more violations, even in response to
> > timecheck events, until after the next timestamp event. This check shall
> also
> > become dormant if it detects a timestamp event when the associated
> condition is false."
> >
> > This needs to change to something like the following:
> >
> > "The default behavior for $fullskew is timer-based. A violation shall be
> > reported immediately upon elapse of the time limit after the timestamp
> event if
> > a timecheck event does not occur in this time, turning the timing check
> dormant.
> > However, if a timecheck event does occur within the time limit, then no
> > violation is reported and the timing check turns dormant immediately.
> >
>
>
> > If a second timestamp event occurs within the time limit, then a new timing
> > check is activated and no violation is reported on the first.
> > However, if it detects a conditioned timestamp event when the associated
> > condition is false, then the timing check turns dormant.
>
> ===> It is possible that the first timing check is already dormant.
> Consider the following sequence of events, all within time limit:
> timestamp event, timecheck event, timestamp event. The timecheck event
> will turn the first timing check dormant.

Yes, this is true of course.
The simplest case is at the beginning of time.
If the first event to occur is a conditioned event with condition FALSE,
then nothing should happen.


> The other thing, even if the
> tcheck is dormant already, if a false condition is detected for the
> second time stamp event, the (dormant) timing check still need be
> updated so that it starts with the new timestamp event. This is
> important since the last stamp event will be a reference to determine if
> a following ref/data event should start a new timing check or not (see
> Shalom's original commment below)

I'm sorry, I did not understand this.
As I understand it, if the timing check is dormant, then it waits for
either a reference event or a data event. If either of these is conditioned,
it is recognized only if the condition is true. If the condition is false,
then it is ignored. The first event to occur with condition TRUE (if it is
conditioned) will be the timestamp event.

As specified in the LRM (and I am not sure that this is what should have
been written, but this is what is there now), conditioned events with
condition FALSE are totally ignored, except in the special case of
$timeskew or $fullskew where a second timestamp event, if it occurs with
condition FALSE, will turn an active timing check dormant.

>
> Also I think the term "timing check" in above context is a bit
> confusing, since it also refers to the whole timing check task. In other
> subsections of this chapter, "timing window" has been used in similar
> context. Following is an attempt to rephrase:

I agree that 'timing check' is ambiguous.
I agree that 'timing check' properly refers to the entire task.
I was looking for a term to describe the action from the time where the
timing check is triggered till it turns dormant again.
I did not 'timing window' in the current LRM.


> "A second timestamp event occurring within the time limit starts a new
> timing window that replaces the first one. If the timestamp event has
> no condition or has a true condition, and the timing check is dormant,
> then the timing check is activated. However, if a false condition
> associated with the timestamp event is detected, and the timing check is
> active, then the timing check turns dormant."

Pretty good.
However, it is a little ambiguous. The 3rd sentence contradicts the 1st.
The 1st sentence says unconditionally that a 2nd timestamp event starts
a new window. The 3rd sentence says that if the condition is false, the
check turns dormant.


> PS. The "within" in above statement has potential ambiguity. What
> happens if the second timestamp event occurs at the time of (first
> timestamp event + time limit)? This is the same type of ambiguity
> Shalmom mentioned in the last review meeting. The LRM doesn't address
> it. But based on the cases of $skew analogous to this, it probably
> should be considered inclusive. i.e. the second timestamp event occuring
> at the boundary time should start a new timing window to replace the
> first one, hence no violation will be reported.

Yes, I think it is the same ambiguity, but I think you meant $timeskew
instead of $skew. I think the LRM should be more clear about this in both
cases.


> > A reference event or data event is a timestamp event and activates a new
> timing
> > check, unless it is a timecheck event occuring within the time limit after a
> > preceding timestamp event.
> >
>
> ===> It should be noted that, the "within" in above statement is
> inclusive. This is made clear by the LRM (see the end of p252 and
> beginning of p253). Specifically, if the timecheck event happens at the
> time of (timestamp event + time limit), then it will not be treated as a
> new timestamp event.

Yes.


> In relation to my previous change, the above can be rephrased as below:
>
> "A reference event or data event is a timestamp event and starts a new
> timing window, unless it is a timecheck event occurring within the time
> limit after a preceding timestamp event."

Very good.

Please don't stop reading here, there are a couple of more comments
through to the end.

> > In the timer-based mode, the remain active flag is ignored."
> >
> >
> > 2. Case 1 says,
> >
> > " Case 1: Event based flag and remain active flag not set.
> >
> > The transition at A of CP while MODE is true begins a wait for a negative
> > transition on CPN, and a violation is reported at B as soon as a period
> of time
> > equal to 50 time units has passed. This resets the check and readies it
> for the
> > next active transition.
> >
> > A negative transition on CPN occurs next at C, beginning a wait for a
> positive
> > transition on CP while MODE is true. At D a time equal to 70 time units has
> > passed without a positive edge on CP while MODE is true, so a violation is
> > reported and the check is again reset to await the next active transition.
> >
> > A transition on CPN at E also results in a timing violation, as does the
> > transition at F, because even though CP transitions, MODE is no longer
> true.
> > Transitions at G and H also result in timing violations, but not the
> transition
> > at I, because it is followed by a positive transition on CP while MODE
> is true."
> >
> > Reminder: we decided that Case 1 should be simply, "Event based flag not
> set."
> >
> > The first paragraph says,
> >
> > "a violation is reported at B as soon as a period of time equal to 50
> time units has passed."
> >
> > However, the intent is that 50 timepoints passed WITHOUT a negedge in CPN.
> > But in the figure, we clearly see that there IS a negedge on CPN before B.
> > So the figure does not correct show the intended case.
> > The figure should be redrawn so that there is no negedge on CPN before B.
> >
> > Next, it says,
> >
> > "A negative transition on CPN occurs next at C". As mentioned above,
> > this should appear in the diagram AFTER B. The arrows and vertical lines
> > showing the time between C and D need to move to the right as well.
> >
> > Finally, it ends with
> >
> > "Transitions at G and H also result in timing violations, but not the
> transition at I, because it is followed by a positive transition on CP
> while MODE is true."
> >
> > That positive transition on CP is J. In the current diagram, J is more than
> > 70 timepoints after I. It should be within that time.
> >
> > Simply moving the CP waveform a little to the right might fix all of these.
> >
>
>
> ====> I have updated the diagram to be visually correct, and to reflect
> this description.
>
>
> >
> > 3. Case 2 is:
> >
> > "Case 2: Event based flag set, remain active flag not set.
> >
> > The transition at A of CP while MODE is true begins a wait for a negative
> > transition on CPN, and a violation is reported at C on CPN because it
> occurs
> > beyond the 50 time unit limit. This transition at C also begins a wait
> of 70
> > time units for a positive transition on CP while MODE is true. But for
> > transitions on CPN at B through H there is no positive transition on CP
> while
> > MODE is true, and so no timing violations are reported. The transition
> at I on
> > CPN begins a wait of 70 time units, and this is satisfied by the positive
> > transition on CP at J while MODE is true."
> >
> > The same comments that C should be after B and J after I hold here too.
> >
> > The sentence "But for transitions on CPN at B through H" should be
> > "But for transitions on CPN at C through H".
> > (The history of this is that in the 1364-2001 draft, it was originally
> > written "This transition at B also begins a wait of 70 time units.."
> > and one reviewer noticed that it should be C, but the second place where
> > B should also be C was missed.)

Need to fix this.


> > Note that the same rules about when a new timing check is activated hold
> > in the event based mode as well as in the timer based mode.

The LRM needs to state that the rules about starting and ending timing windows
apply to the event-based mode as well.


> > 4. I'm getting tired...
> >
> >
> > 5. Case 3:
> >
> > "Case 3: Event based flag and remain active flag both set.
> >
> > The transition at A of CP while MODE is true begins a wait for a negative
> > transition on CPN, and a violation is reported at C on CPN, and it shall
> also
> > begin a wait for a positive transition on CP while MODE is true. No such
> > transition on CP ever takes place after CPN transitions C through H, but no
> > violations are reported because CP never experiences a positive transition
> > while MODE is true. Transition I also reports no violation because a
> positive
> > transition at I on CP while MODE is true occurs within the 70 time unit
> skew
> > limit."
> >
> > Case 3 actually describes EXACTLY the same value as Case 2.
> >
> > So what difference does the remain active flag mean here?
> >
> > I'm not sure whether there is a case where it does make a difference.
> >
> > Note that in the original proposal, the original version of this flag had
> > a different role, to determine whether a conditioned timestamp event with
> > condition false would turn the check dormant or not.

Need to deal with this.


> > 6. The paragraph describing $fullskew in event based mode should be changed
> > because it says that in this mode, $fullskew is like $skew, which is
> misleading,
> > because $skew is unidirectional. And it does not describe the behavior shown
> > in Case 2, describing when an event is a timestamp and when it is a
> timecheck
> > event. The rules are the same as in timer based mode. Case 3 is definitely
> > not describing a behavior like $skew, which reports multiple violations on
> > multiple timecheck events.
> >
>
> ===> I agree. The behavior of $fullskew in event mode is a new one that
> $skew doesn't have, and the second sentence of this paragraph need be
> fixed. Aslo in the last sentence of the same paragraph, "$timeskew"
> should be "$fullskew", and the rest of the sentence need also be
> updated.

Yes.


> > 7. The example for both $fullskew and $timeskew should contain the flags,
> > such as
> > $fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, e_b_f, r_a_f);
> >
> >
> > 8. Finally, an easy one: The $skew section says that "$timeskew and
> $fullskew
> > shall be used if violation reports are absolutely required". That should be
> > "should" instead of "shall".

Need to fix these as well.

We are getting closer. Even if we don't manage to fix everything,
even a partial fix will be significant.

Thanks,
Shalom

--
Shalom.Bresticker @freescale.com Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary

From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc: yonghao@cadence.com, roberts@cadence.com, elkind@cadence.com
Subject: Re: errata/659: $fullskew bugs
Date: Fri, 15 Apr 2005 16:28:41 +0300 (IDT)

In the hope of getting something passed, I submit this preliminary
proposal, which incorporates Yonghao's and my proposed rewordings and
some further edits. It still leaves some issues unresolved, most
notably the role of the remain_active_flag in event-based mode.
As such, it still leaves Case 3 in the example, although it currently
describes exactly the same behavior as Case 2.
The diagram also needs to be replaced with Yonghao's corrected version.

PROPOSAL: In 15.3.3, "$fullskew", CHANGE the text from
text paragraph 3 to the end of the subclause with the following:


$fullskew is identical to $timeskew except the reference and data events can transition in either order. The first limit is the maximum time by which the data event can follow the reference event. The second limit is the maximum time by which the reference event can follow the data event.

The reference event is the timestamp event and the data event is the timecheck event when the reference event precedes the data event. The data event is the timestamp event and the reference event is the timecheck event when the data event precedes the reference event.

The $fullskew timing check reports a violation only in the following case, where limit is set to limit1 when the reference event transitions first, and to limit2 when the data event transitions first:

(timecheck time) - (timestamp time) > limit

Simultaneous transitions on the reference and data signals shall never cause $fullskew to report a timing violation, even when the skew limit value is zero.

The default behavior for $fullskew is timer-based (event based flag not set).
A violation shall be
reported immediately upon elapse of the time limit after the timestamp event if
a timecheck event does not occur in this time, turning the timing check dormant.
However, if a timecheck event does occur within the time limit, then no
violation is reported and the timing check turns dormant immediately.

A second timestamp event occurring within the time limit starts a new
timing window that replaces the first one, with the following exception:
If a false condition
associated with the timestamp event is detected, and the timing check is
active, then the timing check turns dormant.
If the timestamp event has
no condition or has a true condition, and the timing check is dormant,
then the timing check is activated.

A reference event or data event is a timestamp event and starts a new timing
window, unless it is a timecheck event occuring within the time limit after a
preceding timestamp event.

In the timer-based mode, the remain active flag is ignored.

The $fullskew check's default timer-based behavior can be altered to event-based using the event based flag.
In this mode, $fullskew is similar to $skew, in that a violation is reported
not upon elapse of the time limit after the timestamp event (as in timer-based
mode), but rather if a timecheck event occurs after the time limit. Such an
event ends the first timing window and immediately begins a new timing window,
where it acts as the timestamp event of the new window. A timecheck event
within the time limit ends the timing window, turns the timing check dormant,
and no violation is reported.

Example:
$fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, event_based_flag, remain_active_flag);

Case 1: Event based flag not set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at B as soon as a period of time equal to 50 time units has passed. This resets the check and readies it for the next active transition.

A negative transition on CPN occurs next at C, beginning a wait for a positive transition on CP while MODE is true. At D a time equal to 70 time units has passed without a positive edge on CP while MODE is true, so a violation is reported and the check is again reset to await the next active transition.

A transition on CPN at E also results in a timing violation, as does the transition at F, because even though CP transitions, MODE is no longer true. Transitions at G and H also result in timing violations, but not the transition at I, because it is followed by a positive transition on CP while MODE is true.

Case 2: Event based flag set, remain active flag not set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN because it occurs beyond the 50 time unit limit. This transition at C also begins a wait of 70 time units for a positive transition on CP while MODE is true. But for transitions on CPN at C through H there is no positive transition on CP while MODE is true, and so no timing violations are reported. The transition at I on CPN begins a wait of 70 time units, and this is satisfied by the positive transition on CP at J while MODE is true.

Case 3: Event based flag and remain active flag both set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN, and it shall also begin a wait for a positive transition on CP while MODE is true. No such transition on CP ever takes place after CPN transitions C through H, but no violations are reported because CP never experiences a positive transition while MODE is true. Transition I also reports no violation because a positive transition at I on CP while MODE is true occurs within the 70 time unit skew limit.

--
Shalom.Bresticker @freescale.com Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478


From: Yonghao Chen <yonghao@cadence.com>
To: Shalom.Bresticker@freescale.com
Cc: etf-bugs@boyd.com, yonghao@gda.Cadence.COM, roberts@gda.Cadence.COM,
elkind@gda.Cadence.COM
Subject: errata/659: errata $fullskew bugs
Date: Fri, 15 Apr 2005 17:26:43 -0400

Hi Shalom:


Please find following comments.

Regards,

-Yonghao


1. Regarding the role of remain active flag

I reread the original proposal about this flag. As you correctly
pointed out it impacts how a false condition should turns off tcheck,
and following is what Ted Elkind wrote about it:

"How conditions affect timestamp events is an important issue, and
is the motivating factor for the dormant flag"

We can still make sense with this flag if we treat the event based mode
differently as following:

For timer based mode, when a second stamp event occurs with a false
condition, it will turn the tcheck dormant. However, what happens to
event based mode? Do we simply ignore the second stamp event, as is the
case with $skew, or do we turns the tcheck dormant, as with the timer
based mode? I think that should depend on the remain_active_flag. If
this flag is set, then we should just ignore the second stamp event and
leave the tcheck as it is, i.e. active. On the other hand, if the flag
is false, then we turn the tcheck dormant. The net result is that, a
subsequent timing check event outside the limit will report a violation
in the first case, and will not in the second case.

Also, I think this also applied to $timeskew, if it hasn't been
addressed yet.

In following paragraph of page 251:

"The $timeskew check's timer-based behavior can be altered to
event-based using the event based flag. It behaves like the $skew check
when both the event based flag and the remain active flag are set. The
$timeskew check behaves like the $skew check when only the event based
flag is set, except it becomes dormant after reporting the first
violation"

What it doesn't say is, what happens to the stamp event with false
condition? In the timer mode description in the preceding paragraph, it
says that "This check shall also become dormant if it detects a
reference event when its condition is false." I think this should be
true too with event based mode if the remain active flag is false.
Therefore the last sentence in above quote is not accurate. It should be
rephrased like following:

" The $timeskew check behaves like the $skew check when only the event
based flag is set, except it becomes dormant after reporting the first
violation, or having a second stamp event with a false condition. "


2. a question

This one is related to item 1. In your previous mail, you mentioned that

"As specified in the LRM (and I am not sure that this is what should
have
been written, but this is what is there now), conditioned events with
condition FALSE are totally ignored, except in the special case of
$timeskew or $fullskew where a second timestamp event, if it occurs with
condition FALSE, will turn an active timing check dormant."

I couldn't find the above spec in the LRM, maybe I am using an older
version. But as we see in 1), a false conditioned stamp event can turn
off a tcheck only in following conditions: 1) timer based mode, 2) event
based mode with remain active flag false. If the above quoted statement
is true, then the discussion in item 1) will not stand. However, I'd
think other way around and change above statement to reflect the
discussion in item 1).




3. A typo

In the last sentence in your proposal,

"Transition I also reports no violation because a positive transition
at I on CP while MODE is true occurs within the 70 time unit skew
limit."

The "at I on CP" should be read as "at J on CP"


4. Ambiguity

As we have discussed the issue, I think we may be able to address it by
adding something like following to the end of the first paragraph on
page 253:

"Simultaneous transitions on the reference and data signals shall never
cause $fullskew to report a timing violation, even when the skew limit
value is zero. There should be no violation either if a stamp event
happens to occur at the end of a timing window."





On Fri, 2005-04-15 at 09:28, Shalom.Bresticker@freescale.com wrote:
> In the hope of getting something passed, I submit this preliminary
> proposal, which incorporates Yonghao's and my proposed rewordings and
> some further edits. It still leaves some issues unresolved, most
> notably the role of the remain_active_flag in event-based mode.
> As such, it still leaves Case 3 in the example, although it currently
> describes exactly the same behavior as Case 2.
> The diagram also needs to be replaced with Yonghao's corrected version.
>
> PROPOSAL: In 15.3.3, "$fullskew", CHANGE the text from
> text paragraph 3 to the end of the subclause with the following:
>
>
> $fullskew is identical to $timeskew except the reference and data events can transition in either order. The first limit is the maximum time by which the data event can follow the reference event. The second limit is the maximum time by which the reference event can follow the data event.
>
> The reference event is the timestamp event and the data event is the timecheck event when the reference event precedes the data event. The data event is the timestamp event and the reference event is the timecheck event when the data event precedes the reference event.
>
> The $fullskew timing check reports a violation only in the following case, where limit is set to limit1 when the reference event transitions first, and to limit2 when the data event transitions first:
>
> (timecheck time) - (timestamp time) > limit
>
> Simultaneous transitions on the reference and data signals shall never cause $fullskew to report a timing violation, even when the skew limit value is zero.
>
> The default behavior for $fullskew is timer-based (event based flag not set).
> A violation shall be
> reported immediately upon elapse of the time limit after the timestamp event if
> a timecheck event does not occur in this time, turning the timing check dormant.
> However, if a timecheck event does occur within the time limit, then no
> violation is reported and the timing check turns dormant immediately.
>
> A second timestamp event occurring within the time limit starts a new
> timing window that replaces the first one, with the following exception:
> If a false condition
> associated with the timestamp event is detected, and the timing check is
> active, then the timing check turns dormant.
> If the timestamp event has
> no condition or has a true condition, and the timing check is dormant,
> then the timing check is activated.
>
> A reference event or data event is a timestamp event and starts a new timing
> window, unless it is a timecheck event occuring within the time limit after a
> preceding timestamp event.
>
> In the timer-based mode, the remain active flag is ignored.
>
> The $fullskew check's default timer-based behavior can be altered to event-based using the event based flag.
> In this mode, $fullskew is similar to $skew, in that a violation is reported
> not upon elapse of the time limit after the timestamp event (as in timer-based
> mode), but rather if a timecheck event occurs after the time limit. Such an
> event ends the first timing window and immediately begins a new timing window,
> where it acts as the timestamp event of the new window. A timecheck event
> within the time limit ends the timing window, turns the timing check dormant,
> and no violation is reported.
>
> Example:
> $fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, event_based_flag, remain_active_flag);
>
> Case 1: Event based flag not set.
>
> The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at B as soon as a period of time equal to 50 time units has passed. This resets the check and readies it for the next active transition.
>
> A negative transition on CPN occurs next at C, beginning a wait for a positive transition on CP while MODE is true. At D a time equal to 70 time units has passed without a positive edge on CP while MODE is true, so a violation is reported and the check is again reset to await the next active transition.
>
> A transition on CPN at E also results in a timing violation, as does the transition at F, because even though CP transitions, MODE is no longer true. Transitions at G and H also result in timing violations, but not the transition at I, because it is followed by a positive transition on CP while MODE is true.
>
> Case 2: Event based flag set, remain active flag not set.
>
> The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN because it occurs beyond the 50 time unit limit. This transition at C also begins a wait of 70 time units for a positive transition on CP while MODE is true. But for transitions on CPN at C through H there is no positive transition on CP while MODE is true, and so no timing violations are reported. The transition at I on CPN begins a wait of 70 time units, and this is satisfied by the positive transition on CP at J while MODE is true.
>
> Case 3: Event based flag and remain active flag both set.
>
> The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN, and it shall also begin a wait for a positive transition on CP while MODE is true. No such transition on CP ever takes place after CPN transitions C through H, but no violations are reported because CP never experiences a positive transition while MODE is true. Transition I also reports no violation because a positive transition at I on CP while MODE is true occurs within the 70 time unit skew limit.

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/659: errata $fullskew bugs
Date: Fri, 15 Apr 2005 17:32:50 -0400 (EDT)

------------- Begin Forwarded Message -------------

Subject: errata/659: errata $fullskew bugs
From: Yonghao Chen <yonghao>
To: Shalom.Bresticker@freescale.com
Cc: etf-bugs@boyd.com, yonghao, roberts, elkind
Mime-Version: 1.0
Date: Fri, 15 Apr 2005 17:26:43 -0400
X-UIDL: TW(!!84U"!bn_"!#\U!!
Content-Transfer-Encoding: 7bit


Hi Shalom:


Please find following comments.

Regards,

-Yonghao


1. Regarding the role of remain active flag

I reread the original proposal about this flag. As you correctly
pointed out it impacts how a false condition should turns off tcheck,
and following is what Ted Elkind wrote about it:

"How conditions affect timestamp events is an important issue, and
is the motivating factor for the dormant flag"

We can still make sense with this flag if we treat the event based mode
differently as following:

For timer based mode, when a second stamp event occurs with a false
condition, it will turn the tcheck dormant. However, what happens to
event based mode? Do we simply ignore the second stamp event, as is the
case with $skew, or do we turns the tcheck dormant, as with the timer
based mode? I think that should depend on the remain_active_flag. If
this flag is set, then we should just ignore the second stamp event and
leave the tcheck as it is, i.e. active. On the other hand, if the flag
is false, then we turn the tcheck dormant. The net result is that, a
subsequent timing check event outside the limit will report a violation
in the first case, and will not in the second case.

Also, I think this also applied to $timeskew, if it hasn't been
addressed yet.

In following paragraph of page 251:

"The $timeskew check's timer-based behavior can be altered to
event-based using the event based flag. It behaves like the $skew check
when both the event based flag and the remain active flag are set. The
$timeskew check behaves like the $skew check when only the event based
flag is set, except it becomes dormant after reporting the first
violation"

What it doesn't say is, what happens to the stamp event with false
condition? In the timer mode description in the preceding paragraph, it
says that "This check shall also become dormant if it detects a
reference event when its condition is false." I think this should be
true too with event based mode if the remain active flag is false.
Therefore the last sentence in above quote is not accurate. It should be
rephrased like following:

" The $timeskew check behaves like the $skew check when only the event
based flag is set, except it becomes dormant after reporting the first
violation, or having a second stamp event with a false condition. "


2. a question

This one is related to item 1. In your previous mail, you mentioned that

"As specified in the LRM (and I am not sure that this is what should
have
been written, but this is what is there now), conditioned events with
condition FALSE are totally ignored, except in the special case of
$timeskew or $fullskew where a second timestamp event, if it occurs with
condition FALSE, will turn an active timing check dormant."

I couldn't find the above spec in the LRM, maybe I am using an older
version. But as we see in 1), a false conditioned stamp event can turn
off a tcheck only in following conditions: 1) timer based mode, 2) event
based mode with remain active flag false. If the above quoted statement
is true, then the discussion in item 1) will not stand. However, I'd
think other way around and change above statement to reflect the
discussion in item 1).




3. A typo

In the last sentence in your proposal,

"Transition I also reports no violation because a positive transition
at I on CP while MODE is true occurs within the 70 time unit skew
limit."

The "at I on CP" should be read as "at J on CP"


4. Ambiguity

As we have discussed the issue, I think we may be able to address it by
adding something like following to the end of the first paragraph on
page 253:

"Simultaneous transitions on the reference and data signals shall never
cause $fullskew to report a timing violation, even when the skew limit
value is zero. There should be no violation either if a stamp event
happens to occur at the end of a timing window."





On Fri, 2005-04-15 at 09:28, Shalom.Bresticker@freescale.com wrote:
> In the hope of getting something passed, I submit this preliminary
> proposal, which incorporates Yonghao's and my proposed rewordings and
> some further edits. It still leaves some issues unresolved, most
> notably the role of the remain_active_flag in event-based mode.
> As such, it still leaves Case 3 in the example, although it currently
> describes exactly the same behavior as Case 2.
> The diagram also needs to be replaced with Yonghao's corrected version.
>
> PROPOSAL: In 15.3.3, "$fullskew", CHANGE the text from
> text paragraph 3 to the end of the subclause with the following:
>
>
> $fullskew is identical to $timeskew except the reference and data events can
transition in either order. The first limit is the maximum time by which the
data event can follow the reference event. The second limit is the maximum time
by which the reference event can follow the data event.
>
> The reference event is the timestamp event and the data event is the timecheck
event when the reference event precedes the data event. The data event is the
timestamp event and the reference event is the timecheck event when the data
event precedes the reference event.
>
> The $fullskew timing check reports a violation only in the following case,
where limit is set to limit1 when the reference event transitions first, and to
limit2 when the data event transitions first:
>
> (timecheck time) - (timestamp time) > limit
>
> Simultaneous transitions on the reference and data signals shall never cause
$fullskew to report a timing violation, even when the skew limit value is zero.
>
> The default behavior for $fullskew is timer-based (event based flag not set).
> A violation shall be
> reported immediately upon elapse of the time limit after the timestamp event
if
> a timecheck event does not occur in this time, turning the timing check
dormant.
> However, if a timecheck event does occur within the time limit, then no
> violation is reported and the timing check turns dormant immediately.
>
> A second timestamp event occurring within the time limit starts a new
> timing window that replaces the first one, with the following exception:
> If a false condition
> associated with the timestamp event is detected, and the timing check is
> active, then the timing check turns dormant.
> If the timestamp event has
> no condition or has a true condition, and the timing check is dormant,
> then the timing check is activated.
>
> A reference event or data event is a timestamp event and starts a new timing
> window, unless it is a timecheck event occuring within the time limit after a
> preceding timestamp event.
>
> In the timer-based mode, the remain active flag is ignored.
>
> The $fullskew check's default timer-based behavior can be altered to
event-based using the event based flag.
> In this mode, $fullskew is similar to $skew, in that a violation is reported
> not upon elapse of the time limit after the timestamp event (as in timer-based
> mode), but rather if a timecheck event occurs after the time limit. Such an
> event ends the first timing window and immediately begins a new timing window,
> where it acts as the timestamp event of the new window. A timecheck event
> within the time limit ends the timing window, turns the timing check dormant,
> and no violation is reported.
>
> Example:
> $fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, event_based_flag,
remain_active_flag);
>
> Case 1: Event based flag not set.
>
> The transition at A of CP while MODE is true begins a wait for a negative
transition on CPN, and a violation is reported at B as soon as a period of time
equal to 50 time units has passed. This resets the check and readies it for the
next active transition.
>
> A negative transition on CPN occurs next at C, beginning a wait for a positive
transition on CP while MODE is true. At D a time equal to 70 time units has
passed without a positive edge on CP while MODE is true, so a violation is
reported and the check is again reset to await the next active transition.
>
> A transition on CPN at E also results in a timing violation, as does the
transition at F, because even though CP transitions, MODE is no longer true.
Transitions at G and H also result in timing violations, but not the transition
at I, because it is followed by a positive transition on CP while MODE is true.
>
> Case 2: Event based flag set, remain active flag not set.
>
> The transition at A of CP while MODE is true begins a wait for a negative
transition on CPN, and a violation is reported at C on CPN because it occurs
beyond the 50 time unit limit. This transition at C also begins a wait of 70
time units for a positive transition on CP while MODE is true. But for
transitions on CPN at C through H there is no positive transition on CP while
MODE is true, and so no timing violations are reported. The transition at I on
CPN begins a wait of 70 time units, and this is satisfied by the positive
transition on CP at J while MODE is true.
>
> Case 3: Event based flag and remain active flag both set.
>
> The transition at A of CP while MODE is true begins a wait for a negative
transition on CPN, and a violation is reported at C on CPN, and it shall also
begin a wait for a positive transition on CP while MODE is true. No such
transition on CP ever takes place after CPN transitions C through H, but no
violations are reported because CP never experiences a positive transition while
MODE is true. Transition I also reports no violation because a positive
transition at I on CP while MODE is true occurs within the 70 time unit skew
limit.


------------- End Forwarded Message -------------


Steven Sharp
sharp@cadence.com


Fix replaced by Shalom.Bresticker@freescale.com on Sun Apr 17 06:11:02 2005
Preliminary proposal, incorporating more corrections and
clarifications, but still does not deal with
remain_active_flag:

In 15.3.3, "$fullskew", CHANGE the text from
text paragraph 3 to the end of the subclause with the following:


"$fullskew is identical to $timeskew except the reference and data events can transition in either order. The first limit is the maximum
time by which the data event can follow the reference event. The second limit is the maximum time by which the reference event can
follow the data event.

The reference event is the timestamp event and the data event is the timecheck event when the reference event precedes the data event.
The data event is the timestamp event and the reference event is the timecheck event when the data event precedes the reference event.

The $fullskew timing check reports a violation only in the following case, where limit is set to limit1 when the reference event
transitions first, and to limit2 when the data event transitions first:

(timecheck time) - (timestamp time) > limit

Simultaneous transitions on the reference and data signals
shall not cause $fullskew to report a timing violation,
even when the skew limit value is zero.
$fullskew shall also not report a violation
if a new timestamp event occurs exactly at the expiration
of the time limit.

The default behavior for $fullskew is timer-based (event based flag not set).
A violation shall be
reported immediately upon elapse of the time limit after the timestamp event if
a timecheck event does not occur in this time, turning the timing check dormant.
However, if a timecheck event does occur within the time limit, then no
violation is reported and the timing check turns dormant immediately.

A second timestamp event occurring within the time limit starts a new
timing window that replaces the first one, with the following exception:
If a false condition
associated with the timestamp event is detected, and the timing check is
active, then the timing check turns dormant.
If the timestamp event has
no condition or has a true condition, and the timing check is dormant,
then the timing check is activated.

A reference event or data event is a timestamp event and starts a new timing
window, unless it is a timecheck event occuring within the time limit after a
preceding timestamp event.

In the timer-based mode, the remain active flag is ignored.

The $fullskew check's default timer-based behavior can be altered to event-based using the event based flag.
In this mode, $fullskew is similar to $skew, in that a violation is reported
not upon elapse of the time limit after the timestamp event (as in timer-based
mode), but rather if a timecheck event occurs after the time limit. Such an
event ends the first timing window and immediately begins a new timing window,
where it acts as the timestamp event of the new window. A timecheck event
within the time limit ends the timing window, turns the timing check dormant,
and no violation is reported.

Example:
$fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, event_based_flag, remain_active_flag);

Case 1: Event based flag not set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at B as soon as
a period of time equal to 50 time units has passed. This resets the check and readies it for the next active transition.

A negative transition on CPN occurs next at C, beginning a wait for a positive transition on CP while MODE is true. At D a time equal to
70 time units has passed without a positive edge on CP while MODE is true, so a violation is reported and the check is again reset to
await the next active transition.

A transition on CPN at E also results in a timing violation, as does the transition at F, because even though CP transitions, MODE is no
longer true. Transitions at G and H also result in timing violations, but not the transition at I, because it is followed by a positive
transition on CP while MODE is true.

Case 2: Event based flag set, remain active flag not set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN
because it occurs beyond the 50 time unit limit. This transition at C also begins a wait of 70 time units for a positive transition on
CP while MODE is true. But for transitions on CPN at C through H there is no positive transition on CP while MODE is true, and so no
timing violations are reported. The transition at I on CPN begins a wait of 70 time units, and this is satisfied by the positive
transition on CP at J while MODE is true.

Case 3: Event based flag and remain active flag both set.

The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN,
and it shall also begin a wait for a positive transition on CP while MODE is true. No such transition on CP ever takes place after CPN
transitions C through H, but no violations are reported because CP never experiences a positive transition while MODE is true.
Transition I also reports no violation because a positive transition at J on CP while MODE is true occurs within the 70 time unit skew
limit."


Also, in 15.3.2, CHANGE

"Simultaneous transitions on the reference and data signals can never cause $timeskew to report a timing violation, even when the skew limit value is zero."

TO

"Simultaneous transitions on the reference and data signals
shall not cause $timeskew to report a timing violation,
even when the skew limit value is zero.
$fullskew shall also not report a violation
if a new timestamp event occurs exactly at the expiration
of the time limit."


Also, in 15.3.1, in the sentence,

"In contrast, the $timeskew and $fullskew checks are timer-based by default, and they shall be used if violation reports are absolutely required and the data event can be very late or even absent altogether."

CHANGE "shall be used" to "should be used".


From: Shalom.Bresticker@freescale.com
To: Yonghao Chen <yonghao@cadence.com>
Cc: etf-bugs@boyd.com, roberts@cadence.com, elkind@cadence.com
Subject: Re: errata/659: errata $fullskew bugs
Date: Sun, 17 Apr 2005 16:35:41 +0300 (IDT)

Hi,

Regarding #1, I don't object to this change, which is that the
remain_active_flag will determine in event_based_mode whether or not
a timestamp event with condition false will turn the timing check
dormant. But since this is a change from the current LRM and not
clearly an errata fix, it requires consensus.

In that case, remain_active_flag could have the same role in
timer_based_mode. Currently, in timer_based_mode, such a timestamp
event will always turn the timecheck dormant, but it could be
made conditional upon remain_active_flag = 0. That would also be
a change from the current LRM, but it would also be the intention
of the original $timeskew and $fullskew proposals, I think.


Regarding #2, I was referring to the statement in 15.1 that
"Reference events and data events shall only be detected by timing checks when their associated conditions are true."

But I did not intend to say that timestamp events with false condition
turn $timeskew and $fullskew dormant under all conditions. I was just
writing in brief.

However, you write that it turns the check dormant for event based mode
with remain active flag false. Again, the current LRM does not say this,
at least not clearly. But again, I do not object to this change.


3. You are correct, I forgot this. I will modify the proposal.


4. I will modify the proposal to incorporate this idea.


Thanks,
Shalom


On Fri, 15 Apr 2005, Yonghao Chen wrote:

> 1. Regarding the role of remain active flag
>
> I reread the original proposal about this flag. As you correctly
> pointed out it impacts how a false condition should turns off tcheck,
> and following is what Ted Elkind wrote about it:
>
> "How conditions affect timestamp events is an important issue, and
> is the motivating factor for the dormant flag"
>
> We can still make sense with this flag if we treat the event based mode
> differently as following:
>
> For timer based mode, when a second stamp event occurs with a false
> condition, it will turn the tcheck dormant. However, what happens to
> event based mode? Do we simply ignore the second stamp event, as is the
> case with $skew, or do we turns the tcheck dormant, as with the timer
> based mode? I think that should depend on the remain_active_flag. If
> this flag is set, then we should just ignore the second stamp event and
> leave the tcheck as it is, i.e. active. On the other hand, if the flag
> is false, then we turn the tcheck dormant. The net result is that, a
> subsequent timing check event outside the limit will report a violation
> in the first case, and will not in the second case.
>
> Also, I think this also applied to $timeskew, if it hasn't been
> addressed yet.
>
> In following paragraph of page 251:
>
> "The $timeskew check's timer-based behavior can be altered to
> event-based using the event based flag. It behaves like the $skew check
> when both the event based flag and the remain active flag are set. The
> $timeskew check behaves like the $skew check when only the event based
> flag is set, except it becomes dormant after reporting the first
> violation"
>
> What it doesn't say is, what happens to the stamp event with false
> condition? In the timer mode description in the preceding paragraph, it
> says that "This check shall also become dormant if it detects a
> reference event when its condition is false." I think this should be
> true too with event based mode if the remain active flag is false.
> Therefore the last sentence in above quote is not accurate. It should be
> rephrased like following:
>
> " The $timeskew check behaves like the $skew check when only the event
> based flag is set, except it becomes dormant after reporting the first
> violation, or having a second stamp event with a false condition. "
>
>
> 2. a question
>
> This one is related to item 1. In your previous mail, you mentioned that
>
> "As specified in the LRM (and I am not sure that this is what should
> have
> been written, but this is what is there now), conditioned events with
> condition FALSE are totally ignored, except in the special case of
> $timeskew or $fullskew where a second timestamp event, if it occurs with
> condition FALSE, will turn an active timing check dormant."
>
> I couldn't find the above spec in the LRM, maybe I am using an older
> version. But as we see in 1), a false conditioned stamp event can turn
> off a tcheck only in following conditions: 1) timer based mode, 2) event
> based mode with remain active flag false. If the above quoted statement
> is true, then the discussion in item 1) will not stand. However, I'd
> think other way around and change above statement to reflect the
> discussion in item 1).
>
>
>
>
> 3. A typo
>
> In the last sentence in your proposal,
>
> "Transition I also reports no violation because a positive transition
> at I on CP while MODE is true occurs within the 70 time unit skew
> limit."
>
> The "at I on CP" should be read as "at J on CP"
>
>
> 4. Ambiguity
>
> As we have discussed the issue, I think we may be able to address it by
> adding something like following to the end of the first paragraph on
> page 253:
>
> "Simultaneous transitions on the reference and data signals shall never
> cause $fullskew to report a timing violation, even when the skew limit
> value is zero. There should be no violation either if a stamp event
> happens to occur at the end of a timing window."
>
>
>
>
>
> On Fri, 2005-04-15 at 09:28, Shalom.Bresticker@freescale.com wrote:
> > In the hope of getting something passed, I submit this preliminary
> > proposal, which incorporates Yonghao's and my proposed rewordings and
> > some further edits. It still leaves some issues unresolved, most
> > notably the role of the remain_active_flag in event-based mode.
> > As such, it still leaves Case 3 in the example, although it currently
> > describes exactly the same behavior as Case 2.
> > The diagram also needs to be replaced with Yonghao's corrected version.
> >
> > PROPOSAL: In 15.3.3, "$fullskew", CHANGE the text from
> > text paragraph 3 to the end of the subclause with the following:
> >
> >
> > $fullskew is identical to $timeskew except the reference and data events can transition in either order. The first limit is the maximum time by which the data event can follow the reference event. The second limit is the maximum time by which the reference event can follow the data event.
> >
> > The reference event is the timestamp event and the data event is the timecheck event when the reference event precedes the data event. The data event is the timestamp event and the reference event is the timecheck event when the data event precedes the reference event.
> >
> > The $fullskew timing check reports a violation only in the following case, where limit is set to limit1 when the reference event transitions first, and to limit2 when the data event transitions first:
> >
> > (timecheck time) - (timestamp time) > limit
> >
> > Simultaneous transitions on the reference and data signals shall never cause $fullskew to report a timing violation, even when the skew limit value is zero.
> >
> > The default behavior for $fullskew is timer-based (event based flag not set).
> > A violation shall be
> > reported immediately upon elapse of the time limit after the timestamp event if
> > a timecheck event does not occur in this time, turning the timing check dormant.
> > However, if a timecheck event does occur within the time limit, then no
> > violation is reported and the timing check turns dormant immediately.
> >
> > A second timestamp event occurring within the time limit starts a new
> > timing window that replaces the first one, with the following exception:
> > If a false condition
> > associated with the timestamp event is detected, and the timing check is
> > active, then the timing check turns dormant.
> > If the timestamp event has
> > no condition or has a true condition, and the timing check is dormant,
> > then the timing check is activated.
> >
> > A reference event or data event is a timestamp event and starts a new timing
> > window, unless it is a timecheck event occuring within the time limit after a
> > preceding timestamp event.
> >
> > In the timer-based mode, the remain active flag is ignored.
> >
> > The $fullskew check's default timer-based behavior can be altered to event-based using the event based flag.
> > In this mode, $fullskew is similar to $skew, in that a violation is reported
> > not upon elapse of the time limit after the timestamp event (as in timer-based
> > mode), but rather if a timecheck event occurs after the time limit. Such an
> > event ends the first timing window and immediately begins a new timing window,
> > where it acts as the timestamp event of the new window. A timecheck event
> > within the time limit ends the timing window, turns the timing check dormant,
> > and no violation is reported.
> >
> > Example:
> > $fullskew (posedge CP &&& MODE, negedge CPN, 50, 70, event_based_flag, remain_active_flag);
> >
> > Case 1: Event based flag not set.
> >
> > The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at B as soon as a period of time equal to 50 time units has passed. This resets the check and readies it for the next active transition.
> >
> > A negative transition on CPN occurs next at C, beginning a wait for a positive transition on CP while MODE is true. At D a time equal to 70 time units has passed without a positive edge on CP while MODE is true, so a violation is reported and the check is again reset to await the next active transition.
> >
> > A transition on CPN at E also results in a timing violation, as does the transition at F, because even though CP transitions, MODE is no longer true. Transitions at G and H also result in timing violations, but not the transition at I, because it is followed by a positive transition on CP while MODE is true.
> >
> > Case 2: Event based flag set, remain active flag not set.
> >
> > The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN because it occurs beyond the 50 time unit limit. This transition at C also begins a wait of 70 time units for a positive transition on CP while MODE is true. But for transitions on CPN at C through H there is no positive transition on CP while MODE is true, and so no timing violations are reported. The transition at I on CPN begins a wait of 70 time units, and this is satisfied by the positive transition on CP at J while MODE is true.
> >
> > Case 3: Event based flag and remain active flag both set.
> >
> > The transition at A of CP while MODE is true begins a wait for a negative transition on CPN, and a violation is reported at C on CPN, and it shall also begin a wait for a positive transition on CP while MODE is true. No such transition on CP ever takes place after CPN transitions C through H, but no violations are reported because CP never experiences a positive transition while MODE is true. Transition I also reports no violation because a positive transition at I on CP while MODE is true occurs within the 70 time unit skew limit.
>

--
Shalom.Bresticker @freescale.com Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary



From: Yonghao Chen <yonghao@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/659: errata $fullskew bugs
Date: Thu, 28 Apr 2005 10:56:34 -0400

--=-hQRf0Q3zVd9WB3ufo6IT
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Included please find the comments from Ted Elkind about $timeskew and
$fullskew. Please note that some of the issues Ted mentioned have
already been addressed.

Thanks,

-Yonghao

--=-hQRf0Q3zVd9WB3ufo6IT
Content-Disposition: inline
Content-Description: Forwarded message - $fullskew Info
Content-Type: message/rfc822

Received: from exmbx01chel.global.cadence.com (exmbx01chel
[158.140.105.230]) by gda.cadence.com (8.9.3/8.8.5) with ESMTP id SAA25631;
Wed, 27 Apr 2005 18:11:48 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: $fullskew Info
Date: Wed, 27 Apr 2005 18:11:47 -0400
Message-ID: <B64C24D6DF7BF040BAF59B923D06180B05FA9503@exmbx01chel.global.cadence.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: $fullskew Info
Thread-Index: AcVLdhqAlPmH2RXiRrSJglp2SzYmMw==
From: "Ted Elkind" <elkind>
To: "Yonghao Chen" <yonghao>
Cc: "John Pierce" <jlp>
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C54B76.1AFB6A05"
X-UIDL: DZ^"!i8*#!$#?!!6YE!!
Status: ROr

This is a multi-part message in MIME format.

------_=_NextPart_001_01C54B76.1AFB6A05
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'm using a pdf of the 1364 2001 LRM for reference. I provide my best
recollection of how we thought about the behavior of $fullskew while
working on this LRM five or six years ago. Perhaps there has been
improved thinking on these matters in the intervening years, but this is
how I recall we saw them at the time.

About $timeskew
---------------

I know $timeskew isn't under discussion, but while refreshing my memory
about the timing checks I noticed a possible erratum in the $timeskew
section. In diagram 46, transition F should occur after transition E,
not simultaneous with it. The CPN transitions afer E should be labeled
G, H, I and J to accord with my rewrite of the descriptions for the four
cases. This is similar to what is already there, but there are
important differences:

Case 1: Event based flag and remain active flag not set.

After the first reference event on CP at A, a violation is reported
at B as soon as 50 time units have passed. No further violations are
reported.

Case 2: Event based flag set, remain active flag not set.

The negative transition on CPN at point C shall cause a timing
violation, turning the $timeskew check dormant, and no further
violations are reported. The second reference event at F occurs while
MODE is false, so the $timeskew check remains dormant. (Note: this is
same behavior as described in LRM, but different reasoning.)

Case 3: Event based flag set, remain active flag set.

The first three negative transitions on CPN at points C, D and E
shall cause timing violations. The second reference event at F occurs
while MODE is false, but because the remain active flag is set the
$timeskew check remains active and so additional violations are reported
at G, H, I and J. In other words, all CPN transitions cause violations.
(Note: this is different behavior than described in the LRM.)

Case 4: Event based flag not set, remain active flag set. (Note: this
heading is different from the LRM.)

After the first reference event on CP at A, a violation is reported
at B as soon as 50 time units have passed. This is the same behavior as
Case 1 because the remain active flag has no effect for the waveform in
Figure 46. (Note: this is different behavior than described in the LRM.)

In order to provide an example of the effect of the event based flag not
being set while the remain active flag is set, the CP signal would have
to experience a positive transition while MODE is true, then have MODE
immediately go false, then have CP transition to 0 and back to 1, all
before time B. The remain active flag would cause the check to remain
active, and there would be a violation at time B.

About $fullskew
---------------

In the $fullskew section in figure 47 on page 254, the waveform for CPN
and the 70 unit time periods aligned with it should be shifted to the
right. The CPN waveform should be in roughly the same position relative
to the CP waveform as it is in figure 46. I've attached a corrected
version of the figure as a jpeg file.

The number of variables affecting $fullskew (two transition events which
can occur in either order, possibly a condition on each, with possibly
asymetric skew times and two flags affecting behavior) creates
sufficient complexity that there is more than one way to define
"correct" behavior. I can argue for my interpretation, but I don't
think I could ever offer sufficient justification to prove it "correct."

1. The "remain active" flag was intended to have two effects:

a) Do not make the check dormant after the first transition of the
timecheck event causes a violation, but rather keep reporting further
transitions of the timecheck event as violations. b) Do not make the
check dormant after a transition of the timestamp event while its
condition is false, but rather continue checking for violations.

Both these effects are possible in "event based", but only (b) makes
sense in "timer based" mode. In my view, the $timeskew check
implementation in NC-Verilog is incorrect because it goes dormant when a
transition occurs while the condition is false but the "remain active"
flag is set.

2. The descriptions for "Case 1" and "Case 2" interpret the effect of
the MODE condition on CP differently. "Case 1" says that timecheck
events that occur while the timecheck condition is false are interpreted
as missing timecheck events, and so it says the transition of CPN at F
received a violation because although CP transitioned in time, the
condition associated with CP (MODE) is false.

But "Case 2" says that for transitions E through H (it actually says "B
through H", but it really means "E through H") there are no positive
transitions on CP while MODE is true, and so no violations are reported.

"Case 2" is consistent with the behavior of the $skew and $timeskew
checks and is correct. The description for "Case 1" should be modified
appropriately.

3. Does the remain active flag have any impact? If I described a "Case
4" where the event based flag is not set but the remain active flag is
set, the behavior would be identical to "Case 1". But that is only
because the waveform in Figure 47 does not bring out the difference.
Just as I described for $timeskew, if CP were to quickly transition a
second time while MODE was false before B, then this would bring out the
difference.

That's all I have. Hope this is helpful.

--Ted


------_=_NextPart_001_01C54B76.1AFB6A05
Content-Type: image/jpeg; name="LRM1364-2001-Figure47.jpg"
Content-Description: LRM1364-2001-Figure47.jpg
Content-Disposition: attachment; filename="LRM1364-2001-Figure47.jpg"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAJuApEDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3r7Lb
/wDPCL/vgUfZbf8A54Rf98CpaKAIvstv/wA8Iv8AvgUfZbf/AJ4Rf98CpaKAIvstv/zwi/74FH2W
3/54Rf8AfAqWigCL7Lb/APPCL/vgUfZbf/nhF/3wKlooAi+y2/8Azwi/74FH2W3/AOeEX/fAqWig
CL7Lb/8APCL/AL4FH2W3/wCeEX/fAqWigCL7Lb/88Iv++BR9lt/+eEX/AHwKlooAi+y2/wDzwi/7
4FH2W3/54Rf98CpaKAIvstv/AM8Iv++BR9lt/wDnhF/3wKlooAi+y2//ADwi/wC+BR9lt/8AnhF/
3wKlooAi+y2//PCL/vgUfZbf/nhF/wB8CpaKAIvstv8A88Iv++BR9lt/+eEX/fAqWigCL7Lb/wDP
CL/vgUfZbf8A54Rf98CpaKAIvstv/wA8Iv8AvgUfZbf/AJ4Rf98CpaKAIvstv/zwi/74FH2W3/54
Rf8AfAqWigCL7Lb/APPCL/vgUfZbf/nhF/3wKlooAi+y2/8Azwi/74FH2W3/AOeEX/fAqWigCL7L
b/8APCL/AL4FH2W3/wCeEX/fAqWigCL7Lb/88Iv++BR9lt/+eEX/AHwKlooAi+y2/wDzwi/74FH2
W3/54Rf98CpaKAIvstv/AM8Iv++BR9lt/wDnhF/3wKlooAi+y2//ADwi/wC+BR9lt/8AnhF/3wKl
ooAi+y2//PCL/vgUfZbf/nhF/wB8CpaKAIvstv8A88Iv++BR9lt/+eEX/fAqWigCL7Lb/wDPCL/v
gUfZbf8A54Rf98CpaKAIvstv/wA8Iv8AvgUfZbf/AJ4Rf98CpaKAIvstv/zwi/74FH2W3/54Rf8A
fAqWigCL7Lb/APPCL/vgUfZbf/nhF/3wKlooAi+y2/8Azwi/74FH2W3/AOeEX/fAqWigCL7Lb/8A
PCL/AL4FH2W3/wCeEX/fAqWigCL7Lb/88Iv++BR9lt/+eEX/AHwKlooAi+y2/wDzwi/74FH2W3/5
4Rf98CpaKAIvstv/AM8Iv++BR9lt/wDnhF/3wKlooAi+y2//ADwi/wC+BR9lt/8AnhF/3wKlooAi
+y2//PCL/vgUfZbf/nhF/wB8CpaKAIvstv8A88Iv++BR9lt/+eEX/fAqWigCL7Lb/wDPCL/vgUfZ
bf8A54Rf98CpaKAIvstv/wA8Iv8AvgUfZbf/AJ4Rf98CpaKAIvstv/zwi/74FH2W3/54Rf8AfAqW
igCL7Lb/APPCL/vgUfZbf/nhF/3wKlooAi+y2/8Azwi/74FH2W3/AOeEX/fAqWigCL7Lb/8APCL/
AL4FFS0UAFFFFABRRXL+JPiJ4V8I6jHYa5qv2S6kiEyp9nlkyhJAOUUjqp/KgDqKK8//AOF2/Dz/
AKGH/wAkrj/43R/wu34ef9DD/wCSVx/8boA9Aorz/wD4Xb8PP+hh/wDJK4/+N0f8Lt+Hn/Qw/wDk
lcf/ABugD0CivP8A/hdvw8/6GH/ySuP/AI3R/wALt+Hn/Qw/+SVx/wDG6APQKK8//wCF2/Dz/oYf
/JK4/wDjdH/C7fh5/wBDD/5JXH/xugD0CivP/wDhdvw8/wChh/8AJK4/+N0f8Lt+Hn/Qw/8Aklcf
/G6APQKK8/8A+F2/Dz/oYf8AySuP/jdH/C7fh5/0MP8A5JXH/wAboA9Aorz/AP4Xb8PP+hh/8krj
/wCN0f8AC7fh5/0MP/klcf8AxugD0CivP/8Ahdvw8/6GH/ySuP8A43R/wu34ef8AQw/+SVx/8boA
9Aorz/8A4Xb8PP8AoYf/ACSuP/jdH/C7fh5/0MP/AJJXH/xugD0CivP/APhdvw8/6GH/AMkrj/43
R/wu34ef9DD/AOSVx/8AG6APQKK8/wD+F2/Dz/oYf/JK4/8AjdH/AAu34ef9DD/5JXH/AMboA9Ao
rz//AIXb8PP+hh/8krj/AON0f8Lt+Hn/AEMP/klcf/G6APQKK8//AOF2/Dz/AKGH/wAkrj/43R/w
u34ef9DD/wCSVx/8boA9Aorz/wD4Xb8PP+hh/wDJK4/+N0f8Lt+Hn/Qw/wDklcf/ABugD0CivP8A
/hdvw8/6GH/ySuP/AI3R/wALt+Hn/Qw/+SVx/wDG6APQKK8//wCF2/Dz/oYf/JK4/wDjdH/C7fh5
/wBDD/5JXH/xugD0CivP/wDhdvw8/wChh/8AJK4/+N0f8Lt+Hn/Qw/8Aklcf/G6APQKK8/8A+F2/
Dz/oYf8AySuP/jdH/C7fh5/0MP8A5JXH/wAboA9Aorz/AP4Xb8PP+hh/8krj/wCN0f8AC7fh5/0M
P/klcf8AxugD0CivP/8Ahdvw8/6GH/ySuP8A43R/wu34ef8AQw/+SVx/8boA9Aorz/8A4Xb8PP8A
oYf/ACSuP/jdH/C7fh5/0MP/AJJXH/xugD0CivP/APhdvw8/6GH/AMkrj/43R/wu34ef9DD/AOSV
x/8AG6APQKK8/wD+F2/Dz/oYf/JK4/8AjdH/AAu34ef9DD/5JXH/AMboA9Aorz//AIXb8PP+hh/8
krj/AON0f8Lt+Hn/AEMP/klcf/G6APQKK8//AOF2/Dz/AKGH/wAkrj/43R/wu34ef9DD/wCSVx/8
boA9Aorz/wD4Xb8PP+hh/wDJK4/+N0f8Lt+Hn/Qw/wDklcf/ABugD0CivP8A/hdvw8/6GH/ySuP/
AI3R/wALt+Hn/Qw/+SVx/wDG6APQKK8//wCF2/Dz/oYf/JK4/wDjdH/C7fh5/wBDD/5JXH/xugD0
CivP/wDhdvw8/wChh/8AJK4/+N0f8Lt+Hn/Qw/8Aklcf/G6APQKK8/8A+F2/Dz/oYf8AySuP/jdH
/C7fh5/0MP8A5JXH/wAboA9Aorz/AP4Xb8PP+hh/8krj/wCN0f8AC7fh5/0MP/klcf8AxugD0Civ
P/8Ahdvw8/6GH/ySuP8A43R/wu34ef8AQw/+SVx/8boA9Aorz/8A4Xb8PP8AoYf/ACSuP/jdH/C7
fh5/0MP/AJJXH/xugD0CivP/APhdvw8/6GH/AMkrj/43R/wu34ef9DD/AOSVx/8AG6APQKK8/wD+
F2/Dz/oYf/JK4/8AjdH/AAu34ef9DD/5JXH/AMboA9Aorz//AIXb8PP+hh/8krj/AON0f8Lt+Hn/
AEMP/klcf/G6APQKK8//AOF2/Dz/AKGH/wAkrj/43R/wu34ef9DD/wCSVx/8boA9AorH8N+KdG8X
adJf6Hefa7WOUws/lPHhwASMOAejD862KACiiigAooooAKKKKACvF/F9hZ6n+0r4Ws7+0gu7WTSn
3wzxiRGwLkjKng4IB/CvaK8f8Q/8nQ+E/wDsFSf+g3VAHoH/AAgng/8A6FTQ/wDwXQ//ABNH/CCe
D/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10FFAH
P/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//
ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ/
/E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ
/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFT
Q/8AwXQ//E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgn
g/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wg
ng//AKFTQ/8AwXQ//E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQ
Bz//AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P
/wATR/wgng//AKFTQ/8AwXQ//E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0
P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU
0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wCh
U0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAI
J4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8
IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQU
UAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10FFAHP/8ACCeD/wDoVND/APBd
D/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDB
dD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10FFAHP/8ACCeD/wDo
VND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8A
oVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10FFAHP/8A
CCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDwXQ//ABNH
/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8AwXQ//E10
FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A6FTQ/wDw
XQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAc//wAIJ4P/AOhU0P8A8F0P/wATR/wgng//AKFTQ/8A
wXQ//E10FFAHP/8ACCeD/wDoVND/APBdD/8AE0f8IJ4P/wChU0P/AMF0P/xNdBRQBz//AAgng/8A
6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TXQUUAeP/s4/8k81D/sKyf8AoqKvYK8f/Zx/5J5q
H/YVk/8ARUVewUAFFFFABRRRQAUUUUAFeP8AiH/k6Hwn/wBgqT/0G6r2CvH/ABD/AMnQ+E/+wVJ/
6DdUAewUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP8A7OP/ACTzUP8AsKyf+ioq
9grx/wDZx/5J5qH/AGFZP/RUVewUAFFFFABRRRQAUUUUAFeP+If+TofCf/YKk/8AQbqvYK8f8Q/8
nQ+E/wDsFSf+g3VAHsFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHj/7OP/JPNQ/7
Csn/AKKir2CvH/2cf+Seah/2FZP/AEVFXsFABRRRQAUUUUAFFFFABXj/AIh/5Oh8J/8AYKk/9Buq
9grx/wAQ/wDJ0PhP/sFSf+g3VAHsFFFFABRRRQAUVwPi74taP4J1T7Bq2lawXMaSCWCKJ4yrFgvP
mDBJR+D/AHTXc21zDeWkN1buJIZkWSNx0ZSMg/lQBLXm/inRvitd+I7ufw14m0qy0htn2eCeNS6Y
RQ2SYW6tuPU9fwq1q/xc0LR/GEXhh7HVLi+llSGNoI4/Ld2baACzjo2QeOoNdlfapZ6XpsmoalOl
nbRLukeZgAv1wev0oA8r/wCEe+Of/Q56H/35X/5Ho/4R745/9Dnof/flf/keu6tvGkF7pq6rZaNq
9xpbRmVbtIFAZR3EbMJWz1GEOe1aeh+IdK8SaWuo6PeR3ls3eM4IP90g4Kn2OKAPMv8AhHvjn/0O
eh/9+V/+R6P+Ee+Of/Q56H/35X/5Hro7n4rabb+NX8IromszawrbRFGsAVvk8zhmlA+7zzitaDx5
pH9tw6JqKXWk6nOMw29/GF8zthXUsjH2DUAcN/wj3xz/AOhz0P8A78r/API9H/CPfHP/AKHPQ/8A
vyv/AMj12/jXx1YeA9Phv9Usb+a1mmEKyWqxthypYAhnU9FP5Uyz8a3GoaTBqlp4Q1+azuIlmidG
tMshGQdvn7unbGaAOL/4R745/wDQ56H/AN+V/wDkej/hHvjn/wBDnof/AH5X/wCR69K8Na/b+KNB
t9Xtbe5t4Z2kURXSBJEKOyMGAJwcqe9a1AHj/wDwj3xz/wChz0P/AL8r/wDI9H/CPfHP/oc9D/78
r/8AI9ewUUAeP/8ACPfHP/oc9D/78r/8j0f8I98c/wDoc9D/AO/K/wDyPXsFFAHj/wDwj3xz/wCh
z0P/AL8r/wDI9H/CPfHP/oc9D/78r/8AI9ewUUAeP/8ACPfHP/oc9D/78r/8j0f8I98c/wDoc9D/
AO/K/wDyPXsFFAHj/wDwj3xz/wChz0P/AL8r/wDI9H/CPfHP/oc9D/78r/8AI9ewUUAeP/8ACPfH
P/oc9D/78r/8j1j32sfFPwj4y8KWHiHxNY3drq+oJCUtLeM5QSRhwSYVIyJO3v0r3ivH/i//AMlD
+GP/AGFT/wCjbegD2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArj/il
reo+HPhxq2raTcfZ76DyfLl2K+3dMinhgQeCRyK7CvP/AI2/8kh13/t3/wDSiOgDk9J0/wCNus6N
Y6pb+MNGWC9t47iNZIEDBXUMAcW5GcH1NXP+Ee+Of/Q56H/35X/5Hr0DwJ/yTzw1/wBgq1/9FLXQ
UAeP/wDCPfHP/oc9D/78r/8AI9H/AAj3xz/6HPQ/+/K//I9ewUUAeP8A/CPfHP8A6HPQ/wDvyv8A
8j0f8I98c/8Aoc9D/wC/K/8AyPXsFFAHj/8Awj3xz/6HPQ/+/K//ACPR/wAI98c/+hz0P/vyv/yP
XsFFAHj/APwj3xz/AOhz0P8A78r/API9H/CPfHP/AKHPQ/8Avyv/AMj17BRQB4//AMI98c/+hz0P
/vyv/wAj0f8ACPfHP/oc9D/78r/8j17BRQB4/wD8I98c/wDoc9D/AO/K/wDyPR/wj3xz/wChz0P/
AL8r/wDI9ewUUAeP/wDCPfHP/oc9D/78r/8AI9H/AAj3xz/6HPQ/+/K//I9ewUUAeP8A/CPfHP8A
6HPQ/wDvyv8A8j17BRRQAUUUUAFFFFABRRRQB4/+zj/yTzUP+wrJ/wCioq9grx/9nH/knmof9hWT
/wBFRV7BQAUUUUAFFFFABRRRQAV4/wCIf+TofCf/AGCpP/QbqvYK8f8AEP8AydD4T/7BUn/oN1QB
7BRRRQAUUUUAeX/ELwoPGFz4nsI0DXkWkWFxanAz5iy3mB7ZGV/Gsb4L+Omufh5dabKRLqGklYre
NjjzVkOIh/32dvsMV6DZXefiHqpNpfLFJp9nCk7WcoiZ0kuCwDlccCVO/f2rkvDnwyOjfGXWPECq
V0xovOtlGcGWUneOv8JVjj/aX0oA4Tx3Yrpnx38E2auZDGbDfIRgyOblizH3LEk/Wr/7QWo3N74n
8PeGfMlispVWaQj7rs8hQfUqFP8A31UvxD03VNQ+OPh3V7PRdWn0+zez8+4j0+ZkXZMWbnbzgHtX
a/Fb4dN4+0m1u9NkEOrWWTAZMoJFOMqe4OQCD/jQB6JDDHbwRwxKFjjUIqjoABgCvn7wFdzeH/2h
9c0K1MhsL6e43Rj7qEAyKT9OVB969bsfFd2ujQ/2joGrR6wIcyWcdq0itIByFmUeVgnplhwa5b4b
fD2/0jXtU8Y+I1VNY1F5HW1jfeLdXbcwJHBboOOgHvQBxtx/ydwP99P/AEiFb37R9pEfB2k6htAu
YdRESSAfMFaN2IB+qL+VYt9Z6lB+0g3iVtE1ptHSRQbqPTJ3Xi2EZICoSRu44FdN8RNE1n4nz6Vo
2m2NzZaNDL9pudQvYjCScbQEibDkgFuoHWgDl/ijqdzrH7P/AIU1C8YvczXUBkdhguwhlBb8cZ/G
us8G+KNSjs/h5og0a8tbO5tgJL2ZozHMEtXYKmxieSA3zYPHT0o/Gfw9P/wrfRfDnh/S9QvDZXUW
yO2tZJdsaRSLklQRnLD866Dwrrljp/grw9a6hpOvC+021jBiGiXbFJBGYzgiPaeGbv3oA7+3tobW
IxwIEQu8hA/vMxZj+JJP41LXPeENV1DXLC71K/0+704TXTC2tLuIxyxxKFUblPckM3/Asc4yehoA
KKKKACiiigAooooAKKKKACiiigArx/4v/wDJQ/hj/wBhU/8Ao23r2CvE/jrqUOjeKvh/qlwsjQWV
7LcSLGAWKo8DEDJAzgeooA9sorx//ho7wf8A9A3XP+/EP/x2j/ho7wf/ANA3XP8AvxD/APHaAPYK
K8f/AOGjvB//AEDdc/78Q/8Ax2j/AIaO8H/9A3XP+/EP/wAdoA9gorx//ho7wf8A9A3XP+/EP/x2
j/ho7wf/ANA3XP8AvxD/APHaAPYKK8f/AOGjvB//AEDdc/78Q/8Ax2j/AIaO8H/9A3XP+/EP/wAd
oA9gorx//ho7wf8A9A3XP+/EP/x2j/ho7wf/ANA3XP8AvxD/APHaAPYKK8f/AOGjvB//AEDdc/78
Q/8Ax2j/AIaO8H/9A3XP+/EP/wAdoA9gorx//ho7wf8A9A3XP+/EP/x2j/ho7wf/ANA3XP8AvxD/
APHaAPYKK8f/AOGjvB//AEDdc/78Q/8Ax2j/AIaO8H/9A3XP+/EP/wAdoA9gorx//ho7wf8A9A3X
P+/EP/x2j/ho7wf/ANA3XP8AvxD/APHaAPYKK8f/AOGjvB//AEDdc/78Q/8Ax2j/AIaO8H/9A3XP
+/EP/wAdoA9grz/42/8AJIdd/wC3f/0ojrn/APho7wf/ANA3XP8AvxD/APHa5j4ifGvw34u8Calo
dhZarHdXXlbHnijCDbKjnJEhPRT2oA9n8Cf8k88Nf9gq1/8ARS10Fc/4E/5J54a/7BVr/wCilroK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8f8A2cf+Seah/wBh
WT/0VFXsFeP/ALOP/JPNQ/7Csn/oqKvYKACiiigAooooAKKKKACvH/EP/J0PhP8A7BUn/oN1XsFe
P+If+TofCf8A2CpP/QbqgD2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/9nH/k
nmof9hWT/wBFRV7BXj/7OP8AyTzUP+wrJ/6Kir2CgAooooAKKKKACiiigArx/wAQ/wDJ0PhP/sFS
f+g3VewV4/4h/wCTofCf/YKk/wDQbqgD2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igDx/wDZx/5J5qH/AGFZP/RUVewV4/8As4/8k81D/sKyf+ioq9goAKKKKACiiigAooooAK8f8Q/8
nQ+E/wDsFSf+g3VewV4/4h/5Oh8J/wDYKk/9BuqAPYKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKAPH/2cf+Seah/2FZP/AEVFXsFeP/s4/wDJPNQ/7Csn/oqKvYKACiiigAooooAKKKKA
CvH/ABD/AMnQ+E/+wVJ/6DdV7BXj/iH/AJOh8J/9gqT/ANBuqAPYKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKAPH/ANnH/knmof8AYVk/9FRV7BXj/wCzj/yTzUP+wrJ/6Kir2CgAoooo
AKKKKACiiigArx/xD/ydD4T/AOwVJ/6DdV7BXj/iH/k6Hwn/ANgqT/0G6oA9gooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooA8f/Zx/5J5qH/YVk/8ARUVewV4/+zj/AMk81D/sKyf+ioq9
goAKKKKACiiigAooooAK8f8AEP8AydD4T/7BUn/oN1XsFeP+If8Ak6Hwn/2CpP8A0G6oA9gooooA
KKKKACivK/HPxA1NvGtj4D8KyRQ6pcsoub6RA4tlI3YVehYL8xz2wOp47G28JNa27FfEOuPesgBu
pLwv82OoiYGIfTbQB0dFcLqsWt23w08SyatqEx1O1gvJYbq0d4OFQtEy7SMcBcjpnPWvM/AVxq+s
/CbxL4guPEmuDVdMeaS3nOpTMoEcKuFKMxRgTkcjPPXpQB9DUV5/8HvF+p+MvBRvNWUG7trhrYzh
domAVTuwOAfmwcccfhXoFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP/ALOP/JPNQ/7Csn/oqKvYK8f/AGcf+Sea
h/2FZP8A0VFXsFABRRRQAUUUUAFFFFABXj/iH/k6Hwn/ANgqT/0G6r2CvH/EP/J0PhP/ALBUn/oN
1QB7BRRRQAUUUUAfOk8Unh39qaC61HMcF3cM0ErnAcSwtGuD7Mdv4V9F1jeI/Cmi+LLJbXWbFLhU
O6NwSrxn1Vhgiqtr4SNvEbd/EWuz2hTYIJbpRgYxxIqiT8d+aAF8cSJJ8PPE5jdWC6XdqdpzgiJs
ivIfgf4Zi8S+ANXtL3Ub9NPlvjHNZ28ixpL8kZyzBd/PQgMAR2r2rUvD1pqPh240KOSWysp4XgcW
oRTsYEMBuUjkE8471l+CfAWn+A7Oez0u+v5reeTzWjumjbDYAyCqKegHftQBuaPo2neH9Kg0zSrV
LWzgGEjT9SSeST3J5NXqKKACiiigAooooAKK+cPhx4a8YfEDw9cat/wsjXLDybtrbyvNmlzhEbdn
zV/v4xjtXX/8Kg8Yf9FZ1z8pv/j9AHsFFeP/APCoPGH/AEVnXPym/wDj9H/CoPGH/RWdc/Kb/wCP
0AewUV4//wAKg8Yf9FZ1z8pv/j9H/CoPGH/RWdc/Kb/4/QB7BRXj/wDwqDxh/wBFZ1z8pv8A4/R/
wqDxh/0VnXPym/8Aj9AHsFFeP/8ACoPGH/RWdc/Kb/4/R/wqDxh/0VnXPym/+P0AewUV4/8ABa61
j/hIfG2k6trd9qv9mXcdtHLdzO/3XmUsAzHbnaDgHsOuK9goAKKKKACiiigAooooAKKKKACivB9Y
sfEni746eIfD1h4y1XRbW1tIrlBBNIUH7uEFQgdQMmQnP+NbH/CoPGH/AEVnXPym/wDj9AHsFFeP
/wDCoPGH/RWdc/Kb/wCP0f8ACoPGH/RWdc/Kb/4/QB7BRXj/APwqDxh/0VnXPym/+P0f8Kg8Yf8A
RWdc/Kb/AOP0AewUV4//AMKg8Yf9FZ1z8pv/AI/R/wAKg8Yf9FZ1z8pv/j9AHsFFeP8A/CoPGH/R
Wdc/Kb/4/R/wqDxh/wBFZ1z8pv8A4/QB7BRXgd7YeKvhv8QfBiXHjXUtdg1a9NvJBdvKIwpKRklT
KwY4lyPQqDzXvlABRRRQAUUUUAFFFFABRRRQAUV4/wDGm61j/hIfBOk6Trd9pX9p3cltJLaTOn3n
hUMQrDdjcTgnuemaP+FQeMP+is65+U3/AMfoA9gorx//AIVB4w/6Kzrn5Tf/AB+j/hUHjD/orOuf
lN/8foA9gorx/wD4VB4w/wCis65+U3/x+j/hUHjD/orOuflN/wDH6APYKK8f/wCFQeMP+is65+U3
/wAfo/4VB4w/6Kzrn5Tf/H6APYKK8f8A+FQeMP8AorOuflN/8fo/4VB4w/6Kzrn5Tf8Ax+gD2Civ
H/8AhUHjD/orOuflN/8AH69goAKKKKACiiigAooooAKKKKAPH/2cf+Seah/2FZP/AEVFXsFeP/s4
/wDJPNQ/7Csn/oqKvYKACiiigAooooAKKKKACvH/ABD/AMnQ+E/+wVJ/6DdV7BXj/iH/AJOh8J/9
gqT/ANBuqAPYKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPH/ANnH/knmof8AYVk/9FRV7BXj
/wCzj/yTzUP+wrJ/6Kir2CgAooooAKKKKACiiigAooooA8f+EH/JQ/id/wBhUf8Ao24r2CvH/hB/
yUP4nf8AYVH/AKNuK9goAKKKKACiiigAooooAKKKKAPH/D3/ACdD4s/7BUf/AKDa17BXj/h7/k6H
xZ/2Co//AEG1r2CgAooooAKKKKACiiigAooooA8f+L//ACUP4Y/9hU/+jbevYK8f+L//ACUP4Y/9
hU/+jbevYKACiiigAooooAKKKKACiiigDx/4v/8AJQ/hj/2FT/6Nt69grx/4v/8AJQ/hj/2FT/6N
t69goAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8f/Zx/5J5qH/YVk/8ARUVe
wV4/+zj/AMk81D/sKyf+ioq9goAKKKKACiiigAooooAK8f8AEP8AydD4T/7BUn/oN1XsFeP+If8A
k6Hwn/2CpP8A0G6oA9gooooAKKKKACiiigArzfxT8R/Emg+I7vTLD4earq1rDs2XsBk2S5RWOMRM
OCSOp6V6RRQB4/8A8Lf8Yf8ARJtc/Ob/AOMUf8Lf8Yf9Em1z85v/AIxXsFFAHj//AAt/xh/0SbXP
zm/+MUf8Lf8AGH/RJtc/Ob/4xXsFFAHj/wDwt/xh/wBEm1z85v8A4xR/wt/xh/0SbXPzm/8AjFew
UUAeV/ALSdS0bwLfW+qafd2M7anI6x3ULRMV8qIZAYA4yCM+xr1SiigAooooAKKKKACiiigAoooo
A+fNG1nxV4D8deNbi38Bazq0Gqam7xyRwyxqFWWUggiNgwIfOfbvmuj/AOFv+MP+iTa5+c3/AMYr
2CigDx//AIW/4w/6JNrn5zf/ABij/hb/AIw/6JNrn5zf/GK9gooA8f8A+Fv+MP8Aok2ufnN/8Yo/
4W/4w/6JNrn5zf8AxivYKKAPH/8Ahb/jD/ok2ufnN/8AGKP+Fv8AjD/ok2ufnN/8Yr2CigDx/wD4
W/4w/wCiTa5+c3/xij/hb/jD/ok2ufnN/wDGK9gooA8T+HLa9rPxp1zxPqnhnUtFgvdM2Kt1C4UM
pgXAdlUEkITjHr6V7ZRRQAUUUUAFFFFABRRRQAUUUUAeJ/GVtefx14SuNL8M6lqcGjOL5pLWF3WR
jKp8olVIUgQg55++OOObn/C3/GH/AESbXPzm/wDjFewUUAeP/wDC3/GH/RJtc/Ob/wCMUf8AC3/G
H/RJtc/Ob/4xXsFFAHj/APwt/wAYf9Em1z85v/jFH/C3/GH/AESbXPzm/wDjFewUUAeP/wDC3/GH
/RJtc/Ob/wCMUf8AC3/GH/RJtc/Ob/4xXsFFAHj/APwt/wAYf9Em1z85v/jFH/C3/GH/AESbXPzm
/wDjFewUjusaF3YKoGSScAUAfPus6z4q8eeOvBVxceAtZ0mDS9TR5JJIZZFKtLESSTGoUAJnPv2x
X0HWMni/wzJefY08RaQ11vKeSt7GX3Dtt3Zz7VsAhgCCCDyCKAFooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigDx/wDZx/5J5qH/AGFZP/RUVewV4/8As4/8k81D/sKyf+ioq9goAKKK
KACiiigAooooAK8f8Q/8nQ+E/wDsFSf+g3VewV4/4h/5Oh8J/wDYKk/9BuqAPYKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoorkvEni2/0Txf4c0a30k3Fvq0r
RyXJfaIsDOBxgnGTjuBxQB5PbqB+1uQAMeY5/wDJI19C14JpFjNqP7VOo31sC9vY7nmkUZVc2wjw
T2O5v0Ne90AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP/s4/wDJPNQ/7Csn
/oqKvYK8f/Zx/wCSeah/2FZP/RUVewUAFFFFABRRRQAUUUUAFeP+If8Ak6Hwn/2CpP8A0G6r2CvH
/EP/ACdD4T/7BUn/AKDdUAewUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc/4N/5Adz/2FdS/
9LZq6Cuf8G/8gO5/7Cupf+ls1dBQBh+E55rnR7h55ZJXGp36BnYsQq3cyqOewUAAdgAK3K5/wb/y
A7n/ALCupf8ApbNXQUAFFFFABRRRQAUUV55438U+N7HW0sPBmgW2ppDEGu5ZwSEduVUYkXnaMnr9
4UAeh0VxnhLX/Ex8N6jq3juws9JNqzMqQqRiJVDFzl29wOnSsc/Eu+/4QIePPsMP9i+fs+x4P2jy
vO8rfv3bc5527f8AgXegD0uiq9hfW+p6fbX9pIJLa5jWWJx/ErDIP61YoAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKgvLK01C2e2vbaG5t3GGimjDq31B4N
T0UAV7LT7LTbcW9jaW9rCvAjgjCKPwAxViiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigDx/9nH/AJJ5qH/YVk/9FRV7BXj/AOzj/wAk81D/ALCsn/oqKvYKACiiigAooooAKKKK
ACvH/EP/ACdD4T/7BUn/AKDdV7BXj/iH/k6Hwn/2CpP/AEG6oA9gooooAKKKKACiiigAoorL1KDX
pbhW0vUtNtoNgDJdae87FsnkMsyADGOMdjzzwAalFc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8A
wTTf/JVAGf46+I+j/D/7B/a1tfTfbvM8v7IiNjZtzncy/wB8dM96NM+KngbV/N+zeJrGPysbvtbG
2znOMeaF3dO2ccZ6ivIP2h4dYi/4Rz+1r6xus/afL+yWb2+3/VZzulfPbpjGD1zx4fQB99wTw3Vv
FcW8sc0EqB45I2DK6kZBBHBBHOakr408KeD/AIhzXAuvDem6zaPNb71uo3a0WSIlTxIxUMD8pwCc
4z2r3PwroPxitZ9ObVvFGlfYUiAkguIftEi/JgByqoXYHGSJeozluhAO48G/8gO5/wCwrqX/AKWz
V0Fc/wCDf+QHc/8AYV1L/wBLZq6CgDn/AAb/AMgO5/7Cupf+ls1dBXncV74vs/Cl8/hbSNNv5xqd
+U+1XbI277fMGAj2hSNvOTIvfg4wfJPG3jD4xW/25dWgvtIsV8vzGsLbbDF93G24XceTjOJDySvt
QB9Nzzw2tvLcXEscMESF5JJGCqigZJJPAAHOa5d/ib4LXWbTSU8QWlxeXbokK2u6dWZ22qC6AqDn
sSMcE8GvjjUtW1LWbhbjVNQu76dUCLJdTNKwXJOAWJOMknHua0PBZmXx14ea3jjknGp2xjSRyis3
mrgFgCQM98HHoaAPuOiuf+2eMP8AoBaH/wCDmb/5Fo+2eMP+gFof/g5m/wDkWgDoK8W8Q+B/ihae
IdW17w34jgxdztP9iSUrnACoNrgoW2qoycdBXpP2zxh/0AtD/wDBzN/8i1nWVh4+sPEVy8uraTqe
jTyu6RzxtDNbqT8qqUUhgBxzz3oA8+vPG2s+Lfgz4wtNQtFtde0oJDeRgFcoWG5sdiVWQY9veqP/
ADaH/n/n/r2WDwvp4tdXjuYlnfWGLXxxgSZQJgDnACgD8z1Ncf8A8K0v/wDhAh4D+3Q/2L5+/wC2
ZP2jyvO83Zs27c543bv+A9qANb4R/af+FVeH/tf+s8hsf7m9tn/ju2u1qvYWNvpmn21haRiK2to1
iiQfwqowBVigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPH/2cf+Seah/2FZP/
AEVFXsFeP/s4/wDJPNQ/7Csn/oqKvYKACiiigAooooAKKKKACvH/ABD/AMnQ+E/+wVJ/6DdV7BXj
/iH/AJOh8J/9gqT/ANBuqAPYKKKKACiiigAooooAKKKKACiiigDn/E/gnw74x+y/2/p/2z7Lv8n9
9JHt3Y3fcYZztXr6VoaZoWj6J5v9k6VY2HnY8z7JbpFvxnGdoGcZPX1NaFFABRRRQBz/AIN/5Adz
/wBhXUv/AEtmroK5/wAG/wDIDuf+wrqX/pbNXQUAc/4N/wCQHc/9hXUv/S2augrn/Bv/ACA7n/sK
6l/6WzV0FAGPrPhTw/4h3nV9Fsb2RojD500CmRUOeFfG5epIwRgnI5rj4/gf4OtPEOn6zpyX1jJY
yxzJBDcbo3dH3At5gZueAcMOB2PNekUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAeP/ALOP/JPNQ/7Csn/oqKvYK8f/AGcf+Seah/2FZP8A0VFXsFAB
RRRQAUUUUAFFFFABXj/iH/k6Hwn/ANgqT/0G6r2CvH/EP/J0PhP/ALBUn/oN1QB7BRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQBh+E4JrbR7hJ4pInOp37hXUqSrXczKeexUgg9wQa3KKKAKemabD
pVq9vA0jI9xPcEuQTullaVhwBxucge2OvWrlUtN1ay1aOd7KYyC3ne3lDIyFJFOGUhgD/jnIq7QA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP/
ALOP/JPNQ/7Csn/oqKvYK8f/AGcf+Seah/2FZP8A0VFXsFABRRRQAUUUUAFFFFABXj/iH/k6Hwn/
ANgqT/0G6r2CvH/EP/J0PhP/ALBUn/oN1QB7BRRRQAUUUUAFFFFABRRRQAUUUUAFcL8WtbvdK8CX
8Olo76hdQyKuzrHEq5lkzkY2pnn1Iruq4aJtZ1bxLqWsWGmaXfWKK2m2xu79oSAjETEBYH4ZxtPz
dIxxQBc+GvipfGHgaw1JnDXaL5F0AeRKvBJ54yMN9GFdbXz78Lb248B/FXVvBWpItvBevut41kaR
FfG5NrFRuyhxkgZIH0r6CoAKKKKAPM9Q8WXXgrw74i1uLS4b63h1mVZUN2YnG4ooIGxgeSO4qPwN
8U9Y+IA1D+yfDNjD9h8vzBdas67t+7G3bA39w9cdqxPH8Ag+EvjYAsQ+us/zHJ5mi7/5wOOgrmv2
eptZhXxL/ZFjY3RItvM+13jwbf8AW4xtifd3znGMDrngA7zU/jVD4Y14aP4q8O3enXHDeZbzrcRl
CSA4OFJHB7Z4PFemWN9balYQX1nMs1tcIJIpF6MpGQa+Y/iKkt38RI5/iOl3psTQrFbDSolmjMIJ
ORIzDoWbPyk89OlfQ/g240O48J6d/wAI3MsulRxCKAgnIC8YbPO71zQBu0UUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4/+zj/yTzUP+wrJ/wCioq9grx/9
nH/knmof9hWT/wBFRV7BQAUUUUAFFFFABRRRQAV4/wCIf+TofCf/AGCpP/QbqvYK8f8AEP8AydD4
T/7BUn/oN1QB7BRRRQAUUUUAFFFFABRRRQAUUUUAMmiWeF4nLhXBUlHKNj2III+orP0PQNO8OWP2
LS4pYrYMzCN7iSUAsSxI3scZJJ+prTooA5XU/hv4V1nWo9Y1DT5ptRjKlLg3s4ZNpyuMOMYPPFdS
ihEVRnCjAyST+Z60tFABRRRQB5P4z8PeI9Y8A6/o9noM73eoaq08Q+0QACISKwZiX4yF6DJ5Ge9Y
3wf8NeLfh82sf2r4UvZlvhD5Ztbq1YqU35yGmX+/+le40UAeJfEPwN4z+J2rWEh0200aws1ZU+13
SvKdxG5iI9w/hGACfrzx6N4C8GW3gTwvHo9vO1w5kM08xXb5khABIHYYAA+ldPRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4/+zj/yTzUP+wrJ/wCi
oq9grx/9nH/knmof9hWT/wBFRV7BQAUUUUAFFFFABRRRQAV4/wCIf+TofCf/AGCpP/QbqvYK8f8A
EP8AydD4T/7BUn/oN1QB7BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
VXvdQstNt2uL+7t7WBRlpJ5Aij6knFZUXjbwpPKsUPifRZJGOFRL+Ikn2AagDdopqOkiK8bK6MMh
lOQRTqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/9nH/knmof
9hWT/wBFRV7BXj/7OP8AyTzUP+wrJ/6Kir2CgAooooAKKKKACiiigArx/wAQ/wDJ0PhP/sFSf+g3
VewV4/4h/wCTofCf/YKk/wDQbqgD2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigDn/HYz8PPEv/YKuv8A0U1ebfs7QQ3XgDVoLiJJYn1FgySKGVh5UfBBr0nx2cfDzxL/ANgq
6/8ARTV5v+znNFD4D1aSWRI0TUWZmZgAo8uPkntQBk+FdWn8CfHS/wDBdvK7aHdz4it2bKwM8YlU
r6fe249D3Ir36vA/DOjz+OPjvf8AjO1Rv7Cs5/3dyVws7JGIlCHvyN2fQe9e+UAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHj/7OP8AyTzUP+wrJ/6Kir2CvH/2cf8A
knmof9hWT/0VFXsFABRRRQAUUUUAFFFFABXj/iH/AJOh8J/9gqT/ANBuq9grx/xD/wAnQ+E/+wVJ
/wCg3VAHsFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFZfhrUptZ8K6Rqlwsaz
3tlDcSLGCFDOgYgZJOMn1Nalc/4E/wCSeeGv+wVa/wDopaANe90+y1K3a3v7S3uoG4aOeMOp+oIx
WHP4Y8GaOsd3J4d0a3/fRwpImnR5DyOI0AwuRlmAz788V0tc/wCMv+QHbf8AYV03/wBLYaAN5EWN
AiKFUcBVGAKdRRQAUUUUAFFFFABRWfr2rRaD4f1DV5kMkdlbvOUBwW2qTgH36V5DJ8etaitmuZPh
zqCW6rvMrXLhQvrnycYoA9uorj5vH1vYeGNC1PUbJ4L7WmijtdPR97l5MYBYgYABBJI46cnGbdj4
uifxW3hfU7dbPV/swuokSXzY5oySDtYqpyNpyCB7ZwaAOlooooAKKKKACiiigAooooAKKKKACiis
W78YeGbC6ktbzxHpFvcRHbJFNexo6H0ILZFAG1RWXpviXQdZuGt9L1vTb6dULtFa3aSsFBAyQpJx
kjn3FT3er6Zp88UF7qNpbTTHEUc06ozn/ZBOT+FAF2ijrRQAUUUUAFFFFAEc88Nrby3FxLHDBEhe
SSRgqooGSSTwABzmpK5/x3/yTzxL/wBgq6/9FNXQUAFRzTw2yB55Y4kLqgZ2CgszBVHPcsQAO5IF
SVz/AIy/5Adt/wBhXTf/AEthoA6CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP
H/2cf+Seah/2FZP/AEVFXsFeP/s4/wDJPNQ/7Csn/oqKvYKACiiigAooooAKKKKACvH/ABD/AMnQ
+E/+wVJ/6DdV7BXj/iH/AJOh8J/9gqT/ANBuqAPYKKKKACiiigAooooAKKKKACiiigAooooAKKx7
7xLYafeSWs1vqryJjJg0m6mQ5APDpGVPXseOnWq//CZaX/z665/4Ir3/AOM0AdBRXP8A/CZaX/z6
65/4Ir3/AOM14p8f/EEd5ceF7jTv7Stp7V7h1kmsp7RlbMRUoZEUkgjOV6cdMigD6Lor4w0z4qeO
dI837N4mvpPNxu+1sLnGM4x5obb17YzxnoK9A0z9pTWIvN/tbw/Y3WceX9kme329c53b89umMYPX
PAB9H1z/AIE/5J54a/7BVr/6KWuX8G/GfQvGOoxabBp2q2980Qdx9mM0atlVI3R5IUFvvsqrjrjp
XUeBP+SeeGv+wVa/+iloA6Cuf8Zf8gO2/wCwrpv/AKWw10Fc/wCMv+QHbf8AYV03/wBLYaAOgorz
Px18SvEfhe4uoLDwJqV1BFbvINRkO6BMFhvIjDDYAobDMjYPIXg14xqXx58eX1wstvfWmnoECmK1
tEZScn5j5m855x1xwOOuQD6zrP0zXdH1vzf7J1Wxv/Jx5n2S4SXZnOM7ScZwevoa+INT13WNb8r+
1tVvr/yc+X9ruHl2ZxnG4nGcDp6CvYP2eNRurD/hJPs2jX2pb/s277I8C+XjzcZ82ROue2ehzjjI
B9H0Vn6ZqN1f+b9p0a+03Zjb9reBvMznOPKkfpjvjqMZ5xTn13UYbiWJPCeszojlVljlswrgH7w3
Tg4PXkA+oFAGzLDHPHslQOmQ2D0yDkfqBXF/Ep2v9P0vwvExEuu3yW8m1sEW6fvJj6/dXH/Aq6PT
dVvL64aK48P6lp6BCwlupLdlJyPlHlyuc856Y4PPTOQmj3958TpNZvINmn2Gni3sWLKfMkkbMrYB
JGAqryB1PWgDzT4qyyr8avh/aCPbaxT2zREdNxuAGH4BU/OnfEGee2/aP8GvbIWc29uhH+w00ysf
wUk13nj7wRL4kv8AQNasGQalot7HcIjnAmjDqzJnsflBB/DjORCvg+51z4o2vjPUrdrOGwshb2tp
IytI0mXJdijFQAHOBk59scgHfUUUUAFFFFABRRRQAUUUUAFFFFABXlz/AAM8N6leXWpa1NfXWoXk
zTzMs+1FZjkqvGdozgZ/+tXqNc18QNdbw54G1XUIs/aRD5VuFGSZX+RMDvyQfwoA4T4V6RpPhqz8
Y+JLGN49NS4khtjLIGzBbg7n3ejNu/75ql8IbhvFfhbxnqusKlzd6hO8c7MMgp5WQgz0Ubjgdq9A
0/wiun/Cv/hFUwHbS5LaQoAMyOh3kfVmJrzz4Bo8PgHxLFKjRyR3Tq6OMFSIhkEdqANb4AeJ7rXP
Btzp17P502lzCONmOW8phlQfoQwHsAO1etV4h+zbpUlv4f1rVHV1W7uI4U3DAYRhjkevMhH4e1e3
0AFFFeb+Ovi7Z+AvFtpo9/pM9xazWguXuYJRvTLOoURkAHlBzuHX25APSKK830b45+BtX2LLfz6b
M8oiWO+gK5zjDFk3Iq5PVmGMEnA5rvNN1bTdZt2uNL1C0voFco0lrMsqhsA4JUkZwQce4oAy/Hf/
ACTzxL/2Crr/ANFNXQVz/jv/AJJ54l/7BV1/6KaugoAK5/xl/wAgO2/7Cum/+lsNdBXP+Mv+QHbf
9hXTf/S2GgDoKKKy9S8S6Do1wtvqmt6bYzsgdY7q6SJiuSMgMQcZBGfY0AalFeX6n8fvA1h5X2a4
vtS353fZLUr5eMYz5pTrntnoc44zofDL4m/8LG/tT/iUf2f9g8r/AJefN379/wDsLjGz360AegUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP/s4/wDJPNQ/7Csn/oqKvYK8f/Zx/wCSeah/2FZP
/RUVewUAFFFFABRRRQAUUUUAFeP+If8Ak6Hwn/2CpP8A0G6r2CvH/EP/ACdD4T/7BUn/AKDdUAew
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeZ/Fn4bal8Q7jQVsry0tYLJ5hcvNuLBXMfKKBh
iAh4JXtz6emUUAeH6Z+zXo8Xm/2t4gvrrOPL+yQpb7euc7t+e3TGMHrnj0DTPhX4G0jzfs3hmxk8
3G77WpucYzjHmltvXtjPGegrsKKAI4IIbW3it7eKOGCJAkccahVRQMAADgADjFYfgT/knnhr/sFW
v/opa6Cuf8Cf8k88Nf8AYKtf/RS0AdBXP+Mv+QHbf9hXTf8A0throK5/xl/yA7b/ALCum/8ApbDQ
B0FZepeGtB1m4W41TRNNvp1QIsl1apKwXJOAWBOMknHua1KKAPL9T+APga/8r7Nb32m7M7vsl0W8
zOMZ80P0x2x1Oc8Y0Phl8Mv+Fc/2p/xN/wC0Pt/lf8u3lbNm/wD22znf7dK9AooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigArH1/w3Z+IzpwvpLgR2F4l4kUbgLI6Z2h+Dlec44rYooAK
5m58D6bLd6jPa3F5p41QYv47SRVS54IJOVJUkE5ZCpPrXTUUAcxZ+D5NMtUs9L8SatYWMWRDawQ2
myJc52gtAWPXqxJPck81P/wj2qf9Dnrn/fmy/wDkeugooA5//hHtU/6HPXP+/Nl/8j186fH2ynsf
HVjFcand6g50yNhLdLErAebL8o8tEGOM9M8nnpj6rqnJpOmzapDqkun2j6hCmyK7aFTKi88K+Mgf
M3APc+tAHxJo3hTxB4h2HSNFvr2NpRD50MDGNXOOGfG1eoJyRgHJ4rvNN/Z98b31u0twNN09w5UR
XVyWYjA+YeWrjHOOueDx0z9V0UAeTz+B9d8MeCPFk+p+OdV1qOTSrjEE6jZxDIOS5dh94H5Cv3ed
w4HrFc/47/5J54l/7BV1/wCimroKACuf8Zf8gO2/7Cum/wDpbDXQVz/jL/kB23/YV03/ANLYaAOT
8dfDXxH4ouLqew8d6lawS27xjTpBtgfJY7CYyo2EMFyyu2ByW4FeMal8BvHljcLFb2NpqCFAxltb
tFUHJ+U+ZsOeM9Mcjnrj6zooA+ENT0LWNE8r+1tKvrDzs+X9rt3i34xnG4DOMjp6ivYP2eNOur//
AIST7NrN9puz7Nu+yJA3mZ83GfNjfpjtjqc54x9H1n6ZoWj6J5v9k6VY2HnY8z7JbpFvxnGdoGcZ
PX1NAGf/AMI9qn/Q565/35sv/kej/hHtU/6HPXP+/Nl/8j10FFAGfpmnXVh5v2nWb7Ut+Nv2tIF8
vGc48qNOue+egxjnNyeCG6t5be4ijmglQpJHIoZXUjBBB4II4xUlFABRRRQAUUUUAFFFFABRRRQA
UUUUAeP/ALOP/JPNQ/7Csn/oqKvYK8f/AGcf+Seah/2FZP8A0VFXsFABRRRQAUUUUAFFFFABXj/i
H/k6Hwn/ANgqT/0G6r2CvH/EP/J0PhP/ALBUn/oN1QB7BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABXP+BP8Aknnhr/sFWv8A6KWugqvYWNvpmnW1hZx+Xa2sSQwpuJ2ooAUZPJwA
OtAFiuf8Zf8AIDtv+wrpv/pbDXQVHNBDcoEnijlQOrhXUMAysGU89wwBB7EA0ASUUUUAFFFFABRR
RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBz/jv/AJJ5
4l/7BV1/6KaugrH8WWNxqfg3XLCzj8y6utPuIYU3AbnaNgoyeBkkda2KACuf8Zf8gO2/7Cum/wDp
bDXQVj+JbG41DSoIbWPzJF1CymI3AYSO6ikc8+iqx98cc0AbFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQAUUUUAeP8A7OP/ACTzUP8AsKyf+ioq9grx/wDZx/5J5qH/AGFZP/RUVewUAFFF
FABRRRQAUUUUAFeP+If+TofCf/YKk/8AQbqvYK8f8Q/8nQ+E/wDsFSf+g3VAHsFFFFABRRRQAUUU
UAFFFFAFe+v7PTLOS8v7uC0tY8b5p5BGi5IAyx4GSQPxrH/4Tvwf/wBDXof/AIMYf/iq0Nb0TTvE
ejz6Tq1v9osZ9vmRb2TdtYMOVII5APBrj/8AhSXw8/6F7/yduP8A45QB0H/Cd+D/APoa9D/8GMP/
AMVR/wAJ34P/AOhr0P8A8GMP/wAVXP8A/Ckvh5/0L3/k7cf/AByj/hSXw8/6F7/yduP/AI5QB0H/
AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VXP/APCkvh5/0L3/AJO3H/xyj/hSXw8/
6F7/AMnbj/45QB0H/Cd+D/8Aoa9D/wDBjD/8VR/wnfg//oa9D/8ABjD/APFVz/8AwpL4ef8AQvf+
Ttx/8co/4Ul8PP8AoXv/ACduP/jlAHQf8J34P/6GvQ//AAYw/wDxVH/Cd+D/APoa9D/8GMP/AMVX
P/8ACkvh5/0L3/k7cf8Axyj/AIUl8PP+he/8nbj/AOOUAdB/wnfg/wD6GvQ//BjD/wDFVsWN/Z6n
Zx3lhdwXdrJnZNBIJEbBIOGHBwQR+FeX+LPhB4E0zwbrl/Z6F5d1a6fcTQv9rnO11jYqcF8HBA61
sfBL/kkOhf8Abx/6USUAegUUUUAY994s8N6ZeSWd/wCINKtLqPG+Ge9jjdcgEZUnIyCD+NV/+E78
H/8AQ16H/wCDGH/4qvJ28LaN4u/aQ8UWGuWf2u1j0+KZU8148OI7cA5Qg9GP513H/Ckvh5/0L3/k
7cf/ABygDoP+E78H/wDQ16H/AODGH/4qj/hO/B//AENeh/8Agxh/+Krn/wDhSXw8/wChe/8AJ24/
+OV5x8a/h34V8I+DbO/0PSvsl1JqCQs/2iWTKGOQkYdiOqj8qAPoeiiigArn/wDhO/B//Q16H/4M
Yf8A4qugr54+Cnw78K+LvBt5f65pX2u6j1B4Vf7RLHhBHGQMIwHVj+dAHs//AAnfg/8A6GvQ/wDw
Yw//ABVH/Cd+D/8Aoa9D/wDBjD/8VXP/APCkvh5/0L3/AJO3H/xyj/hSXw8/6F7/AMnbj/45QB1F
j4s8N6neR2dh4g0q7upM7IYL2OR2wCThQcnABP4VsV4OvhbRvCP7SHhew0Oz+yWsmnyzMnmvJlzH
cAnLknoo/KveKACq99f2emWcl5f3cFpax43zTyCNFyQBljwMkgfjVivP/jb/AMkh13/t3/8ASiOg
DoP+E78H/wDQ16H/AODGH/4qj/hO/B//AENeh/8Agxh/+Krh/Cfwg8Can4N0O/vNC8y6utPt5pn+
1zjc7RqWOA+Bkk9K2P8AhSXw8/6F7/yduP8A45QB0H/Cd+D/APoa9D/8GMP/AMVWhpmu6Prfm/2T
qtjf+TjzPslwkuzOcZ2k4zg9fQ1x/wDwpL4ef9C9/wCTtx/8crl/gjY2+meMviLYWcfl2trqCQwp
uJ2oslwFGTycADrQB7RRRRQBn6nruj6J5X9rarY2HnZ8v7XcJFvxjONxGcZHT1FZ/wDwnfg//oa9
D/8ABjD/APFV5v8AG6xt9T8ZfDqwvI/MtbrUHhmTcRuRpLcMMjkZBPSuo/4Ul8PP+he/8nbj/wCO
UAdB/wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FVz/wDwpL4ef9C9/wCTtx/8crH8
WfCDwJpng3XL+z0Ly7q10+4mhf7XOdrrGxU4L4OCB1oA9Qsb+z1OzjvLC7gu7WTOyaCQSI2CQcMO
Dggj8KsV5/8ABL/kkOhf9vH/AKUSV6BQAVj33izw3pl5JZ3/AIg0q0uo8b4Z72ON1yARlScjIIP4
1sV4O3hbRvF37SHiiw1yz+12senxTKnmvHhxHbgHKEHox/OgD1j/AITvwf8A9DXof/gxh/8AiqP+
E78H/wDQ16H/AODGH/4quf8A+FJfDz/oXv8AyduP/jlH/Ckvh5/0L3/k7cf/ABygDoP+E78H/wDQ
16H/AODGH/4qugr54+Nfw78K+EfBtnf6HpX2S6k1BIWf7RLJlDHISMOxHVR+VfQ9ABRRRQBz/wDw
nfg//oa9D/8ABjD/APFUf8J34P8A+hr0P/wYw/8AxVeMfBT4d+FfF3g28v8AXNK+13UeoPCr/aJY
8II4yBhGA6sfzr0f/hSXw8/6F7/yduP/AI5QB0H/AAnfg/8A6GvQ/wDwYw//ABVWLHxZ4b1O8js7
DxBpV3dSZ2QwXscjtgEnCg5OACfwrl/+FJfDz/oXv/J24/8AjlcOvhbRvCP7SHhew0Oz+yWsmnyz
MnmvJlzHcAnLknoo/KgD3iiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/wDZx/5J5qH/AGFZ
P/RUVewV4/8As4/8k81D/sKyf+ioq9goAKKKKACiiigAooooAK8f8Q/8nQ+E/wDsFSf+g3VewV4/
4h/5Oh8J/wDYKk/9BuqAPYKKK82+M/jm68GeFYU02RY9S1CQxRSE8xIBl3A7kZUe27NAHc3uu6Rp
k0cN/qtjayyMFRJ7hI2YnoACeTVv7Vb7A/nxbWUsG3jBAxk/TkfnXG/DXwjZ6F4Rsbia3WXVb6BL
i9upsPK7sN2C3cDOB/8AXzWrbeEbCw8ZL4gsY1ty1nLbTQx8IzM8bhwvQH5Dk9+PSgB7eOfCKOyP
4p0RWU4IOoRAg/8AfVbFte2l7b/aLW6hnhxnzIpAy/mOK+f/AIZhB+0L4vDBRGGv8g9MfaFrQ8Cp
O3x/1+Xw5/yLgLi6MWfJLFR0x8u7zM49t1AHsFt4q8O3t+LC117S57xmKi3ivI2kJGcjaDnIwfyq
7falY6Xbm41C9t7SEdZLiVY1H4kgV4R8R/Aeo6hrniLxd4eMg1PS9Tj3xRcMYxaW770HdgzEkdwT
3GDv6P8AEe38efCLxLDdbI9ZtNIuRcxcYkAibEij0J6+h/CgD122ube8gWe1ninhcZWSJwykexFS
0gAUAAAAcACloAKKKKACiiigAooooAKKKKAOf8d/8k88S/8AYKuv/RTVz/wS/wCSQ6F/28f+lEld
B47/AOSeeJf+wVdf+imrn/gl/wAkh0L/ALeP/SiSgD0CiiigDx/w9/ydD4s/7BUf/oNrXsFeP+Hv
+TofFn/YKj/9Bta9goAK8f8A2jv+Seaf/wBhWP8A9FS17BXj/wC0d/yTzT/+wrH/AOipaAPYKKKK
ACvH/wBnH/knmof9hWT/ANFRV7BXj/7OP/JPNQ/7Csn/AKKioA9gooooA8f8Q/8AJ0PhP/sFSf8A
oN1XsFeP+If+TofCf/YKk/8AQbqvYKACvP8A42/8kh13/t3/APSiOvQK8/8Ajb/ySHXf+3f/ANKI
6AOg8Cf8k88Nf9gq1/8ARS10Fc/4E/5J54a/7BVr/wCilroKACvH/hB/yUP4nf8AYVH/AKNuK9gr
x/4Qf8lD+J3/AGFR/wCjbigD2CiiigDx/wCL/wDyUP4Y/wDYVP8A6Nt69grx/wCL/wDyUP4Y/wDY
VP8A6Nt69goAK5/x3/yTzxL/ANgq6/8ARTV0Fc/47/5J54l/7BV1/wCimoA5/wCCX/JIdC/7eP8A
0okr0CvP/gl/ySHQv+3j/wBKJK9AoAK8f8Pf8nQ+LP8AsFR/+g2tewV4/wCHv+TofFn/AGCo/wD0
G1oA9gooooA8f/aO/wCSeaf/ANhWP/0VLXsFeP8A7R3/ACTzT/8AsKx/+ipa9goAKKKKAPH/ANnH
/knmof8AYVk/9FRV7BXj/wCzj/yTzUP+wrJ/6Kir2CgArx/xD/ydD4T/AOwVJ/6DdV7BXj/iH/k6
Hwn/ANgqT/0G6oA9gooooAKKKKACiiigAooooAKKKKACiiigAooooA8f/Zx/5J5qH/YVk/8ARUVe
wV4/+zj/AMk81D/sKyf+ioq9goAKKKKACiiigAooooAK8f8AEP8AydD4T/7BUn/oN1XsFeP+If8A
k6Hwn/2CpP8A0G6oA9gryz46eDb3xT4VtrzTLdri90yRpPJQZd42A3hR3Pyqcd8HvXqdFAHF/Dbx
ZY694M05GuoxqFpAlteQSEJIkiDacr2zjNdNa6vZ317LbWkhn8kfvJYxmNWzjZu6FuvA6Y5xkVHe
+HdE1K4S4v8ARtPup4zlJZ7VHZT6gkZHQVeFvCsAgEMYhAx5YUbcfSgD508Aadp+qftB+K4dQsra
8iWe+kRLiJZFDi4GGAIPI55r6KgtoLWIRW8McMY6JGoUfkKy4PCXhq1uvtVv4e0mG4yT5sdlGr89
eQua2CAwIIBB4INAHP8AhxlbXPFoDAkaqmcH/pztv8DXi/xg+HN14durnxZ4YV4rO4jePUIIf+WY
dSrMBj7jAnPoTn6e92mi6VYXMtzZ6ZZW08p3SSwwKjOfUkDJq3LFHNE8UqLJG4KsjjIYHqCO9AD6
KKKACiiigAooooAKKKKACiiigDL8S6bNrPhXV9Lt2jWe9spreNpCQoZ0KgnAJxk+hryPRPAXxi8O
aPBpOk+KtDt7GDd5cWzft3MWPLQEnkk8mvS/FnjnSPB6W6XplnvrtglrY2y75pmJwMD0zxk0+DWf
EH2drq88MeXDtVligvVluMHrlCqrkegc57UAcD/wj3xz/wChz0P/AL8r/wDI9H/CPfHP/oc9D/78
r/8AI9el+G9eg8TaHDq1tDNDDLJKipMu1xskaPkds7c47ZrVoA8r8A+AfF+jfEHUfFPirU9Nvp72
yNu72pYMWzHtJXy1UALHjj2r1SiigArg/iz4K1Lx54VtdL0ue0hnivUuGa6dlUqEdcDarHOXHb1r
uznBwQD2zXkV38RvFQ+MbeBbc6MkJcBLuSzldgDCJeVEwz6dR60AN/4R745/9Dnof/flf/kej/hH
vjn/ANDnof8A35X/AOR67N7jxjY6zpyzXOiX2mS3Hk3bQWcsMsOVJUjMzjrtH411tAHj/wDwj3xz
/wChz0P/AL8r/wDI9dJ8JvBWpeA/Ct1peqT2k08t69wrWrsyhSiLg7lU5yh7eld5RQAUUVFcLO0D
C2kjjlx8rSIXUH3AIz+dAHmHj7wD4v1n4g6d4p8K6nptjPZWQt0e6LFg2ZNxC+WykFZMc+9U/wDh
Hvjn/wBDnof/AH5X/wCR6b8M/iJ4w+IsupJ5uh6f9iWM5/s+aXfv3f8ATdcY2+/Wu+0O68SjXruz
1ttLns/s6TWlzYwvHvySGDBnbp8vQ96AOD/4R745/wDQ56H/AN+V/wDkes/W/AXxi8R6PPpOreKt
DuLGfb5kWzZu2sGHKwAjkA8GvcKKAMvw1ps2jeFdI0u4aNp7Kyht5GjJKlkQKSMgHGR6CtSiigAr
xNfhz8S9G8VeItU8MeINGsYNXvZLhlky7Fd7sgO6FgCA56Hv3r1nX9f07wzotxq2qTiG1gGWPUse
yqO5PYVz/hvXfEni/SItZtIbDSLGdy1ul3C9zLLFnAYhXQIT1H3vxoA5L/hHvjn/ANDnof8A35X/
AOR6P+Ee+Of/AEOeh/8Aflf/AJHruLfXtbi8XW2hajpMKQzQSTLqEEpaOTbt+XaRlWyxJBJ4AwTk
46igDxNvhz8S9Z8VeHdU8T+INGvoNIvY7hVjyjBd6M4G2FQSQg6nt2r2yiigArL8S6bNrPhXV9Lt
2jWe9spreNpCQoZ0KgnAJxk+hrUryv4u/EbX/h9PpR02LTbiK+E2VuYJCyFNndZBnO/07UAYeieA
vjF4c0eDSdJ8VaHb2MG7y4tm/buYseWgJPJJ5NaH/CPfHP8A6HPQ/wDvyv8A8j13XiLVNZ0bwPfa
xFNYSXtpaPckPbP5b7V3Yx5mR0POTWL8JvGms+PPD11q2qJYQiK7a2WK1hdeiI2SWdv7/p2oA5//
AIR745/9Dnof/flf/kerngHwD4v0b4g6j4p8Vanpt9Pe2Rt3e1LBi2Y9pK+WqgBY8ce1eqUUAFFF
Ic4OCAe2aAOE+LPgrUvHnhW10vS57SGeK9S4Zrp2VSoR1wNqsc5cdvWub/4R745/9Dnof/flf/ke
pZfiP4lT40jwME0n7KZFH2g20m/aYRL083GecZ/GvWlyFG4gtjkgYGaAPIP+Ee+Of/Q56H/35X/5
Ho/4R745/wDQ56H/AN+V/wDkevYKKAOD+E3grUvAfhW60vVJ7SaeW9e4VrV2ZQpRFwdyqc5Q9vSu
8oooAK8r8feAfF+s/EHTvFPhXU9NsZ7KyFuj3RYsGzJuIXy2UgrJjn3r1SigDx//AIR745/9Dnof
/flf/kej/hHvjn/0Oeh/9+V/+R69gooA8f8A+Ee+Of8A0Oeh/wDflf8A5Ho/4R745/8AQ56H/wB+
V/8AkevYKKAPH/8AhHvjn/0Oeh/9+V/+R6P+Ee+Of/Q56H/35X/5Hr2CigDx/wD4R745/wDQ56H/
AN+V/wDkej/hHvjn/wBDnof/AH5X/wCR69gooA8f/wCEe+Of/Q56H/35X/5Hq5pOhfGWHWbGXVPF
mjT6elxG11FHEoZ4gw3qP3A5K5HUfUV6pRQAUUUUAFFFFAHj/wCzj/yTzUP+wrJ/6Kir2CvH/wBn
H/knmof9hWT/ANFRV7BQAUUUUAFFFFABRRRQAV4/4h/5Oh8J/wDYKk/9Buq9grx/xD/ydD4T/wCw
VJ/6DdUAewUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB876HcPrf7Ud3JqZZXt
JriO1id8jEaFUwD2K5fA78+tfRFeY+LvhpezeNrTxv4WuYIdYgZWmtrnIjuMDaTuGSpK5B4OeOnf
rbbWPEN1G0beF5LS4GAHuLyIwk9yChZyO/Kgn2oA3Le3htYzHBGI0LvIQP7zMWY/iST+NS1BZx3E
VpGl3Os9wBl5FTYpOc8DJwOw5P1NT0AFFFFABXznqqXcn7VjrYTwQXRdPLknhMqL/oY6qGUnjP8A
EP6V9FnODgAntmvIbz4c+K2+MTeOrb+xXiDgrayXkqsQIRFywhODxnoaAO78IJqdpot2NfuIZb1L
2dppkG2PbuypAPQBdvXpjqetdJXF6taeOtXktLZINC06xNzE960d7LNLJErAsq5hQAkDHP0yK7Sg
AooooAKKKiuGnWBjbRxyS4+VZHKKT7kA/wAqAPmj4Ewa/PD4nXw9fWNrc+TDzdWzS7j+8xtIcbe/
JDdenFfQXhCOePwVoKXe77SunW6y7zlt/lruye5zXA/CT4b+IPh9e6m2oy6ZcQ3qxjNvPIWQoW7N
GAfvevavVwAoAAAA4AFAC0UUUAFFFFAHh37Sr3Y0HQkQD7EbqQyn/poFGz9DJXrHhfyIfBeiiyTf
brYQeUsZzlfLXGCT6epp/iTw5pvivQ59J1WHzLeXkEHDIw6Mp7EVh+H9F8UeEtEi0e0l03WbW2+S
2kupntJI4uyttSQNjpn5eKAJNL+IPh3XvEsuhWJuJdVtGkEkTW5Xyip2vljgcE46111eceDfhlce
HfHuseLLzUopZ9RaYi1hjO2PzJN5+YnJxgDoK9HoAKKKKACvn/8Aaa/5lb/t7/8AaNfQFeV/F34c
6/8AEGfShpsum28ViJstczyBnL7OyxnGNnr3oAt+Mbfxcvw51prnVNEe2GmymRItNlVyvlnIDGcg
HHfB+lZH7OP/ACTzUP8AsKyf+ioq7rxFpes6z4HvtHihsEvbu0a2Je5fy03Ltzny8nqe3pWJ8JvB
es+A/D91pWqPYTCW7a5WW1mdsZRFwQyL/c9e9AHoNFFFABRRSHODgAntmgD57uP+TuB/vp/6RCvo
WvJJfhx4lf40jxyH0n7KJFP2c3Mm/aIRF18rGe9etLuKjcAGxyAcgGgBaKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKAPH/ANnH/knmof8AYVk/9FRV7BXj/wCzj/yTzUP+wrJ/
6Kir2CgAooooAKKKKACiiigArx/xD/ydD4T/AOwVJ/6DdV7BXj/iH/k6Hwn/ANgqT/0G6oA9gooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8f/Zx/5J5qH/YVk/8ARUVewV4/+zj/AMk8
1D/sKyf+ioq9goAKKKKACiiigAooooAK8f8AEP8AydD4T/7BUn/oN1XsFeP+If8Ak6Hwn/2CpP8A
0G6oA9gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8f8A2cf+Seah/wBhWT/0VFXs
FeP/ALOP/JPNQ/7Csn/oqKvYKACiiigAooooAKKKKACvH/EP/J0PhP8A7BUn/oN1XsFeP+If+Tof
Cf8A2CpP/QbqgD2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDx/9nH/knmof9hWT
/wBFRV7BXj/7OP8AyTzUP+wrJ/6Kir2CgAooooAKKKKACiiigArx/wAQ/wDJ0PhP/sFSf+g3VewV
4v4vv7PTP2lfC15f3cFpax6U++aeQRouRcgZY8DJIH40Ae0UVz//AAnfg/8A6GvQ/wDwYw//ABVH
/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUA
dBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDw
Yw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8A
wYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A
6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//
AKGvQ/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//
AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAV
R/wnfg//AKGvQ/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xV
AHQUVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A
8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/
AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/
AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P
/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc/
/wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8A
FUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8
VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/
APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D
/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUAdBRXP/8ACd+D
/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDwYw//ABVH/Cd+
D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw//FUAdBRX
P/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ/wDwYw//
ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGvQ/8AwYw/
/FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnfg/8A6GvQ
/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB0FFc//wAJ34P/AOhr0P8A8GMP/wAVR/wnfg//AKGv
Q/8AwYw//FUAdBRXP/8ACd+D/wDoa9D/APBjD/8AFUf8J34P/wChr0P/AMGMP/xVAHQUVz//AAnf
g/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQB5/wDs4/8AJPNQ/wCwrJ/6Kir2CvH/ANnH
/knmof8AYVk/9FRV7BQAUUUUAFFFFABRRRQAVy/iT4d+FfF2ox3+uaV9ruo4hCr/AGiWPCAkgYRg
OrH866iigDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F7/yd
uP8A45R/wpL4ef8AQvf+Ttx/8cr0CigDz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xy
vQKKAPP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj/wCO
Uf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F7/yduP8A45R/wpL4ef8AQvf+Ttx/8cr0CigD
z/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xyvQKKAPP/APhSXw8/6F7/AMnbj/45R/wp
L4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8A
hSXw8/6F7/yduP8A45R/wpL4ef8AQvf+Ttx/8cr0CigDz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/
0L3/AJO3H/xyvQKKAPP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP
+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F7/yduP8A45R/wpL4ef8AQvf+
Ttx/8cr0CigDz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xyvQKKAPP/APhSXw8/6F7/
AMnbj/45R/wpL4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8A
xyvQKKAPP/8AhSXw8/6F7/yduP8A45R/wpL4ef8AQvf+Ttx/8cr0CigDz/8A4Ul8PP8AoXv/ACdu
P/jlH/Ckvh5/0L3/AJO3H/xyvQKKAPP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H/wAcr0Ci
gDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F7/yduP8A45R/
wpL4ef8AQvf+Ttx/8cr0CigDz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xyvQKKAPP/
APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh
5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F7/yduP8A45R/wpL4ef8AQvf+Ttx/8cr0CigDz/8A4Ul8
PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xyvQKKAPP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/
5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F
7/yduP8A45R/wpL4ef8AQvf+Ttx/8cr0CigDz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3
H/xyvQKKAPP/APhSXw8/6F7/AMnbj/45R/wpL4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj
/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAPP/8AhSXw8/6F7/yduP8A45R/wpL4ef8AQvf+Ttx/8cr0
CigDz/8A4Ul8PP8AoXv/ACduP/jlH/Ckvh5/0L3/AJO3H/xyvQKKAPP/APhSXw8/6F7/AMnbj/45
R/wpL4ef9C9/5O3H/wAcr0CigDz/AP4Ul8PP+he/8nbj/wCOUf8ACkvh5/0L3/k7cf8AxyvQKKAM
fw34W0bwjp0lhodn9ktZJTMyea8mXIAJy5J6KPyrYoooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/9k=

------_=_NextPart_001_01C54B76.1AFB6A05--


--=-hQRf0Q3zVd9WB3ufo6IT--

--=-hQRf0Q3zVd9WB3ufo6IT--

From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc: elkind@cadence.com, yonghao@cadence.com, jlp@cadence.com
Subject: Re: errata/659: errata $fullskew bugs
Date: Fri, 29 Apr 2005 14:11:41 +0300 (IDT)

Hi,

I have only had time to review in detail the $timeskew comments.
I only skimmed extremely quickly the $fullskew comments.
It seems Ted is backing the original proposal, where the remain active
flag would turn the timing checks dormant in both event and timer mode
if a reference event with condition false occurred.

This is a change from the current LRM for both timing checks and thus
not backward compatible completely with 1364-2001, but I also think it
makes the most sense. There have been a few cases where 1364-2005 is not
quite backward compatible with 1364-2001, notably generates and power
operator.

Can we achieve consensus? If we can acheive consensus and Yonghao will be
available next week, then I think he and I can work out final wording by the
end of the week.

Following are detailed comments about $timeskew.
(I wrote those comments first, then skimmed Ted's comments about $fullskew
afterwards, then wrote my above introductory comments. That order explains
what may seem like redundancies in my comments or memory loss.)

> From: "Ted Elkind" <elkind>
> To: "Yonghao Chen" <yonghao>
> Cc: "John Pierce" <jlp>
>
> About $timeskew
> ---------------
>
> I know $timeskew isn't under discussion, but while refreshing my memory
> about the timing checks I noticed a possible erratum in the $timeskew
> section. In diagram 46, transition F should occur after transition E,
> not simultaneous with it.

I noticed this, but the changes we passed included deleting the last sentence
of Case 2 and deleting Case 3 entirely (renumbering Case 4 as Case 3). With
those changes, F was no longer mentioned, making the timing ambiguity of F
unimportant.


> The CPN transitions afer E should be labeled
> G, H, I and J to accord with my rewrite of the descriptions for the four
> cases. This is similar to what is already there, but there are
> important differences:
>
> Case 1: Event based flag and remain active flag not set.
>
> After the first reference event on CP at A, a violation is reported
> at B as soon as 50 time units have passed. No further violations are
> reported.

This is the same as the current text.


> Case 2: Event based flag set, remain active flag not set.
>
> The negative transition on CPN at point C shall cause a timing
> violation, turning the $timeskew check dormant, and no further
> violations are reported. The second reference event at F occurs while
> MODE is false, so the $timeskew check remains dormant. (Note: this is
> same behavior as described in LRM, but different reasoning.)

This is consistent with the corrected text we passed, but clearer.
I support this text. This still does not make the timing of F relative to E
important.


> Case 3: Event based flag set, remain active flag set.
>
> The first three negative transitions on CPN at points C, D and E
> shall cause timing violations. The second reference event at F occurs
> while MODE is false, but because the remain active flag is set the
> $timeskew check remains active and so additional violations are reported
> at G, H, I and J. In other words, all CPN transitions cause violations.
> (Note: this is different behavior than described in the LRM.)

This is similar to what is described in Case 4 of 1364-2001, which is Case 3
after deleting the current Case 3.

However, it implies that if the remain active flag were 0, then the reference
event with condition false at F would turn the timing check dormant, which is
different from the current LRM and also different from $skew, which the LRM
states that $timeskew is the same as when both flags are set.
(again raising the
question as to why this mode is needed at all if it just duplicates $skew.)

Now case 2 is where the event based flag is 1 and the remain active flag is 0,
and in this case it does not make a difference, because the timing violation
at C turns the timing check dormant anyway.

Where it would make a difference whether a reference event with condition
false turns the timing check dormant or not is in the case where such a
reference event occurs before a timecheck event after the time limit.
If the reference event turns the timing check dormant, then a violation
would not be reported. If the reference event has no effect, as in the current
LRM, then a violation would be reported.


> Case 4: Event based flag not set, remain active flag set. (Note: this
> heading is different from the LRM.)
>
> After the first reference event on CP at A, a violation is reported
> at B as soon as 50 time units have passed. This is the same behavior as
> Case 1 because the remain active flag has no effect for the waveform in
> Figure 46. (Note: this is different behavior than described in the LRM.)

> In order to provide an example of the effect of the event based flag not
> being set while the remain active flag is set, the CP signal would have
> to experience a positive transition while MODE is true, then have MODE
> immediately go false, then have CP transition to 0 and back to 1, all
> before time B. The remain active flag would cause the check to remain
> active, and there would be a violation at time B.

This comment comes to say that the remain active flag does have an effect
where the event based flag is 0. This is different from the current LRM,
which implies that the remain active flag has no meaning in this mode.
The ballot comment also asserted that the remain active flag has no meaning
in this mode, but it seems that the balloter entity would consider another
definition. However, other entities should also be polled in order to
achieve consensus. Note that our schedule is very pressured.

Shalom


> About $fullskew
> ---------------
>
> In the $fullskew section in figure 47 on page 254, the waveform for CPN
> and the 70 unit time periods aligned with it should be shifted to the
> right. The CPN waveform should be in roughly the same position relative
> to the CP waveform as it is in figure 46. I've attached a corrected
> version of the figure as a jpeg file.
>
> The number of variables affecting $fullskew (two transition events which
> can occur in either order, possibly a condition on each, with possibly
> asymetric skew times and two flags affecting behavior) creates
> sufficient complexity that there is more than one way to define
> "correct" behavior. I can argue for my interpretation, but I don't
> think I could ever offer sufficient justification to prove it "correct."
>
> 1. The "remain active" flag was intended to have two effects:
>
> a) Do not make the check dormant after the first transition of the
> timecheck event causes a violation, but rather keep reporting further
> transitions of the timecheck event as violations. b) Do not make the
> check dormant after a transition of the timestamp event while its
> condition is false, but rather continue checking for violations.
>
> Both these effects are possible in "event based", but only (b) makes
> sense in "timer based" mode. In my view, the $timeskew check
> implementation in NC-Verilog is incorrect because it goes dormant when a
> transition occurs while the condition is false but the "remain active"
> flag is set.
>
> 2. The descriptions for "Case 1" and "Case 2" interpret the effect of
> the MODE condition on CP differently. "Case 1" says that timecheck
> events that occur while the timecheck condition is false are interpreted
> as missing timecheck events, and so it says the transition of CPN at F
> received a violation because although CP transitioned in time, the
> condition associated with CP (MODE) is false.
>
> But "Case 2" says that for transitions E through H (it actually says "B
> through H", but it really means "E through H") there are no positive
> transitions on CP while MODE is true, and so no violations are reported.
>
> "Case 2" is consistent with the behavior of the $skew and $timeskew
> checks and is correct. The description for "Case 1" should be modified
> appropriately.
>
> 3. Does the remain active flag have any impact? If I described a "Case
> 4" where the event based flag is not set but the remain active flag is
> set, the behavior would be identical to "Case 1". But that is only
> because the waveform in Figure 47 does not bring out the difference.
> Just as I described for $timeskew, if CP were to quickly transition a
> second time while MODE was false before B, then this would bring out the
> difference.
>

--
Shalom.Bresticker @freescale.com Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

Unformatted



Hosted by Boyd Technology