Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
<cs_posting@hotmail.com> wrote in message news:1172071323.893445.72120@q2g2000cwa.googlegroups.com... > On Feb 21, 10:19 am, cs_post...@hotmail.com wrote: > > > Then don't use the UART. Make your own synchronous serial > > connection. You seem to be treating the jtag loader as somehow magic > > - it isn't, it's still a synchronous serial connection with a download > > speed deteremined by it's clock rate. > > And start by looking here: > > http://www.xilinx.com/publications/xcellonline/xcell_53/xc_jtag53.htm > Interesting! Thanks for the link.Article: 115826
Tom, What you are missing in all of this is: support. If you asked the same question of the Xilinx hotline, a Xilinx SI expert would reply to your "what if" simulation, and give you the output impedance of the driver type you had chosen. If you were in a big company with premium support, you would get the answer quickly. If you were a student, or a very very small customer, a webcase may take a few days to get you the answer. If you posted the same question that you did but for Xilinx here on c.a.f., I would run the simulation myself, and post the results here (just to illustrate the tools I used, and the method for general education). AustinArticle: 115827
Tom, Further, just to show that I feel sorry for you in your plight, a SSTL driver for Stratix II was 23.7 ohms, and suggested using a 59 ohm series resistor to match 65 ohm t-line, and the same driver for V4 was 30.8 ohms, and suggested using a 45 ohm series resistor to match the 65 ohm line. I use Mentor's Hyperlynx (not free), and it takes seconds to get the answer. How much is your time worth? How much is a re-spin of the pcb worth? You pay for the tool if you save just one re-spin. Don't like Mentor? Cadence has a very nice tool set, and there are others, too. AustinArticle: 115828
The Xilinx Constraints Guide includes the applicable elements list for each constraint. Often - but not always - an attribute attached to a NET may propagate to the PAD or pad INST that's attached to it. If you wonder whether the PAD or NET is the right target for a specific constraint, look up that constraint in the Constraints Guide. I haven't worked much with XST but I've seen this in Synplify results often enough - when a clock pin is included in the pin list for the top module and the synthesizer recognizes it as a clock pin, a clock buffer is added by the synthesizer (rather than requiring the manual instantiation) to deliver the clock over the global clock routing network. Adding this buffer between the pad and registers means there are now two nets. Typically the net connecting the pad to the buffer will have the _c appended to the name to make the net unique but understandably related to the clock. - John_H "vu_5421" <nugentoffer@gmail.com> wrote in message news:1172078680.923299.66240@j27g2000cwj.googlegroups.com... > Hello all, > > What is the difference between a NET and a PAD with regards to > constraints management? > > Also, I noticed that I can constrain my FPGA_CLK but it looks like > there's another element called FPGA_CLK_c . Why does Xilinx ISE add > this extra element? What is it? > > Thanks. >Article: 115829
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > MikeJ wrote: > >>>There is a motorola booklet describing a stereo graphic equalizer >>>built with a 56001. That would probably have all the logic you >>>would need to do what you want. > >> Sounds interesting. I don't suppose you have a link? Google is currently >> failing me ... > > It is older than the web, so it might not be there. > (Well, older than when the web started to get popular.) > > I might be able to find mine and scan it. > > -- glen > Web was developed on a NeXT machine which had DSP56001 in it. Ancient..... Just for your information. Cheers! SatoruArticle: 115830
On Feb 21, 2:11 pm, "Pasacco" <pasa...@gmail.com> wrote: > Hi > > I need to convert > > type : array (0 to 3) of std_logic_vector (31 downto 0) > > to > > type : STD_LOGIC_VECTOR2 ( 3 downto 0 , 31 downto 0 ) > > As an example, I was using signal > > DATA_TEMP(3) <= x"80030001"; > > How should I modify the *DATA_TEMP* signal? > Create a function that takes as input an array of std_logic_vector() and outputs a two dimensional array of of std_logic_vector2. Kevin JenningsArticle: 115831
Hi, first of all, I know that asynchronous signals are bad, etc but that's what i have to work with. I am using Spartan 3E FPGA. I have an internal clock running at 125 MHz. I cannot use any DCM for conversion so i'm stuck with that. I get an external signal that alternates between high and low state at a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an error in external hardware that the signal is held low or high for more than 1/2 a cycle. I need to be able to detect this. I originally thought of detecting the first rising edge,(Major issues with setup time can occur here) then use a counter and approximate that 3 125 MHz cycle should fall into the low region of the 13.56 MHz period. If my counter reaches 3 or 4 and the signal is still hi, then there is an error. I would also need to check if the signal stays low for longer than necessary. It's not very precise thought so i am wondering if there is a better solution. Any idea???? Thanks a lot, AmishArticle: 115832
axr0284 wrote: > Hi, > first of all, I know that asynchronous signals are bad, etc but > that's what i have to work with. I am using Spartan 3E FPGA. I have an > internal clock running at 125 MHz. I cannot use any DCM for conversion > so i'm stuck with that. > > I get an external signal that alternates between high and low state at > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > error in external hardware that the signal is held low or high for > more than 1/2 a cycle. I need to be able to detect this. > > I originally thought of detecting the first rising edge,(Major issues > with setup time can occur here) then use a counter and approximate > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > period. If my counter reaches 3 or 4 and the signal is still hi, then > there is an error. I would also need to check if the signal stays low > for longer than necessary. > > It's not very precise thought so i am wondering if there is a better > solution. Any idea???? Thanks a lot, > Amish Key question is how much more than 1/2 a cycle is an error ? How soon do you need to flag that as an error ? Is jitter OK on that error signal ? You need to set a trip threshold, and the longer that it, % wise, the easier it gets :) It's basically an XOR edge detector triggering a monostable. -jgArticle: 115833
Hi Tom, Have a look at the contents of the ibis file with a text editor. Some sections of the file will show I vs V figures for the IO. So using V/I = R you can get an approximation for the output impedance of any drivers. >>I would think that if I had an ibis simulator, then I could use the ibis >>models provided by manufacturers and then create ibis models of my own to >>simulate the transmission lines in my design. >>1) Is that last assumption correct? In my experience, not quite. For example, in hyperlynx you can use their GUI to enter parameters/geometry etc from your transmission line, and import the ibis model for the drivers/receivers. One doesn't "create" IBIS models for the transmission lines as such.Article: 115834
The straightforward implementation (counting 125 MHz during every half- period of 13.5 MHz) has a phasing error of one 125 MHz period = 8 ns. If that is too big an error, you can frequency-double the 125 MHz (asuming it has a 50% duty cycle) quite easily, see my "Six easy pieces" in Xilinx TechXclusives. That reduces the phasing error to 4 ns. Then you must declare an error when the count reaches 11. Peter Alfke On Feb 21, 2:39 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > axr0284 wrote: > > Hi, > > first of all, I know that asynchronous signals are bad, etc but > > that's what i have to work with. I am using Spartan 3E FPGA. I have an > > internal clock running at 125 MHz. I cannot use any DCM for conversion > > so i'm stuck with that. > > > I get an external signal that alternates between high and low state at > > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > > error in external hardware that the signal is held low or high for > > more than 1/2 a cycle. I need to be able to detect this. > > > I originally thought of detecting the first rising edge,(Major issues > > with setup time can occur here) then use a counter and approximate > > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > > period. If my counter reaches 3 or 4 and the signal is still hi, then > > there is an error. I would also need to check if the signal stays low > > for longer than necessary. > > > It's not very precise thought so i am wondering if there is a better > > solution. Any idea???? Thanks a lot, > > Amish > > Key question is how much more than 1/2 a cycle is an error ? > How soon do you need to flag that as an error ? > Is jitter OK on that error signal ? > > You need to set a trip threshold, and the longer that it, % wise, > the easier it gets :) > > It's basically an XOR edge detector triggering a monostable. > > -jgArticle: 115835
On Feb 21, 12:56 am, "Pete Fraser" <pfra...@covad.net> wrote: > I am a consultant, and have had good luck with Avnet and with > the local rep organization. There's never been too much of a problem > getting prototypes and pilot-production Xilinx parts for any of my > clients. > > Have you tried getting in touch with the local rep organization? > A good relationship with them could work wonders. Good for you. I live in Indonesia, and struggling to death for getting XC3S100E from AvNet and NuHorizon Singapore (I mean buying it, not getting free samples of it). I don't know what they're thinking about. But I think small customer who ordered 10-pieces of XC3S100E for electronic billboard is not worth enough to serve. That's where Digikey saved my day =) I just wish there are more distributors that specialized in small order quantity. FPGAs and CPLDs obviously not an easy part to search in SE Asia region. -kunilArticle: 115836
axr0284 wrote: > Hi, > first of all, I know that asynchronous signals are bad, etc but > that's what i have to work with. I am using Spartan 3E FPGA. I have an > internal clock running at 125 MHz. I cannot use any DCM for conversion > so i'm stuck with that. > > I get an external signal that alternates between high and low state at > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > error in external hardware that the signal is held low or high for > more than 1/2 a cycle. I need to be able to detect this. > > I originally thought of detecting the first rising edge,(Major issues > with setup time can occur here) then use a counter and approximate > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > period. If my counter reaches 3 or 4 and the signal is still hi, then > there is an error. I would also need to check if the signal stays low > for longer than necessary. > > It's not very precise thought so i am wondering if there is a better > solution. Any idea???? Thanks a lot, > Amish 1) How precise do you want to be and 2) is this a unique test or do you want the measurement in production? I've been playing down at this level in the Spartan 3E for a while. It can be done to extreme precision but how much pain and resource do you want to throw that direction?Article: 115837
John_H wrote: <snip> >> It's not very precise thought so i am wondering if there is a better >> solution. Any idea???? Thanks a lot, >> Amish > > > 1) How precise do you want to be and 2) is this a unique test or do you > want the measurement in production? > > I've been playing down at this level in the Spartan 3E for a while. It > can be done to extreme precision but how much pain and resource do you > want to throw that direction? What does 'extreme precision' and 'pain and resource' equate to, on the 3E ? -jgArticle: 115838
John_H wrote: > axr0284 wrote: >> Hi, >> first of all, I know that asynchronous signals are bad, etc but >> that's what i have to work with. I am using Spartan 3E FPGA. I have an >> internal clock running at 125 MHz. I cannot use any DCM for conversion >> so i'm stuck with that. >> >> I get an external signal that alternates between high and low state at >> a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an >> error in external hardware that the signal is held low or high for >> more than 1/2 a cycle. I need to be able to detect this. >> >> I originally thought of detecting the first rising edge,(Major issues >> with setup time can occur here) then use a counter and approximate >> that 3 125 MHz cycle should fall into the low region of the 13.56 MHz >> period. If my counter reaches 3 or 4 and the signal is still hi, then >> there is an error. I would also need to check if the signal stays low >> for longer than necessary. >> >> It's not very precise thought so i am wondering if there is a better >> solution. Any idea???? Thanks a lot, >> Amish > > 1) How precise do you want to be and 2) is this a unique test or do you > want the measurement in production? > > I've been playing down at this level in the Spartan 3E for a while. It > can be done to extreme precision but how much pain and resource do you > want to throw that direction? First stab: Most people can just skip the post when their eyes start to glaze over; I'm going into detail to show what *can* be done, not necessarily to suggest this is a great way to go. The fastest routed LUT delay in the S3E is on the order of 270 ps (from -MIN timing). If an 8-LUT ring oscillator were used, the oscillator period would be a maximum of about 230 MHz or just over 16 ring oscillator periods in your 13.56 MHz period. For each half cycle, use a ring oscillator and a 5-bit combinatorial Gray code counter to count the ring oscillator half periods. If the ring oscillator is only enabled when the half cycle you're measuring begins, the ring oscillator starts oscillating and the Gray counter starts counting when you enter the appropriate half cycle. When the end of the half cycle hits, latch the count values into their embedded registers and latch a 1 in a self-reset register. Use the self-reset register to reset the ring oscillator and clear the Gray counter. When all is zero, asynchronously clear the self-reset register. The ring oscillator is disabled and held in reset until the next half period begins. End result - you can decode a binary count value from the bits you've latched independently for the two half cycles. The two values should be approximately the same and the sum of the two counts is the total ring oscillator LUT delays in a 13.56 MHz period. If the 13.56 MHz period *is* constant, the 100% point total should be roughly consistent between adjacent cycles though it may vary by many percent across temperature, voltage, and other internal influences. You can compare the two half counts to a percentage of the total to see if you're in the acceptance window or not. The 8-LUT ring oscillator can be constructed in one CLB with around 20 ps routing between LUTs (as reported by the Timing Analyzer or FPGA Editor) with judicious selection of which LUT goes where (using LOC or RLOC/RLOC_ORIGIN constraints) to access the shortest, most consistent timing. SLICE_L and SLICE_M delays vary slightly but don't impact a measurement on the order of what you're trying to achieve. The ring oscillator and the combinatorial Gray counter should be developed with great care. The conversion from the 8-bit Johnson counter (the ring oscillator) and the 5-bit half-period Gray counter is more than 2 minutes of work especially with the extra bit in the Gray counter used to reduce confusion between conflicting Johnson counts and Gray counts when they both transition about the same time when sampled. The self-reset is used to guarantee hold times between the sampling 13.56 MHz clock and the clear. What a mess, right? But, ... Your resolution could be just over 1% in the slowest device (a count of 93 for the total period). You use no DCMs. You don't even need the 125 MHz clock. You have lots of fun straining your Gray matter. - John_HArticle: 115839
Jim Granville wrote: > John_H wrote: > <snip> >>> It's not very precise thought so i am wondering if there is a better >>> solution. Any idea???? Thanks a lot, >>> Amish >> >> >> 1) How precise do you want to be and 2) is this a unique test or do >> you want the measurement in production? >> >> I've been playing down at this level in the Spartan 3E for a while. >> It can be done to extreme precision but how much pain and resource do >> you want to throw that direction? > > What does 'extreme precision' and 'pain and resource' equate to, on the > 3E ? > > -jg Precision: better than 800 ps. Another technique could be used to approximately halve that value if needed. Pain and resource: check the other post.Article: 115840
axr0284 wrote: > Hi, > first of all, I know that asynchronous signals are bad, etc but > that's what i have to work with. I am using Spartan 3E FPGA. I have an > internal clock running at 125 MHz. I cannot use any DCM for conversion > so i'm stuck with that. > > I get an external signal that alternates between high and low state at > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > error in external hardware that the signal is held low or high for > more than 1/2 a cycle. I need to be able to detect this. > > I originally thought of detecting the first rising edge,(Major issues > with setup time can occur here) then use a counter and approximate > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > period. If my counter reaches 3 or 4 and the signal is still hi, then > there is an error. I would also need to check if the signal stays low > for longer than necessary. > > It's not very precise thought so i am wondering if there is a better > solution. Any idea???? Thanks a lot, > Amish > It may take less logic to shift it in, and look for three or four consecutive ones or zeros. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 115841
I need to design an FPGA for a chip bringup system with the following clocking requirements: There is a 2.75 MHz input clock from the DUT. One part of the FPGA-DUT interface is running on this clock. We need to generate a 11 MHz ( 4x) clock using the 2.75 MHz input. One part of the FPGA-DUT interface is running on this 4x clock. Given the slow speeds involved, I dont need a phase-lock. There is large timing margin. But I need the FX functionality in the DCM to generate the higher frequency clock. I am planning to get a 16x ( 44 MHz ) clock generated at the FX output of the DCM and then divide using a simple counter to get the 4x clock. How to I connect the feedback clock input of the DCM? For other designs where the input clock frequency is high enough for DLL locking, we take the CLK0 through a BUFG and connect it back to CLKFB. The same signal also goes to the flops in the design. Thanks. -DipuArticle: 115842
What speed grade part do you have? Only the fastest part is spec'd to operate its M4K (true dual port mode) at 200MHz. Other key contributors to this high memory speed are: 1. both ports driven from the same clock (which is what you are doing). 2. memory clocks driven by the internal PLL onto the global clock network. "Jules" <jules@dsf.org.uk> wrote in message news:1172059976.345496.76990@s48g2000cws.googlegroups.com... > Just wondered if anyone could point me to documentation on the timing > constraints for the "altsyncram" standard module on Cyclone II. I > have chapter 8 of the device handbook, which has a basic diagram, but > when I try to duplicate the timing of this diagram, I don't seem to be > able to get clock speeds above about 100MHz to work correctly > (according to Quartus II's simulation). I understood this module was > supposed to function at 200MHz, so I guess I must be doing something > wrong, but what it is I'm at a loss to explain. I've tried shifting > my clock signal's phase in relation to the control signals, but > haven't found anything that helps. In case it's relevant, I'm using > it in true dual-port mode, with a single clock for both ports. >Article: 115843
dipu, Connect nothing to the CLKFB pin. Use of the CLKFB pin invokes the DLL function (which you do not need, or can use at these low CLKIN frequency). Just run the CLKFX output to a BUFG, and go from there. AustinArticle: 115844
John_H wrote: <snip> > > First stab: > > Most people can just skip the post when their eyes start to glaze over; > I'm going into detail to show what *can* be done, not necessarily to > suggest this is a great way to go. > > > The fastest routed LUT delay in the S3E is on the order of 270 ps (from > -MIN timing). > > If an 8-LUT ring oscillator were used, the oscillator period would be a > maximum of about 230 MHz or just over 16 ring oscillator periods in your > 13.56 MHz period. > > For each half cycle, use a ring oscillator and a 5-bit combinatorial > Gray code counter to count the ring oscillator half periods. If the > ring oscillator is only enabled when the half cycle you're measuring > begins, the ring oscillator starts oscillating and the Gray counter > starts counting when you enter the appropriate half cycle. When the end > of the half cycle hits, latch the count values into their embedded > registers and latch a 1 in a self-reset register. Use the self-reset > register to reset the ring oscillator and clear the Gray counter. When > all is zero, asynchronously clear the self-reset register. The ring > oscillator is disabled and held in reset until the next half period begins. Interesting. and perhaps allow a 6th bit, or more, just to cover faster than expected ring osc cases. You could also make the Gray Counter saturating, so there is no confusion of '>' - otherwise a multiple of Gray cycles might get a 'pass mark'. > > End result - you can decode a binary count value from the bits you've > latched independently for the two half cycles. The two values should be > approximately the same and the sum of the two counts is the total ring > oscillator LUT delays in a 13.56 MHz period. If the 13.56 MHz period > *is* constant, the 100% point total should be roughly consistent between > adjacent cycles though it may vary by many percent across temperature, > voltage, and other internal influences. You can compare the two half > counts to a percentage of the total to see if you're in the acceptance > window or not. > > The 8-LUT ring oscillator can be constructed in one CLB with around 20 > ps routing between LUTs (as reported by the Timing Analyzer or FPGA > Editor) with judicious selection of which LUT goes where (using LOC or > RLOC/RLOC_ORIGIN constraints) to access the shortest, most consistent > timing. SLICE_L and SLICE_M delays vary slightly but don't impact a > measurement on the order of what you're trying to achieve. > > The ring oscillator and the combinatorial Gray counter should be > developed with great care. The conversion from the 8-bit Johnson > counter (the ring oscillator) and the 5-bit half-period Gray counter is > more than 2 minutes of work especially with the extra bit in the Gray > counter used to reduce confusion between conflicting Johnson counts and > Gray counts when they both transition about the same time when sampled. I think here you have jumped to sampling BOTH, in order to hike the precision from the ~4ns to the ~270ps, right ? I've often thought of doing exactly this, but wondered just how you'd 'align' the Johnson edges, with the Gray, to keep things a) monotonic and b) hopefully nominally equal in LSB step size. > The self-reset is used to guarantee hold times between the sampling > 13.56 MHz clock and the clear. > > What a mess, right? But, ... > Your resolution could be just over 1% in the slowest device (a count of > 93 for the total period). > You use no DCMs. > You don't even need the 125 MHz clock. No, but as some stage an absolute time reference might be a good idea ? I've also thought of building two of these types of circuit, and having one in a CAL phase whilst the other samples the IP, and then swap on the next cycle, (and so on). Thus you store the 93 (or 87, or 104) or whatever your CAL says is the present time-value. Have you ever tried that ? Logic has > doubled (bit it is 2-of-the-same), but you now track-out the process and temp variations. Another idea was to 'Coarse Cal', with a tapped Osc, so the CAL scheme simply tries to lock N x OscPeriod, to some reference time. -jgArticle: 115845
Jim Granville wrote: > John_H wrote: > > <snip> >> >> First stab: >> >> Most people can just skip the post when their eyes start to glaze >> over; I'm going into detail to show what *can* be done, not >> necessarily to suggest this is a great way to go. >> >> >> The fastest routed LUT delay in the S3E is on the order of 270 ps >> (from -MIN timing). >> >> If an 8-LUT ring oscillator were used, the oscillator period would be >> a maximum of about 230 MHz or just over 16 ring oscillator periods in >> your 13.56 MHz period. >> >> For each half cycle, use a ring oscillator and a 5-bit combinatorial >> Gray code counter to count the ring oscillator half periods. If the >> ring oscillator is only enabled when the half cycle you're measuring >> begins, the ring oscillator starts oscillating and the Gray counter >> starts counting when you enter the appropriate half cycle. When the >> end of the half cycle hits, latch the count values into their embedded >> registers and latch a 1 in a self-reset register. Use the self-reset >> register to reset the ring oscillator and clear the Gray counter. >> When all is zero, asynchronously clear the self-reset register. The >> ring oscillator is disabled and held in reset until the next half >> period begins. > > Interesting. > > and perhaps allow a 6th bit, or more, just to cover faster than expected > ring osc cases. You could also make the Gray Counter saturating, so > there is no confusion of '>' - otherwise a multiple of Gray cycles might > get a 'pass mark'. The ring oscillator is subject to the -MIN timing for the device; the numbers work out to 40% of the fastest (-5) speed grade. Adding an extra bit or two would increase the range to measure longer times but I'd expect the maximum counts to be about 160 for the sum of the two halves rather than the 93 or 271 for the max -4 numbers or the -MIN numbers, respectively, given what I saw as "typical" on my S3E Starter board (-4 device). There should be no part that exceeds a LUT-delay count of 271 for an 8-LUT ring oscillator in a Spartan 3E device. >> End result - you can decode a binary count value from the bits you've >> latched independently for the two half cycles. The two values should >> be approximately the same and the sum of the two counts is the total >> ring oscillator LUT delays in a 13.56 MHz period. If the 13.56 MHz >> period *is* constant, the 100% point total should be roughly >> consistent between adjacent cycles though it may vary by many percent >> across temperature, voltage, and other internal influences. You can >> compare the two half counts to a percentage of the total to see if >> you're in the acceptance window or not. >> >> The 8-LUT ring oscillator can be constructed in one CLB with around 20 >> ps routing between LUTs (as reported by the Timing Analyzer or FPGA >> Editor) with judicious selection of which LUT goes where (using LOC or >> RLOC/RLOC_ORIGIN constraints) to access the shortest, most consistent >> timing. SLICE_L and SLICE_M delays vary slightly but don't impact a >> measurement on the order of what you're trying to achieve. >> >> The ring oscillator and the combinatorial Gray counter should be >> developed with great care. The conversion from the 8-bit Johnson >> counter (the ring oscillator) and the 5-bit half-period Gray counter >> is more than 2 minutes of work especially with the extra bit in the >> Gray counter used to reduce confusion between conflicting Johnson >> counts and Gray counts when they both transition about the same time >> when sampled. > > I think here you have jumped to sampling BOTH, in order to hike the > precision from the ~4ns to the ~270ps, right ? > > I've often thought of doing exactly this, but wondered just how you'd > 'align' the Johnson edges, with the Gray, to keep things > a) monotonic > and > b) hopefully nominally equal in LSB step size. Both are sampled, indeed, making the precision a *minimum* or 270 ps but a maximum just under 800 ps with a typical -4 value being, perhaps, about 450 ps (based on my one sample of one -4 ES device). The Johnson counter is the "ruling" time stamp. Using the full Johnson count range as one period, each step in the Johnson count is 1/16 and the half-period counter give gray values in 1/2 steps. If the Johnson counter says 1/16 but the Gray counter says 5.5, the Gray gets nudged to 6.0 rather than brought down to 5.0. Care must be taken to align the uncertainties such that a disagreement between values is "obvious" as to which way to correct the Gray value. The LSB sizes are pretty darned close when the LUTs are in the same CLB and the routes are all the same, shortest length. I mentioned there's a slight difference between SLICE_M and SLICE_L LUTs bet the system ends up pretty darned consistent. >> The self-reset is used to guarantee hold times between the sampling >> 13.56 MHz clock and the clear. >> >> What a mess, right? But, ... >> Your resolution could be just over 1% in the slowest device (a count >> of 93 for the total period). >> You use no DCMs. >> You don't even need the 125 MHz clock. > > No, but as some stage an absolute time reference might be a good idea ? If you want an absolute measurement, the 125 MHz can be used as a reference to measure the ring oscillator frequency. Absolutely. The task at hand was determining when the duty cycle of the 13.56 MHz signal is out of whack; nothing absolute needed. > I've also thought of building two of these types of circuit, and having > one in a CAL phase whilst the other samples the IP, and then swap on the > next cycle, (and so on). Thus you store the 93 (or 87, or 104) or > whatever your CAL says is the present time-value. > > Have you ever tried that ? The beauty is that the same ring oscillator can feed the frequency counter. No need for an independent CAL cycle if you're interested in the average frequency. Something I'm looking at now for a different application is using a reference oscillator to drive the scale in a sing-oscillator based NCO where jitter isn't a huge concern (a couple nanoseconds are fine) but the phase needs to be agile - far beyond the capabilities of a DCM. > Logic has > doubled (but it is 2-of-the-same), but you now track-out the > process and temp variations. For applications where one ring oscillator is used for cal and another is used for strict delay rather than another ring oscillator, my concern has been that the full scale values would be off a bit because of the energy (and heating) for the CW oscillator versus the one-shot delay. It's all touchy-feely at this point without a bit of testing or specific device knowledge but the differences should be minor if everything is very close together. I just haven't tried. > Another idea was to 'Coarse Cal', with a tapped Osc, so the CAL scheme > simply tries to lock N x OscPeriod, to some reference time. > > -jg A tapped oscillator as in finely adjusting the ring oscillator? Absolutely. A combination of LUTs with different route time selections (choose the longer or the shorter route) in a ring oscillator can arrive at a closest-approximation to some M/N of the reference clock, dithering between two very close ring period values to keep the phase where it needs to be. Carry chains can also provide some tight resolution though the overall frequency can tend to increase because the carry chain starts to leave the ring oscillator's neighborhood and needs to be routed back. This is the stuff of good fun for me. It's been nice bouncing it by you, Jim. If anyone else has looked far enough into the ramblings to spark some interest, kudos! Silicon is wonderful to stretch in funny ways to think outside the sandbox. - John_HArticle: 115846
I want to generate a program in VHDL for generating registers which can be used then into a state machine. If anyone has a sample program to share, it will be very helpful. Thanks and regards, sandipArticle: 115847
John_H wrote: > Jim Granville wrote: >> Logic has > doubled (but it is 2-of-the-same), but you now track-out the >> process and temp variations. > > > For applications where one ring oscillator is used for cal and another > is used for strict delay rather than another ring oscillator, my concern > has been that the full scale values would be off a bit because of the > energy (and heating) for the CW oscillator versus the one-shot delay. > It's all touchy-feely at this point without a bit of testing or specific > device knowledge but the differences should be minor if everything is > very close together. I just haven't tried. Just to clarify my details, I was not thinking of a dual Cal / SW osc, but of an Alternate scheme ( like in PAL TV's ), where you try and build two identical Oscs, and then use each one 50% of the time. - this does imply a repetitive trigger situation (as in the OP ), and most precison delay measuring schemes are triggered in one way or another. That means heating / thermal die slopes / etc do not matter, because you alternately cal and use each one, and at whatever the trigger rate is ( 80ns here ) -jgArticle: 115848
If you are using the RAM as top level in your test design maybe you should use additional input and output registers Rgds AndreArticle: 115849
Hi Jules, "Jules" <jules@dsf.org.uk> wrote in message news:1172059976.345496.76990@s48g2000cws.googlegroups.com... > Just wondered if anyone could point me to documentation on the timing > constraints for the "altsyncram" standard module on Cyclone II. I > have chapter 8 of the device handbook, which has a basic diagram, but > when I try to duplicate the timing of this diagram, I don't seem to be > able to get clock speeds above about 100MHz to work correctly > (according to Quartus II's simulation). I understood this module was > supposed to function at 200MHz, so I guess I must be doing something > wrong, but what it is I'm at a loss to explain. I've tried shifting > my clock signal's phase in relation to the control signals, but > haven't found anything that helps. In case it's relevant, I'm using > it in true dual-port mode, with a single clock for both ports. > Using it on my board with a 2C20F484C7, no registers on the outputs, it takes around 8ns for the outputs to stabilize after the clock pulse transition. That is using the V6.1 Q2 and libraries, according the simulation results. Your results may vary depending on your C2's speed grade, the version of Q2 libraries you are using (if the megafunctions have changed that is), or other aspects of your design. Red
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z