From: felix_bertram@my-deja.com Newsgroups: comp.arch.fpga Subject: Spartan-II DLL Usage Date: Thu, 04 Jan 2001 15:44:30 GMT Organization: Deja.com Lines: 32 Message-ID: <9325os$dq9$1@nnrp1.deja.com> NNTP-Posting-Host: 212.86.34.67 X-Article-Creation-Date: Thu Jan 04 15:44:30 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) X-Http-Proxy: 1.1 x73.deja.com:80 (Squid/1.1.22) for client 212.86.34.67 X-MyDeja-Info: XMYDJUIDfelix_bertram Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!btnet-peer1!btnet-peer0!btnet-peer!btnet!newsfeed.mathworks.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3629 Hello everybody, I am working on an FPGA with the surrounded hardware being given, so that I have to find a solution, even if it is not optimal. I want to quadruple a clock of 24MHz, so that I finally have a clock with 96MHz frequency. I used two DLLs to do so and- it seems to work fine. However, the datasheet gives 25MHz as the lowest DLL input frequency, so that I am definitly out of spec. There seem to be two solutions: 1) There is some safety margin, so that I can feed 24MHz into the DLL. As the DLL's resolution is limited to 60ps I assume that it is built from 60ps-delay items- which will have some temperature or voltage dependency. Is there some detailed information on the behavior of the DLLs??? 2) I first double the clock by using combinational logic, basically a small delay followed by an XOR. This results in a 48MHz clock with a very small duty cycle which is fed into a single DLL. This DLL will correct my duty cycle to 50% and at the same time doubles my clock to 96MHz. If this works, has anybody done so? I am working with VHDL, how do I prevent the tools from "optimizing" my combinational path? Any comments very much appreciated, best regards Felix Bertram Sent via Deja.com http://www.deja.com/ ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Thu, 04 Jan 2001 08:43:56 -0800 Organization: Xilinx Lines: 83 Message-ID: <3A54A84C.9FCFB016@xilinx.com> References: <9325os$dq9$1@nnrp1.deja.com> NNTP-Posting-Host: 149.199.7.181 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeed.germany.net!newscore.gigabell.net!newsfeed00.sul.t-online.de!t-online.de!ptdnetP!newsgate.ptd.net!attmtf.ip.att.net!attla1!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3612 Felix, The low frequency limit of the DLL is process, voltage and temperature dependent (as you might guess!). The delay lines run off their own regulated supply, so the voltage variations are extremely small (don't worry about them). The temperature variation is important, because if it locks at hot, and then it gets cold, it could run out of taps at a low frequency (line not long enough as it gets faster as it got colder). There is definitely a safety margin, and it is at least 10%. But we may choose to ship product that is much much faster (everyone loves faster), and reduce this margin in the future. Now, I am assuming you are not going below 0C, so there will be some margin there. But if not, then definitely don't do it. In process, the delay lines use techniques to make them less sensitive to transistor speed, but a fast lot will still have slightly faster delay lines, which will not work reliably at lower frequencies. All of that said, I would not recommend its use out of specification. You would probably get away with it until that one lot came along that was just a little too fast when your board got just a little too cold.....(been there, done that: not good for your career!). Doubling with a delay and an XOR is a common technique, and if you can take the delay element and place it off chip, you will not have to worry about it getting too fast due to the process/voltage/temperature variations in the FPGA. I used to use a small RC off chip that added to the delay and made this reliable (used in 100K+ units of a fiber optic transmission system). I lived through three process changes of Xilinx fpga's with this method, even though it is an asynchronous "no-no". The DLL only cares about the rising edge of the input, and is incredibly tolerant to input jitter, so it can easily use the XOR doubled input signal. The resulting 4X output, however achieved, will have more jitter. I would expect less than 200ps peak to peak period jitter, worst case, when everything is up and running (all ff's clocking, IOB's toggling, etc). A single DLL (not doubling) in the same scenario would have less than 100 ps. Jitter is not strictly additive, and the DLL does no filtering of any input jitter. Austin felix_bertram@my-deja.com wrote: > Hello everybody, > > I am working on an FPGA with the surrounded hardware being given, so > that I have to find a solution, even if it is not optimal. > > I want to quadruple a clock of 24MHz, so that I finally have a clock > with 96MHz frequency. I used two DLLs to do so and- it seems to work > fine. However, the datasheet gives 25MHz as the lowest DLL input > frequency, so that I am definitly out of spec. > > There seem to be two solutions: > 1) There is some safety margin, so that I can feed 24MHz into the DLL. > As the DLL's resolution is limited to 60ps I assume that it is built > from 60ps-delay items- which will have some temperature or voltage > dependency. Is there some detailed information on the behavior of the > DLLs??? > > 2) I first double the clock by using combinational logic, basically a > small delay followed by an XOR. This results in a 48MHz clock with a > very small duty cycle which is fed into a single DLL. This DLL will > correct my duty cycle to 50% and at the same time doubles my clock to > 96MHz. If this works, has anybody done so? I am working with VHDL, how > do I prevent the tools from "optimizing" my combinational path? > > Any comments very much appreciated, > best regards > > Felix Bertram > > Sent via Deja.com > http://www.deja.com/ ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: 5 Jan 2001 09:50:38 GMT Organization: Compaq Systems Research Center Lines: 75 Distribution: world Message-ID: <9345de$ktr@src-news.pa.dec.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!mailint03.im.hou.compaq.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:3649 [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] > Now, I am assuming you are not going below 0C, so there will be some > margin there. But if not, then definitely don't do it. In general, CMOS prop time is linear in temp and supply voltage. He's only off by 4% so we should be able to draw the forbidden zone on a graph with voltage on one axis and temp on the other. Does that sort of reasoning work with DLLs? > Doubling with a delay and an XOR is a common technique, and if you can > take the delay element and place it off chip, you will not have to worry > about it getting too fast due to the process/voltage/temperature > variations in the FPGA. I used to use a small RC off chip that added to > the delay and made this reliable (used in 100K+ units of a fiber optic > transmission system). I lived through three process changes of Xilinx > fpga's with this method, even though it is an asynchronous "no-no". I seem to remember an old APP note describing using an XOR for a clock doubler and promising that the circuit would work. I think the trick was to use the clock on a FF that was inside the clock generation path so the delay was sure to be long enough to clock a FF on that chip and at that temp/voltage. Try this. The clock is the XOR of the input to a FF and it's output and that clock clocks the FF. Then the pulse width will be whatever the FF needs to get clocked plus some prop time for roundup. I can't see any way that wouldn't work. Well, it might not run fast enough, but that seems unlikely if the reason we are using this hack is because the clock it too slow for the DLL. But we can check the min time (worst case) and compare that to the spec sheet. I'd call a hack/kludge like this a non-prefered solution rather than a no-no. The goal is to make designs that work solidly. Mostly, that means meeting timings and that's obviously easier to check with clean digital logic - we have tools that do most of the work for us. But there are things like metastability so you do have to think about other issues. As long as there aren't many of them and they are around the edges we can probably get the whole design right. I'll try reasonably hard to avoid things like the XOR doubler, but when I run out of alternatives AND I think I can convince myself that it will work reliabily then I'll use them. That convincing frequently involves taking advantage of temp/voltage tracking to "prove" that the worst case can't happen when it will hurt you. The reason to avoid them is not that they don't work, but that it takes time to make sure they will work. I can think of two risks when using a non-prefered technique. The first is that I'll overlook something significant. The second is that there is a flaw in my reasoning or my arithmetic. This is the time when it's great to have smart friends who are willing to look over your design and double check your reasoning. I'd probably be more worried about bypassing on the power planes than something like an XOR clock doubler. Also note that the XOR doubler trick doesn't work if the design needs the DLL to phase lock to the input clock as well as generate faster clocks. -- These are my opinions, not necessarily my employers. I hate spam. ###### From: felix_bertram@my-deja.com Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Fri, 05 Jan 2001 15:37:35 GMT Organization: Deja.com Lines: 183 Message-ID: <934pnu$l0k$1@nnrp1.deja.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> NNTP-Posting-Host: 212.86.34.67 X-Article-Creation-Date: Fri Jan 05 15:37:35 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) X-Http-Proxy: 1.1 x53.deja.com:80 (Squid/1.1.22) for client 212.86.34.67 X-MyDeja-Info: XMYDJUIDfelix_bertram Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3634 Hello everybody, first of all I'd like to thank you for your valuable input, special thanks to Austin and Hal. I succeeded creating a 48MHz clock from the 24Mhz, using an XOR and a FF. I can see the clock with my scope, it is running at 48Mhz and is approx 4ns high (and 16ns low), with my XC2S50-TQ144-5C. The signal I probed was CLK2x from the code below. I did not succeed creating a 96MHz clock from the 48MHz using a DLL. The signal probed at CLK4x is still 48MHz, however with a duty cycle of 50%. I probed the DLL's LOCKED pin- it seems to be high. Hal, you wrote: >>> Also note that the XOR doubler trick doesn't work if the design needs the DLL to phase lock to the input clock as well as generate faster clocks <<< I do not care about the phase of my 96MHz clock, so as far as I understood things, everything should be fine. Is there something obvious that I missed? Thanks again for your suggestions, best regards Felix Bertram ---------------------------------------- library IEEE; use IEEE.std_logic_1164.all; entity Clk4x is port( CLKIN : in STD_LOGIC; -- driven by 24MHz quartz CLK1x : out STD_LOGIC; -- BUFged CLKIN CLK2x : out STD_LOGIC; -- 48MHz (small duty cycle) CLK4x : out STD_LOGIC -- should be 96MHz... ); end Clk4x; architecture BHV of Clk4x is ---- Component declarations ----- component bufg port ( I : in std_ulogic; O : out std_ulogic ); end component; component clkdll port ( CLKFB : in std_ulogic := '0'; CLKIN : in std_ulogic := '0'; RST : in std_ulogic := '0'; CLK0 : out std_ulogic := '0'; CLK180 : out std_ulogic := '0'; CLK270 : out std_ulogic := '0'; CLK2X : out std_ulogic := '0'; CLK90 : out std_ulogic := '0'; CLKDV : out std_ulogic := '0'; LOCKED : out std_ulogic := '0' ); end component; component fd port ( C : in std_ulogic; D : in std_ulogic; Q : out std_ulogic ); end component; component inv port ( I : in std_ulogic; O : out std_ulogic ); end component; component xor2 port ( I0 : in std_ulogic; I1 : in std_ulogic; O : out std_ulogic ); end component; ---- User defined diagram declarations ----- attribute dont_touch: STRING; ---- Constants ----- constant GND_CONSTANT : STD_LOGIC := '0'; ---- Signal declarations used on the diagram ---- signal CLK1I : STD_LOGIC; -- 1x clock signal CLK2I : STD_LOGIC; -- 2x clock signal CLK4I : STD_LOGIC; -- 4x clock signal DLLOUT : STD_LOGIC; -- 2x DLL output signal Q : STD_LOGIC; -- FF Q output signal QINV : STD_LOGIC; -- ... inverted ---- Ground signals declarations ----- signal GND : STD_LOGIC; ---- Instance attributes ---- attribute dont_touch of U2 : label is "true"; attribute dont_touch of U3 : label is "true"; attribute dont_touch of U4 : label is "true"; begin ---- Component instantiations ---- U1 : bufg port map( I => dllout, O => clk4i ); U2 : xor2 port map( I0 => clk1i, I1 => qinv, O => clk2i ); U3 : inv port map( I => q, O => qinv ); U4 : fd port map( C => clk2i, D => qinv, Q => q ); U7 : bufg port map( I => CLKIN, O => clk1i ); U8 : clkdll port map( CLK2X => dllout, CLKFB => clk4i, CLKIN => clk2i, RST => GND ); ---- Power , ground assignment ---- GND <= GND_CONSTANT; ---- Terminal assignment ---- CLK1x <= clk1i; CLK2x <= clk2i; CLK4x <= clk4i; end BHV; ---------------------------------------- Sent via Deja.com http://www.deja.com/ ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Fri, 05 Jan 2001 10:37:27 -0800 Organization: Xilinx Lines: 79 Message-ID: <3A561466.534B42DB@xilinx.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> NNTP-Posting-Host: 149.199.7.181 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!ptdnetP!newsgate.ptd.net!attmtf.ip.att.net!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3606 Hal, Yes. I just can't say "go ahead" for all of the reasons I stated. Someday, some lot might be just a little too fast (even though it is pretty unlikely). Austin Hal Murray wrote: > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] > > > Now, I am assuming you are not going below 0C, so there will be some > > margin there. But if not, then definitely don't do it. > > In general, CMOS prop time is linear in temp and supply voltage. He's > only off by 4% so we should be able to draw the forbidden zone on a graph > with voltage on one axis and temp on the other. > > Does that sort of reasoning work with DLLs? > > > Doubling with a delay and an XOR is a common technique, and if you can > > take the delay element and place it off chip, you will not have to worry > > about it getting too fast due to the process/voltage/temperature > > variations in the FPGA. I used to use a small RC off chip that added to > > the delay and made this reliable (used in 100K+ units of a fiber optic > > transmission system). I lived through three process changes of Xilinx > > fpga's with this method, even though it is an asynchronous "no-no". > > I seem to remember an old APP note describing using an XOR for a clock > doubler and promising that the circuit would work. > > I think the trick was to use the clock on a FF that was inside the > clock generation path so the delay was sure to be long enough to clock > a FF on that chip and at that temp/voltage. > > Try this. The clock is the XOR of the input to a FF and it's output > and that clock clocks the FF. Then the pulse width will be whatever > the FF needs to get clocked plus some prop time for roundup. I can't > see any way that wouldn't work. Well, it might not run fast enough, > but that seems unlikely if the reason we are using this hack is > because the clock it too slow for the DLL. But we can check the > min time (worst case) and compare that to the spec sheet. > > I'd call a hack/kludge like this a non-prefered solution rather than a > no-no. The goal is to make designs that work solidly. Mostly, that > means meeting timings and that's obviously easier to check with clean > digital logic - we have tools that do most of the work for us. > > But there are things like metastability so you do have to think about > other issues. As long as there aren't many of them and they are around > the edges we can probably get the whole design right. > > I'll try reasonably hard to avoid things like the XOR doubler, but when > I run out of alternatives AND I think I can convince myself that it will > work reliabily then I'll use them. That convincing frequently involves > taking advantage of temp/voltage tracking to "prove" that the worst > case can't happen when it will hurt you. The reason to avoid them > is not that they don't work, but that it takes time to make sure they > will work. > > I can think of two risks when using a non-prefered technique. > > The first is that I'll overlook something significant. > > The second is that there is a flaw in my reasoning or my arithmetic. > This is the time when it's great to have smart friends who are willing > to look over your design and double check your reasoning. > > I'd probably be more worried about bypassing on the power planes > than something like an XOR clock doubler. > > Also note that the XOR doubler trick doesn't work if the design > needs the DLL to phase lock to the input clock as well as generate > faster clocks. > -- > These are my opinions, not necessarily my employers. I hate spam. ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Fri, 05 Jan 2001 10:40:41 -0800 Organization: Xilinx Lines: 192 Message-ID: <3A561529.E65C3953@xilinx.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> <934pnu$l0k$1@nnrp1.deja.com> NNTP-Posting-Host: 149.199.7.181 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!xfer10.netnews.com!netnews.com!howland.erols.net!usc.edu!attmtf.ip.att.net!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3605 Felix, Try having your design RESET the DLL after the input is stable and running. If the DLL locked before the input was stable, it might have locked to the un-doubled input, Austin felix_bertram@my-deja.com wrote: > Hello everybody, > > first of all I'd like to thank you for your valuable input, > special thanks to Austin and Hal. > > I succeeded creating a 48MHz clock from the 24Mhz, using > an XOR and a FF. I can see the clock with my scope, > it is running at 48Mhz and is approx 4ns high (and 16ns low), > with my XC2S50-TQ144-5C. The signal I probed was CLK2x from > the code below. > > I did not succeed creating a 96MHz clock from the 48MHz > using a DLL. The signal probed at CLK4x is still 48MHz, > however with a duty cycle of 50%. > > I probed the DLL's LOCKED pin- it seems to be high. > > Hal, you wrote: > >>> > Also note that the XOR doubler trick doesn't work if the > design needs the DLL to phase lock to the input clock > as well as generate faster clocks > <<< > > I do not care about the phase of my 96MHz clock, so as > far as I understood things, everything should be fine. > Is there something obvious that I missed? > > Thanks again for your suggestions, > best regards > > Felix Bertram > > ---------------------------------------- > library IEEE; > use IEEE.std_logic_1164.all; > > entity Clk4x is > port( > CLKIN : in STD_LOGIC; -- driven by 24MHz quartz > CLK1x : out STD_LOGIC; -- BUFged CLKIN > CLK2x : out STD_LOGIC; -- 48MHz (small duty cycle) > CLK4x : out STD_LOGIC -- should be 96MHz... > ); > end Clk4x; > > architecture BHV of Clk4x is > > ---- Component declarations ----- > > component bufg > port ( > I : in std_ulogic; > O : out std_ulogic > ); > end component; > > component clkdll > port ( > CLKFB : in std_ulogic := '0'; > CLKIN : in std_ulogic := '0'; > RST : in std_ulogic := '0'; > CLK0 : out std_ulogic := '0'; > CLK180 : out std_ulogic := '0'; > CLK270 : out std_ulogic := '0'; > CLK2X : out std_ulogic := '0'; > CLK90 : out std_ulogic := '0'; > CLKDV : out std_ulogic := '0'; > LOCKED : out std_ulogic := '0' > ); > end component; > > component fd > port ( > C : in std_ulogic; > D : in std_ulogic; > Q : out std_ulogic > ); > end component; > > component inv > port ( > I : in std_ulogic; > O : out std_ulogic > ); > end component; > > component xor2 > port ( > I0 : in std_ulogic; > I1 : in std_ulogic; > O : out std_ulogic > ); > end component; > > ---- User defined diagram declarations ----- > > attribute dont_touch: STRING; > > ---- Constants ----- > constant GND_CONSTANT : STD_LOGIC := '0'; > > ---- Signal declarations used on the diagram ---- > > signal CLK1I : STD_LOGIC; -- 1x clock > signal CLK2I : STD_LOGIC; -- 2x clock > signal CLK4I : STD_LOGIC; -- 4x clock > signal DLLOUT : STD_LOGIC; -- 2x DLL output > signal Q : STD_LOGIC; -- FF Q output > signal QINV : STD_LOGIC; -- ... inverted > > ---- Ground signals declarations ----- > signal GND : STD_LOGIC; > > ---- Instance attributes ---- > > attribute dont_touch of U2 : label is "true"; > attribute dont_touch of U3 : label is "true"; > attribute dont_touch of U4 : label is "true"; > > begin > > ---- Component instantiations ---- > > U1 : bufg > port map( > I => dllout, > O => clk4i > ); > > U2 : xor2 > port map( > I0 => clk1i, > I1 => qinv, > O => clk2i > ); > > U3 : inv > port map( > I => q, > O => qinv > ); > > U4 : fd > port map( > C => clk2i, > D => qinv, > Q => q > ); > > U7 : bufg > port map( > I => CLKIN, > O => clk1i > ); > > U8 : clkdll > port map( > CLK2X => dllout, > CLKFB => clk4i, > CLKIN => clk2i, > RST => GND > ); > > ---- Power , ground assignment ---- > > GND <= GND_CONSTANT; > > ---- Terminal assignment ---- > > CLK1x <= clk1i; > CLK2x <= clk2i; > CLK4x <= clk4i; > > end BHV; > ---------------------------------------- > > Sent via Deja.com > http://www.deja.com/ ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: 6 Jan 2001 00:05:57 GMT Organization: Compaq Systems Research Center Lines: 11 Distribution: world Message-ID: <935nh5$qae@src-news.pa.dec.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> <934pnu$l0k$1@nnrp1.deja.com> <3A561529.E65C3953@xilinx.com> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!mailint03.im.hou.compaq.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:3648 > Try having your design RESET the DLL after the input is stable and > running. > > If the DLL locked before the input was stable, it might have locked to > the un-doubled input, That gatcha is covered in the Xilinx App Note on DLLs. -- These are my opinions, not necessarily my employers. I hate spam. ###### Message-ID: <3A59891A.C2D6D5C4@sqf.hp.com> Date: Mon, 08 Jan 2001 09:32:10 +0000 From: Nial Stewart Reply-To: nials@sqf.hp.com Organization: Agilent X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> <934pnu$l0k$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: hpqt0797.britain.agilent.com X-Original-Trace: 8 Jan 2001 09:32:11 GMT, hpqt0797.britain.agilent.com Lines: 40 NNTP-Posting-Host: claymore.sqf.hp.com X-Trace: 8 Jan 2001 02:32:30 -0700, claymore.sqf.hp.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-mue1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!ihnp4.ucsd.edu!sdd.hp.com!hp-corv.cv.hp.com!hpb10302.boi.hp.com!hpsqftk!hpqt0797.britain.agilent.com Xref: chonsp.franklin.ch comp.arch.fpga:3686 felix_bertram@my-deja.com wrote: > > Hello everybody, > > first of all I'd like to thank you for your valuable input, > special thanks to Austin and Hal. > > I succeeded creating a 48MHz clock from the 24Mhz, using > an XOR and a FF. I can see the clock with my scope, > it is running at 48Mhz and is approx 4ns high (and 16ns low), > with my XC2S50-TQ144-5C. The signal I probed was CLK2x from > the code below. > > I did not succeed creating a 96MHz clock from the 48MHz > using a DLL. The signal probed at CLK4x is still 48MHz, > however with a duty cycle of 50%. > > I probed the DLL's LOCKED pin- it seems to be high. > > Hal, you wrote: > >>> > Also note that the XOR doubler trick doesn't work if the > design needs the DLL to phase lock to the input clock > as well as generate faster clocks > <<< > > I do not care about the phase of my 96MHz clock, so as > far as I understood things, everything should be fine. > Is there something obvious that I missed? Felix, There's an app note about using 2 DLLs to implement a clock quadrupler (?). I think you've to let the first DLL lock before letting the second try to lock and so the second one should be held off for a while. This might be the root of your problem. Nial. ###### From: felix_bertram@my-deja.com Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Mon, 08 Jan 2001 15:39:29 GMT Organization: Deja.com Lines: 27 Message-ID: <93cmvg$mai$1@nnrp1.deja.com> References: <9325os$dq9$1@nnrp1.deja.com> NNTP-Posting-Host: 212.86.34.67 X-Article-Creation-Date: Mon Jan 08 15:39:29 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) X-Http-Proxy: 1.1 x65.deja.com:80 (Squid/1.1.22) for client 212.86.34.67 X-MyDeja-Info: XMYDJUIDfelix_bertram Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!nntp2.deja.com!nnrp1.deja.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3699 Hello everybody, thanks again for all your helpful input. I finally succeeded in creating a 4x clock, so I am a lucky guy now. > DLL starts adjusting clock delay before configuration > process of the FPGA is completed - your first clock > doubler not running still. May be DLL will act correctly, > if RST is connected to input pin and DLL resetted after > configuration is completed? Indeed, the problem seems to be related to the DLL starting to work *before* the FPGA being completely configured (so before my first clock doubler is implemented). This seems a bit odd to me, and I ask myself especially the question: What clock is the DLL running from (and locking to) before the FPGA is configured? The clock that comes into the most closely located GCLK pin? Hmm, ... However, as I said before, I am a lucky guy now, best regards Felix Bertram Sent via Deja.com http://www.deja.com/ ###### Message-ID: <3A5A430B.2ACA685E@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage References: <9325os$dq9$1@nnrp1.deja.com> <93cmvg$mai$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 49 Date: Mon, 08 Jan 2001 22:42:41 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 978993761 24.13.238.93 (Mon, 08 Jan 2001 14:42:41 PST) NNTP-Posting-Date: Mon, 08 Jan 2001 14:42:41 PST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!209.249.123.233.MISMATCH!xfer10.netnews.com!netnews.com!howland.erols.net!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3690 Hey Xilinx (Austin?, Peter?) what's the real scoop on the DLL 2x outputs? Altera's got a thing on their website at http://www.altera.com/html/products/apex20KE.html indicating the jitter on the 2x output is an order of magnitude higher than the 35ps that has been bandied about before. If this is real, then how does this affect passing a signal between a 1x and 2x clock domain (from the same DLL)? I suspect it might not be able to be done reliably despite previous assurances from Xilinx. How about effects on the maximum clock rates as reported by trce, I imagine a 400 ps jitter is going to eat into that unless you have already factored that jitter into the worst case timing. Perhaps it is just an artifact of their test set-up, but I suspect the numbers may really be worse than what Xilinx portrays (And I suspect that might be the root of a problem I have been having with a design that used both 1x and 2x clocks) felix_bertram@my-deja.com wrote: > > Hello everybody, > > thanks again for all your helpful input. I finally succeeded in > creating a 4x clock, so I am a lucky guy now. > > > DLL starts adjusting clock delay before configuration > > process of the FPGA is completed - your first clock > > doubler not running still. May be DLL will act correctly, > > if RST is connected to input pin and DLL resetted after > > configuration is completed? > > Indeed, the problem seems to be related to the DLL starting to work > *before* the FPGA being completely configured (so before my first clock > doubler is implemented). This seems a bit odd to me, and I ask myself > especially the question: What clock is the DLL running from (and > locking to) before the FPGA is configured? The clock that comes into > the most closely located GCLK pin? Hmm, ... > > However, as I said before, I am a lucky guy now, > best regards > > Felix Bertram > > Sent via Deja.com > http://www.deja.com/ -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Mon, 08 Jan 2001 17:44:34 -0800 Organization: Xilinx Lines: 234 Message-ID: <3A5A6D02.F15AE307@xilinx.com> References: <9325os$dq9$1@nnrp1.deja.com> <93cmvg$mai$1@nnrp1.deja.com> <3A5A430B.2ACA685E@andraka.com> NNTP-Posting-Host: 149.199.7.181 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------380B40F2909F9E51030EDAF5" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!ptdnetP!newsgate.ptd.net!attmtf.ip.att.net!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3687 --------------380B40F2909F9E51030EDAF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ray, The straight scoop is that the 2X jitter output is 2X the clk0 jitter output. Within any one period to the next adjacent period, the jitter is still bounded by a tap change per the data sheet. It is just that in the 2X mode, you can get twice as many tap changes over a few tens of periods than in the CLK0/90/180/270 modes. Thanks to the other guy for bringing to our attention. As it turns out, they were not the first ones to bring this to our attention. We are preparing a little something with the jitter compared between the DLL and the other guys PLL, both with and without internal logic happening, and with and without IO's switching (and we used their board!) under the same conditions and with similar designs (as closely as we can make them). Let's just say that we are not going to publish it on the web site, as that would be trivializing a serious issue (control and management of jitter). But we will make it available through the FAE's so that we can share our systems experience and knowledge with our customers. The control and manangement of jitter will probably become an app note one day. Theoretically, a PLL should beat out the DLL by miles when it comes to jitter. It is all in the implementation, and the layout, and power supply decoupling, and the isolation, and the process lot parameters, and the filter parameters, and oops!..... (again, why state the obvious?). It is all well and good to connect up a digital sampler to a clock input, and push the "jitter" button, but you have to do a hell of a lot more than that. What kind of "jitter" are you measuring: period jitter, ITU-T jitter, stochastic stationary jitter, band pass filtered jitter...? Is your signal integrity perfect (bad rise times = bad jitter!)? What is your clock source jitter? Did you know that P-P jitter increases the longer you measure it? How many samples is good enough? Ever heard of "left and right hand curve fitting"? What is your jitter noise floor? How much jitter is added by going on, and getting off the chip (just IO's)? Does your jitter add arithmetically? What is the spectral content of the jitter? How long do you have to wait to get enough samples? Is the equipment capable of sampling every single event? Did you look at the resulting eye pattern? With psuedorandom data? .... I am not going to tell the whole world here all about jitter measurement methodology ( I spent 12 years at T1X1.3 and in the lab on the subject) ... I'll let the other guy learn the same way I did (and it wasn't all fun and games, although we had some really good lunches and dinners with folks from Lucent, Nortel, Alcatel, Bell Labs, Tellabs, MCI, Sprint, Motorola, .... in those 12 years). Anyone who wants a preview of the measurements may email me directly. As for cascading DLL's, the input tolerance is about 3X what is in the data sheet so the DLL's down the line are going to lock, and remain locked. We are having trouble measuring the actual tolerance as no one makes test equipment that generates that much HF jitter energy. If you have a specific problem with the DLL's, please email me directly, or open a hotline case (I can see them, too). Austin Ray Andraka wrote: > Hey Xilinx (Austin?, Peter?) what's the real scoop on the DLL 2x outputs? > Altera's got a thing on their website at > http://www.altera.com/html/products/apex20KE.html indicating the jitter on the > 2x output is an order of magnitude higher than the 35ps that has been bandied > about before. If this is real, then how does this affect passing a signal > between a 1x and 2x clock domain (from the same DLL)? I suspect it might not be > able to be done reliably despite previous assurances from Xilinx. How about > effects on the maximum clock rates as reported by trce, I imagine a 400 ps > jitter is going to eat into that unless you have already factored that jitter > into the worst case timing. Perhaps it is just an artifact of their test > set-up, but I suspect the numbers may really be worse than what Xilinx portrays > (And I suspect that might be the root of a problem I have been having with a > design that used both 1x and 2x clocks) > > felix_bertram@my-deja.com wrote: > > > > Hello everybody, > > > > thanks again for all your helpful input. I finally succeeded in > > creating a 4x clock, so I am a lucky guy now. > > > > > DLL starts adjusting clock delay before configuration > > > process of the FPGA is completed - your first clock > > > doubler not running still. May be DLL will act correctly, > > > if RST is connected to input pin and DLL resetted after > > > configuration is completed? > > > > Indeed, the problem seems to be related to the DLL starting to work > > *before* the FPGA being completely configured (so before my first clock > > doubler is implemented). This seems a bit odd to me, and I ask myself > > especially the question: What clock is the DLL running from (and > > locking to) before the FPGA is configured? The clock that comes into > > the most closely located GCLK pin? Hmm, ... > > > > However, as I said before, I am a lucky guy now, > > best regards > > > > Felix Bertram > > > > Sent via Deja.com > > http://www.deja.com/ > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.com --------------380B40F2909F9E51030EDAF5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ray,

