Your design process sounds like it works well for you. However,
it sounds as though you have a captive foundry, i.e., they
do what you ask of them - within reason of course.
What does the SI designer do that has no influence
to change the I/O design as is the case with purchasing
off-the-shelf parts? We often contemplate tuning the output
buffer impedance to the transmission line impedance with the
use of series discrete resistors. But this approach is messy
when the pin count gets high. And the buffers are apparently
designed for LVTTL in that the pull-up impedance is usually
much different than the pull-down impedance. Nevertheless,
we seem to be able to get by for 100Mhz designs.
Mije
On Jul 14, 2:56pm, Jonathan Dowling wrote:
> Subject: Re: [SI-LIST] : Some Semiconductors are Unnecessarily Fast
> Gentle SI-List Demons,
>
> The 'spec' based I/O buffer design is the best way I've
> found to design high speed interfaces. The way it works
> is as follows:
>
> 1. I/O design determines various strengths/edge-rates/
> pad delays which are possible to fabricate.
>
> 2. Interconnect design performs pre-layout simulation
> to determine a desired range of strength/edge-rate/
> pad delay for the I/O.
>
> 3. I/O design and interconnect design agree on a range
> of operation for the I/O buffer which is a) possible
> to fabricate and b) meets the bus interface Timing/SI
> requirements over all PVT. Interestingly, the 'spec'
> model does not have to line up exactly with the actual
> buffer's performance. The only requirement is that the
> 'spec' model envelope the I/O buffer performance at all
> PVT. E.g. If the timings are loose, the slow corner
> 'spec' could have extra margin to anticipate a poor
> silicon process. Tester guardbands can be introduced
> into the 'spec' model, etc.
>
> Throughout the remainder of the design process, detailed
> timing/SI analysis is then performed with the 'spec'
> buffer with the knowledge that the I/O design will
> eventually fit inside the prescribed box (whether it be
> the 1st, 2nd, or 3rd silicon tapeout). If the I/O
> buffer comes in off-target, it will change in the next
> spin of silicon rather than the interconnect. This method
> prevents the major headache of constantly spinning new
> sets of models every time the I/O design is tweaked.
> The time savings is important because typically there
> is only enough design time to perform a decent bus
> interface timing/SI margin analysis once in the process.
>
> I/O design benefits by having fixed requirements to
> target. If the bus interface requires impedance
> controlled or slew-rate controlled drivers, I/O design
> is made aware of it early in the process. Interconnect
> design benefits because a fixed set of models is
> necessary to perform a detailed analysis which will have
> lasting meaning. Due to an unforseen problem, the 'spec'
> models may have to change during the design process.
> Typically these changes are slight adjustments rather than
> major alterations and will not mandate a project RESET#.
>
> The beauty of behavioral modeling is that it is easy to
> alter the strength/edge-rate and run a quick sim. As Roy
> suggests, the interconnect designer can be proactive
> rather than reactive in the process by influencing the
> I/O design early enough to make a difference.
>
> Many successful high speed bus interfaces have been
> designed with the 'spec' based modeling method. It
> lends itself well to timely Monte Carlo and/or margin
> analyses.
>
> The 'Spec' based modeling method does not lend itself to
> exact correlation of interconnect simulation to lab
> measurement because slow/fast PVT corners are difficult
> to reproduce in a lab environment. However, designers
> can verify that the I/O performance fits within the
> allowable range by making measurements under various
> switching conditions. I have been willing to accept this
> limitation given that detailed correlation work is
> extremely time consuming and is not supported by real
> world design schedules. (It's good for graduate school
> thesis work, seminar presentations, simulation tool
> algorithm development, etc. where timeliness is not an
> issue.)
>
> Jonathan Dowling
>
>
-- _______________________________________________________________ Mike Degerstrom Email: [email protected] Mayo Clinic 200 1st Street SW Gugg. Bldg. RM 1042A Phone: (507) 284-3292 Rochester, MN 55905 FAX: (507) 284-9171 WWW: http://www.mayo.edu/sppdg/sppdg_home_page.html _______________________________________________________________**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****