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
In a recent thread, there was a discussion regarding the desire for hysteresis on clock inputs for programmable logic. Although this would certainly help those applications where noisy or slow clock edges are present, there would be repercussions that might make a product with this feature only useful in special cases. (In other words, to be frank, the small sales would make the product not worth the investment from the vendor's (i.e. - my) point of view.) With this in mind, reactions and comments on the following points are welcome. 1. Assume any hysteresis on the clock edges that is sufficient to be useful (perhaps 0.4 to 0.5 volts) will also cause the clock-to-output delay to increase by 0.5 nsec. (I think this is a reasonable estimate.) Why would you buy this product if you were not interested in the hysteresis and another PLD was available with a faster Tco? Note: Some may suggest making the hysteresis programmable with an EE or SRAM bit. For the purpose of this discussion, assume that such programmability would itself add circuit complexity that would increase the Tco even without hysteresis. (At the very least, we would have to add a development and time-to-market cost variable into the discussion, which would muddy the picture a bit too much.) 2. Half of the 0.5 nsec delta in Tco is simply due to the translated threshold point compared to the timing spec. For example, if we have 0.5 nsec of hysteresis centered around a spec'd 1.5 volt input threshold, then the input buffer won't switch until the pin signal reaches 1.75 volts. For a 2.5 nsec clock input rise time (a reasonable value on IC testers), 10-90% of a 3.3 volt input signal, this implies an added built-in delay of .25 nsec. In a system with long clock edges (remember, this is one of the applications this structure is for) the adder will be even greater. For a 10 nsec clock input (10-90), I calculate the additional Tco from this effect to be around 1 nsec. So, the question: With centered hysteresis, the Tco will be fairly strongly dependent on clock rise time. Comments? (If the vendor moved the data sheet's clock input trip point to 1.75 on the rise and 1.25 on the fall, then board delay calculations will have to include the effect. This, I think, would only confuse the board designer and look like "specsmanship." The delay is real ... it must be accounted for somewhere.) Note: Although off-centering the hysteresis (designing the input buffer so that the rising edge would trigger at 1.5 volts, not 1.75 volts, with the falling edge triggering at 1.0 volts) would negate this effect entirely, it would only work for positive edge going (at the pin) clocks. The delay, however, would be doubled for falling leading edges... (For anyone suggesting programming either the rising or falling edge for optimization, note that modern CPLDs offer local polarity control at the macrocell. Once the input buffer at the pin is passed, hysteresis can no longer be implemented since any hysteresis put in a later stage would be reduced, as seen at the pin, by the gain of the input buffer -- typically by a factor of 10X per buffer stage. Sorry.) 3) Finally, more and more PLDs have output slew-rate control. This also adds to the Tco, but the choice can be made on a pin-by-pin basis. Does this feature obviate the need for hysteresis at the input pins? This subject is often debated in my company, and it occurred to me that this newsgroup would be a good place to discuss the technical issues involved. I look forward to your comments with interest. Ron Cline Product Development Mgr Philips Programmable Logic ProductsArticle: 14326
seebs@plethora.net (Peter Seebach) writes:
> > void main() {
>
> Interesting, but not C. main returns int in C.
Oh no, not again !
This pops up in every tech newsgroup every so often, starting long
religious flamewars on compilers, languages, operating systems ...
The ANSI C standard states that there is C for environments which
contain an operating system. In that case main returns an int which
the OS should interpret as an exit code.
However, if you have the so-called free-standing environment, (which is
the case with most embedded systems) the main() function:
- does not have to exist at all, but
- if it exists, it can have any prototype you like, and
- does not have to return at all
If you think about it, where exactly would main() return to say in a
PIC which controls the temperature in your fishtank ?
So, main() returns int not in C but when C is used in an environment
where the standard program start prologue routine calls the function which
by convention (and by the parts of the standard applied to such situations)
is called 'main()' and should return an int.
Since using C for logic synthesis would probably be a free-standing
implementation (you wouldn't run the resulting netlist under an OS,
would you) you don't have to declare main() as an int function.
Zoltan
--
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi | I don't believe in miracles |
| Bendor Research Pty. Ltd. | but I rely on them. |
+--------------------------------+---------------------------------+
Article 74 of comp.compilers.lcc:
Article: 14327In article <36AD3B01.C889596@swcp.com>, Ron Cline <rcline@swcp.com> wrote: >In a recent thread, there was a discussion regarding the desire for >hysteresis on clock inputs for programmable logic. Although this >would certainly help those applications where noisy or slow clock edges >are present, I can remember a time when 100nS was considered "fast" for some logic. Now a 100nS edge would be considered very slow. As logic gets faster, the need for a more forgiving input circuit becomes greater. The PZ [3,5]128 is God's gift to the designer of low powered equipment, but twitchiness of the clock input is about that same as all the other makers. > there would be repercussions that might make a product with >this feature only useful in special cases. Every product I have ever designed has been a special case of some kind. The more special cases you can cover with the same product the more useful the part is. As a rule the cost of the part also goes up too so there is a bit of a trade off. A CPLD that can switch 100A on its outputs would be nice but a bit too pricy. CPLDs usually have more than one clock input. Not all of them need to be super high speed. You could have a fast one and one with backlash. >1. Assume any hysteresis on the clock edges that is sufficient to be >useful (perhaps 0.4 to 0.5 volts) will also cause the clock-to-output >delay to increase by 0.5 nsec. (I think this is a reasonable >estimate.) Why would you buy this product if you were not interested in >the hysteresis and another PLD was available with a faster Tco? If the WayCoolInput CPLD was in the stock system and brand X's was not chances are I would look at the WayCoolInput one before looking at the other. Even if I don't need a feature, if it doesn't cause harm in the new design and doesn't double the cost of the part, I would likely use it. It would increase the number of units used, and hopefully lower the cost per part. Many things I design have timing requirements measured in the figurative days range and not in the pS range. A couple of nS on the input is neither here nor there, but ease of use can get me home in time for dinner. [....] >3) Finally, more and more PLDs have output slew-rate control. This also >adds to the Tco, but the choice can be made on a pin-by-pin basis. Does >this feature obviate the need for hysteresis at the input pins? Very seldom is the clock input the output from another CPLD. It is more often a clock that has come through quite a long collection of traces from some 74HCXXX buffer on another board. The impedance of the clock trace varies randomly from a few ohms to 100 ohm down its length and it runs right through the middle of an RF output stage, but someone else designed that board. -- -- kensmith@rahul.net forging knowledgeArticle: 14328
I'm looking for Altera 10K libraries for Protel Adv. Schematic. I want to use Protel schematics to generate an EDIF netlist to feed into MAXPLUSII Thanks Scott Baker scd@teleport.comArticle: 14329
I would very much like say 200mV of hysteresis on the clock input, in fact on all the inputs. I use the P3Z22V10. I agree with the other post, stating that clock signals often come via some PCB routes and are not exactly perfect by the time they reach the PLD. An extra 0.5ns is nothing in most cases. >In a recent thread, there was a discussion regarding the desire for >hysteresis on clock inputs for programmable logic. Although this >would certainly help those applications where noisy or slow clock edges >are present, there would be repercussions that might make a product with >this feature only useful in special cases. (In other words, to be >frank, the small sales would make the product not worth the investment >from the vendor's (i.e. - my) point of view.) With this in mind, >reactions and comments on the following points are welcome. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 14330
Ken Smith wrote: > > In article <36AD3B01.C889596@swcp.com>, Ron Cline <rcline@swcp.com> wrote: > >In a recent thread, there was a discussion regarding the desire for > >hysteresis on clock inputs for programmable logic. Although this > >would certainly help those applications where noisy or slow clock edges > >are present, > > I can remember a time when 100nS was considered "fast" for some logic. > Now a 100nS edge would be considered very slow. As logic gets faster, the > need for a more forgiving input circuit becomes greater. I'm with Ron Cline - if your clock edges have been degraded enough for hysteresis to become desirable, you need to clean up the clock or the electromagnetic environment. <snipped sensible comments about selecting PLD's> > [....] > >3) Finally, more and more PLDs have output slew-rate control. This also > >adds to the Tco, but the choice can be made on a pin-by-pin basis. Does > >this feature obviate the need for hysteresis at the input pins? > > Very seldom is the clock input the output from another CPLD. It is more > often a clock that has come through quite a long collection of traces from > some 74HCXXX buffer on another board. The impedance of the clock trace > varies randomly from a few ohms to 100 ohm down its length and it runs > right through the middle of an RF output stage, but someone else designed > that board. I'd put a lot more effort into getting that board modified than I would finding a PLD with hysteresis on the clock input - if the clock is crap now, and coming from a board over which I've no control, the next "up-grade" of that board is going to make things so much worse that even hysteresis won't save the situation. Then you find yourself on a midnight flight to Finland, committed to curing the incurable, and if you fail you will have trouble passing the buck to the engineer who gave you the crap clock. Bill Sloman, Nijmegen Article 71 of comp.compilers.lcc:Article: 14331
Hello, I am studying the architectures of different FPGAs. I want to make a comparison between Xilinx, QuickLogic and Altera FPGAs. I have some information about Xilinx but almost no information about Altera and QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what are the routing resources and the technology on which it works(like SRAM, anti-fuse via etc) How do I go about finding literature. Any inputs will be appreciated. Thanx in advance. Best Regards Pandey -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14332
[Me speaking from a Handel-C-centric viewpoint] Jonathan Bromley writes: > I think it makes perfect sense. You can think of any sequential > program as a big state machine with the program counter as its > state variable (indeed, this is quite a useful way to think about > certain kinds of parallel programming problem). Getting an > optimal implementation is quite another matter, of course. Yes, this is what Handel-C does. Except as there is explicit parallelism, multiple control states can be active simultaneously. > Personally I think C is a blind alley :-) Handel-C actually started as Handel which was based on Occam. We put a C "front end" on it to make it more attractive to folks that know C already. The result is actually a big improvement over the original Handel, in terms of readability and compact code. The fine-grained parallelism and communication primitives from Occam are still present and very usable, so it's a nice combination. > - you need > far more explicit control over parallelism, Handel-C comes close > but is not sufficiently configurable - but the possibilities are > obviously there. Do you have anything more specific in mind? I find Handel-C's limitations very frustrating, but with experience I've found ways of doing things that turn out nicely in the end. -- JamieArticle: 14333
jerry english writes: > Let me add an AMEN to that. Most of my time is spent wrestling with > the tool to get it to do what I want. I've always wondered why the > examples in the tutorials are so trival as to not provide any insight > into the useage of the tool. You clearly need to participate in the thread "The development of a free FPGA synthesis tool" on comp.arch.fpga/gnu.misc.discuss :-) There is another issue. <Handel-C hat on> I write some quite tricky modules, that combine high level and low level knowledge. It is full of hacks to make specific things work. This code will not be used in examples, even though a few people might find it useful, because it is felt that most people would be scared away from the tool if they saw the hard core stuff. Essentially, the tool is not _aimed_ at the kind of people who wrestle with the tool. If you are one of those people, bad luck as you aren't really within the focus of the company. (Unless you can show that there are a lot of you, or write a cheque). The tool may still be useful to you. -- JamieArticle: 14334
pandey@my-dejanews.com wrote in message <78khl4$oju$1@nnrp1.dejanews.com>... >Hello, I am studying the architectures of different FPGAs. I want to make a >comparison between Xilinx, QuickLogic and Altera FPGAs. I have some >information about Xilinx but almost no information about Altera and >QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what >are the routing resources and the technology on which it works(like SRAM, >anti-fuse via etc) How do I go about finding literature. www.altera.com www.quicklogic.com steveArticle: 14335
You can find handy links to Xilinx, QuickLogic, Altera, and all the other on The Programmable Logic Jump Station at http://www.optimagic.com. You may also find some of the material useful in the Frequently-Asked Questions section (http://www.optimagic.com/faq.html). ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- pandey@my-dejanews.com wrote in message <78khl4$oju$1@nnrp1.dejanews.com>... >Hello, I am studying the architectures of different FPGAs. I want to make a >comparison between Xilinx, QuickLogic and Altera FPGAs. I have some >information about Xilinx but almost no information about Altera and >QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what >are the routing resources and the technology on which it works(like SRAM, >anti-fuse via etc) How do I go about finding literature. Any inputs will be >appreciated. Thanx in advance. Best Regards Pandey > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14336
Hello ! You can enter into ALTERA WEB and find all information you need ! www.altera.com , good luck. pandey@my-dejanews.com wrote: > Hello, I am studying the architectures of different FPGAs. I want to make a > comparison between Xilinx, QuickLogic and Altera FPGAs. I have some > information about Xilinx but almost no information about Altera and > QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what > are the routing resources and the technology on which it works(like SRAM, > anti-fuse via etc) How do I go about finding literature. Any inputs will be > appreciated. Thanx in advance. Best Regards Pandey > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14337
denis lachapelle wrote: > I would suggest a DSP that has a T1 interface. To me it will be more > appropriate. > He asked if it would be possible. To that the answer would be yes, assuming he chose a device big enough to handle all the logic needed. As to whether it is feasible/appropriate... that's an entirely different question. > nobody@nowhere wrote in message <78a9n0$koh@cs1.FTA-Berlin.de>... > >Hi guys, > > > >it is possible to implement a DTMF Decoder in a FPGA/Xilinx ? > >Input signal would be a digital E1/T1 signal, generated by a E1/T1 Framer > >(CLK, DATA) > > > >comments please here or to mb@cellware.de > > > >Thanx > > > >Michael Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14338
To get the Xilinx Student Edition 1.4 upgrade complete and submit the request form located at http://www.xilinx.com/xup/express/xse14_rg.htm. Anna M. Acevedo Xilinx University Program EKC wrote: > I am a high-school student in the 10th grade interested in synthesizing > designs for the Xilinx XC4000 series of FPGAs using VHDL. However, I am > having trouble obtaining a low-cost VHDL/Verilog synthesis tool. I am > currently using the ABEL language supported by Foundation Version 3.1 > student edition. The Xilinx web-page states that I need to obtain the > Foundation V1.4 cd's to upgrade V1.3 so that I can design with VHDL. > Does anyone know how to obtain these CD's from Xilinx? Or alternatively, > are there any free or open-source VHDL synthesis tools available? > > Thanks in advance, > > -EKC > > I think it's a shame that Xilinx and Altera are charging such hefty sums > for their software. It seems that the distinguishing factor between FPGA's > from different vendors is the quality and ease-of-use of the design > software, especially as the gate numbers stretch into the millions. By > decreasing or eliminating the price-barrier, FPGA vendors with superior > design software would increase the rate of diffusion of their software into > the market-place, and consequently promote their FPGA's. Such a lowering of > the price-barrier would pose a serious threat to companies that offer only > synthesis tools, which generally target FPGA's from different companies. > This would lock clients into FPGAs from a single vendor. -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Anna Acevedo Tel: USA 408-879-5338 Xilinx University Program Fax: USA 408-879-4442 2100 Logic Dr. email: anna.acevedo@xilinx.com San Jose, CA 95124 USA Hot Web Site: http://www.xilinx.com/programs/univ.htm * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *Article: 14339
I'm re posting this from work. It did not propagate from my home ISP, JPS! In article <36ABBE8B.82BBBA6E@xilinx.com>, peter@xilinx.com says... > >David T Le wrote: > >> I need help to implement a simple PLL in Xilinx FPGA for >> self-leaning. >> Appreciated for help to any webpages, application, or >> example. >> > Why not search dejanews for comp.arch.fpga posts about PLL? There's lots of information there. Unfortunately, there are a lot of questions like, "I need a PLL to do this." The answers address this question, but many of the designs should have been implemented with a DDS not a PLL. If what you really want is a digital PLL with all its clock jitter, Here's one way to do it. Start with an accumulator to which you add a constant, such that the overflow rate of the accumulator is the output frequency you want. If you have a clock available that's 16x you're desired output frequency, then you would clock the accumulator with the 16x clock and add a constant of 1/16th the full value of the accumulator. The signal to which you wish to lock must now be used to adjust the phase of the accumulator to track the reference, such as data edges. Try this: differentiate the rising edge of the reference to create a one clock wide pulse. Use this pulse to enable transferring a copy of the accumulator to a second register. But on the way to the second register, divide the accumulator value by say, 16 by shifting everything right by 4. (Different divide ratios will change your loop.) The value in this second register must now be subtracted from the accumulator, on the next clock while at the same time continuing to add the constant. You could use a subtractor to subtract this value from the accumulator's feedback. Or subtract it from the constant. The idea is that you are trying to get the accumulator to be at zero, or its wrap around point, at the time the reference edge arrives. So, every time the reference edge arrives, you measure the phase of the accumulator and feed back of 1/16th of the error as a proportional negative correction. When the ref edge arrives, if the accumulator is a little fast, it will contain a positive value. Take 1/16th of that value, and subtract it from the accumulator while continuing to add the nominal constant. Next time a reference edge arrives, the error will be less. The loop will gradually approach the correct phase. Instead of subtracting 1/16th the error once, you could subtract 1/256th the value 16 times, if that's easier. If you have sparse reference edges, don't fall into the trap of only updating the negative feedback when a reference edge arrives. Rather feedback a fixed amount of phase correction then revert to no correction ie just the constant, until another reference edge arrives. Good luck. Dave Decker Diablo Research Co. LLCArticle: 14340
All the information you are asking for is available on the vendor websites. If you need the urls, go to either my website or to http://www.optimagic.com. You'll find links plus some information in both places. pandey@my-dejanews.com wrote: > Hello, I am studying the architectures of different FPGAs. I want to make a > comparison between Xilinx, QuickLogic and Altera FPGAs. I have some > information about Xilinx but almost no information about Altera and > QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what > are the routing resources and the technology on which it works(like SRAM, > anti-fuse via etc) How do I go about finding literature. Any inputs will be > appreciated. Thanx in advance. Best Regards Pandey > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka Article 73 of comp.compilers.lcc:Article: 14341
Can't help you with Protel to Max+II, but here's a reference to a nifty Max+II (.acf file) to Orcad (.LIB file) utility. Protel can read/import the Orcad .LIB file. I've used it, it works just fine (but not entirely seamless, depending on number of ins, numberof outs, etc). see http://members.tripod.com/~ma_gm/al2or.html This is way better than manually transcribing pin names from one tool to the other! scd wrote: > I'm looking for Altera 10K libraries for Protel Adv. Schematic. > I want to use Protel schematics to generate an EDIF netlist to > feed into MAXPLUSII > > Thanks > Scott Baker > scd@teleport.com Bob Elkind eteam@aracnet.comArticle: 14342
>1. Assume any hysteresis on the clock edges that is sufficient to be >useful (perhaps 0.4 to 0.5 volts) will also cause the clock-to-output >delay to increase by 0.5 nsec. Seems 200mV would be useful. 400mV would be *great*. How much would 200mV slow it down? Programmable hysterisis that does not slow down the Tco if it isn't enabled would be a real product differentiator. I'm suprised the device guys can't come up with something novel there. Generally hysterisis is covering up problems that *should* be fixed in other places. That said however, the extra noise margin from *some* hysterisis still makes me feel comfortable, and I would consider that a plus. The 0.5ns Tco increase *could* be a plus also, since it would provide for a better output hold time :) But, I don't look forward to doing my clock network timing analysis with the different thresholds. bruceArticle: 14343
Mr. Cline: There are "methods" for effectively applying hysteresis to an input with CPLDs (or FPGAs). One that comes to mind is the inverting-buffer-feedback-through-a-resistor trick, discussed several times in this discussion group. I think there is at least one application note covering this on the Xilinx website, but I'm not sure. To basics: what are the bad things that can happen to clock signals? 1. reflections from poor routing and/or termination... Hysteresis is a stopgap bandaid in this case. It gives you some short-term help that can blow up in your face at any moment, especially with multiple loads distributed along the transmission line. Some designers are comfortable with this solution, some of the time. It comes down to a matter of degree (and faith?). Some designers look at reflection problems as a clear indication that the design isn't finished yet. 2. induced noise from capacitive or inductive coupling... Hysteresis is a viable solution for induced noise problems, to a degree. If you bump the noise immunity level *up* another 200-400 mV, can you be **sure** that this is enough? In many cases yes, in some cases no. Anyway, a "way more cool" feature for clock input handling would be the option for differential (complementary) inputs. In most cases where hysteresis may be the first solution that comes to mind, but the fundamental problem *really* indicates the need for differential clock distribution. In other words, the clock waveform problem is related to induced noise. Unlike reflection problems, the induced noise problem isn't a reflection (pun intended) on the designer's character. In many cases, the problem is an inherited and unavoidable condition that *can* be treated. Hysteresis can work (again, it's a matter of degree), but differential clock distribution is a solution that doesn't depend on the degree of noise induction. In other words, differential clock distribution is a much more solid solution. As a designer, if I know/suspect that noise can be a problem, I design in differential clocks. This almost always requires a dedicated driver and a dedicated receiver, simply because the FPGAs I tend to use don't support differential drive/reception (hint hint... care to address this?). But I can sleep soundly at night knowing the problem has been completely avoided, never to reappear. I fully understand that CMOS devices don't lend themselves to differential logic as easily as bipolar/ECL/CML devices, but differential clock IOs is my foremost wish for CMOS CPLDs and FPGAs. Many of these devices drive and/or receive busses, and we all know how easily busses can have problems with clock noise and signal integrity. Thank you for your time... Bob Elkind, FPGA designer and consultant eteam@aracnet.com website: www.aracnet.com/~eteamArticle: 14344
bob elkind wrote in message <36AE3816.DF995D7A@aracnet.com>... > >I fully understand that CMOS devices don't lend themselves to differential >logic as easily as bipolar/ECL/CML devices, but differential clock IOs is >my foremost wish for CMOS CPLDs and FPGAs. Many of these devices drive >and/or receive busses, and we all know how easily busses can have problems >with clock noise and signal integrity. > Hear hear! Differential clocks are a feature I'd like to see on a lot more fast logic devices. Especially low voltage stuff. As well as being an all round more robust form of clock distribution, it makes inverting the clock trivial and zero delay. DJArticle: 14345
Hi ALL I need to know if their is any FPGA student design contest for this year 1999. Please provide me with any related information. thanks Yousef Hawwar hawwar@uwm.eduArticle: 14346
I'm interested in generating small-stepped delays with FPGA/CPLDs for a phased array transmitter, and initially thinking of Xilinx 4000E & 9500 series +M1.5 Foundation, though would happily consider others. I've done a bit of design with all synchronous components at 30MHz but now need some small time shifts which are probably too small to be done by clocking. I'd welcome any comments or pointers. (1) I'm using an FPGA clocked output, with a delay from external clock input to output pin transition of say 8ns, on a 30MHz clock. (2ns input delay, ~6ns output delay). I'd like to be able to get the output transition to be much closer to the external clock rising edge. Can I create an internal delay of 25ns (33-8), and somehow fix this so it doesn't vary if I alter the design later ? A variation of +/-2ns might be OK. Is it possible to specify this kind of constraint? (2) Could I take a delayed clock such as the above and distribute it within the FPGA and get it treated like a primary clock, so that synchronous counters etc reliably count off it? Is there an attribute I can attach to a net to get it treated this way ? (3) I'd like to set up an array of async paths through the FPGA and get a very small amount of phase difference between them, and to ensure its fixed between recompilation. eg co1>outpin1-> delay1 -> inpin->comb logic ->outpin1a,1b co2>outpin2-> delay2 -> inpin->comb logic ->outpin2a,2b co3>outpin3-> delay3 -> inpin->comb logic ->outpin3a,3b etc co1,co2,o3 etc are clocked outputs, sharing a common clock. delay1,2,3 are digitally controlled analog delay lines programmable in 1ns (or less steps) typically in the range 10-80ns. The combinational logic is hopefully one CLB 4 input logic block per output and outputs are in pairs, so one CLB per group should do it. Again, I'd like to be able to specify a range of phase variation between all of the outputs, though they don't come out of clocked outputs. So, could I specify a constraint to use a particular CLB and IOB? About 50% of the total design might change, but I'd like to keep these stages constant. Currently I have working hardware in F series logic and I'd like to simplify the hardware by collapsing several channels into one package, but still have several dozen packages all clocked together. I'm bothered about variations between channels in each package and between packages. Am I likely to get that sort of data out of a manufacturer ? (4) Supposing I were to give up the idea of any external variable delay and do it all internally, probably synchronously, on the FPGA/CPLD - What is the smallest time increment I might achieve ? I've seen clock speeds of 196MHz mentioned, which might give me 5ns steps. Is this reliable, and is there anything faster? Thats enough for now! Many thanks in advance, Paul Richards SRD Ltd. (uk)Article: 14347
Input hysteresis has been called BandAid or Aspirin that kind-of fix problems that ought to be fixed properly in a different way. Nevertheless, we all keep BandAid and Aspirin in our medicine cabinets... One very common problem, where hysteresis helps, has not been discussed here: Designs with multiple uncorrelated clocks, where one clock generates ground bounce that will, sooner or later, occur right during the active clock transition of the other clock. I ran into an example where one device had a 33 MHz PCI interface, but otherwise operated at a different lower clock rate. Every now and then, the PCI-bus-generated ground bounce would kick into the slower clock ( or the other way round ) and would then result in double-triggering. But the clocks looked perfect on the pc-board. This problem has become worse since our ( generic term: "the industry's" ) flip-flops have become so fast that they can resolve clock edges less than 2 ns apart. Needless to say, all Xilinx FPGAs have some hysteresis on all their inputs :-) A BandAid will at least stop the blood from getting all over your clothes.... Peter Alfke, Xilinx ApplicationsArticle: 14348
This is a multi-part message in MIME format. --------------AD766C2D042883D384F0A02B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit bob elkind wrote: > Anyway, a "way more cool" feature for clock input handling would be the > option for differential (complementary) inputs. In most cases where > hysteresis may be the first solution that comes to mind, but the > fundamental problem *really* indicates the need for differential clock > distribution. In other words, the clock waveform problem is related to > induced noise. Unlike reflection problems, the induced noise problem isn't > a reflection (pun intended) on the designer's character. In many cases, > the problem is an inherited and unavoidable condition that *can* be treated. > You might look at the following page which compares the pin-pin jitter/skew between various TTL, CMOS and LVPECL Motorola clock drivers. For instance, the 3.3V PECL device MC100LVE111 specs a 50 ps skew between 9 pairs. This is roughly 10x better than TTL devices. These parts can be used directly with some SRAMs and other clock chips, but I don't believe any FPGA vendors support PECL clock inputs (except Dynachip). http://mot-sps.com/logic/Time_sel.htm Even if we ignore crosstalk, ground bounce and supply variation, single ended clocks suffer from wide TTL input thresholds (0.8-2.0V) which coupled with the slow (1-2 ns) risetime associated with typical terminated PCB clock lines and 0.5 ns of clock generation skew pretty much eliminates chip-chip timing precision of better that 1 ns. I don't really know how to derate the 50 ps skew associated with LVPECL outputs, but since the signals are immune to first order to crosstalk, ground bounce, supply and risetime, but my guess is that they would contribute less than 100 ps. - Brad --------------AD766C2D042883D384F0A02B Content-Type: text/x-vcard; charset=us-ascii; name="blt.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brad Taylor Content-Disposition: attachment; filename="blt.vcf" begin:vcard n:Taylor;Brad tel;work:1-408-730-3300 ext108 x-mozilla-html:FALSE url:www.cmln.com org:Chameleon Systems;Applications version:2.1 email;internet:blt@cmln.com title:Director of Applications adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A fn:Brad Taylor end:vcard --------------AD766C2D042883D384F0A02B--Article: 14349
Paul, 200+ MHz logic is attainable in modern FPGAs if the logic and layout are carefully controlled. That means doing your floorplanning and being careful that the logic between registers is limited to a single level. You won't get there easily using synthesis though. The clock distribution tree limits the performance of a design clocked by a global clock tree, so you are not going to get 1ns clock ticks. If the high speed clock is used only in a few flip-flops, you are better off bringing the clock in on a regular IOB near the flip-flops instead of the global clock. Doing that, you can clock a flip flop or two in Xilinx at close to 500MHz. You will need to be aware of the clock skew if you do this. One approach might be to externally generate a multi-phase clock and bring each phase in to get the finer resolution. This will probably require hand routing to ensure the delays for each clock to output path is matched (you can get good matching of delays but not good control of absolute delay) I heartily advise against trying to do what you need to using combinatorial delays in the FPGA. Your design will fail in that case as soon as the voltage or temperature changes. As I mentioned, careful design and layout can achieve decent matching of path delays (but don't expect the auto-place and route to do it), but the absolute delays are open loop, difficult to predict and virtually impossible to guarantee. You will also have improved chance of success using a newer family than the 4000E, preferably one of the low voltage families because of the improved speeds. (consider for example the 4000XLA or 4000XV families) Paul Attilla Richards wrote: > I'm interested in generating small-stepped delays with FPGA/CPLDs for > a phased array transmitter, and initially thinking of Xilinx 4000E & > 9500 series +M1.5 Foundation, though would happily consider others. > > I've done a bit of design with all synchronous components at 30MHz but > now need some small time shifts which are probably too small to be > done by clocking. I'd welcome any comments or pointers. > > (1) I'm using an FPGA clocked output, with a delay from external > clock input to output pin transition of say 8ns, on a 30MHz clock. > (2ns input delay, ~6ns output delay). I'd like to be able to get the > output transition to be much closer to the external clock rising edge. > > Can I create an internal delay of 25ns (33-8), and somehow fix this so > it doesn't vary if I alter the design later ? A variation of +/-2ns > might be OK. Is it possible to specify this kind of constraint? > > (2) Could I take a delayed clock such as the above and distribute it > within the FPGA and get it treated like a primary clock, so that > synchronous counters etc reliably count off it? Is there an > attribute I can attach to a net to get it treated this way ? > > (3) I'd like to set up an array of async paths through the FPGA and > get a very small amount of phase difference between them, and to > ensure its fixed between recompilation. eg > co1>outpin1-> delay1 -> inpin->comb logic ->outpin1a,1b > co2>outpin2-> delay2 -> inpin->comb logic ->outpin2a,2b > co3>outpin3-> delay3 -> inpin->comb logic ->outpin3a,3b > etc > > co1,co2,o3 etc are clocked outputs, sharing a common clock. > delay1,2,3 are digitally controlled analog delay lines programmable in > 1ns (or less steps) typically in the range 10-80ns. The combinational > logic is hopefully one CLB 4 input logic block per output and outputs > are in pairs, so one CLB per group should do it. > > Again, I'd like to be able to specify a range of phase variation > between all of the outputs, though they don't come out of clocked > outputs. So, could I specify a constraint to use a particular CLB and > IOB? About 50% of the total design might change, but I'd like to keep > these stages constant. > > Currently I have working hardware in F series logic and I'd like to > simplify the hardware by collapsing several channels into one package, > but still have several dozen packages all clocked together. I'm > bothered about variations between channels in each package and between > packages. Am I likely to get that sort of data out of a manufacturer > ? > > (4) Supposing I were to give up the idea of any external variable > delay and do it all internally, probably synchronously, on the > FPGA/CPLD - What is the smallest time increment I might achieve ? > I've seen clock speeds of 196MHz mentioned, which might give me 5ns > steps. Is this reliable, and is there anything faster? > > Thats enough for now! Many thanks in advance, > > Paul Richards > SRD Ltd. (uk) -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka
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