The straight scoop is that the 2X jitter output is 2X the clk0 jitter output.

Within any one period to the next adjacent period, the jitter is still bounded by a tap change per the data sheet.  It is just that in the 2X mode, you can get twice as many tap changes over a few tens of periods than in the CLK0/90/180/270 modes.  Thanks to the other guy for bringing to our attention.  As it turns out, they were not the first ones to bring this to our attention.

We are preparing a little something with the jitter compared between the DLL and the other guys PLL, both with and without internal logic happening, and with and without IO's switching (and we used their board!) under the same conditions and with similar designs (as closely as we can make them).

Let's just say that we are not going to publish it on the web site, as that would be trivializing a serious issue (control and management of jitter).  But we will make it available through the FAE's so that we can share our systems experience and knowledge with our customers.  The control and manangement of jitter will probably become an app note one day.

Theoretically, a PLL should beat out the DLL by miles when it comes to jitter.  It is all in the implementation, and the layout, and power supply decoupling, and the isolation, and the process lot parameters, and the filter parameters, and oops!..... (again, why state the obvious?).

It is all well and good to connect up a digital sampler to a clock input, and push the "jitter" button, but you have to do a hell of a lot more than that.  What kind of "jitter" are you measuring:  period jitter, ITU-T jitter, stochastic stationary jitter, band pass filtered jitter...?    Is your signal integrity perfect (bad rise times = bad jitter!)?  What is your clock source jitter?  Did you know that P-P jitter increases the longer you measure it?  How many samples is good enough?  Ever heard of "left and right hand curve fitting"?  What is your jitter noise floor?  How much jitter is added by going on, and getting off the chip (just IO's)?  Does your jitter add arithmetically?  What is the spectral content of the jitter?  How long do you have to wait to get enough samples?  Is the equipment capable of sampling every single event?  Did you look at the resulting eye pattern?  With psuedorandom data? ....

I am not going to tell the whole world here all about jitter measurement methodology ( I spent 12 years at T1X1.3 and in the lab on the subject) ... I'll let the other guy learn the same way I did (and it wasn't all fun and games, although we had some really good lunches and dinners with folks from Lucent, Nortel, Alcatel, Bell Labs, Tellabs, MCI, Sprint, Motorola, .... in those 12 years).

Anyone who wants a preview of the measurements may email me directly.

As for cascading DLL's, the input tolerance is about 3X what is in the data sheet so the DLL's down the line are going to lock, and remain locked.   We are having trouble measuring the actual tolerance as no one makes test equipment that generates that much HF jitter energy.

If you have a specific problem with the DLL's, please email me directly, or open a hotline case (I can see them, too).

Austin

Ray Andraka wrote:

Hey Xilinx (Austin?, Peter?) what's the real scoop on the DLL 2x outputs?
Altera's got a thing on their website at
http://www.altera.com/html/products/apex20KE.html indicating the jitter on the
2x output is an order of magnitude higher than the 35ps that has been bandied
about before. If this is real, then how does this affect passing a signal
between a 1x and 2x clock domain (from the same DLL)?  I suspect it might not be
able to be done reliably despite previous assurances from Xilinx.  How about
effects on the maximum clock rates as reported by trce, I imagine a 400 ps
jitter is going to eat into that unless you have already factored that jitter
into the worst case timing.  Perhaps it is just an artifact of their test
set-up, but I suspect the numbers may really be worse than what Xilinx portrays
(And I suspect that might be the root of a problem I have been having with a
design that used both 1x and 2x clocks)

felix_bertram@my-deja.com wrote:
>
> Hello everybody,
>
> thanks again for all your helpful input. I finally succeeded in
> creating a 4x clock, so I am a lucky guy now.
>
> > DLL starts adjusting clock delay before configuration
> > process of the FPGA is completed - your first clock
> > doubler not running still. May be DLL will act correctly,
> > if RST is connected to input pin and DLL resetted after
> > configuration is completed?
>
> Indeed, the problem seems to be related to the DLL starting to work
> *before* the FPGA being completely configured (so before my first clock
> doubler is implemented). This seems a bit odd to me, and I ask myself
> especially the question: What clock is the DLL running from (and
> locking to) before the FPGA is configured? The clock that comes into
> the most closely located GCLK pin? Hmm, ...
>
> However, as I said before, I am a lucky guy now,
> best regards
>
> Felix Bertram
>
> Sent via Deja.com
> http://www.deja.com/

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com

--------------380B40F2909F9E51030EDAF5-- ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: 12 Jan 2001 02:29:57 GMT Organization: Compaq Systems Research Center Lines: 64 Distribution: world Message-ID: <93lq75$439@src-news.pa.dec.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> <3A561466.534B42DB@xilinx.com> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!mailint03.im.hou.compaq.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:3774 [My initial msg.] > > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] > > > > > Now, I am assuming you are not going below 0C, so there will be some > > > margin there. But if not, then definitely don't do it. > > > > In general, CMOS prop time is linear in temp and supply voltage. He's > > only off by 4% so we should be able to draw the forbidden zone on a graph > > with voltage on one axis and temp on the other. > > > > Does that sort of reasoning work with DLLs? > > In article <3A561466.534B42DB@xilinx.com>, Austin Lesea writes: > Hal, > > Yes. > > I just can't say "go ahead" for all of the reasons I stated. Someday, some > lot might be just a little too fast (even though it is pretty unlikely). That's exactly the point I was trying to make. Why can't you say "go ahead"? Is there a flaw in my reasoning or is that due to legal issues? In most interesting projects, a designer has to use a lot of information that isn't in the data sheet. What's the "contract" between the vendor and the designer? How can I be sure that a design will work correctly if I use information from app notes or general common sense or rumors from usenet? Note that there are two types of extra information. One is things like how to get the tools to do what you want or explainations of what a particular line on the data sheet really means. The other type of information is extra - things you won't find in the data sheet at all. The obvious example is speed being linear with temperature and VCC. In this context, I guess that some of the tools are part of the contract, next to the data sheet. I'm thinking of the timing verifier or report generator and the power estimator. The particular case that I proposed is tricky because it depends upon minimum prop times and the general party line is things might go faster. But in this particular case, there is a requirement for that min in the spec sheet. The spec sheet says it will work down to 25 MHz. Most people know it's "legal" to reduce the prop times in a data sheet if you can keep a part cool and/or keep the VCC above min. My proposal uses the same approach, just with the reverse sign bit. If it will work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least 5% below max? -- These are my opinions, not necessarily my employers. I hate spam. ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: Fri, 12 Jan 2001 08:40:24 -0800 Organization: Xilinx Lines: 277 Message-ID: <3A5F3377.C9728B47@xilinx.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> <3A561466.534B42DB@xilinx.com> <93lq75$439@src-news.pa.dec.com> NNTP-Posting-Host: 149.199.7.181 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B8C7AD462CF21207EA77122C" X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!cyclone.swbell.net!bos-service1.ext.raytheon.com!attla1!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3792 --------------B8C7AD462CF21207EA77122C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hal, I will comment below. Austin Hal Murray wrote: > [My initial msg.] > > > > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] > > > > > > > Now, I am assuming you are not going below 0C, so there will be some > > > > margin there. But if not, then definitely don't do it. > > > > > > In general, CMOS prop time is linear in temp and supply voltage. He's > > > only off by 4% so we should be able to draw the forbidden zone on a graph > > > with voltage on one axis and temp on the other. > > > > > > Does that sort of reasoning work with DLLs? > > > > > In article <3A561466.534B42DB@xilinx.com>, > Austin Lesea writes: > > Hal, > > > > Yes. > > > > I just can't say "go ahead" for all of the reasons I stated. Someday, some > > lot might be just a little too fast (even though it is pretty unlikely). > > That's exactly the point I was trying to make. Why can't you say "go ahead"? > Is there a flaw in my reasoning or is that due to legal issues? There is an implicit contract here. We state in the specifications that the product will do X. If it doesn't do X, you get it replaced with one that does. > > > In most interesting projects, a designer has to use a lot of information > that isn't in the data sheet. What's the "contract" between the vendor > and the designer? How can I be sure that a design will work correctly > if I use information from app notes or general common sense or rumors > from usenet? Spec sheet = contract. App note = we will support it just like the spec sheet. A email from a Xilinx engineer is a written document, so it also must be treated as a statement of 'suitablity for use' ... ie we would have to supply chips that do what was said. Thus, my caution. Anything else, well, have fun. > > > Note that there are two types of extra information. One is things like > how to get the tools to do what you want or explainations of what a > particular line on the data sheet really means. > > The other type of information is extra - things you won't find in the > data sheet at all. The obvious example is speed being linear with > temperature and VCC. True. There are a lot of implicit assumptions engineers make everday. I did it for 20 years in telecom, and I still have to do it now. Sometimes the common knowledge isn't all that common, and it may not be true (e.g. maybe there is temperature compensation in the circuit, and it isn't getting faster as it gets colder, or there is a voltage regulator hidden on chip that we don't talk about). Usually a phone call, or an email will clear up little things like that. That is what this question was all about -- is there any reason why one shouldn't use it at 24 MHz? I went around, and unanimously everyone said "no problem," but then I asked OK, so then why don't we change the spec? No takers. 0, Nada. So, if the spec won't change, I can not recommend its use -- for all of thereasons stated. > > > In this context, I guess that some of the tools are part of the contract, > next to the data sheet. I'm thinking of the timing verifier or report > generator and the power estimator. Yes. > > > The particular case that I proposed is tricky because it depends upon > minimum prop times and the general party line is things might go faster. > > But in this particular case, there is a requirement for that min in the > spec sheet. The spec sheet says it will work down to 25 MHz. > > Most people know it's "legal" to reduce the prop times in a data sheet > if you can keep a part cool and/or keep the VCC above min. My proposal > uses the same approach, just with the reverse sign bit. If it will > work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least > 5% below max? OK. Now that is a good question. If you kept the Vccint below the recommended maximum limit by 5%, you have gained some margin. If you additionally never go below 10 C (an asian indoor telecom limit -- it never really gets cold in Taiwan or Hong Kong), they you have some more margin. But remember the comments about the possibility of a hidden voltage regulator, and temperature compensation? Maybe the margin gained isn't all that much. > > > -- > These are my opinions, not necessarily my employers. I hate spam. What I would do, if there was a clear reason to do this (save a ton of money, or make the board smaller, or ...) is to take apart, find the low frequency limit, and then change the voltage, and change the temperature, and see how it changes. I'll save you some of the work: the voltage is regulated for part of the circuit, so it won't get as fast as expected with voltage. There was also a lot of work on removing temperature sensitivity, but it is still there. The DLL will get faster as it gets colder, but not faster as fast as the core logic. Then, I would see what my margin is. If I have a 2X margin, then I would probably just go to it, and be done with it (standard engineering derating). If my margin was only 50%, then I probably still would go ahead, as it would take a lot of process changes, and perhaps even design changes to eat that up -- but I could never be sure. I might put in place an incoming inspection, and I might ask for a letter from my distributor to inform me of any change to the process on that part (a standard service for customers). I always got that letter in my telecom job, because in telecom, if anything changes, it scares the hell out of the phone companies. They have only been in business for 130+ years, so they know that change = bad in any design. Changes in components required an immediate re-qualification of the product, regardless of the change (unless it was the ink on the top, or some other silly change). When Matra changed the 80C31 (did a shrink for yield and cost), they shrank a transistor pullup that should have stayed big (strong). It caused an immense amount of **** because we had to add a 10K pullup resistor. You would think the world came to an end! The wailing, the nashing of teeth .... you get the picture. --------------B8C7AD462CF21207EA77122C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hal,

I will comment below.

Austin

Hal Murray wrote:

[My initial msg.]

> > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.]
> >
> > > Now,  I am assuming you are not going below 0C, so there will be some
> > > margin there.  But if not, then definitely don't do it.
> >
> > In general, CMOS prop time is linear in temp and supply voltage.  He's
> > only off by 4% so we should be able to draw the forbidden zone on a graph
> > with voltage on one axis and temp on the other.
> >
> > Does that sort of reasoning work with DLLs?
> >

In article <3A561466.534B42DB@xilinx.com>,
 Austin Lesea <austin.lesea@xilinx.com> writes:
> Hal,
>
> Yes.
>
> I just can't say "go ahead" for all of the reasons I stated.  Someday, some
> lot might be just a little too fast (even though it is pretty unlikely).

That's exactly the point I was trying to make.  Why can't you say "go ahead"?
Is there a flaw in my reasoning or is that due to legal issues?

There is an implicit contract here.  We state in the specifications that the product will do X.  If it doesn't do X, you get it replaced with one that does.
 

In most interesting projects, a designer has to use a lot of information
that isn't in the data sheet.  What's the "contract" between the vendor
and the designer?  How can I be sure that a design will work correctly
if I use information from app notes or general common sense or rumors
from usenet?

Spec sheet = contract.  App note = we will support it just like the spec sheet.  A email from a Xilinx engineer is a written document, so it also must be treated as a statement of 'suitablity for use' ... ie we would have to supply chips that do what was said.  Thus, my caution.  Anything else, well, have fun.
 

Note that there are two types of extra information.  One is things like
how to get the tools to do what you want or explainations of what a
particular line on the data sheet really means.

The other type of information is extra - things you won't find in the
data sheet at all.  The obvious example is speed being linear with
temperature and VCC.

True.  There are a lot of implicit assumptions engineers make everday.  I did it for 20 years in telecom, and I still have to do it now.  Sometimes the common knowledge isn't all that common, and it may not be true (e.g. maybe there is temperature compensation in the circuit, and it isn't getting faster as it gets colder, or there is a voltage regulator hidden on chip that we don't talk about).  Usually a phone call, or an email will clear up little things like that.  That is what this question was all about -- is there any reason why one shouldn't use it at 24 MHz?  I went around, and unanimously everyone said "no problem," but then I asked OK, so then why don't we change the spec?  No takers.  0, Nada.  So, if the spec won't change, I can not recommend its use -- for all of thereasons stated.
 

In this context, I guess that some of the tools are part of the contract,
next to the data sheet.  I'm thinking of the timing verifier or report
generator and the power estimator.

Yes.
 

The particular case that I proposed is tricky because it depends upon
minimum prop times and the general party line is things might go faster.

But in this particular case, there is a requirement for that min in the
spec sheet.  The spec sheet says it will work down to 25 MHz.

