From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: High speed clock routing Date: Fri, 15 Mar 2002 12:42:47 -0500 Organization: Arius, Inc Lines: 40 Message-ID: <3C923297.57531263@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaJoaN0tlNTV2ufWTz7x4dCmgRyyZqgms42sZuQdYoyMlRHb8+611pz X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 15 Mar 2002 17:41:51 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15329 I need to plan a high speed bus that will connect 5 devices. They will all be very closely spaced so that the lengths of the routes can be kept pretty short. The clock line is the one I am most concerned about. It is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if you keep it square (as layout guys like to do). The other signals are within the box these two points inscribe. Another approach would be to daisy chain them which would make the total run about 3 inches. What type of termination could I expect to work well with this type of run? With such short runs, I was thinking about using no termination with a star topology. I am not even sure I need to worry about keeping the net delays equal since the variation will be less than +- 1 inch or about 100 pS of clock skew. Anyone have much experience with running high speed clocks on such short runs? Can I expect this to work well? I know Austin will tell me to simulate it, which I plan to do. I am just trying to get a "gut" feeling as Bob Pease would want to do. You know how easy it is to get the WRONG, right answer from a computer. GIGO. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Magnus Homann Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 15 Mar 2002 19:01:05 +0100 Organization: Chalmers univ. of Technology Lines: 16 Message-ID: References: <3C923297.57531263@yahoo.com> NNTP-Posting-Host: mis.dtek.chalmers.se X-Trace: nyheter.chalmers.se 1016215266 2263 129.16.30.55 (15 Mar 2002 18:01:06 GMT) X-Complaints-To: abuse@chalmers.se NNTP-Posting-Date: 15 Mar 2002 18:01:06 GMT X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.wirehub.nl!easynet-monga!easynet.net!news.ebone.net!news1.ebone.net!newsfeed.sunet.se!news01.sunet.se!news.chalmers.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15305 rickman writes: > I need to plan a high speed bus that will connect 5 devices. They will > all be very closely spaced so that the lengths of the routes can be kept > pretty short. The clock line is the one I am most concerned about. It > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. Is this differential? In that case I would go for daisychaining and termination at the end. SHORT stubs at intermediate devices. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Fri, 15 Mar 2002 13:05:28 -0500 Organization: Arius, Inc Lines: 31 Message-ID: <3C9237E8.8D818B3A@yahoo.com> References: <3C923297.57531263@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYMxBZap56R4kgOpVYwVNYx/pT6EAbDLZtahPWKzJE8dWIG4JVdvzCN X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 15 Mar 2002 18:04:48 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15272 Magnus Homann wrote: > > rickman writes: > > > I need to plan a high speed bus that will connect 5 devices. They will > > all be very closely spaced so that the lengths of the routes can be kept > > pretty short. The clock line is the one I am most concerned about. It > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > Is this differential? In that case I would go for daisychaining and > termination at the end. SHORT stubs at intermediate devices. > > Homann No this is not differential. This is LVTTL. BTW, what do you mean by SHORT? Is that anything like telling someone to pay CAREFULL attention to signal routing? :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Fri, 15 Mar 2002 15:08:16 -0500 Organization: Arius, Inc Lines: 125 Message-ID: <3C9254B0.9C6F0700@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVb39uqYZz41mjgn2g+WBvmJ+1iLxAZKzZTnAwGH2o4mGQB4/RAlCPeu X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 15 Mar 2002 20:07:36 GMT To: john@yahoo.com X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15330 Austin, thanks for the simulation. This looks like great data. But I am not sure if you were trying to help by doing my simulation for me, or if you were just trying to show what the tool can do. I am not clear about what this is simulating. Obviously you used the daisy chain model, but how do you know what to use as a trace impedance and where did the delays come from? The preliminary layout I am using has the following delays in the daisy chain case, assuming 100pS per inch. Is that a valid assumption? DSP to FPGA 100pS FPGA to SDRAM1 50pS SDRAM1 to SDRAM2 50pS SDRAM2 to SBSRAM 100pS Don't I need to caclulate the trace impedance from the PCB design rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 layers with a total thickness of 0.062". Of course, I can use wider traces for the clock and control which layer they are on. I would expect these four loads to behave much better than the five loads with 200+ pS delays. If you were just trying to demonstate the tool, that's fine. But if you were trying to simulate my case, these are the data that should be used. When I am done my other work today, I will try downloading the software and giving it a try this weekend or next week. Austin Lesea wrote: > > Rick, > > [Image] > > Parallel termination (shown above) is great for daisy chained clocks. > Of course, you have to deal with the timing, and the delays (or > skews). > > Another great thing that is easy to do in HyperLynx using IBIS models. > > Austin > > PS: > > Here is no termination .... > [Image] > > Note some devices don't get any clocks at all ..... > > > rickman wrote: > > > I need to plan a high speed bus that will connect 5 devices. They > > will > > all be very closely spaced so that the lengths of the routes can be > > kept > > pretty short. The clock line is the one I am most concerned about. > > It > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an > > SBSRAM, > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y > > if > > you keep it square (as layout guys like to do). The other signals > > are > > within the box these two points inscribe. > > > > Another approach would be to daisy chain them which would make the > > total > > run about 3 inches. What type of termination could I expect to work > > > > well with this type of run? > > > > With such short runs, I was thinking about using no termination with > > a > > star topology. I am not even sure I need to worry about keeping the > > net > > delays equal since the variation will be less than +- 1 inch or > > about > > 100 pS of clock skew. > > > > Anyone have much experience with running high speed clocks on such > > short > > runs? Can I expect this to work well? > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > > just trying to get a "gut" feeling as Bob Pease would want to do. > > You > > know how easy it is to get the WRONG, right answer from a computer. > > GIGO. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the > > XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### Message-ID: <3C925BF8.E3CEC021@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 152 Date: Fri, 15 Mar 2002 20:39:20 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1016224760 192.65.17.17 (Fri, 15 Mar 2002 13:39:20 MST) NNTP-Posting-Date: Fri, 15 Mar 2002 13:39:20 MST Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!usenetserver.com!newsfeed2.earthlink.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!sjc1.nntp.concentric.net!newsfeed.concentric.net!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15337 85 ps per inch works for free space. A better approximation would be 170 ps per inch for internal traces where the relative permitivity of about 4 for FR4 material at high frequency gives a good approximation (sqrt(4) for scaling to free space). The outside traces are a bit faster because they're propagating through a combination of air and FR4 - I don't have the numbers handy for those speeds. You're right about the stackup being important - the trace widths and plane spacings need to be well specified by you to get the board house to provide impedances that won't over/undershoot. A little mistermination is fine - the mid-transition reversals are what kills; those can occur when the driver sees a low impedance for much of the risetime but gets the reflection coming back before the clock's out of the transition region. There's the beauty of SI - this general info gets applied. With everything close and distributed capacitance throughout, you could get smooth transitions with the star configuration, but it's dependent on the drivers and input capacitance. Are independent clocks from the FPGA something you want to avoid? "Zero delay buffers" are part of the clock management's best application. It's often better from a debug standpoint to have access to individual terminations if things go desperately wrong. rickman wrote: > Austin, thanks for the simulation. > > This looks like great data. But I am not sure if you were trying to > help by doing my simulation for me, or if you were just trying to show > what the tool can do. > > I am not clear about what this is simulating. Obviously you used the > daisy chain model, but how do you know what to use as a trace impedance > and where did the delays come from? The preliminary layout I am using > has the following delays in the daisy chain case, assuming 100pS per > inch. Is that a valid assumption? > > DSP to FPGA 100pS > FPGA to SDRAM1 50pS > SDRAM1 to SDRAM2 50pS > SDRAM2 to SBSRAM 100pS > > Don't I need to caclulate the trace impedance from the PCB design > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > layers with a total thickness of 0.062". Of course, I can use wider > traces for the clock and control which layer they are on. > > I would expect these four loads to behave much better than the five > loads with 200+ pS delays. > > If you were just trying to demonstate the tool, that's fine. But if you > were trying to simulate my case, these are the data that should be > used. > > When I am done my other work today, I will try downloading the software > and giving it a try this weekend or next week. > > Austin Lesea wrote: > > > > Rick, > > > > [Image] > > > > Parallel termination (shown above) is great for daisy chained clocks. > > Of course, you have to deal with the timing, and the delays (or > > skews). > > > > Another great thing that is easy to do in HyperLynx using IBIS models. > > > > Austin > > > > PS: > > > > Here is no termination .... > > [Image] > > > > Note some devices don't get any clocks at all ..... > > > > > > rickman wrote: > > > > > I need to plan a high speed bus that will connect 5 devices. They > > > will > > > all be very closely spaced so that the lengths of the routes can be > > > kept > > > pretty short. The clock line is the one I am most concerned about. > > > It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an > > > SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y > > > if > > > you keep it square (as layout guys like to do). The other signals > > > are > > > within the box these two points inscribe. > > > > > > Another approach would be to daisy chain them which would make the > > > total > > > run about 3 inches. What type of termination could I expect to work > > > > > > well with this type of run? > > > > > > With such short runs, I was thinking about using no termination with > > > a > > > star topology. I am not even sure I need to worry about keeping the > > > net > > > delays equal since the variation will be less than +- 1 inch or > > > about > > > 100 pS of clock skew. > > > > > > Anyone have much experience with running high speed clocks on such > > > short > > > runs? Can I expect this to work well? > > > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > > > > just trying to get a "gut" feeling as Bob Pease would want to do. > > > You > > > know how easy it is to get the WRONG, right answer from a computer. > > > GIGO. > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the > > > XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Magnus Homann Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 15 Mar 2002 22:17:43 +0100 Organization: Chalmers univ. of Technology Lines: 33 Message-ID: References: <3C923297.57531263@yahoo.com> <3C9237E8.8D818B3A@yahoo.com> NNTP-Posting-Host: mis.dtek.chalmers.se X-Trace: nyheter.chalmers.se 1016227065 3374 129.16.30.55 (15 Mar 2002 21:17:45 GMT) X-Complaints-To: abuse@chalmers.se NNTP-Posting-Date: 15 Mar 2002 21:17:45 GMT X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news-peer-europe.sprintlink.net!news.sprintlink.net!newsfeed.sunet.se!news01.sunet.se!news.chalmers.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15334 rickman writes: > Magnus Homann wrote: > > > > rickman writes: > > > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > Is this differential? In that case I would go for daisychaining and > > termination at the end. SHORT stubs at intermediate devices. > > > > Homann > > No this is not differential. This is LVTTL. Ah, in that case I would ask my boss to be put on another project... Or use a zero-delay clock buffer (PLL/DLL), if possible. > BTW, what do you mean by > SHORT? Is that anything like telling someone to pay CAREFULL attention > to signal routing? :) EXACTLY :-) Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Fri, 15 Mar 2002 14:42:14 -0800 Organization: Xilinx Lines: 134 Message-ID: <3C9278C6.8B94964B@xilinx.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.cwix.com!news.maxwell.syr.edu!news.stealth.net!news.stealth.net!news-east.rr.com!news-west.rr.com!border1.nntp.aus1.giganews.com!nntp2.aus1.giganews.com!nntp.giganews.com!NetNews1!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15343 Rick, Just showing an example, you need your own IBIS models for each driver and receiver, and of course, your pcb trace lengths and impedances, or their widths and spacing, and the pcb stackup. Austin rickman wrote: > Austin, thanks for the simulation. > > This looks like great data. But I am not sure if you were trying to > help by doing my simulation for me, or if you were just trying to show > what the tool can do. > > I am not clear about what this is simulating. Obviously you used the > daisy chain model, but how do you know what to use as a trace impedance > and where did the delays come from? The preliminary layout I am using > has the following delays in the daisy chain case, assuming 100pS per > inch. Is that a valid assumption? > > DSP to FPGA 100pS > FPGA to SDRAM1 50pS > SDRAM1 to SDRAM2 50pS > SDRAM2 to SBSRAM 100pS > > Don't I need to caclulate the trace impedance from the PCB design > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > layers with a total thickness of 0.062". Of course, I can use wider > traces for the clock and control which layer they are on. > > I would expect these four loads to behave much better than the five > loads with 200+ pS delays. > > If you were just trying to demonstate the tool, that's fine. But if you > were trying to simulate my case, these are the data that should be > used. > > When I am done my other work today, I will try downloading the software > and giving it a try this weekend or next week. > > Austin Lesea wrote: > > > > Rick, > > > > [Image] > > > > Parallel termination (shown above) is great for daisy chained clocks. > > Of course, you have to deal with the timing, and the delays (or > > skews). > > > > Another great thing that is easy to do in HyperLynx using IBIS models. > > > > Austin > > > > PS: > > > > Here is no termination .... > > [Image] > > > > Note some devices don't get any clocks at all ..... > > > > > > rickman wrote: > > > > > I need to plan a high speed bus that will connect 5 devices. They > > > will > > > all be very closely spaced so that the lengths of the routes can be > > > kept > > > pretty short. The clock line is the one I am most concerned about. > > > It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an > > > SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y > > > if > > > you keep it square (as layout guys like to do). The other signals > > > are > > > within the box these two points inscribe. > > > > > > Another approach would be to daisy chain them which would make the > > > total > > > run about 3 inches. What type of termination could I expect to work > > > > > > well with this type of run? > > > > > > With such short runs, I was thinking about using no termination with > > > a > > > star topology. I am not even sure I need to worry about keeping the > > > net > > > delays equal since the variation will be less than +- 1 inch or > > > about > > > 100 pS of clock skew. > > > > > > Anyone have much experience with running high speed clocks on such > > > short > > > runs? Can I expect this to work well? > > > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > > > > just trying to get a "gut" feeling as Bob Pease would want to do. > > > You > > > know how easy it is to get the WRONG, right answer from a computer. > > > GIGO. > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the > > > XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Fri, 15 Mar 2002 18:22:57 -0500 Organization: Arius, Inc Lines: 109 Message-ID: <3C928251.239BEAC2@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZNll4RajC34U2nIEBjOoFfstqDlxuYGgR/XwE2AeTxN3n8jxR31XW2 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 15 Mar 2002 23:22:15 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!howland.erols.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15376 Thanks for your comments John. I guess I am a little green with clocks above 50 MHz. I was expecting runs this short to be pretty simple and not to have to do too much to make it work. But with the input from Austin and yourself as well as some others, I do at least plan to take a first pass at a simulation. My main concern is that you have to know a lot of details about the board to run a USEFUL simulation. I have learned a lot from reading some of Bob Pease's articles and I fully realize that a simulation won't do me a lick of good if I don't make all the right assumptions. I have been working on a very tightly packed switching power supply while I am doing the digital stuff and I am finding that I can make it look pretty feasible if I make THESE assumptions and I can make it look pretty impossible if I make THOSE assumptions. I think we won't really know how well it will work until we fire it up on the final board layout. I expect that we will see the same sort of thing with this clock design. I did consider using a zero delay buffer. But this board is very tight for space and I have a hard time justifying it with 1.5 inch traces. But if the simulation shows a problem, of course we will do what we have to. The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max. This is another difference between the simulation Austin did and what I have. He seems to have used all VII inputs with 10 pF capacitance. It is also not clear to me if the simulations are being done with typical values or worst case values. If typ values are used, then I don't see how the results have any meaning at all. Rick Collins John_H wrote: > > 85 ps per inch works for free space. A better approximation would be 170 ps > per inch for internal traces where the relative permitivity of about 4 for > FR4 material at high frequency gives a good approximation (sqrt(4) for > scaling to free space). The outside traces are a bit faster because they're > propagating through a combination of air and FR4 - I don't have the numbers > handy for those speeds. > > You're right about the stackup being important - the trace widths and plane > spacings need to be well specified by you to get the board house to provide > impedances that won't over/undershoot. A little mistermination is fine - > the mid-transition reversals are what kills; those can occur when the > driver sees a low impedance for much of the risetime but gets the reflection > coming back before the clock's out of the transition region. There's the > beauty of SI - this general info gets applied. > > With everything close and distributed capacitance throughout, you could get > smooth transitions with the star configuration, but it's dependent on the > drivers and input capacitance. > > Are independent clocks from the FPGA something you want to avoid? "Zero > delay buffers" are part of the clock management's best application. It's > often better from a debug standpoint to have access to individual > terminations if things go desperately wrong. > > rickman wrote: > > > Austin, thanks for the simulation. > > > > This looks like great data. But I am not sure if you were trying to > > help by doing my simulation for me, or if you were just trying to show > > what the tool can do. > > > > I am not clear about what this is simulating. Obviously you used the > > daisy chain model, but how do you know what to use as a trace impedance > > and where did the delays come from? The preliminary layout I am using > > has the following delays in the daisy chain case, assuming 100pS per > > inch. Is that a valid assumption? > > > > DSP to FPGA 100pS > > FPGA to SDRAM1 50pS > > SDRAM1 to SDRAM2 50pS > > SDRAM2 to SBSRAM 100pS > > > > Don't I need to caclulate the trace impedance from the PCB design > > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > > layers with a total thickness of 0.062". Of course, I can use wider > > traces for the clock and control which layer they are on. > > > > I would expect these four loads to behave much better than the five > > loads with 200+ pS delays. > > > > If you were just trying to demonstate the tool, that's fine. But if you > > were trying to simulate my case, these are the data that should be > > used. > > > > When I am done my other work today, I will try downloading the software > > and giving it a try this weekend or next week. ...snip... -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Fri, 15 Mar 2002 15:47:30 -0800 Organization: Xilinx Lines: 131 Message-ID: <3C928812.3A8A5CCD@xilinx.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!logbridge.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15345 Rick, Use the fast/strong IBIS corner, and that covers the worst case for process/voltage/temperature. The capactances don't matter all that much (convince yourself by changing them, and you will see that the results don't change much at all). The claim of IBIS simulator vendors is that it saves all of the PCB spins to fix SI, and they are right. The sims are not that fussy, and all you need to be sure of are the parts and their models, and the PCB impedance and the lengths. Input models are not fussy either, hence my use of VII for all inputs is probably +/- 10% of the real measured result. All CMOS inputs look pretty much the same. If you have wide buses, then crosstalk is important, and you need a little more detail for the geometry. Austin rickman wrote: > Thanks for your comments John. > > I guess I am a little green with clocks above 50 MHz. I was expecting > runs this short to be pretty simple and not to have to do too much to > make it work. But with the input from Austin and yourself as well as > some others, I do at least plan to take a first pass at a simulation. > My main concern is that you have to know a lot of details about the > board to run a USEFUL simulation. I have learned a lot from reading > some of Bob Pease's articles and I fully realize that a simulation won't > do me a lick of good if I don't make all the right assumptions. > > I have been working on a very tightly packed switching power supply > while I am doing the digital stuff and I am finding that I can make it > look pretty feasible if I make THESE assumptions and I can make it look > pretty impossible if I make THOSE assumptions. I think we won't really > know how well it will work until we fire it up on the final board > layout. I expect that we will see the same sort of thing with this > clock design. > > I did consider using a zero delay buffer. But this board is very tight > for space and I have a hard time justifying it with 1.5 inch traces. > But if the simulation shows a problem, of course we will do what we have > to. > > The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max. > This is another difference between the simulation Austin did and what I > have. He seems to have used all VII inputs with 10 pF capacitance. > > It is also not clear to me if the simulations are being done with > typical values or worst case values. If typ values are used, then I > don't see how the results have any meaning at all. > > Rick Collins > > John_H wrote: > > > > 85 ps per inch works for free space. A better approximation would be 170 ps > > per inch for internal traces where the relative permitivity of about 4 for > > FR4 material at high frequency gives a good approximation (sqrt(4) for > > scaling to free space). The outside traces are a bit faster because they're > > propagating through a combination of air and FR4 - I don't have the numbers > > handy for those speeds. > > > > You're right about the stackup being important - the trace widths and plane > > spacings need to be well specified by you to get the board house to provide > > impedances that won't over/undershoot. A little mistermination is fine - > > the mid-transition reversals are what kills; those can occur when the > > driver sees a low impedance for much of the risetime but gets the reflection > > coming back before the clock's out of the transition region. There's the > > beauty of SI - this general info gets applied. > > > > With everything close and distributed capacitance throughout, you could get > > smooth transitions with the star configuration, but it's dependent on the > > drivers and input capacitance. > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > delay buffers" are part of the clock management's best application. It's > > often better from a debug standpoint to have access to individual > > terminations if things go desperately wrong. > > > > rickman wrote: > > > > > Austin, thanks for the simulation. > > > > > > This looks like great data. But I am not sure if you were trying to > > > help by doing my simulation for me, or if you were just trying to show > > > what the tool can do. > > > > > > I am not clear about what this is simulating. Obviously you used the > > > daisy chain model, but how do you know what to use as a trace impedance > > > and where did the delays come from? The preliminary layout I am using > > > has the following delays in the daisy chain case, assuming 100pS per > > > inch. Is that a valid assumption? > > > > > > DSP to FPGA 100pS > > > FPGA to SDRAM1 50pS > > > SDRAM1 to SDRAM2 50pS > > > SDRAM2 to SBSRAM 100pS > > > > > > Don't I need to caclulate the trace impedance from the PCB design > > > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > > > layers with a total thickness of 0.062". Of course, I can use wider > > > traces for the clock and control which layer they are on. > > > > > > I would expect these four loads to behave much better than the five > > > loads with 200+ pS delays. > > > > > > If you were just trying to demonstate the tool, that's fine. But if you > > > were trying to simulate my case, these are the data that should be > > > used. > > > > > > When I am done my other work today, I will try downloading the software > > > and giving it a try this weekend or next week. > > ...snip... > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Fri, 15 Mar 2002 15:48:21 -0800 Organization: Xilinx Lines: 31 Message-ID: <3C928845.5D811DF@xilinx.com> References: <3C923297.57531263@yahoo.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15340 Falk, Yes. But, if the lengths are all real short, and the rise time fairly slow, perhaps no termination at all is needed. Austin Falk Brunner wrote: > "Magnus Homann" schrieb im Newsbeitrag > news:ltg03190da.fsf@mis.dtek.chalmers.se... > > rickman writes: > > > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > Is this differential? In that case I would go for daisychaining and > > termination at the end. SHORT stubs at intermediate devices. > > Isnt end termination the ONLY clean way when daisy-chaining??? (According to > the "bible" from Howard Johnson) > > Regards > Falk ###### Message-ID: <3C929234.EAAE130B@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 20 Date: Sat, 16 Mar 2002 00:30:42 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1016238642 192.65.17.17 (Fri, 15 Mar 2002 17:30:42 MST) NNTP-Posting-Date: Fri, 15 Mar 2002 17:30:42 MST Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15375 When I quoted the zero delay buffers, I was trying to point you back into the FPGA. The DLLs and DCMs can produce clocks that are very nicely phase related to a single clock, duplicating the functionality of a zero delay buffer without an external part. rickman wrote: > I did consider using a zero delay buffer. But this board is very tight > for space and I have a hard time justifying it with 1.5 inch traces. > But if the simulation shows a problem, of course we will do what we have > to. > > John_H wrote: > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > delay buffers" are part of the clock management's best application. It's > > often better from a debug standpoint to have access to individual > > terminations if things go desperately wrong. ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Sat, 16 Mar 2002 00:42:42 -0500 Organization: Arius, Inc Lines: 38 Message-ID: <3C92DB52.DE42CC74@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> <3C929234.EAAE130B@mail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaMn80eGUclHGP1wqSDrJWaO0PEQMwuroD4TXmQIA084Wxx6Ja+Q1ZY X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 16 Mar 2002 05:41:53 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15339 I have other uses for the clock buffers, like bringing clocks into the chip. In fact, I would like to have six low skew clock inputs, but there are only four on the XC2Se I will be using. John_H wrote: > > When I quoted the zero delay buffers, I was trying to point you back into the > FPGA. The DLLs and DCMs can produce clocks that are very nicely phase related to > a single clock, duplicating the functionality of a zero delay buffer without an > external part. > > rickman wrote: > > > I did consider using a zero delay buffer. But this board is very tight > > for space and I have a hard time justifying it with 1.5 inch traces. > > But if the simulation shows a problem, of course we will do what we have > > to. > > > > John_H wrote: > > > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > > delay buffers" are part of the clock management's best application. It's > > > often better from a debug standpoint to have access to individual > > > terminations if things go desperately wrong. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: hmurray-nospam@megapathdsl.net (Hal Murray) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Sat, 16 Mar 2002 06:20:46 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> X-Complaints-To: newsabuse@supernews.com Lines: 48 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!feed.cgocable.net!newsfeed-tor.nnrp.ca!newsfeed-tor.nnrp.ca!news.gv.tsc.tdk.com!sn-xit-02!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray-nospam Xref: chonsp.franklin.ch comp.arch.fpga:15353 >I guess I am a little green with clocks above 50 MHz. I was expecting >runs this short to be pretty simple and not to have to do too much to >make it work. But with the input from Austin and yourself as well as >some others, I do at least plan to take a first pass at a simulation. >My main concern is that you have to know a lot of details about the >board to run a USEFUL simulation. I have learned a lot from reading >some of Bob Pease's articles and I fully realize that a simulation won't >do me a lick of good if I don't make all the right assumptions. Clock frequency isn't the critical parameter. You need to worry about edge rate. You would have the same troubles if you tried to run your collection of chips at half speed. If the round trip time is less than 1/Nth of your transition time, then you can treat everything as a lumped capacitor. Also remember that transmission lines go much slower if you add lumped capacitors along them. For things like this, I highly recommend: High-Speed Digital Design - A Handbook of Black Magic by Johnson and Graham The examples are a bit out of date now, but the methods of thinking about a problem are correct. It's a very educational book - fun to read and (generally) easy to understand. It's the sort of book that I can pick up to check something and get sucked into reading another chapter or two just because I see an interesting graph abd stop to check it out. (like stopping to chat when you meet an old friend) A more modern version is: High-Speed Digital System Design A Handbook of Interconnect Theory and Design Practices by Hall, Hall, and McCall I'm not as familiar with this. It looks good, but doesn't seem to be as much fun to read. Lots of good/new stuff. -- These are my opinions, not necessarily my employer's. I hate spam. ###### From: Jonathan Kirwan Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Message-ID: <3oq59u8798hbf79ss5bif295dckj6jk2ak@4ax.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 13 NNTP-Posting-Host: 12.224.242.116 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc02 1016261428 12.224.242.116 (Sat, 16 Mar 2002 06:50:28 GMT) NNTP-Posting-Date: Sat, 16 Mar 2002 06:50:28 GMT Organization: AT&T Broadband Date: Sat, 16 Mar 2002 06:50:28 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!wn2feed!wn1feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc02.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15367 On Sat, 16 Mar 2002 06:20:46 -0000, hmurray-nospam@megapathdsl.net (Hal Murray) wrote: >A more modern version is: > > High-Speed Digital System Design > A Handbook of Interconnect Theory and Design Practices > by Hall, Hall, and McCall I'll take a look at it, too. Thanks. I agree about your comments on Johnson and Graham's book. Jon ###### From: Magnus Homann Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 16 Mar 2002 12:35:08 +0100 Organization: Chalmers univ. of Technology Lines: 54 Message-ID: References: <3C923297.57531263@yahoo.com> <3C9237E8.8D818B3A@yahoo.com> NNTP-Posting-Host: mis.dtek.chalmers.se X-Trace: nyheter.chalmers.se 1016278510 5380 129.16.30.55 (16 Mar 2002 11:35:10 GMT) X-Complaints-To: abuse@chalmers.se NNTP-Posting-Date: 16 Mar 2002 11:35:10 GMT X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.gamma.ru!Gamma.RU!news.algonet.se!algonet!newsfeed1.uni2.dk!news.net.uni-c.dk!newsfeed.sunet.se!news01.sunet.se!news.chalmers.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15363 "Falk Brunner" writes: > "Magnus Homann" schrieb im Newsbeitrag > news:ltsn71cyyw.fsf@mis.dtek.chalmers.se... > > > > Is this differential? In that case I would go for daisychaining and > > > > termination at the end. SHORT stubs at intermediate devices. > > > > > > > > Homann > > > > > > No this is not differential. This is LVTTL. > > > > Ah, in that case I would ask my boss to be put on another project... > > You are a big Sissy. > > SCNR. ;-)) Nah, just lazy. > A little bit more serious, is a 100 MHz LVTTL clock propagating some inches > on a FR4 board that difficult to handle?? I mean, sure, lots of things can > go wrong if you dont know what you are doing, BUT Was it LVTTL? The headache start when you don't have point-to-point clocks. With P2P, it is much easier. Slap in a series termination resistor, and adjust as apropriate. Daisy-chaining works quite well, but it is a bit harder to route, and you get clock skew between devices. Star-topology? Well, in some cases. > Two guys in our company designed a board with a big communication processor, > with 3 fast SDRAM/SSRAM/ZBTRAM busses (100-133 MHz). They did NO simulation, > "just" had an eye at the layout and followed the basic guidelines that apply > on this kind of stuff. And you wont believe it, it worked on the first run, > almost perfect, just some minor modification of termination resistors and > some clock line (length) modification. As long as you know what you're doing. > Your comment, Austin?? ;-) > > > Or use a zero-delay clock buffer (PLL/DLL), if possible. > > No problem, there are at least 4 inside the FPGA, Virtex-E/-II has even > more. Unless they have to be independent of the FPGA, of course. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se ###### From: Magnus Homann Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 16 Mar 2002 12:35:51 +0100 Organization: Chalmers univ. of Technology Lines: 25 Message-ID: References: <3C923297.57531263@yahoo.com> NNTP-Posting-Host: mis.dtek.chalmers.se X-Trace: nyheter.chalmers.se 1016278552 5380 129.16.30.55 (16 Mar 2002 11:35:52 GMT) X-Complaints-To: abuse@chalmers.se NNTP-Posting-Date: 16 Mar 2002 11:35:52 GMT X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!logbridge.uoregon.edu!newsfeed.sunet.se!news01.sunet.se!news.chalmers.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15360 "Falk Brunner" writes: > "Magnus Homann" schrieb im Newsbeitrag > news:ltg03190da.fsf@mis.dtek.chalmers.se... > > rickman writes: > > > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > Is this differential? In that case I would go for daisychaining and > > termination at the end. SHORT stubs at intermediate devices. > > Isnt end termination the ONLY clean way when daisy-chaining??? (According to > the "bible" from Howard Johnson) Of course. Was I unclear? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se ###### From: "Leon Heller" Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Sat, 16 Mar 2002 14:23:35 +0000 (UTC) Organization: BT Openworld Lines: 33 Message-ID: References: <3C923297.57531263@yahoo.com> <3C9237E8.8D818B3A@yahoo.com> NNTP-Posting-Host: host62-7-112-114.in-addr.btopenworld.com X-Trace: knossos.btinternet.com 1016288615 6190 62.7.112.114 (16 Mar 2002 14:23:35 GMT) X-Complaints-To: news-complaints@lists.btinternet.com NNTP-Posting-Date: Sat, 16 Mar 2002 14:23:35 +0000 (UTC) X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!colt.net!dispose.news.demon.net!demon!btnet-peer0!btnet-feed5!btnet!news.btopenworld.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15356 "rickman" wrote in message news:3C9237E8.8D818B3A@yahoo.com... > Magnus Homann wrote: > > > > rickman writes: > > > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > Is this differential? In that case I would go for daisychaining and > > termination at the end. SHORT stubs at intermediate devices. > > > > Homann > > No this is not differential. This is LVTTL. BTW, what do you mean by > SHORT? Is that anything like telling someone to pay CAREFULL attention > to signal routing? :) Presumably 'short relative to 1/4 the wavelength', where the wavelength is that of the highest harmonic you need to maintain the integrity of the signal. You don't want the stub acting as a circuit component, as with transmission lines and microwave circuitry. Leon ###### From: "Pete Dudley" Newsgroups: comp.arch.fpga,comp.arch.embedded References: <3C923297.57531263@yahoo.com> Subject: Re: High speed clock routing Lines: 55 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Date: Sun, 17 Mar 2002 21:08:14 CST Organization: Giganews.Com - Premium News Outsourcing X-Trace: sv3-rGBwo62NZph1rEAU691KquqPTDLs9zBkHcJdvNG+FNOgTn19aJ2Ra3Wzuo784KeYVZL4MRjZXtQxIcL!tVkjBmFY0LLVXA6yVPAgXQrHpcCnn1dEbcSZuGUyyknLN4IAYPaBGHRWh5BSUTQyru7YDakL04J1!tBA= X-Complaints-To: abuse@comcast.com X-DMCA-Complaints-To: abuse@comcast.com X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly Date: Mon, 18 Mar 2002 03:08:14 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!netnews.com!feed2.news.rcn.net!rcn!news.voicenet.com!nntp2.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!bin2.nnrp.aus1.giganews.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15454 I would think about doing the star routing with a source termination resistor for each leg of the star, may 20 Ohms each. Make all the legs the same length and make sure there are no breaks in the ground return under these legs. -- Pete Dudley Arroyo Grande Systems "rickman" wrote in message news:3C923297.57531263@yahoo.com... > I need to plan a high speed bus that will connect 5 devices. They will > all be very closely spaced so that the lengths of the routes can be kept > pretty short. The clock line is the one I am most concerned about. It > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if > you keep it square (as layout guys like to do). The other signals are > within the box these two points inscribe. > > Another approach would be to daisy chain them which would make the total > run about 3 inches. What type of termination could I expect to work > well with this type of run? > > With such short runs, I was thinking about using no termination with a > star topology. I am not even sure I need to worry about keeping the net > delays equal since the variation will be less than +- 1 inch or about > 100 pS of clock skew. > > Anyone have much experience with running high speed clocks on such short > runs? Can I expect this to work well? > > I know Austin will tell me to simulate it, which I plan to do. I am > just trying to get a "gut" feeling as Bob Pease would want to do. You > know how easy it is to get the WRONG, right answer from a computer. > GIGO. > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX > ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Mon, 18 Mar 2002 16:29:09 -0500 Organization: Arius, Inc Lines: 94 Message-ID: <3C965C25.974C5512@yahoo.com> References: <3C923297.57531263@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbUE85EmT2GxEzRqYFbbzUorMzcYj8PLuw5hSn5HyW2+f4mJeEQ8ZQx X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 18 Mar 2002 21:29:10 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15466 This is one that I will test in simulation, but I don't hold much hope for it to work well. I found an article from Howard Johnson on the web about designing T routes. It showed that this could be made to work, but that it was not easy. Splitting the trace four ways, would make it very hard to do. Just adding a series resistor is not magic. It is there to match the source impedance to the trace. Then where the trace splits, the outbound traces need to have a higher impedance to prevent a discontinuity. I have not looked up the formula for trace impedances, but HJ made it sound like they would get pretty narrow to bring the impedance up enough to match. In this case it would need to be about 200 Ohms after a four way split if you had 50 ohms before the split. I guess I could use a very small resistor, or no resistor, at the output of the chip. This would give me an impedance less than 50 Ohms and would allow the traces after the split to be somewhat wider. Here is the URL http://www.sigcon.com/articles/edn/tee.htm One problem with any analysis is the lack of good data. One data point I am lacking is the rise time of the clock. In this case I need to know the minium rise time since this is the worst case. The maximum is 2 nS, so it may be reasonable to assume 1 nS as a typical value. Pete Dudley wrote: > > I would think about doing the star routing with a source termination > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > same length and make sure there are no breaks in the ground return under > these legs. > > -- > Pete Dudley > > Arroyo Grande Systems > > "rickman" wrote in message > news:3C923297.57531263@yahoo.com... > > I need to plan a high speed bus that will connect 5 devices. They will > > all be very closely spaced so that the lengths of the routes can be kept > > pretty short. The clock line is the one I am most concerned about. It > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if > > you keep it square (as layout guys like to do). The other signals are > > within the box these two points inscribe. > > > > Another approach would be to daisy chain them which would make the total > > run about 3 inches. What type of termination could I expect to work > > well with this type of run? > > > > With such short runs, I was thinking about using no termination with a > > star topology. I am not even sure I need to worry about keeping the net > > delays equal since the variation will be less than +- 1 inch or about > > 100 pS of clock skew. > > > > Anyone have much experience with running high speed clocks on such short > > runs? Can I expect this to work well? > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > just trying to get a "gut" feeling as Bob Pease would want to do. You > > know how easy it is to get the WRONG, right answer from a computer. > > GIGO. > > > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Mon, 18 Mar 2002 19:07:25 -0500 Organization: Arius, Inc Lines: 60 Message-ID: <3C96813D.99CCDB8B@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaRDrkaYOfG7YWaKFr/LKq2l+zzkJ/r8MYctZaKackpnm3FSBN6T4N1 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 19 Mar 2002 00:07:24 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed1.cidera.com!Cidera!dca6-feed2.news.digex.net!intermedia!nntp.abs.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15468 I found another article that discusses the issue of splitting a signal and driving stubs. It is at http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. Here Dr Howard Johnson (HJ) shows the need for series terminators at the receivers to damp resonance oscillations. I was surprised by this. rickman wrote: > > This is one that I will test in simulation, but I don't hold much hope > for it to work well. I found an article from Howard Johnson on the web > about designing T routes. It showed that this could be made to work, > but that it was not easy. Splitting the trace four ways, would make it > very hard to do. Just adding a series resistor is not magic. It is > there to match the source impedance to the trace. Then where the trace > splits, the outbound traces need to have a higher impedance to prevent a > discontinuity. > > I have not looked up the formula for trace impedances, but HJ made it > sound like they would get pretty narrow to bring the impedance up enough > to match. In this case it would need to be about 200 Ohms after a four > way split if you had 50 ohms before the split. I guess I could use a > very small resistor, or no resistor, at the output of the chip. This > would give me an impedance less than 50 Ohms and would allow the traces > after the split to be somewhat wider. > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > One problem with any analysis is the lack of good data. One data point > I am lacking is the rise time of the clock. In this case I need to know > the minium rise time since this is the worst case. The maximum is 2 nS, > so it may be reasonable to assume 1 nS as a typical value. > > Pete Dudley wrote: > > > > I would think about doing the star routing with a source termination > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > same length and make sure there are no breaks in the ground return under > > these legs. > > > > -- > > Pete Dudley > > > > Arroyo Grande Systems -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Mon, 18 Mar 2002 16:56:01 -0800 Organization: Xilinx Lines: 74 Message-ID: <3C968CA1.43FAD089@xilinx.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C96813D.99CCDB8B@yahoo.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15474 Rick, The only thing that surprises me is how many people want an 'easy' solution, and are unwilling to simulate it. Once you simulate it, all mysteries are gone, the lights come on, the sun shines, well, you get the idea. Once simulated, the only issues that can go wrong are: pcb isn't fabricated per the print, device models are completely wrong. Since those are pretty unlikely (at least for most reputable IC vendors and pcb houses) you are pretty safe. Austin rickman wrote: > I found another article that discusses the issue of splitting a signal > and driving stubs. It is at > http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. > > Here Dr Howard Johnson (HJ) shows the need for series terminators at the > receivers to damp resonance oscillations. I was surprised by this. > > rickman wrote: > > > > This is one that I will test in simulation, but I don't hold much hope > > for it to work well. I found an article from Howard Johnson on the web > > about designing T routes. It showed that this could be made to work, > > but that it was not easy. Splitting the trace four ways, would make it > > very hard to do. Just adding a series resistor is not magic. It is > > there to match the source impedance to the trace. Then where the trace > > splits, the outbound traces need to have a higher impedance to prevent a > > discontinuity. > > > > I have not looked up the formula for trace impedances, but HJ made it > > sound like they would get pretty narrow to bring the impedance up enough > > to match. In this case it would need to be about 200 Ohms after a four > > way split if you had 50 ohms before the split. I guess I could use a > > very small resistor, or no resistor, at the output of the chip. This > > would give me an impedance less than 50 Ohms and would allow the traces > > after the split to be somewhat wider. > > > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > > > One problem with any analysis is the lack of good data. One data point > > I am lacking is the rise time of the clock. In this case I need to know > > the minium rise time since this is the worst case. The maximum is 2 nS, > > so it may be reasonable to assume 1 nS as a typical value. > > > > Pete Dudley wrote: > > > > > > I would think about doing the star routing with a source termination > > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > > same length and make sure there are no breaks in the ground return under > > > these legs. > > > > > > -- > > > Pete Dudley > > > > > > Arroyo Grande Systems > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Mon, 18 Mar 2002 20:47:36 -0500 Organization: Arius, Inc Lines: 108 Message-ID: <3C9698B8.94A11AB0@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C96813D.99CCDB8B@yahoo.com> <3C968CA1.43FAD089@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYEyugnaVmvNw0nHrLLCIb0L9GejVpTuWLj/sgo52mVh8cusEgsxhow X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 19 Mar 2002 01:47:33 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15467 I think that most people don't want to simulate because it is unfamiliar territory for them. I am in that camp. I would perfer not to, but I am not willing to take a chance on 100 MHz clock lines which may be run up to 133 when the faster chip comes out. Yes, I know that the clock speed is not what is important, but rather it is the edge rate. But to allow the clock to speed up the edge rate will also go up. But I am concerned that I will not have the correct data when I perform the simulation. I still need to close the loop to get valid data that reflects my PCB. That is an item that I will have to research further. I am going to start with an old copy of the Motorola ECL data book. It has a good chapter on Stripline and Microline (if I am remembering the terms correctly) and calculating all the relevant characteristics... if I can get the appropriate data on the PCB materials. Lots of places to make mistakes... unless you have a pretty good idea of the answer before you start. Austin Lesea wrote: > > Rick, > > The only thing that surprises me is how many people want an 'easy' solution, and > are unwilling to simulate it. > > Once you simulate it, all mysteries are gone, the lights come on, the sun shines, > well, you get the idea. > > Once simulated, the only issues that can go wrong are: pcb isn't fabricated per > the print, device models are completely wrong. Since those are pretty unlikely > (at least for most reputable IC vendors and pcb houses) you are pretty safe. > > Austin > > rickman wrote: > > > I found another article that discusses the issue of splitting a signal > > and driving stubs. It is at > > http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. > > > > Here Dr Howard Johnson (HJ) shows the need for series terminators at the > > receivers to damp resonance oscillations. I was surprised by this. > > > > rickman wrote: > > > > > > This is one that I will test in simulation, but I don't hold much hope > > > for it to work well. I found an article from Howard Johnson on the web > > > about designing T routes. It showed that this could be made to work, > > > but that it was not easy. Splitting the trace four ways, would make it > > > very hard to do. Just adding a series resistor is not magic. It is > > > there to match the source impedance to the trace. Then where the trace > > > splits, the outbound traces need to have a higher impedance to prevent a > > > discontinuity. > > > > > > I have not looked up the formula for trace impedances, but HJ made it > > > sound like they would get pretty narrow to bring the impedance up enough > > > to match. In this case it would need to be about 200 Ohms after a four > > > way split if you had 50 ohms before the split. I guess I could use a > > > very small resistor, or no resistor, at the output of the chip. This > > > would give me an impedance less than 50 Ohms and would allow the traces > > > after the split to be somewhat wider. > > > > > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > > > > > One problem with any analysis is the lack of good data. One data point > > > I am lacking is the rise time of the clock. In this case I need to know > > > the minium rise time since this is the worst case. The maximum is 2 nS, > > > so it may be reasonable to assume 1 nS as a typical value. > > > > > > Pete Dudley wrote: > > > > > > > > I would think about doing the star routing with a source termination > > > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > > > same length and make sure there are no breaks in the ground return under > > > > these legs. > > > > > > > > -- > > > > Pete Dudley > > > > > > > > Arroyo Grande Systems > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Kevin Brace Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Mon, 18 Mar 2002 20:03:11 -0600 Organization: None Lines: 31 Sender: kevinbraceusenet@hotmail.com Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C96813D.99CCDB8B@yahoo.com> <3C968CA1.43FAD089@xilinx.com> NNTP-Posting-Host: 1cust216.tnt21.chi5.da.uu.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: newsreader.mailgate.org 1016502896 15211 67.195.15.216 (19 Mar 2002 01:54:56 GMT) X-Complaints-To: abuse@mailgate.org NNTP-Posting-Date: Tue, 19 Mar 2002 01:54:56 +0000 (UTC) X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsreader.mailgate.org!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15500 What are the names of "most reputable pcb houses?" Sort of off topic, but how many PCB houses offer lead-free solder? Okay, maybe PCB houses don't do SMT, or do they? (Obviously I don't know much about PCB related stuff) Also, how much does it cost to make a PCI card in prototype quantity (one or two) with a Spartan-II FG456 package (Fine-Pitch BGA 456 pin) and an SO-DIMM socket on it? Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Austin Lesea wrote: > > Rick, > > The only thing that surprises me is how many people want an 'easy' solution, and > are unwilling to simulate it. > > Once you simulate it, all mysteries are gone, the lights come on, the sun shines, > well, you get the idea. > > Once simulated, the only issues that can go wrong are: pcb isn't fabricated per > the print, device models are completely wrong. Since those are pretty unlikely > (at least for most reputable IC vendors and pcb houses) you are pretty safe. > > Austin > ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Tue, 19 Mar 2002 01:29:07 -0500 Organization: Arius, Inc Lines: 157 Message-ID: <3C96DAB2.ECFB1BA6@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> <3C928812.3A8A5CCD@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYZPOmXIVOPR97h8mqh0KWcrXgpR6uKM9V/SToF/8vYATWSSJ4m2IUR X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 19 Mar 2002 06:29:01 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15469 I tried downloading the Hyperlynx demo and found that it won't let you do anything at all useful. I can enter my own data, but I can't simulate it. I can simulate and example file, but I can't change anything to try to fix problems, or it won't simulate again. This would appear to be a very useless demo. It is not demoing anything except the installation, which did go very smoothly. Isn't this the tool that you said we could do simple things with? I thought the main limitation was that data could not be saved or printed? Austin Lesea wrote: > > Rick, > > Use the fast/strong IBIS corner, and that covers the worst case for > process/voltage/temperature. > > The capactances don't matter all that much (convince yourself by changing them, > and you will see that the results don't change much at all). > > The claim of IBIS simulator vendors is that it saves all of the PCB spins to fix > SI, and they are right. The sims are not that fussy, and all you need to be sure > of are the parts and their models, and the PCB impedance and the lengths. > > Input models are not fussy either, hence my use of VII for all inputs is probably > +/- 10% of the real measured result. All CMOS inputs look pretty much the same. > > If you have wide buses, then crosstalk is important, and you need a little more > detail for the geometry. > > Austin > > rickman wrote: > > > Thanks for your comments John. > > > > I guess I am a little green with clocks above 50 MHz. I was expecting > > runs this short to be pretty simple and not to have to do too much to > > make it work. But with the input from Austin and yourself as well as > > some others, I do at least plan to take a first pass at a simulation. > > My main concern is that you have to know a lot of details about the > > board to run a USEFUL simulation. I have learned a lot from reading > > some of Bob Pease's articles and I fully realize that a simulation won't > > do me a lick of good if I don't make all the right assumptions. > > > > I have been working on a very tightly packed switching power supply > > while I am doing the digital stuff and I am finding that I can make it > > look pretty feasible if I make THESE assumptions and I can make it look > > pretty impossible if I make THOSE assumptions. I think we won't really > > know how well it will work until we fire it up on the final board > > layout. I expect that we will see the same sort of thing with this > > clock design. > > > > I did consider using a zero delay buffer. But this board is very tight > > for space and I have a hard time justifying it with 1.5 inch traces. > > But if the simulation shows a problem, of course we will do what we have > > to. > > > > The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max. > > This is another difference between the simulation Austin did and what I > > have. He seems to have used all VII inputs with 10 pF capacitance. > > > > It is also not clear to me if the simulations are being done with > > typical values or worst case values. If typ values are used, then I > > don't see how the results have any meaning at all. > > > > Rick Collins > > > > John_H wrote: > > > > > > 85 ps per inch works for free space. A better approximation would be 170 ps > > > per inch for internal traces where the relative permitivity of about 4 for > > > FR4 material at high frequency gives a good approximation (sqrt(4) for > > > scaling to free space). The outside traces are a bit faster because they're > > > propagating through a combination of air and FR4 - I don't have the numbers > > > handy for those speeds. > > > > > > You're right about the stackup being important - the trace widths and plane > > > spacings need to be well specified by you to get the board house to provide > > > impedances that won't over/undershoot. A little mistermination is fine - > > > the mid-transition reversals are what kills; those can occur when the > > > driver sees a low impedance for much of the risetime but gets the reflection > > > coming back before the clock's out of the transition region. There's the > > > beauty of SI - this general info gets applied. > > > > > > With everything close and distributed capacitance throughout, you could get > > > smooth transitions with the star configuration, but it's dependent on the > > > drivers and input capacitance. > > > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > > delay buffers" are part of the clock management's best application. It's > > > often better from a debug standpoint to have access to individual > > > terminations if things go desperately wrong. > > > > > > rickman wrote: > > > > > > > Austin, thanks for the simulation. > > > > > > > > This looks like great data. But I am not sure if you were trying to > > > > help by doing my simulation for me, or if you were just trying to show > > > > what the tool can do. > > > > > > > > I am not clear about what this is simulating. Obviously you used the > > > > daisy chain model, but how do you know what to use as a trace impedance > > > > and where did the delays come from? The preliminary layout I am using > > > > has the following delays in the daisy chain case, assuming 100pS per > > > > inch. Is that a valid assumption? > > > > > > > > DSP to FPGA 100pS > > > > FPGA to SDRAM1 50pS > > > > SDRAM1 to SDRAM2 50pS > > > > SDRAM2 to SBSRAM 100pS > > > > > > > > Don't I need to caclulate the trace impedance from the PCB design > > > > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > > > > layers with a total thickness of 0.062". Of course, I can use wider > > > > traces for the clock and control which layer they are on. > > > > > > > > I would expect these four loads to behave much better than the five > > > > loads with 200+ pS delays. > > > > > > > > If you were just trying to demonstate the tool, that's fine. But if you > > > > were trying to simulate my case, these are the data that should be > > > > used. > > > > > > > > When I am done my other work today, I will try downloading the software > > > > and giving it a try this weekend or next week. > > > > ...snip... > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Tue, 19 Mar 2002 08:19:06 -0800 Organization: Xilinx Lines: 176 Message-ID: <3C9764FA.DC25EA46@xilinx.com> References: <3C923297.57531263@yahoo.com> <3C9239B0.6636346E@xilinx.com> <3C9254B0.9C6F0700@yahoo.com> <3C925BF8.E3CEC021@mail.com> <3C928251.239BEAC2@yahoo.com> <3C928812.3A8A5CCD@xilinx.com> <3C96DAB2.ECFB1BA6@yahoo.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attbt1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15477 Rick, I am very sorry. The demo I first downloaded two years ago allowed me to fiddle with drivers that were in their library, and with trace lengths, and my own circuits. I could not change their libraries, and I could not print the results, or add new IBIS files to the tool, or save the results. It did allow me to enter my own topology, and model it (if the library had the parts I needed already -- which it had a lot of). Sounds like they may have changed it? Any one else able to make the demo do something useful? I won't recommend the demo, but I still recommend the tool itself. Austin rickman wrote: > I tried downloading the Hyperlynx demo and found that it won't let you > do anything at all useful. I can enter my own data, but I can't > simulate it. I can simulate and example file, but I can't change > anything to try to fix problems, or it won't simulate again. This would > appear to be a very useless demo. It is not demoing anything except the > installation, which did go very smoothly. > > Isn't this the tool that you said we could do simple things with? I > thought the main limitation was that data could not be saved or > printed? > > Austin Lesea wrote: > > > > Rick, > > > > Use the fast/strong IBIS corner, and that covers the worst case for > > process/voltage/temperature. > > > > The capactances don't matter all that much (convince yourself by changing them, > > and you will see that the results don't change much at all). > > > > The claim of IBIS simulator vendors is that it saves all of the PCB spins to fix > > SI, and they are right. The sims are not that fussy, and all you need to be sure > > of are the parts and their models, and the PCB impedance and the lengths. > > > > Input models are not fussy either, hence my use of VII for all inputs is probably > > +/- 10% of the real measured result. All CMOS inputs look pretty much the same. > > > > If you have wide buses, then crosstalk is important, and you need a little more > > detail for the geometry. > > > > Austin > > > > rickman wrote: > > > > > Thanks for your comments John. > > > > > > I guess I am a little green with clocks above 50 MHz. I was expecting > > > runs this short to be pretty simple and not to have to do too much to > > > make it work. But with the input from Austin and yourself as well as > > > some others, I do at least plan to take a first pass at a simulation. > > > My main concern is that you have to know a lot of details about the > > > board to run a USEFUL simulation. I have learned a lot from reading > > > some of Bob Pease's articles and I fully realize that a simulation won't > > > do me a lick of good if I don't make all the right assumptions. > > > > > > I have been working on a very tightly packed switching power supply > > > while I am doing the digital stuff and I am finding that I can make it > > > look pretty feasible if I make THESE assumptions and I can make it look > > > pretty impossible if I make THOSE assumptions. I think we won't really > > > know how well it will work until we fire it up on the final board > > > layout. I expect that we will see the same sort of thing with this > > > clock design. > > > > > > I did consider using a zero delay buffer. But this board is very tight > > > for space and I have a hard time justifying it with 1.5 inch traces. > > > But if the simulation shows a problem, of course we will do what we have > > > to. > > > > > > The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max. > > > This is another difference between the simulation Austin did and what I > > > have. He seems to have used all VII inputs with 10 pF capacitance. > > > > > > It is also not clear to me if the simulations are being done with > > > typical values or worst case values. If typ values are used, then I > > > don't see how the results have any meaning at all. > > > > > > Rick Collins > > > > > > John_H wrote: > > > > > > > > 85 ps per inch works for free space. A better approximation would be 170 ps > > > > per inch for internal traces where the relative permitivity of about 4 for > > > > FR4 material at high frequency gives a good approximation (sqrt(4) for > > > > scaling to free space). The outside traces are a bit faster because they're > > > > propagating through a combination of air and FR4 - I don't have the numbers > > > > handy for those speeds. > > > > > > > > You're right about the stackup being important - the trace widths and plane > > > > spacings need to be well specified by you to get the board house to provide > > > > impedances that won't over/undershoot. A little mistermination is fine - > > > > the mid-transition reversals are what kills; those can occur when the > > > > driver sees a low impedance for much of the risetime but gets the reflection > > > > coming back before the clock's out of the transition region. There's the > > > > beauty of SI - this general info gets applied. > > > > > > > > With everything close and distributed capacitance throughout, you could get > > > > smooth transitions with the star configuration, but it's dependent on the > > > > drivers and input capacitance. > > > > > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > > > delay buffers" are part of the clock management's best application. It's > > > > often better from a debug standpoint to have access to individual > > > > terminations if things go desperately wrong. > > > > > > > > rickman wrote: > > > > > > > > > Austin, thanks for the simulation. > > > > > > > > > > This looks like great data. But I am not sure if you were trying to > > > > > help by doing my simulation for me, or if you were just trying to show > > > > > what the tool can do. > > > > > > > > > > I am not clear about what this is simulating. Obviously you used the > > > > > daisy chain model, but how do you know what to use as a trace impedance > > > > > and where did the delays come from? The preliminary layout I am using > > > > > has the following delays in the daisy chain case, assuming 100pS per > > > > > inch. Is that a valid assumption? > > > > > > > > > > DSP to FPGA 100pS > > > > > FPGA to SDRAM1 50pS > > > > > SDRAM1 to SDRAM2 50pS > > > > > SDRAM2 to SBSRAM 100pS > > > > > > > > > > Don't I need to caclulate the trace impedance from the PCB design > > > > > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > > > > > layers with a total thickness of 0.062". Of course, I can use wider > > > > > traces for the clock and control which layer they are on. > > > > > > > > > > I would expect these four loads to behave much better than the five > > > > > loads with 200+ pS delays. > > > > > > > > > > If you were just trying to demonstate the tool, that's fine. But if you > > > > > were trying to simulate my case, these are the data that should be > > > > > used. > > > > > > > > > > When I am done my other work today, I will try downloading the software > > > > > and giving it a try this weekend or next week. > > > > > > ...snip... > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: kayrock66@yahoo.com (Jay) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 19 Mar 2002 10:02:53 -0800 Organization: http://groups.google.com/ Lines: 105 Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> NNTP-Posting-Host: 208.178.183.62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1016560973 18176 127.0.0.1 (19 Mar 2002 18:02:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Mar 2002 18:02:53 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15507 I think your intuition is correct. Be brave and go with the star topology with the idea of minimizing the length of the longest leg. As I'm sure you understand, when the traces are short relative to the edge rate then you don't have to fuss with impedance control/buffers which is easily done wrong anyway. And you are correct about the sim, only meaningful with correct board impedance data, too much finess required. Regards rickman wrote in message news:<3C965C25.974C5512@yahoo.com>... > This is one that I will test in simulation, but I don't hold much hope > for it to work well. I found an article from Howard Johnson on the web > about designing T routes. It showed that this could be made to work, > but that it was not easy. Splitting the trace four ways, would make it > very hard to do. Just adding a series resistor is not magic. It is > there to match the source impedance to the trace. Then where the trace > splits, the outbound traces need to have a higher impedance to prevent a > discontinuity. > > I have not looked up the formula for trace impedances, but HJ made it > sound like they would get pretty narrow to bring the impedance up enough > to match. In this case it would need to be about 200 Ohms after a four > way split if you had 50 ohms before the split. I guess I could use a > very small resistor, or no resistor, at the output of the chip. This > would give me an impedance less than 50 Ohms and would allow the traces > after the split to be somewhat wider. > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > One problem with any analysis is the lack of good data. One data point > I am lacking is the rise time of the clock. In this case I need to know > the minium rise time since this is the worst case. The maximum is 2 nS, > so it may be reasonable to assume 1 nS as a typical value. > > > > Pete Dudley wrote: > > > > I would think about doing the star routing with a source termination > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > same length and make sure there are no breaks in the ground return under > > these legs. > > > > -- > > Pete Dudley > > > > Arroyo Grande Systems > > > > "rickman" wrote in message > > news:3C923297.57531263@yahoo.com... > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if > > > you keep it square (as layout guys like to do). The other signals are > > > within the box these two points inscribe. > > > > > > Another approach would be to daisy chain them which would make the total > > > run about 3 inches. What type of termination could I expect to work > > > well with this type of run? > > > > > > With such short runs, I was thinking about using no termination with a > > > star topology. I am not even sure I need to worry about keeping the net > > > delays equal since the variation will be less than +- 1 inch or about > > > 100 pS of clock skew. > > > > > > Anyone have much experience with running high speed clocks on such short > > > runs? Can I expect this to work well? > > > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > just trying to get a "gut" feeling as Bob Pease would want to do. You > > > know how easy it is to get the WRONG, right answer from a computer. > > > GIGO. > > > > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: bobsrefusebin@hotmail.com (Bob Perlman) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 19 Mar 2002 12:07:23 -0800 Organization: http://groups.google.com/ Lines: 126 Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> NNTP-Posting-Host: 24.221.179.83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1016568443 22016 127.0.0.1 (19 Mar 2002 20:07:23 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Mar 2002 20:07:23 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15532 Rick - A few comments/observations: 1) If your board stackup is at all conventional, trace impedances will fall somewhere in the range of 45 to 65 ohms. You can, with effort, get other impedances, but getting to 200 ohms will require tricks that you won't want to play. 2) I don't know the strength of the C6711 clock driver. If it's strong enough to drive a Thevenin-equivalent parallel termination, and if you can tolerate the inevitable clock skew that arises from daisy-chaining the clock net, then use a single net and parallel termination. But be sure to check the weak/slow corner clock buffer drive. In my experience, the clock outputs of processor chips tend to be underpowered. (And they can be glitchy, too; a ground-bounce-related glitch on the clock output of TI's TMS320C31 nearly torpedoed one project I worked on.) 3) If (2) doesn't pan out, spring for one of the small zero-delay buffers, and drive each clock load with its own PLL output. If the zero-delay buffer has built-in series termination, great; if not, series-terminate each output. It'll cost you (not much) space and (not much) money. I never try to economize on either when generating and distributing clocks. Bob Perlman Cambrian Design Works http://www.cambriandesign.com rickman wrote in message news:<3C965C25.974C5512@yahoo.com>... > This is one that I will test in simulation, but I don't hold much hope > for it to work well. I found an article from Howard Johnson on the web > about designing T routes. It showed that this could be made to work, > but that it was not easy. Splitting the trace four ways, would make it > very hard to do. Just adding a series resistor is not magic. It is > there to match the source impedance to the trace. Then where the trace > splits, the outbound traces need to have a higher impedance to prevent a > discontinuity. > > I have not looked up the formula for trace impedances, but HJ made it > sound like they would get pretty narrow to bring the impedance up enough > to match. In this case it would need to be about 200 Ohms after a four > way split if you had 50 ohms before the split. I guess I could use a > very small resistor, or no resistor, at the output of the chip. This > would give me an impedance less than 50 Ohms and would allow the traces > after the split to be somewhat wider. > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > One problem with any analysis is the lack of good data. One data point > I am lacking is the rise time of the clock. In this case I need to know > the minium rise time since this is the worst case. The maximum is 2 nS, > so it may be reasonable to assume 1 nS as a typical value. > > > > Pete Dudley wrote: > > > > I would think about doing the star routing with a source termination > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > same length and make sure there are no breaks in the ground return under > > these legs. > > > > -- > > Pete Dudley > > > > Arroyo Grande Systems > > > > "rickman" wrote in message > > news:3C923297.57531263@yahoo.com... > > > I need to plan a high speed bus that will connect 5 devices. They will > > > all be very closely spaced so that the lengths of the routes can be kept > > > pretty short. The clock line is the one I am most concerned about. It > > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > > > > > > The longest as-the-crow-flys run is 1.4" with 1 inch x and 1 inch y if > > > you keep it square (as layout guys like to do). The other signals are > > > within the box these two points inscribe. > > > > > > Another approach would be to daisy chain them which would make the total > > > run about 3 inches. What type of termination could I expect to work > > > well with this type of run? > > > > > > With such short runs, I was thinking about using no termination with a > > > star topology. I am not even sure I need to worry about keeping the net > > > delays equal since the variation will be less than +- 1 inch or about > > > 100 pS of clock skew. > > > > > > Anyone have much experience with running high speed clocks on such short > > > runs? Can I expect this to work well? > > > > > > I know Austin will tell me to simulate it, which I plan to do. I am > > > just trying to get a "gut" feeling as Bob Pease would want to do. You > > > know how easy it is to get the WRONG, right answer from a computer. > > > GIGO. > > > > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: bobsrefusebin@hotmail.com (Bob Perlman) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 19 Mar 2002 12:36:09 -0800 Organization: http://groups.google.com/ Lines: 109 Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C96813D.99CCDB8B@yahoo.com> <3C968CA1.43FAD089@xilinx.com> NNTP-Posting-Host: 24.221.179.83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1016570169 23125 127.0.0.1 (19 Mar 2002 20:36:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Mar 2002 20:36:09 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15533 Austin - I agree; I think that more digital designers should include signal simulation in their bag of tricks. Unfortunately, there are some roadblocks to getting these simulations running. For one thing, the quality of IBIS models is iffy at best. The folks at SiQual, a signal integrity consulting firm in the northwest, recently published a paper titled, "A Critique of IBIS Models Available for Download on the Web." They concluded that 70% of the IBIS models produced warnings or errors when processed, and that 40% had serious problems, i.e., problems severe enough to prevent the simulator from using the model, or severe enough to produce erroneous results. The paper's available at www.siqual.com. And I've encountered other IBIS problems that wouldn't even result in a warning. In particular, I've seen more than a few models where it was abundantly clear that the best- and worst-case IV curves were identical to or little different from the nominal curves (and these were not controlled-impedance drivers). I'm not knocking Xilinx models, by the way; I've had pretty good luck with the more recent ones. The point I'm getting to is that being able to run simulations isn't enough; the person running them needs a good BS detector to ferret out mistakes in the model or in the simulation setup. I've seen engineers run simulations that gave good results that they believed, despite the fact that those results were clearly contrary to real life. This is the point that Bob Pease was making when he had someone photograph him lining the bottom of a birdcage with Spice printouts. Bob Perlman Cambrian Design Works http://www.cambriandesign.com Austin Lesea wrote in message news:<3C968CA1.43FAD089@xilinx.com>... > Rick, > > The only thing that surprises me is how many people want an 'easy' solution, and > are unwilling to simulate it. > > Once you simulate it, all mysteries are gone, the lights come on, the sun shines, > well, you get the idea. > > Once simulated, the only issues that can go wrong are: pcb isn't fabricated per > the print, device models are completely wrong. Since those are pretty unlikely > (at least for most reputable IC vendors and pcb houses) you are pretty safe. > > Austin > > rickman wrote: > > > I found another article that discusses the issue of splitting a signal > > and driving stubs. It is at > > http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. > > > > Here Dr Howard Johnson (HJ) shows the need for series terminators at the > > receivers to damp resonance oscillations. I was surprised by this. > > > > rickman wrote: > > > > > > This is one that I will test in simulation, but I don't hold much hope > > > for it to work well. I found an article from Howard Johnson on the web > > > about designing T routes. It showed that this could be made to work, > > > but that it was not easy. Splitting the trace four ways, would make it > > > very hard to do. Just adding a series resistor is not magic. It is > > > there to match the source impedance to the trace. Then where the trace > > > splits, the outbound traces need to have a higher impedance to prevent a > > > discontinuity. > > > > > > I have not looked up the formula for trace impedances, but HJ made it > > > sound like they would get pretty narrow to bring the impedance up enough > > > to match. In this case it would need to be about 200 Ohms after a four > > > way split if you had 50 ohms before the split. I guess I could use a > > > very small resistor, or no resistor, at the output of the chip. This > > > would give me an impedance less than 50 Ohms and would allow the traces > > > after the split to be somewhat wider. > > > > > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > > > > > One problem with any analysis is the lack of good data. One data point > > > I am lacking is the rise time of the clock. In this case I need to know > > > the minium rise time since this is the worst case. The maximum is 2 nS, > > > so it may be reasonable to assume 1 nS as a typical value. > > > > > > Pete Dudley wrote: > > > > > > > > I would think about doing the star routing with a source termination > > > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > > > same length and make sure there are no breaks in the ground return under > > > > these legs. > > > > > > > > -- > > > > Pete Dudley > > > > > > > > Arroyo Grande Systems > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Tue, 19 Mar 2002 13:02:39 -0800 Organization: Xilinx Lines: 124 Message-ID: <3C97A76E.B3315DD7@xilinx.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C96813D.99CCDB8B@yahoo.com> <3C968CA1.43FAD089@xilinx.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.cwix.com!news!nntp.wetware.com!attbt1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15524 Bob, That is really too bad. Maybe people should consider buying more Xilinx FPGAs? We are constantly striving to improve our models, and I in the lab confirm the model accuracy on a regular basis. Recently, for a Virtex II Pro simualrion, the engineer came back to me, and was astonished, as the scope picture looked exactly like what he had built on the bench. Without good models, customers will never succeed. Austin Bob Perlman wrote: > Austin - > > I agree; I think that more digital designers should include signal > simulation in their bag of tricks. > > Unfortunately, there are some roadblocks to getting these simulations > running. For one thing, the quality of IBIS models is iffy at best. > The folks at SiQual, a signal integrity consulting firm in the > northwest, recently published a paper titled, "A Critique of IBIS > Models Available for Download on the Web." They concluded that 70% of > the IBIS models produced warnings or errors when processed, and that > 40% had serious problems, i.e., problems severe enough to prevent the > simulator from using the model, or severe enough to produce erroneous > results. The paper's available at www.siqual.com. > > And I've encountered other IBIS problems that wouldn't even result in > a warning. In particular, I've seen more than a few models where it > was abundantly clear that the best- and worst-case IV curves were > identical to or little different from the nominal curves (and these > were not controlled-impedance drivers). I'm not knocking Xilinx > models, by the way; I've had pretty good luck with the more recent > ones. > > The point I'm getting to is that being able to run simulations isn't > enough; the person running them needs a good BS detector to ferret out > mistakes in the model or in the simulation setup. I've seen engineers > run simulations that gave good results that they believed, despite the > fact that those results were clearly contrary to real life. This is > the point that Bob Pease was making when he had someone photograph him > lining the bottom of a birdcage with Spice printouts. > > Bob Perlman > Cambrian Design Works > http://www.cambriandesign.com > > Austin Lesea wrote in message news:<3C968CA1.43FAD089@xilinx.com>... > > Rick, > > > > The only thing that surprises me is how many people want an 'easy' solution, and > > are unwilling to simulate it. > > > > Once you simulate it, all mysteries are gone, the lights come on, the sun shines, > > well, you get the idea. > > > > Once simulated, the only issues that can go wrong are: pcb isn't fabricated per > > the print, device models are completely wrong. Since those are pretty unlikely > > (at least for most reputable IC vendors and pcb houses) you are pretty safe. > > > > Austin > > > > rickman wrote: > > > > > I found another article that discusses the issue of splitting a signal > > > and driving stubs. It is at > > > http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm. > > > > > > Here Dr Howard Johnson (HJ) shows the need for series terminators at the > > > receivers to damp resonance oscillations. I was surprised by this. > > > > > > rickman wrote: > > > > > > > > This is one that I will test in simulation, but I don't hold much hope > > > > for it to work well. I found an article from Howard Johnson on the web > > > > about designing T routes. It showed that this could be made to work, > > > > but that it was not easy. Splitting the trace four ways, would make it > > > > very hard to do. Just adding a series resistor is not magic. It is > > > > there to match the source impedance to the trace. Then where the trace > > > > splits, the outbound traces need to have a higher impedance to prevent a > > > > discontinuity. > > > > > > > > I have not looked up the formula for trace impedances, but HJ made it > > > > sound like they would get pretty narrow to bring the impedance up enough > > > > to match. In this case it would need to be about 200 Ohms after a four > > > > way split if you had 50 ohms before the split. I guess I could use a > > > > very small resistor, or no resistor, at the output of the chip. This > > > > would give me an impedance less than 50 Ohms and would allow the traces > > > > after the split to be somewhat wider. > > > > > > > > Here is the URL http://www.sigcon.com/articles/edn/tee.htm > > > > > > > > One problem with any analysis is the lack of good data. One data point > > > > I am lacking is the rise time of the clock. In this case I need to know > > > > the minium rise time since this is the worst case. The maximum is 2 nS, > > > > so it may be reasonable to assume 1 nS as a typical value. > > > > > > > > Pete Dudley wrote: > > > > > > > > > > I would think about doing the star routing with a source termination > > > > > resistor for each leg of the star, may 20 Ohms each. Make all the legs the > > > > > same length and make sure there are no breaks in the ground return under > > > > > these legs. > > > > > > > > > > -- > > > > > Pete Dudley > > > > > > > > > > Arroyo Grande Systems > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Wed, 20 Mar 2002 13:33:50 -0500 Organization: Arius, Inc Lines: 75 Message-ID: <3C98D60E.859D5A1A@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZNZs4CR4R+I1ICijvIwnFp35aDORA8irloty3wGQIgq1pJLF2GCWyK X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 20 Mar 2002 18:33:34 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15536 Bob Perlman wrote: > > Rick - > > A few comments/observations: > > 1) If your board stackup is at all conventional, trace impedances will > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > get other impedances, but getting to 200 ohms will require tricks that > you won't want to play. I am not at all clear on how you can guestimate the trace impedance to be in such a narrow range. I was under the impression that it varied directly with trace width. I could be using trace widths anywhere from 4 mil to 10 mil. Further, the board stackup depends entirely on layer count vs. power plane count. What were you assuming for these? I am hoping that I can get away with 4 routing planes and two power planes. But that is not clear at this point. I also would like to use 5/5 width/space on the traces, and I think this is less likely to vary. But I can certainly make the clock traces wider to lower the impedance. HJ has a T circuit analysis (or two) on the web that uses series terminations at each end (all three). The series resistors at the receiver were to damp resonant oscillations that can build up between the receivers. I may give this a try if I can model it. > 2) I don't know the strength of the C6711 clock driver. If it's > strong enough to drive a Thevenin-equivalent parallel termination, and > if you can tolerate the inevitable clock skew that arises from > daisy-chaining the clock net, then use a single net and parallel > termination. But be sure to check the weak/slow corner clock buffer > drive. In my experience, the clock outputs of processor chips tend to > be underpowered. (And they can be glitchy, too; a > ground-bounce-related glitch on the clock output of TI's TMS320C31 > nearly torpedoed one project I worked on.) I think I can afford to be accomodating in the skew since my daisy chained route would be about 3 inches or ~500 ps. However the longest single trace in a star configuration is only 1.4 inches or ~240 ps. The driver spec gives a max of 2 ns (no min) for the rise time, so even if it is 1 ns, my round trip is half the rise time. This is not ideal, but I think it will likley work without termination. > 3) If (2) doesn't pan out, spring for one of the small zero-delay > buffers, and drive each clock load with its own PLL output. If the > zero-delay buffer has built-in series termination, great; if not, > series-terminate each output. It'll cost you (not much) space and > (not much) money. I never try to economize on either when generating > and distributing clocks. Yes, I have thought about that, but small is a relative term and I am loath to add another part to the parts list. I would love to model this circuit, but I don't think I want to plunk down a few $k for a tool that will only be used one or twice per design. I may try to find a friend at a company with the tool and "borrow" it or let him run my tests after I come up with all the relevant data. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: bobsrefusebin@hotmail.com (Bob Perlman) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 20 Mar 2002 17:57:45 -0800 Organization: http://groups.google.com/ Lines: 107 Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> NNTP-Posting-Host: 24.221.179.83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1016675866 14507 127.0.0.1 (21 Mar 2002 01:57:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 21 Mar 2002 01:57:46 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!news-hog.berkeley.edu!newsfeed.berkeley.edu!ucberkeley!news.gv.tsc.tdk.com!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15637 Rick - rickman wrote in message news:<3C98D60E.859D5A1A@yahoo.com>... > Bob Perlman wrote: > > > > Rick - > > > > A few comments/observations: > > > > 1) If your board stackup is at all conventional, trace impedances will > > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > > get other impedances, but getting to 200 ohms will require tricks that > > you won't want to play. > > I am not at all clear on how you can guestimate the trace impedance to > be in such a narrow range. I was under the impression that it varied > directly with trace width. I could be using trace widths anywhere from > 4 mil to 10 mil. Further, the board stackup depends entirely on layer > count vs. power plane count. What were you assuming for these? I'm assuming that you're using a multi-layer board in which the height of the trace off the nearest plane is roughly the same as the trace width. For a 5-mil trace, for example, you'd be 5 mils from the nearest plane. You can violate this rule and make the height greater, thus increasing the impedance, but then crosstalk will bite you unless your trace-to-trace spacings are wide. And increasing the height of the trace above the plane does not increase the impedance rapidly. Here's a question that I ask students when I hold signal integrity courses: Suppose I'm in the space shuttle and I have a length of #30 AWG wire, and there's an infinitely wide ground plane sitting on the earth's surface 160 miles below. What's the impedance? Zillions of ohms? Any guesses? I'm also assuming that traces are narrow enough to fit between the vias for fine-pitch parts; this means they're not going to be extremely wide. These factors tend to put a bound on the practical range of achievable trace impedances. > > I am hoping that I can get away with 4 routing planes and two power > planes. But that is not clear at this point. I also would like to use > 5/5 width/space on the traces, and I think this is less likely to vary. > But I can certainly make the clock traces wider to lower the impedance. > > HJ has a T circuit analysis (or two) on the web that uses series > terminations at each end (all three). The series resistors at the > receiver were to damp resonant oscillations that can build up between > the receivers. I may give this a try if I can model it. > > > > 2) I don't know the strength of the C6711 clock driver. If it's > > strong enough to drive a Thevenin-equivalent parallel termination, and > > if you can tolerate the inevitable clock skew that arises from > > daisy-chaining the clock net, then use a single net and parallel > > termination. But be sure to check the weak/slow corner clock buffer > > drive. In my experience, the clock outputs of processor chips tend to > > be underpowered. (And they can be glitchy, too; a > > ground-bounce-related glitch on the clock output of TI's TMS320C31 > > nearly torpedoed one project I worked on.) > > I think I can afford to be accomodating in the skew since my daisy > chained route would be about 3 inches or ~500 ps. However the longest > single trace in a star configuration is only 1.4 inches or ~240 ps. The > driver spec gives a max of 2 ns (no min) for the rise time, so even if > it is 1 ns, my round trip is half the rise time. This is not ideal, but > I think it will likley work without termination. What happens when TI spins the die and the nominal risetime goes from 1ns to 0.6ns? > > 3) If (2) doesn't pan out, spring for one of the small zero-delay > > buffers, and drive each clock load with its own PLL output. If the > > zero-delay buffer has built-in series termination, great; if not, > > series-terminate each output. It'll cost you (not much) space and > > (not much) money. I never try to economize on either when generating > > and distributing clocks. > > Yes, I have thought about that, but small is a relative term and I am > loath to add another part to the parts list. > > I would love to model this circuit, but I don't think I want to plunk > down a few $k for a tool that will only be used one or twice per > design. I may try to find a friend at a company with the tool and > "borrow" it or let him run my tests after I come up with all the > relevant data. You can do surprisingly useful simulations with nothing more than the student version of PSpice. It's nowhere near as convenient as Hyperlynx, but it's free (or at least it used to be). Bob Perlman Cambrian Design Works http://www.cambriandesign.com > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Thu, 21 Mar 2002 00:34:49 -0500 Organization: Arius, Inc Lines: 91 Message-ID: <3C9970F9.47305AEC@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYL61UUg8DGXN9U4zniVqvwr85BPebe+P6o+1jclBp4IYchWssPwyyM X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 21 Mar 2002 05:34:43 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!fr.clara.net!heighliner.fr.clara.net!diablo.netcom.net.uk!netcom.net.uk!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15597 Bob Perlman wrote: > > Rick - > > rickman wrote in message news:<3C98D60E.859D5A1A@yahoo.com>... > > Bob Perlman wrote: > > > > > > Rick - > > > > > > A few comments/observations: > > > > > > 1) If your board stackup is at all conventional, trace impedances will > > > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > > > get other impedances, but getting to 200 ohms will require tricks that > > > you won't want to play. > > > > I am not at all clear on how you can guestimate the trace impedance to > > be in such a narrow range. I was under the impression that it varied > > directly with trace width. I could be using trace widths anywhere from > > 4 mil to 10 mil. Further, the board stackup depends entirely on layer > > count vs. power plane count. What were you assuming for these? > > I'm assuming that you're using a multi-layer board in which the height > of the trace off the nearest plane is roughly the same as the trace > width. For a 5-mil trace, for example, you'd be 5 mils from the > nearest plane. You can violate this rule and make the height greater, > thus increasing the impedance, but then crosstalk will bite you unless > your trace-to-trace spacings are wide. And increasing the height of > the trace above the plane does not increase the impedance rapidly. > Here's a question that I ask students when I hold signal integrity > courses: Suppose I'm in the space shuttle and I have a length of #30 > AWG wire, and there's an infinitely wide ground plane sitting on the > earth's surface 160 miles below. What's the impedance? Zillions of > ohms? Any guesses? I would not have a clue. But I want to know how you plan to measure it and verify your answer! > I'm also assuming that traces are narrow enough to fit between the > vias for fine-pitch parts; this means they're not going to be > extremely wide. These factors tend to put a bound on the practical > range of achievable trace impedances. I don't know if that is a valid assumption. We are not talking about a bus of many signals. This is the clock route and it can be made any impedance or width I want. There is also not much point in using extremely narrow traces since many of the finer pitch parts can not be rounted between the pins unless you go to unmanufacturable line/space widths. > > I think I can afford to be accomodating in the skew since my daisy > > chained route would be about 3 inches or ~500 ps. However the longest > > single trace in a star configuration is only 1.4 inches or ~240 ps. The > > driver spec gives a max of 2 ns (no min) for the rise time, so even if > > it is 1 ns, my round trip is half the rise time. This is not ideal, but > > I think it will likley work without termination. > > What happens when TI spins the die and the nominal risetime goes from > 1ns to 0.6ns? If they respin the die, the max clock rate will go up and I will be reexamining the board for many reasons. > You can do surprisingly useful simulations with nothing more than the > student version of PSpice. It's nowhere near as convenient as > Hyperlynx, but it's free (or at least it used to be). > > Bob Perlman > Cambrian Design Works > http://www.cambriandesign.com You can, but it takes a lot of time and effort to get the input data right. I was willing to do some testing with Hyperlynx, but I think pSpice will be a rather large effort to ramp up on. I think that a good book will help me more easily and quickly. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: bobsrefusebin@hotmail.com (Bob Perlman) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 21 Mar 2002 08:10:50 -0800 Organization: http://groups.google.com/ Lines: 108 Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> NNTP-Posting-Host: 24.221.179.83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1016727051 7537 127.0.0.1 (21 Mar 2002 16:10:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 21 Mar 2002 16:10:51 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15646 Rick - rickman wrote in message news:<3C9970F9.47305AEC@yahoo.com>... > Bob Perlman wrote: > > > > Rick - > > > > rickman wrote in message news:<3C98D60E.859D5A1A@yahoo.com>... > > > Bob Perlman wrote: > > > > > > > > Rick - > > > > > > > > A few comments/observations: > > > > > > > > 1) If your board stackup is at all conventional, trace impedances will > > > > fall somewhere in the range of 45 to 65 ohms. You can, with effort, > > > > get other impedances, but getting to 200 ohms will require tricks that > > > > you won't want to play. > > > > > > I am not at all clear on how you can guestimate the trace impedance to > > > be in such a narrow range. I was under the impression that it varied > > > directly with trace width. I could be using trace widths anywhere from > > > 4 mil to 10 mil. Further, the board stackup depends entirely on layer > > > count vs. power plane count. What were you assuming for these? > > > > I'm assuming that you're using a multi-layer board in which the height > > of the trace off the nearest plane is roughly the same as the trace > > width. For a 5-mil trace, for example, you'd be 5 mils from the > > nearest plane. You can violate this rule and make the height greater, > > thus increasing the impedance, but then crosstalk will bite you unless > > your trace-to-trace spacings are wide. And increasing the height of > > the trace above the plane does not increase the impedance rapidly. > > Here's a question that I ask students when I hold signal integrity > > courses: Suppose I'm in the space shuttle and I have a length of #30 > > AWG wire, and there's an infinitely wide ground plane sitting on the > > earth's surface 160 miles below. What's the impedance? Zillions of > > ohms? Any guesses? > > I would not have a clue. But I want to know how you plan to measure it > and verify your answer! It's about 1300 ohms. I'll take the space shuttle flight if you'll set up the ground plane (and remove it before the shuttle hits it). > > I'm also assuming that traces are narrow enough to fit between the > > vias for fine-pitch parts; this means they're not going to be > > extremely wide. These factors tend to put a bound on the practical > > range of achievable trace impedances. > > I don't know if that is a valid assumption. We are not talking about a > bus of many signals. This is the clock route and it can be made any > impedance or width I want. There is also not much point in using > extremely narrow traces since many of the finer pitch parts can not be > rounted between the pins unless you go to unmanufacturable line/space > widths. Fair enough. Do the board, and let me know what impedances you end up with. One other observation: if for whatever reason you decide to fatten out the traces to get lower-than-normal impedances (below 50 ohms), make sure you have a driver that can drive them. > > > I think I can afford to be accomodating in the skew since my daisy > > > chained route would be about 3 inches or ~500 ps. However the longest > > > single trace in a star configuration is only 1.4 inches or ~240 ps. The > > > driver spec gives a max of 2 ns (no min) for the rise time, so even if > > > it is 1 ns, my round trip is half the rise time. This is not ideal, but > > > I think it will likley work without termination. > > > > What happens when TI spins the die and the nominal risetime goes from > > 1ns to 0.6ns? > > If they respin the die, the max clock rate will go up and I will be > reexamining the board for many reasons. If they respin the die, they may sell you the faster die in the existing speed grade. That ground bounce problem I mentioned in an earlier message happened just that way. The vendor revved the die, used the new die on lower speed grades--it was cheaper to make, after all--and what had been a perfectly acceptable clock signal was now corrupted by ground bounce from faster neighbor signals. And you don't even need a die spin. What if you get a batch of fast-corner parts for the existing die? If you're making one or two boards, no problem; you hunt around for parts that are slower. But if you're planning to manufacture a number of boards over the long term, you could suddenly find yourself with a batch of boards that don't work. > > You can do surprisingly useful simulations with nothing more than the > > student version of PSpice. It's nowhere near as convenient as > > Hyperlynx, but it's free (or at least it used to be). > > > > Bob Perlman > > Cambrian Design Works > > http://www.cambriandesign.com > > You can, but it takes a lot of time and effort to get the input data > right. I was willing to do some testing with Hyperlynx, but I think > pSpice will be a rather large effort to ramp up on. I think that a good > book will help me more easily and quickly. Books are very useful; I particularly like Hall, Hall, and McCall. Good luck with the board. Bob Perlman Cambrian Design Works http://www.cambriandesign.com ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Thu, 21 Mar 2002 11:26:54 -0500 Organization: Arius, Inc Lines: 59 Message-ID: <3C9A09CE.C1D34736@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVY3AlCiN+SOB1TL6HwjgoO55Fza9QSP5RvXTCoVkrYJL3mmOZyyhfeR X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 21 Mar 2002 16:26:52 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.clara.net!heighliner.fr.clara.net!opentransit.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15598 Bob Perlman wrote: > > Rick - > > rickman wrote in message news:<3C9970F9.47305AEC@yahoo.com>... > > Bob Perlman wrote: > > > > > > Rick - > > > > > > What happens when TI spins the die and the nominal risetime goes from > > > 1ns to 0.6ns? > > > > If they respin the die, the max clock rate will go up and I will be > > reexamining the board for many reasons. > > If they respin the die, they may sell you the faster die in the > existing speed grade. That ground bounce problem I mentioned in an > earlier message happened just that way. The vendor revved the die, > used the new die on lower speed grades--it was cheaper to make, after > all--and what had been a perfectly acceptable clock signal was now > corrupted by ground bounce from faster neighbor signals. I understand that the die can get faster even with the slower spec'd parts. But we would replace our earlier design with a new design to take advantage of the speed and would not be buying the slower speed part (at least that is the most likely senario). When you say "ground bounce", that is not an issue that can be addressed by terminators and such, is it? I thought that ground bounce was purely a matter of decoupling the power and ground planes. > And you don't even need a die spin. What if you get a batch of > fast-corner parts for the existing die? If you're making one or two > boards, no problem; you hunt around for parts that are slower. But if > you're planning to manufacture a number of boards over the long term, > you could suddenly find yourself with a batch of boards that don't > work. If they really can get that fast. Xilinx once provided info on calculating min times from max specs and they essentially came up with a multiplier that was something like 25% or so. This included process, temp and power variations, and I think even typical process improvements over the life of a product. So there is a lower bound. But I expect that they would not need to make the edge rates significantly faster, so I am not sure you should even include process improvements. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### Message-ID: <3C9A0EF5.CDD53F89@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 25 Date: Thu, 21 Mar 2002 16:48:53 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1016729333 192.65.17.17 (Thu, 21 Mar 2002 09:48:53 MST) NNTP-Posting-Date: Thu, 21 Mar 2002 09:48:53 MST Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed1.cidera.com!Cidera!nntp.abs.net!uunet!dca.uu.net!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15656 Bob, Isn't the upper limit of intrinsic impedance that of free space? Squareroot of (absolute permittivity divided by absolute permeability) is about 377 ohms, isn't it? I thought one couldn't get any higher than that. Your insights into why 1300 ohms would be the better answer are much appreciated. - John_H Bob Perlman wrote: > > > Here's a question that I ask students when I hold signal integrity > > > courses: Suppose I'm in the space shuttle and I have a length of #30 > > > AWG wire, and there's an infinitely wide ground plane sitting on the > > > earth's surface 160 miles below. What's the impedance? Zillions of > > > ohms? Any guesses? > > > > I would not have a clue. But I want to know how you plan to measure it > > and verify your answer! > > It's about 1300 ohms. I'll take the space shuttle flight if you'll > set up the ground plane (and remove it before the shuttle hits it). ###### From: Austin Lesea Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Thu, 21 Mar 2002 09:04:19 -0800 Organization: Xilinx Lines: 52 Message-ID: <3C9A1292.BFCC71FE@xilinx.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> <3C9A0EF5.CDD53F89@mail.com> NNTP-Posting-Host: 149.199.9.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!proxad.net!wanadoo.fr!opentransit.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.cwix.com!wn2feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!12.120.28.17!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15606 John, Nope. You can make higher impedance guided wave structures that the impedance of free space. The most common WWII transmission lines in an Army base field station was 600 ohm line, two wires about 6" apart. Much higher than that isn't very practical (spacing is too large, or wire diameter too small). Basically, there are 'magic' impedances, like 75 ohm Cable TV coax, or 50 ohm coax for radio systems, or 50 to 65 ohm pcb traces, or 300 ohm TV ladder line. They are magic because 75 ohms uses the least amout of material, and has the least loss per mile (kilometer). 50 ohms uses the least amount of material, and has the best power handling capacity. 50 to 65 ohms on a pcb can be done with the usual spacings, thickness, and widths. TV ladder line is the lowest loss at 50 MHz to almost 1 GHz with the least cost for receiving only. Oh, those 600 ohm ladder lines were neat because of their very low loss, very high power handling capacity, and their ability to be fixed, built, patched, repaired with nothing more than some copper wire and some wooden sticks. So what comes first is the application (transmit, receive?), and the constraints (cost, material, least copper, shielding, etc), and then you use Maxwell's Equations to find a structure that meets all of your needs....or you just pick something from the catalog. Austin John_H wrote: > Bob, > > Isn't the upper limit of intrinsic impedance that of free space? Squareroot of (absolute > permittivity divided by absolute permeability) is about 377 ohms, isn't it? I thought one > couldn't get any higher than that. > > Your insights into why 1300 ohms would be the better answer are much appreciated. > > - John_H > > Bob Perlman wrote: > > > > > Here's a question that I ask students when I hold signal integrity > > > > courses: Suppose I'm in the space shuttle and I have a length of #30 > > > > AWG wire, and there's an infinitely wide ground plane sitting on the > > > > earth's surface 160 miles below. What's the impedance? Zillions of > > > > ohms? Any guesses? > > > > > > I would not have a clue. But I want to know how you plan to measure it > > > and verify your answer! > > > > It's about 1300 ohms. I'll take the space shuttle flight if you'll > > set up the ground plane (and remove it before the shuttle hits it). ###### Message-ID: <3C9A1DD6.83452FC5@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> <3C9A0EF5.CDD53F89@mail.com> <3C9A1292.BFCC71FE@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 60 Date: Thu, 21 Mar 2002 17:52:24 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1016733144 192.65.17.17 (Thu, 21 Mar 2002 10:52:24 MST) NNTP-Posting-Date: Thu, 21 Mar 2002 10:52:24 MST Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!cyclone2.usenetserver.com!usenetserver.com!sjc-peer.news.verio.net!news.verio.net!news.sanjose1.Level3.net!Level3.net!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15655 Thanks for the info, Austin - I'd forgotten a couple of the detail points and didn't know some others. If I had to guess to save my life, I would've said the upper limit for differential transmission lines would be twice the intrinsic impedance of free space - about 753 ohms. It's great to know some of the background for the things we use today. Austin Lesea wrote: > John, > > Nope. You can make higher impedance guided wave structures that the impedance of free space. > > The most common WWII transmission lines in an Army base field station was 600 ohm line, two > wires about 6" apart. > > Much higher than that isn't very practical (spacing is too large, or wire diameter too small). > > Basically, there are 'magic' impedances, like 75 ohm Cable TV coax, or 50 ohm coax for radio > systems, or 50 to 65 ohm pcb traces, or 300 ohm TV ladder line. They are magic because 75 > ohms uses the least amout of material, and has the least loss per mile (kilometer). 50 ohms > uses the least amount of material, and has the best power handling capacity. 50 to 65 ohms on > a pcb can be done with the usual spacings, thickness, and widths. TV ladder line is the > lowest loss at 50 MHz to almost 1 GHz with the least cost for receiving only. > > Oh, those 600 ohm ladder lines were neat because of their very low loss, very high power > handling capacity, and their ability to be fixed, built, patched, repaired with nothing more > than some copper wire and some wooden sticks. > > So what comes first is the application (transmit, receive?), and the constraints (cost, > material, least copper, shielding, etc), and then you use Maxwell's Equations to find a > structure that meets all of your needs....or you just pick something from the catalog. > > Austin > > John_H wrote: > > > Bob, > > > > Isn't the upper limit of intrinsic impedance that of free space? Squareroot of (absolute > > permittivity divided by absolute permeability) is about 377 ohms, isn't it? I thought one > > couldn't get any higher than that. > > > > Your insights into why 1300 ohms would be the better answer are much appreciated. > > > > - John_H > > > > Bob Perlman wrote: > > > > > > > Here's a question that I ask students when I hold signal integrity > > > > > courses: Suppose I'm in the space shuttle and I have a length of #30 > > > > > AWG wire, and there's an infinitely wide ground plane sitting on the > > > > > earth's surface 160 miles below. What's the impedance? Zillions of > > > > > ohms? Any guesses? > > > > > > > > I would not have a clue. But I want to know how you plan to measure it > > > > and verify your answer! > > > > > > It's about 1300 ohms. I'll take the space shuttle flight if you'll > > > set up the ground plane (and remove it before the shuttle hits it). ###### From: bobsrefusebin@hotmail.com (Bob Perlman) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 21 Mar 2002 16:19:02 -0800 Organization: http://groups.google.com/ Lines: 49 Message-ID: References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> <3C9A0EF5.CDD53F89@mail.com> NNTP-Posting-Host: 24.221.179.83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1016756342 24749 127.0.0.1 (22 Mar 2002 00:19:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 22 Mar 2002 00:19:02 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!sn-xit-01!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15695 John_H wrote in message news:<3C9A0EF5.CDD53F89@mail.com>... > Bob, > > Isn't the upper limit of intrinsic impedance that of free space? Squareroot of (absolute > permittivity divided by absolute permeability) is about 377 ohms, isn't it? I thought one > couldn't get any higher than that. > > Your insights into why 1300 ohms would be the better answer are much appreciated. I found the formula for wire-over-plane in two places: appendix C of Howard Johnson's book, and page 150 of Brian C. Wadell's Transmission Line Handbook. In both cases, the formula is [377/(2*pi)]*ln(4h/d), where h is the height above the plane and d the distance between the center of the wire and the top of the plane. Wadell states that the formula is good for h/d >> d, which certainly is true in this case. I used 450-ohm ladder line of the type Austin mentioned to feed a ham radio antenna as a kid. The impedance equation (276log(2S/d), where S is center to center distance and d is the diameter of the conductors) was a typical question on the amateur radio exam. There's no upper bound, but after a point you have to either accept that you can't get a higher impedance or route half the line through the neighbor's yard. I'm not an EMC guy, but aren't we conflating two related-but-different things? The impedance of free space is the E/H ratio of an electromagnetic field; trace impedance is dV/di. Anyone care to clarify further? Bob Perlman Cambrian Design Works http://www.cambriandesign.com > > - John_H > > > Bob Perlman wrote: > > > > > Here's a question that I ask students when I hold signal integrity > > > > courses: Suppose I'm in the space shuttle and I have a length of #30 > > > > AWG wire, and there's an infinitely wide ground plane sitting on the > > > > earth's surface 160 miles below. What's the impedance? Zillions of > > > > ohms? Any guesses? > > > > > > I would not have a clue. But I want to know how you plan to measure it > > > and verify your answer! > > > > It's about 1300 ohms. I'll take the space shuttle flight if you'll > > set up the ground plane (and remove it before the shuttle hits it). ###### From: hmurray-nospam@megapathdsl.net (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: High speed clock routing Date: Fri, 22 Mar 2002 08:34:51 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> <3C9A09CE.C1D34736@yahoo.com> X-Complaints-To: newsabuse@supernews.com Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed1.cidera.com!Cidera!peer1-sjc1.usenetserver.com!usenetserver.com!sn-xit-04!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray-nospam Xref: chonsp.franklin.ch comp.arch.fpga:15688 >I understand that the die can get faster even with the slower spec'd >parts. But we would replace our earlier design with a new design to >take advantage of the speed and would not be buying the slower speed >part (at least that is the most likely senario). That doesn't make sense to me. How long does it take you to crank out a new design? What do you do if customers want your existing product now? How long does it take you to even figure out that the problem is that a chip got faster when you weren't looking so you know that you need to do a redesign? What sort of volumes are you working in? Do you carefully monitor batch numbers and process changes? Some large organizations do this. It's a huge amount of paperwork. Some IC companys will tell you when they change things that might be interesting - like do a die shrink where they don't change the part number or data sheet. -- These are my opinions, not necessarily my employer's. I hate spam. ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: High speed clock routing Date: Fri, 22 Mar 2002 09:58:27 -0500 Organization: Arius, Inc Lines: 56 Message-ID: <3C9B4693.60F7B09F@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C98D60E.859D5A1A@yahoo.com> <3C9970F9.47305AEC@yahoo.com> <3C9A09CE.C1D34736@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbFYhBhwaKed2GXWAJNghyqmqKn2DRZ84VRlr8fu/DtbpCSwGCfljMG X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 22 Mar 2002 14:58:08 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15663 Hal Murray wrote: > > >I understand that the die can get faster even with the slower spec'd > >parts. But we would replace our earlier design with a new design to > >take advantage of the speed and would not be buying the slower speed > >part (at least that is the most likely senario). > > That doesn't make sense to me. > > How long does it take you to crank out a new design? > > What do you do if customers want your existing product now? > > How long does it take you to even figure out that the problem > is that a chip got faster when you weren't looking so you know > that you need to do a redesign? You make it sound like you are working in a vacuum. Typically you find out that they are cranking out a faster version some 4 to 6 months before it is available. Before all of the old, slower die are gone from the supply chain, you can order the faster speed grade of the chip at least as a sample and often as a production device. So it will be no mystery that they are producing a faster part and we can make whatever changes are needed to accomodate it. > What sort of volumes are you working in? > > Do you carefully monitor batch numbers and process changes? > Some large organizations do this. It's a huge amount of > paperwork. Some IC companys will tell you when they change > things that might be interesting - like do a die shrink where > they don't change the part number or data sheet. A die shrink is normally done to save money or production costs or to get a new speed grade out. Certainly we will know in advance if they are producing a new speed grade. In the DSP market, it will be very seldom that they are producing faster parts and they won't want to provide a new speed grade. It is almost like the PC world where they will have clock speeds 10% apart. In the DSP world they will provide clock speeds as close as 20% apart. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: nospam@needed.com (Paul) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Message-ID: References: <3C923297.57531263@yahoo.com> Lines: 146 Date: Sat, 23 Mar 2002 04:14:12 -0500 NNTP-Posting-Host: 64.230.16.167 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1016874845 64.230.16.167 (Sat, 23 Mar 2002 04:14:05 EST) NNTP-Posting-Date: Sat, 23 Mar 2002 04:14:05 EST Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!netnews.com!xfer02.netnews.com!newsfeed1.cidera.com!Cidera!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!NewsWatcher!user Xref: chonsp.franklin.ch comp.arch.fpga:15738 In article <3C923297.57531263@yahoo.com>, rickman wrote: > I need to plan a high speed bus that will connect 5 devices. They will > all be very closely spaced so that the lengths of the routes can be kept > pretty short. The clock line is the one I am most concerned about. It > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. ... snip... > I know Austin will tell me to simulate it, which I plan to do. I am > just trying to get a "gut" feeling as Bob Pease would want to do. You > know how easy it is to get the WRONG, right answer from a computer. > GIGO. These days, simulation IS the gut feeling. Once you've done a few simulations, with some typical CMOS 4ma, 8ma, 12ma drivers etc, you'll develop classifications for each problem type, their associated risks, and will find your simulation work affecting the way that you architect solutions. For example, before simulation, I would build designs with 10 loads on a long parallel bus - after simulation, I would never try anything like that again. First, for background reading, get a copy of the "MECL System Designers Handbook". Motorola went through several printings of this fine book without substantially updating the content, but it is still handy to have on your desk (it is what I started with 20 years ago). Obviously, Howard Johnston's book is excellent as well. Some other pointers: 1) Choosing track impedance - a higher impedance like 70ohms, can be easier for an IC to drive incident wave, but makes the track more sensitive to loading. A lower impedance track like 50ohms, reduces this sensitivity, but will need a CMOS driver with roughly an 8ma DC drive capability (that is a rule-of-thumb - CMOS 8ma DC drive looks roughly like a 50ohm source). All the digital stuff I do now is 50 ohms. 2) Series damped, point to point interconnect is your friend. In the case of a bidirectional interface, you could use two resistors (a small one on each end), or only place a series damping resistor on the device with extremely fast output edge rates (like data outputs from SDRAM). Use the rule of thumb in (1) to ensure the driver output impedance is less than or equal to the track impedance, so the series damping resistor can be used for "tuning". 3) Multipoint interfaces are a last resort. This is where you invest in a simulator. The first thing you need to do, is develop a realistic model for a copper track in FR-4. In the case of an expensive simulator like Hspice ($35K), you can actually enter geometric information, and the tool creates the parameters for you. To prove in the model, take a pulse source, a series damping resistor at the source and a parallel termination at the end of the transmission line as a proof of concept. If everything is matched, an "ideal" half-size signal should show up at the destination. After you are happy with the single ended or differential model you have developed, you can investigate topology. (Note that 10 experts will have 11 opinions on the validity of various vendors lossless or lossy transmission line models, so prepare to spend some time on this aspect.) a) Multipoint daisy chain. Works fine if the chips have extremely small input capacitance. Otherwise, much careful work must be done. If using a parallel termination resistor, place it AFTER the last IC. b) Star (one track from source to each load, with a series damping resistor). After you add several loads, you'll see the amplitude collapse. c) Symmetric T or H topology. The DIMM designers friend. I don't really understand why it works, because it should ring like crazy. The issue here, is slight differences in the length of the arms of the T or H can break this interconnect case. The issue is time-of-flight, so anything that affects TOF can break the interconnect (the delta allowed is about 1.5 inches or so for the last set of simulations I tried). This case typically uses no terminations, as their use spreads the devices out too far on the board and breaks the timing. 4) When selecting a solution, give some weight to fallback positions. In case (2) above, the series damping resistor value can be changed in the lab, if your assumptions or models are wrong (or if the board vendor spoils the "controlled impedance" tracks you asked for). Use zero ohm resistors to provide places to make engineering changes. 5) In terms of models, when I was working for a big company, I tried to insist on Spice models (Hspice supports a form of encryption, which, until some bozo proved they could break it, allowed the vendor some protection of their intellectual property.) These days, we are stuck with IBIS, which is good enough for the seat-of-the-pants investigation in (3) above. 6) Zero delay buffers can and should be used, to derisk clock distribution. Series damp the outputs. Cypress and many other vendors make zero delay buffers. Things to watch for: a) When planning the clock topology, don't daisy chain too many of these, because of jitter accumulation via the PLLs in these devices. Both active (PLL) and passive (non-PLL) devices exist, so plan accordingly. I aim for no more than one PLL per path from oscillator to load (but vendors say more than that are possible). b) Large fanout devices may have slow rise times, so investigate the timing before committing to using large fanout devices. (2-3 ns Tr for 16 outputs). Slow rise times give clock edge uncertainty. c) Try to allocate a buried layer for the clock signals (to reduce EMI) and use generous spacing rules to avoid clock crosstalk. A clock signal emits 100 times the emissions of a (random) data signal, so a single clock can emit as much as a whole databus. 7) Multilayer boards are your friend (if you can afford them in your application). Stripline (ground layer - signal layer - ground layer) is best, while offset stripline ( ground layer - north/south signal layer - east/west signal layer - ground layer) is really the most commonly used method. The offset stripline isn't, strictly speaking, controlled impedance, but it is good enough. 8) For the economy minded, Berkeley Spice was available in source form in past years (and may still be). The existence of this resource is what has enabled so many large and small developers, to provide analog simulation tools. As a result, cheap tools can be found, but the tradeoff may be, that the vendor's software team may not know anything about analog simulation! That is why I mention the topic of "dialling-in" a simulator below - it takes several hardware design cycles before you'll become somfortable with your simulator. These pleasant generalities are good in the 100-200MHz range. At much higher rates, signal attenuation can become an issue. At some point, your differential tracks may need to change from edge coupled (side by side on the same layer) to broadside coupled (over top of one another on adjacent layers). Broadside reduces loss by allowing the use of wider tracks. For cases involving higher rates, you may have to select devices based on the availability of Spice models. Some vendors will actually offer to run a Spice simulation case for you, at their factory, if it will make the sale and protect their intellectual property. In addition, plan to spin a prototype of the higher rate interconnect case in parallel with your actual hardware design, to "dial-in" your simulation model. Stuff like this is good training for an Eng student. ******* Years ago, a 10MHz bus or clock used to scare me. I never knew whether it would work, until I got into the lab. With the availability of signal integrity simulation, my pain threshold is now about 622Mb/s. In a big company, interconnect simulation can eat up 10-20% of your board design manpower. HTH, Paul (a believer in simulation) ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Sat, 23 Mar 2002 11:34:58 -0500 Organization: Arius, Inc Lines: 226 Message-ID: <3C9CAEB2.359557F2@yahoo.com> References: <3C923297.57531263@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZvpuEUsVdvFhLZjPgGjaDeKSe81ypUykvUskNLe5CqWcFN6JJ3Nxk2 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Mar 2002 16:34:49 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15728 Paul, Thanks for your comments. It was so good, I didn't want to snip any of it. I have made my comments in your text. Paul wrote: > > In article <3C923297.57531263@yahoo.com>, rickman > wrote: > > > I need to plan a high speed bus that will connect 5 devices. They will > > all be very closely spaced so that the lengths of the routes can be kept > > pretty short. The clock line is the one I am most concerned about. It > > is 100 MHz ECLKOUT from a TI C6711 DSP. The five devices are an SBSRAM, > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E. > ... snip... > > I know Austin will tell me to simulate it, which I plan to do. I am > > just trying to get a "gut" feeling as Bob Pease would want to do. You > > know how easy it is to get the WRONG, right answer from a computer. > > GIGO. > > These days, simulation IS the gut feeling. Once you've done a few > simulations, with some typical CMOS 4ma, 8ma, 12ma drivers etc, you'll > develop classifications for each problem type, their associated risks, > and will find your simulation work affecting the way that you architect > solutions. For example, before simulation, I would build designs with > 10 loads on a long parallel bus - after simulation, I would never try > anything like that again. I was working under the assumption that my paths would be short relative to the edge rate of the driver. But I now realize that you can't make any assumptions about your edge rate since this can change at any time as the chips are run with new processes. So the working minimum edge rate is 0 ps. I was planning to do a simulation using the demo version of Hyperlynx. But they no longer allow you to so ANY useful work. This is one of my problems with demo software. They want me to spend thousands of dollars of time to "evaluate" their product, but are not willing to let me get anything in return. I feel it is very reasonable to let me accomplish some amount of work during the evaluation so that my time is not totally wasted if the product does not turn out to be something that I wish to pay thousands of dollars for. Either that or I am rationalizing not being able to pay for every multi-thousand dollar toy that I would like to be able to use. > First, for background reading, get a copy of the "MECL System Designers > Handbook". Motorola went through several printings of this fine book > without substantially updating the content, but it is still handy to > have on your desk (it is what I started with 20 years ago). Obviously, > Howard Johnston's book is excellent as well. I had a copy at some point, but it seems to be MIA at the moment. > Some other pointers: > > 1) Choosing track impedance - a higher impedance like 70ohms, can be > easier for an IC to drive incident wave, but makes the track more > sensitive to loading. A lower impedance track like 50ohms, reduces > this sensitivity, but will need a CMOS driver with roughly an > 8ma DC drive capability (that is a rule-of-thumb - CMOS 8ma DC drive > looks roughly like a 50ohm source). All the digital stuff I do now > is 50 ohms. > 2) Series damped, point to point interconnect is your friend. In the > case of a bidirectional interface, you could use two resistors > (a small one on each end), or only place a series damping resistor > on the device with extremely fast output edge rates (like data > outputs from SDRAM). Use the rule of thumb in (1) to ensure the > driver output impedance is less than or equal to the track > impedance, so the series damping resistor can be used for "tuning". This is a nice solution if you can do it. It would be very, very hard to provide point to point traces for every bit of a 32 bit data bus along with the 20 bit address bus and control signals. > 3) Multipoint interfaces are a last resort. This is where you invest > in a simulator. The first thing you need to do, is develop a > realistic model for a copper track in FR-4. In the case of an > expensive simulator like Hspice ($35K), you can actually enter > geometric information, and the tool creates the parameters for you. > To prove in the model, take a pulse source, a series damping resistor > at the source and a parallel termination at the end of the > transmission line as a proof of concept. If everything is matched, > an "ideal" half-size signal should show up at the destination. After > you are happy with the single ended or differential model you have > developed, you can investigate topology. (Note that 10 experts will > have 11 opinions on the validity of various vendors lossless or > lossy transmission line models, so prepare to spend some time on > this aspect.) I am missing something here. Why would I want a "half-size signal" to appear at my inputs? This would violate the input voltage levels and likely would create double clocking and not work. Or is this just a way to verify the impedance model, but will not be used? > a) Multipoint daisy chain. Works fine if the chips have extremely > small input capacitance. Otherwise, much careful work must be done. > If using a parallel termination resistor, place it AFTER the > last IC. Can you define what you mean by "extremely small input capacitance". Is 10 pF small enough? Is 5 pF small enough? I don't think I remember ever seeing an input spec of 5 pF or less. They are all about 6 to 12 pF. > b) Star (one track from source to each load, with a series damping > resistor). After you add several loads, you'll see the amplitude > collapse. I was thinking about doing this. Why would the amplitude colapse? If parallel termination is not used, why would this be a problem? Howard Johnson (HJ) did an analysis of the T (a simple case of the star) and showed that it could work. He used 50 ohm trace up to the point of split and used 100 ohm trace after that. Of course with a four way star, you would need 200 ohm trace or start with a lower impedance. Some have indicated that 200 ohm traces are a problem. > c) Symmetric T or H topology. The DIMM designers friend. I don't > really understand why it works, because it should ring like crazy. > The issue here, is slight differences in the length of the arms of > the T or H can break this interconnect case. The issue is > time-of-flight, so anything that affects TOF can break the > interconnect (the delta allowed is about 1.5 inches or so for the > last set of simulations I tried). This case typically uses no > terminations, as their use spreads the devices out too far on the > board and breaks the timing. HJ did a couple of articles on this at http://www.sigcon.com/articles/edn/tee.htm and http://www.sigcon.com/articles/edn/DrivingTwoLoads.htm > 4) When selecting a solution, give some weight to fallback positions. > In case (2) above, the series damping resistor value can be changed > in the lab, if your assumptions or models are wrong (or if the board > vendor spoils the "controlled impedance" tracks you asked for). Use > zero ohm resistors to provide places to make engineering changes. > 5) In terms of models, when I was working for a big company, I tried to > insist on Spice models (Hspice supports a form of encryption, which, > until some bozo proved they could break it, allowed the vendor some > protection of their intellectual property.) These days, we are stuck > with IBIS, which is good enough for the seat-of-the-pants > investigation in (3) above. > 6) Zero delay buffers can and should be used, to derisk clock > distribution. Series damp the outputs. Cypress and many other vendors > make zero delay buffers. Things to watch for: > > a) When planning the clock topology, don't daisy chain too many of > these, because of jitter accumulation via the PLLs in these > devices. Both active (PLL) and passive (non-PLL) devices exist, so > plan accordingly. I aim for no more than one PLL per path from > oscillator to load (but vendors say more than that are possible). > b) Large fanout devices may have slow rise times, so investigate > the timing before committing to using large fanout devices. > (2-3 ns Tr for 16 outputs). Slow rise times give clock edge > uncertainty. > c) Try to allocate a buried layer for the clock signals (to reduce > EMI) and use generous spacing rules to avoid clock crosstalk. > A clock signal emits 100 times the emissions of a (random) data > signal, so a single clock can emit as much as a whole databus. > 7) Multilayer boards are your friend (if you can afford them in your > application). Stripline (ground layer - signal layer - ground layer) > is best, while offset stripline ( ground layer - north/south signal > layer - east/west signal layer - ground layer) is really the most > commonly used method. The offset stripline isn't, strictly speaking, > controlled impedance, but it is good enough. > 8) For the economy minded, Berkeley Spice was available in source form > in past years (and may still be). The existence of this resource is > what has enabled so many large and small developers, to provide > analog simulation tools. As a result, cheap tools can be found, but > the tradeoff may be, that the vendor's software team may not know > anything about analog simulation! That is why I mention the topic of > "dialling-in" a simulator below - it takes several hardware design > cycles before you'll become somfortable with your simulator. > > These pleasant generalities are good in the 100-200MHz range. At much > higher rates, signal attenuation can become an issue. At some point, > your differential tracks may need to change from edge coupled (side by > side on the same layer) to broadside coupled (over top of one another > on adjacent layers). Broadside reduces loss by allowing the use of > wider tracks. > > For cases involving higher rates, you may have to select devices based > on the availability of Spice models. Some vendors will actually offer > to run a Spice simulation case for you, at their factory, if it will > make the sale and protect their intellectual property. > > In addition, plan to spin a prototype of the higher rate interconnect > case in parallel with your actual hardware design, to "dial-in" your > simulation model. Stuff like this is good training for an Eng > student. > > ******* > > Years ago, a 10MHz bus or clock used to scare me. I never knew whether > it would work, until I got into the lab. With the availability of > signal integrity simulation, my pain threshold is now about 622Mb/s. > > In a big company, interconnect simulation can eat up 10-20% of your > board design manpower. > > HTH, > Paul (a believer in simulation) Thanks for the comments... -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: nospam@needed.com (Paul) Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Message-ID: References: <3C923297.57531263@yahoo.com> <3C9CAEB2.359557F2@yahoo.com> Lines: 147 Date: Sat, 23 Mar 2002 23:11:36 -0500 NNTP-Posting-Host: 64.230.23.138 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1016943090 64.230.23.138 (Sat, 23 Mar 2002 23:11:30 EST) NNTP-Posting-Date: Sat, 23 Mar 2002 23:11:30 EST Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sunqbc.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!NewsWatcher!user Xref: chonsp.franklin.ch comp.arch.fpga:15760 In article <3C9CAEB2.359557F2@yahoo.com>, rickman wrote: > Paul, > > Thanks for your comments. It was so good, I didn't want to snip any of > it. I have made my comments in your text. > > > These days, simulation IS the gut feeling. Once you've done a few > > simulations, with some typical CMOS 4ma, 8ma, 12ma drivers etc, you'll > > develop classifications for each problem type, their associated risks, > > and will find your simulation work affecting the way that you architect > > solutions. For example, before simulation, I would build designs with > > 10 loads on a long parallel bus - after simulation, I would never try > > anything like that again. > > I was working under the assumption that my paths would be short relative > to the edge rate of the driver. But I now realize that you can't make > any assumptions about your edge rate since this can change at any time > as the chips are run with new processes. So the working minimum edge > rate is 0 ps. If you get the IBIS model for the driver and it has params dV/dt_r and dV/dt_f, that will give risetime of the driver with a simple load on it. If a manufacturer does a simple shrink, they shrink the core geometry but leave the pads at the old geometry (i.e. 0.18u pads, 0.13u core gates). The dV/dt listed in the IBIS file should apply for the life of that part number. > > I was planning to do a simulation using the demo version of Hyperlynx. > But they no longer allow you to so ANY useful work. This is one of my > problems with demo software. They want me to spend thousands of dollars > of time to "evaluate" their product, but are not willing to let me get > anything in return. I feel it is very reasonable to let me accomplish > some amount of work during the evaluation so that my time is not totally > wasted if the product does not turn out to be something that I wish to > pay thousands of dollars for. > > Either that or I am rationalizing not being able to pay for every > multi-thousand dollar toy that I would like to be able to use. The last time I wanted to try some simulations at home, I was able to find a product for Macintosh, that had a 30 day evaluation. If you are trying to do this work as economically as possible, you could go from one evaluation to another, but it will cost you personal time. I guess it really depends on the size of the company. One floating license can support a lot of engineers, when the runtime for a simulation is 30 seconds. (And, for Hspice, I was able to find a viewer package from a university, that avoids having to buy a license for many waveform viewers.) If you are doing detailed simulations, these times can run up to 24 hours - and that type of simulation is not what I am proposing. I like to do quick simulations, sometimes using models from analagous parts, just to see how practical an interconnect topology is. Sort of a manual sensitivity analysis. Doing a search on Altavista (search term "berkeley spice"), I can see, for example, a new project on SourceForge called NGspice. My point is, the Berkeley Spice project has fathered many solutions - either buy an expensive one (and ask on the net, if the tech support is good), or try out some cheaper or free solutions on your own time. ...snip... > > 2) Series damped, point to point interconnect is your friend. In the > > case of a bidirectional interface, you could use two resistors > > (a small one on each end), or only place a series damping resistor > > on the device with extremely fast output edge rates (like data > > outputs from SDRAM). Use the rule of thumb in (1) to ensure the > > driver output impedance is less than or equal to the track > > impedance, so the series damping resistor can be used for "tuning". > > This is a nice solution if you can do it. It would be very, very hard > to provide point to point traces for every bit of a 32 bit data bus > along with the 20 bit address bus and control signals. Agreed. Sometimes you have a choice, as in choosing whether an FPGA sits off the side of a bus, or buffers data onto a sub-bus. On my last project, I cut my bus in two pieces with some 2:1 QuickSwitches, in order to shorten the segments and make a reasonable transfer rate possible. I wouldn't have tried that, if the original sim hadn't looked so bad. > > > 3) Multipoint interfaces are a last resort. This is where you invest > > in a simulator. The first thing you need to do, is develop a > > realistic model for a copper track in FR-4. In the case of an > > expensive simulator like Hspice ($35K), you can actually enter > > geometric information, and the tool creates the parameters for you. > > To prove in the model, take a pulse source, a series damping resistor > > at the source and a parallel termination at the end of the > > transmission line as a proof of concept. If everything is matched, > > an "ideal" half-size signal should show up at the destination. After > > you are happy with the single ended or differential model you have > > developed, you can investigate topology. (Note that 10 experts will > > have 11 opinions on the validity of various vendors lossless or > > lossy transmission line models, so prepare to spend some time on > > this aspect.) > > I am missing something here. Why would I want a "half-size signal" to > appear at my inputs? This would violate the input voltage levels and > likely would create double clocking and not work. Or is this just a way > to verify the impedance model, but will not be used? > Sorry if I was unclear. The "ideal transmission line" case is something I run, to make sure my geometric specification has roughly the right impedance. After I have proved a single segment of transmission line is correct, like Lego, I can start plugging segments together and do my real test cases. > > > a) Multipoint daisy chain. Works fine if the chips have extremely > > small input capacitance. Otherwise, much careful work must be done. > > If using a parallel termination resistor, place it AFTER the > > last IC. > > Can you define what you mean by "extremely small input capacitance". Is > 10 pF small enough? Is 5 pF small enough? I don't think I remember > ever seeing an input spec of 5 pF or less. They are all about 6 to 12 > pF. That was a little tongue in check. The input capacitance is never small enough :-) > > > > b) Star (one track from source to each load, with a series damping > > resistor). After you add several loads, you'll see the amplitude > > collapse. > > I was thinking about doing this. Why would the amplitude colapse? If > parallel termination is not used, why would this be a problem? Howard > Johnson (HJ) did an analysis of the T (a simple case of the star) and > showed that it could work. He used 50 ohm trace up to the point of > split and used 100 ohm trace after that. Of course with a four way > star, you would need 200 ohm trace or start with a lower impedance. > Some have indicated that 200 ohm traces are a problem. The "impedance fork", using two 100 ohm traces running from a 50 ohm trace, is shown in the MECL System Designers Handbook. Making a 100ohm track would require cutting a slot in virtually all your ground layers, so isn't practical. I was referring to driving (n) 50 ohm stubs from one driver - if you try this in simulation, you'll see the amplitude drop pretty quickly. More than three loads or so wouldn't work. Paul ###### From: Martin Thompson Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 25 Mar 2002 08:33:49 +0000 Organization: TRW Conekt Lines: 52 Sender: Thompsm@977845-DT Message-ID: References: <3C923297.57531263@yahoo.com> <3C9CAEB2.359557F2@yahoo.com> NNTP-Posting-Host: 194.74.228.66 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1017045193 22251735 194.74.228.66 (16 [98603]) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!fu-berlin.de!uni-berlin.de!194.74.228.66!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15774 rickman writes: > > I was planning to do a simulation using the demo version of Hyperlynx. > But they no longer allow you to so ANY useful work. This is one of my > problems with demo software. They want me to spend thousands of dollars > of time to "evaluate" their product, but are not willing to let me get > anything in return. I feel it is very reasonable to let me accomplish > some amount of work during the evaluation so that my time is not totally > wasted if the product does not turn out to be something that I wish to > pay thousands of dollars for. > I got a 30-day eval of the full Hyperlynx tool from them, for 30 days I reckon, They were very nice about extending it when I hadn't been able to start the eval soon enough as well. Delivered with manuals (real paper!) and everything! > > > a) Multipoint daisy chain. Works fine if the chips have extremely > > small input capacitance. Otherwise, much careful work must be done. > > If using a parallel termination resistor, place it AFTER the > > last IC. > > Can you define what you mean by "extremely small input capacitance". Is > 10 pF small enough? Is 5 pF small enough? I don't think I remember > ever seeing an input spec of 5 pF or less. They are all about 6 to 12 > pF. > IIRC you are doing a C6711 design? I did a C6711, two flash, two SDRAM (ith two footprints each to accomodate 64MBit and 256MBit devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-). It ended up as a daisy chain, with series ternminators on the FPGA datalines as its edges were horrible. The C6711 has (according to TI) been designed with slower edges than the previos C6x family so it doens;t need terminators as it is a low cost device - and that did seem to be the case. HTH, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt ###### From: rickman Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: Mon, 25 Mar 2002 10:17:03 -0500 Organization: Arius, Inc Lines: 62 Message-ID: <3C9F3F6F.FE54DEE6@yahoo.com> References: <3C923297.57531263@yahoo.com> <3C9CAEB2.359557F2@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVblm8JlcAGPU15z6LvcGdp52FBcENbMHxZWOS2xwylMLxMVIhyWaOow X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 25 Mar 2002 15:16:18 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15776 Martin Thompson wrote: > > rickman writes: > > > > > > > I was planning to do a simulation using the demo version of Hyperlynx. > > But they no longer allow you to so ANY useful work. This is one of my > > problems with demo software. They want me to spend thousands of dollars > > of time to "evaluate" their product, but are not willing to let me get > > anything in return. I feel it is very reasonable to let me accomplish > > some amount of work during the evaluation so that my time is not totally > > wasted if the product does not turn out to be something that I wish to > > pay thousands of dollars for. > > > > I got a 30-day eval of the full Hyperlynx tool from them, for 30 days > I reckon, They were very nice about extending it when I hadn't been > able to start the eval soon enough as well. Delivered with manuals > (real paper!) and everything! > > > > > > > > a) Multipoint daisy chain. Works fine if the chips have extremely > > > small input capacitance. Otherwise, much careful work must be done. > > > If using a parallel termination resistor, place it AFTER the > > > last IC. > > > > Can you define what you mean by "extremely small input capacitance". Is > > 10 pF small enough? Is 5 pF small enough? I don't think I remember > > ever seeing an input spec of 5 pF or less. They are all about 6 to 12 > > pF. > > > > IIRC you are doing a C6711 design? I did a C6711, two flash, two > SDRAM (ith two footprints each to accomodate 64MBit and 256MBit > devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-). It ended up as > a daisy chain, with series ternminators on the FPGA datalines as its > edges were horrible. The C6711 has (according to TI) been designed > with slower edges than the previos C6x family so it doens;t need > terminators as it is a low cost device - and that did seem to be the > case. I am a little confused by what you said. You say that the edge rates on the C6711 seem to be slower than other C6x chips, and yet you say that you needed terminators since the edges were horrible. I don't understand. Did you mean that the C6711B was redesigned? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Subject: Re: High speed clock routing Newsgroups: comp.arch.fpga,comp.arch.embedded References: <3C923297.57531263@yahoo.com> <3C965C25.974C5512@yahoo.com> <3C96813D.99CCDB8B@yahoo.com> <3C968CA1.43FAD089@xilinx.com> <3C9698B8.94A11AB0@yahoo.com> User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (OpenBSD/2.9 (i386)) Lines: 24 Message-ID: NNTP-Posting-Host: 12.249.117.217 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc02 1017077806 12.249.117.217 (Mon, 25 Mar 2002 17:36:46 GMT) NNTP-Posting-Date: Mon, 25 Mar 2002 17:36:46 GMT Organization: AT&T Broadband Date: Mon, 25 Mar 2002 17:36:46 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.cwix.com!wn2feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!sccrnsc02.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15808 In comp.arch.fpga rickman wrote: > I think that most people don't want to simulate because it is unfamiliar > territory for them. I am in that camp. I would perfer not to, but I am > not willing to take a chance on 100 MHz clock lines which may be run up > to 133 when the faster chip comes out. Yes, I know that the clock speed > is not what is important, but rather it is the edge rate. But to allow > the clock to speed up the edge rate will also go up. > But I am concerned that I will not have the correct data when I perform > the simulation. I still need to close the loop to get valid data that > reflects my PCB. That is an item that I will have to research further. > I am going to start with an old copy of the Motorola ECL data book. It > has a good chapter on Stripline and Microline (if I am remembering the > terms correctly) and calculating all the relevant characteristics... if > I can get the appropriate data on the PCB materials. I worked for a company that subcontracted some of this stuff out when we were getting started. The contractor we used did a nice job - their website is http://www.avid-tech.com. They also sold the tools (hyperlynx) to us after we got up to speed. (No affiliation, etc, etc) -- "The sooner you fall behind, the more time you'll have to catch up!" ###### From: Martin Thompson Newsgroups: comp.arch.fpga,comp.arch.embedded Subject: Re: High speed clock routing Date: 26 Mar 2002 08:37:27 +0000 Organization: TRW Conekt Lines: 33 Sender: Thompsm@977845-DT Message-ID: References: <3C923297.57531263@yahoo.com> <3C9CAEB2.359557F2@yahoo.com> <3C9F3F6F.FE54DEE6@yahoo.com> NNTP-Posting-Host: 194.74.228.66 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1017131805 23313278 194.74.228.66 (16 [98603]) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!nntp.infostrada.it!fu-berlin.de!uni-berlin.de!194.74.228.66!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:15771 rickman writes: > > IIRC you are doing a C6711 design? I did a C6711, two flash, two > > SDRAM (ith two footprints each to accomodate 64MBit and 256MBit > > devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-). It ended up as > > a daisy chain, with series terminators on the FPGA datalines as its > > edges were horrible. The C6711 has (according to TI) been designed > > with slower edges than the previos C6x family so it doens;t need > > terminators as it is a low cost device - and that did seem to be the > > case. > > I am a little confused by what you said. You say that the edge rates on > the C6711 seem to be slower than other C6x chips, and yet you say that > you needed terminators since the edges were horrible. I don't > understand. Did you mean that the C6711B was redesigned? > Sorry, I was unclear! The FPGA edges were horrible so the data lines needed terminating. The address lines (driven only by the DSP) were fine, in fact slower than I would've liked, but they were driving a large number of devices. I don't know about the C6711B, have you beaten an IBIS model out of them yet? The first one I got from TI for the C6711 was great - no driver information at all! Good luck! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt