From: Mike LaBonte ([email protected])
Date: Thu May 25 2000 - 06:56:25 PDT
The IBIS description of [Driver Schedule] operation has no special
provision for "multi-cycle bursts". If a PMOS is scheduled to turn
off after 10ns, it will do so in every cycle. To properly model
the case where the first cycle of a burst is handled differently,
IBIS would need separate sets of [Driver Schedule] delay values for
the first cycle and subsequent cycles.
As it stands, a [Driver Schedule] model that keeps a PMOS on for 4ns,
when run at 100MHz, will turn the PMOS on *every* 10ns and will begin
turning the PMOS off 1ns before *every* fall cycle begins. This is
not the scenario that Scott describes for actual bus operation.
Mike
Scott McMorrow wrote:
>
> Actually the model is correct. Most likely it is being used incorrectly
> in the simulator.
>
> The PIII processor uses AGTL+ (assisted GTL+) driver. The assisted
> part is a p-channel "kicker" stage to help rising edge performance.
> Since the bus is "open-collector" in principal this output stage is
> designed to emulate open collector behavior after the first cycle.
> The p-channel driver is fired on the first cycle of a multicycle burst
> and is then disable. This is the behavior which should be
> replicated in the [Driver Schedule] Section of the IBIS model.
>
> Since this is and IBIS 3.2 feature and not all simulators can
> use Version 3.2 models with the Driver Schedule section, the
> IBIS model must support version 2.1 simulators also, for backwards
> compatability. As a result, the main body of the model indicates
> that it is open collector. This is correct, since it is the closest
> IBIS 2.1 approximation to the actual behavior of this buffer. The
> Driver Schedule section is just ignored.
>
> However, with an IBIS 3.2 capable simulator the Driver Schedule
> section for the p-channel will provide the proper control of the
> output, turning it on at the beginning of the cycle and then
> turning it off 10 ns later for a 100 MHz bus (or 7.5ns later for
> a 133 MHz bus). This may not be well documented in the
> model or in the Intel literature. Basically the buffer should turn
> off at the end of one full clock cycle.
>
> Most likely the turn off delay in the model is incorrect for the
> bus speed you are simulating, or the simulator is incorrectly
> using this model.
>
> best regards,
>
> scott
>
> --
> Scott McMorrow
> Principal Engineer
> SiQual, Signal Quality Engineering
> 18735 SW Boones Ferry Road
> Tualatin, OR 97062-3090
> (503) 885-1231
> http://www.siqual.com
**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****
This archive was generated by hypermail 2b29 : Wed Nov 22 2000 - 10:50:28 PST