Most people know it's "legal" to reduce the prop times in a data sheet
if you can keep a part cool and/or keep the VCC above min.  My proposal
uses the same approach, just with the reverse sign bit.  If it will
work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least
5% below max?

OK.  Now that is a good question.  If you kept the Vccint below the recommended maximum limit by 5%, you have gained some margin.  If you additionally never go below 10 C (an asian indoor telecom limit -- it never really gets cold in Taiwan or Hong Kong), they you have some more margin.

But remember the comments about the possibility of a hidden voltage regulator, and temperature compensation?  Maybe the margin gained isn't all that much.

 

--
These are my opinions, not necessarily my employers.  I hate spam.


What I would do, if there was a clear reason to do this (save a ton of money, or make the board smaller, or ...) is to take apart, find the low frequency limit, and then change the voltage, and change the temperature, and see how it changes.  I'll save you some of the work:  the voltage is regulated for part of the circuit, so it won't get as fast as expected with voltage.  There was also a lot of work on removing temperature sensitivity, but it is still there.  The DLL will get faster as it gets colder, but not faster as fast as the core logic.

Then, I would see what my margin is.  If I have a 2X margin, then I would probably just go to it, and be done with it (standard engineering derating).  If my margin was only 50%, then I probably still would go ahead, as it would take a lot of process changes, and perhaps even design changes to eat that up -- but I could never be sure.  I might put in place an incoming inspection, and I might ask for a letter from my distributor to inform me of any change to the process on that part (a standard service for customers).

I always got that letter in my telecom job, because in telecom, if anything changes, it scares the hell out of the phone companies.  They have only been in business for 130+ years, so they know that change = bad in any design.  Changes in components required an immediate re-qualification of the product, regardless of the change (unless it was the ink on the top, or some other silly change).

When Matra changed the 80C31 (did a shrink for yield and cost), they shrank a transistor pullup that should have stayed big (strong).  It caused an immense amount of **** because we had to add a 10K pullup resistor.  You would think the world came to an end!  The wailing, the nashing of teeth .... you get the picture.
  --------------B8C7AD462CF21207EA77122C-- ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Spartan-II DLL Usage Date: 15 Jan 2001 07:18:12 GMT Organization: Compaq Systems Research Center Lines: 25 Distribution: world Message-ID: <93u87k$o9e@src-news.pa.dec.com> References: <9325os$dq9$1@nnrp1.deja.com> <3A54A84C.9FCFB016@xilinx.com> <9345de$ktr@src-news.pa.dec.com> <3A561466.534B42DB@xilinx.com> <93lq75$439@src-news.pa.dec.com> <3A5F3377.C9728B47@xilinx.com> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-koe1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!mailint03.im.hou.compaq.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:3856 In article <3A5F3377.C9728B47@xilinx.com>, Austin Lesea writes: > Spec sheet = contract. App note = we will support it just like the spec sheet. > A email from a Xilinx engineer is a written document, so it also must be treated > as a statement of 'suitablity for use' ... ie we would have to supply chips that > do what was said. Thus, my caution. Anything else, well, have fun. Many thanks. > But remember the comments about the possibility of a hidden voltage regulator, > and temperature compensation? Maybe the margin gained isn't all that much. That's the part that I was fishing for but wasn't smart enough to think of. Thanks again. [Why does the world keep getting more complicated?] -- These are my opinions, not necessarily my employers. I hate spam.