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
>> Assuming a scenario that I have a bit file built for a particular >> FPGA, but i don't have a that FPGA device to download it to, Is there >> a way to check it works on that particular FPGA? >> Thanks in advance >> Water >no I think he can do it with HTVS*. You just check that it looks good on paper, then ship it. * Hubble Telescope Verification System.Article: 125526
On Fri, 26 Oct 2007 07:35:32 -0700, Andy <jonesandy@comcast.net> wrote: >On Oct 26, 8:09 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> Replace the counter with an absurdly long one (say 32 bits), whose count >> length is controllable from a register accessible to whatever host CPU >> (NIOS in this case). >If it is an up counter with a comparator, be careful: if it is an >equality rather than a greater-than comparator, and the CPU sets the >trigger value to less than the current value of the counter, then the >counter will have to roll all the way over, and likely miss a refresh, >with potential data loss resulting. Good point: if doing that, it's advisable to reset the counter (and issue a refresh) whenever you set the trigger value. - BrianArticle: 125527
Hi, I was recently asked in an interview that what points you will consider while selecting the I/O pins in FPGA ? One thing which came to my mind was : 1) considering board aspect that the pins corresponding to peripherals should near to that peripheral so as to minimize the routing delay in PCB. 2) pin should be compatible to the I/O type of peripheral device, i.e. LV_TTL, LC_CMOS etc. Were my points valid ? Any other points are welcome. RegardsArticle: 125528
On 26 Oct 2007 18:42:44 GMT, Berk Birand <dont@email.me> wrote: >Hi all, > >In our design, we have a sensitive circuitry that we think may be affected >by the bulk of the circuit (mainly two state machines). In order to isolate >it in a section of the FPGA (Virtex-II Pro XC2VP30), we tried using the >RLOC and RLOC_ORIGIN attributes. We did manage to group the sensitive >circuitry, and move it all the way to the bottom-left corner of the chip. >However, when we do that, the rest of the CLBs also move with them. > >Although we tried to use the RLOC attribute for the rest of the circuit, >they are somehow not recognized. The reason might be that the files are in >different hierarchy levels, and the Xilinx Floorplanner doesn't recognize >the U_SET. > >How do you suggest we go about doing this isolation? What can be going >wrong with the RLOC attribute? Since this is the first time we've ever used >them, I suspect we might be missing something out. RLOC is Relative LOC; it places parts relative to each other but says nothing about their absolute location. The tools WILL move the groups around to shorten routes... You may need to LOC your sensitive circuit in one corner and LOC the rest in other places; if the rest is large, that's a lot of LOC constraints. Look at the Constraints Guide (cgd.pdf) to see how to use the AREA_GROUP and RANGE constraints. - BrianArticle: 125529
Hello all, The ISE map report gives out a figure under the heading total equivalent gate count... So can anybody help me in understanding what exactly it means?How can we relate it to the ASIC gate count of the same design? Regards, NagarajArticle: 125530
> You can never have too much capacitance on the VCCIO, in my opinion. > At 120 Hz, it should be easy for you to stagger the output timing > of the various triac drivers without materially affecting the dimming > quality. This would reduce the issues of simultaneous switching and > also reduce the high-speed decoupling requirements on VCCIO. > > However there may be another issue that gets you in the end. Where > are you mounting all the triacs and how easy is it for the triac > switching noise to find its way back to the FPGA power system? Even > with optocouplers, if your input supply shares AC wiring with the > triac AC system you may be in for trouble. Think about any possible > coupling paths. > > Have Fun, > Gabor > Gabor, Thanks for the input. I hadn't thought of staggering the switching times. That's a great idea. The software that I'm using to drive the lights won't do that, but I probably have enough logic elements left in the FPGA to implement that in hardware. I wonder... how can I get a feel for how much delay would reduce the need for high capacitance on VCCIO? (I'm a biologist by training, mad scientist by night.) As for the line noise getting back to the FPGA... well, this is for a residence and it's 100% likely the FPGA circuit will be on the same power leg as some of the TRIACs, and highly likely to be on the same circuit, even. In my case, they will be mounted a large physical distance from the FPGA and have long extension cords, but I know there's no snubber circuit on the TRIACs. I suppose extra capacitance and inductance on the FPGA's power supply could help combat that?Article: 125531
> Nevo; > Perhaps you could play (uh,experiment) with with a microprocessor > development board (PIC, AVR, etc) to get ideas on what works and > doesn't work to control your Christmas lights. You could probably get > something working sooner than designing an FPGA project from > scratch. > -Dave Pollum Bah... the homebuilt community has already done that! What's the fun in that? :) Seriously, I've decided to go with an FPGA for a few reasons: 1) The number of I/O pins on a uC is limited compared to FPGA 2) The processing power of a uC limits the number of channels that can be dimmed 3) The per-channel cost is going to be much lower with an FPGA than a uC 4) I've done the uC thing. FPGA's are a new frontier for me to explore! I've prototyped my FPGA design driving LED's and have verified the basic design of the logic. Repeating it 128 times is trivial in an FPGA (not so much in a microcontroller). The only new twist in scaling up from my tests is the addition of a zero crossing detector. The fourth reason above is my main motivation for doing this: I get to learn something new! Even if it doesn't work by Christmas I'll get the education out of it.Article: 125532
Hi -
[3] Some I/O pins are
- Input Only
- Lack IOB FFs
- Dedicated clk input
- For DRAM interfacing there may be specific pins reserved for
specific signals
[4] In some families (Spartan 3/3E), only 2.5 V Differential signaling
supported, not 3.3 V. The important corallarys are : Banks
which contain dfferential signaling must have VCO tied to 2.5, and
this precludes single ended 3.3V signals from being used in that bank.
Sometimes the subtleties of IO are overwelming, and vary slightly from
family to family. One thing I try to do before a pwb is sent out for the
first time, is to code the I/O for the final pin selection, and synthesize.
This is pretty easy, will be the first thing done when coding anyway, AND
allows you to view the generated report files for any possible bad. or
more likely, non-optimal pin assignments.
There is a section in the .mrp file and in the .pad file which should be
reviewed to ensure what you want is what you got.
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant
email : jretta@rtc-inc.com
web : www.rtc-inc.com
"Ved" <vedpsingh@gmail.com> wrote in message
news:1193488229.776279.239100@e34g2000pro.googlegroups.com...
> Hi,
> I was recently asked in an interview that what points you will
> consider while selecting the I/O pins in FPGA ?
>
> One thing which came to my mind was :
> 1) considering board aspect that the pins corresponding to peripherals
> should near to that peripheral so as to minimize the routing delay
> in PCB.
>
> 2) pin should be compatible to the I/O type of peripheral device, i.e.
> LV_TTL, LC_CMOS etc.
>
> Were my points valid ?
> Any other points are welcome.
>
> Regards
>
Article: 125533Everyone, I really appreciate the input I've received on this thread. Y'all have been great and have given me a lot to think about. Reading this thread has been a lot of fun and has been very educational. However, I'm not sure that I've adequately desribed the depths of my ignorance on this subject. I literally have no idea what size capacitors to use... not even a guess as to the order of magnitude. A few picofarads? A few hundred microfarads? Really... I'm that clueless. If someone could just throw out a number that makes some kind of sense, I'd appreciate it. (I promise I will never go professional in your industry without the obtaining the requisite formal education first!)Article: 125534
> Any other points are welcome. I would have mentioned something about in an ideal world making sure you can achieve timing closure before committing to a PCB. These days, the effect of I/O location on design performance is much, much less significant than it was, say, ten years ago - largely because of better and faster on-chip routing, but if you are pushing the limits then the I/O selection can make all the difference. Of course, since it was an interview question, the "right" answer would probably some talked about working as a team with the PCB layout people and choosing a pin-out that is acceptable to both groups.Article: 125535
Thanks Jonathan, The project is NOT all in Verilog. The EDK uses VHDL wrappers for all the modules and I am using Xilinx IP cores which are written in VHDL. The testbench and the system are in Verilog. Underneath that level are all VHDL wrappers. Some modules inside the wrappers are Verilog and some are VHDL. I have pointed ModelSim to the unisims_ver library which contains the Xilinx primitves in Verilog. I am pretty sure the DCM model would be used from here so it should be Verilog, but again, its wrapper is in VHDL. Is there some trick when you traverse hierarchy of diferent languages? I did try to use signal spy, but it didn't work either. It produced either a static 0 signal or a static z signal, but I may revisit that to see if I was doing things incorrectly...which is quite possible!Article: 125536
On Sat, 27 Oct 2007 00:39:05 -0700, Thomas Stanka <usenet_nospam_valid@stanka-web.de> wrote: >when it comed to adders because nearly every actual fpga provides fast >carry logic which I haven't seen in ASIC so far. Almost all ASIC libraires I've used has a full adder in it which is basically what a fast carry logic is in an FPGA where they have hardwired full adders which don't need to be made from luts and don't need the programmable interconnect. I'ts very easy to accomplish the same in an ASIC.Article: 125537
On Sat, 27 Oct 2007 08:59:30 -0700, motty <mottoblatto@yahoo.com> wrote: >Thanks Jonathan, > >The project is NOT all in Verilog. The EDK uses VHDL wrappers for all >the modules and I am using Xilinx IP cores which are written in VHDL. >The testbench and the system are in Verilog. Underneath that level >are all VHDL wrappers. Some modules inside the wrappers are Verilog >and some are VHDL. I have pointed ModelSim to the unisims_ver library >which contains the Xilinx primitves in Verilog. I am pretty sure the >DCM model would be used from here so it should be Verilog, but again, >its wrapper is in VHDL. I think that's the problem; I don't believe you can read "through" a VHDL wrapper, not even into a Verilog lower-level module. But I could be wrong - it's a while since I played with that sort of thing in ModelSim. >Is there some trick when you traverse hierarchy of diferent >languages? Probably, but it might be worth asking your Mentor AE or distributor... >I did try to use signal spy, but it didn't work either. It produced >either a static 0 signal or a static z signal, but I may revisit that >to see if I was doing things incorrectly...which is quite possible! Again, I don't know enough about SignalSpy to be sure what happens in a mixed-language environment, but I *thought* it could see anything the simulator can see. Probably a case of RTFM carefully (again). Good luck. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 125538
Nevo wrote: > Everyone, > > I really appreciate the input I've received on this thread. Y'all have been > great and have given me a lot to think about. Reading this thread has been a > lot of fun and has been very educational. > > However, I'm not sure that I've adequately desribed the depths of my > ignorance on this subject. I literally have no idea what size capacitors to > use... not even a guess as to the order of magnitude. A few picofarads? A > few hundred microfarads? Really... I'm that clueless. > > If someone could just throw out a number that makes some kind of sense, I'd > appreciate it. > > (I promise I will never go professional in your industry without the > obtaining the requisite formal education first!) If you're working from an on-board LDO linear regulator (Low Drop Out), the regulators often have a stable range of output capacitance and a recommended input capacitance. If you plan on supplying a wall-wart power supply to drive your device, things might get a little ugly in the tolerance of the system over the long wires even with a large bulk capacitor. I'd recommend figuring out what current you need at what voltage(s), design in an appropriate LDO, follow their input/output capacitor suggestions, and stagger the turn-on of your individual channels. By keeping the current *changes* small, the capacitance needed is on the order of a microfarad or less rather than tens or hundreds of microfarads. If you have your LDO designed with an appropriate output capacitance, a dozen 0.1 uF surface-mount caps around the part should be wholly sufficient. The "bulk" capacitance at the LDO - along with the regulator itself - takes care of all the low-frequency current needs and the dozen 0.1 uF caps takes care of any current steps. Take a look at the selected regulator's transient response and you get an appreciation for the number of channels you can turn on at once and have the low-frequency voltage needs met. The desire to stagger the outputs comes down to 1) making sure you don't switch 100% of your optos in a couple microseconds for the LDO's sake and 2) keeping the simultaneous "per-clock" changes small to avoid "ground bounce" problems; this takes care of most of the I/O challenges alone. To help with the nano-second scale I/O switching current surge and to accommodate the rest of the minor on-chip functionality, you need those small, physically distributed caps. Also, since your turn-on and turn-off times don't need to be sub-nanosecond, be sure to specify slow output drive for your I/Os. Specifying 8mA drive in combination with current limiting resistors to your optocouplers will keep each current step from sucking down too much instantaneous current before settling down. Even though it's specified as "8 mA" the outputs will drive much more than that when they're trying to transition and will give you the full current at the specified output voltage level. Your modern FPGA probably has different rails for the I/O and for the core. If your I/Os are all that are driven by the one regulator, the high frequency decoupling could be sloppy and your system wouldn't notice as long as the LDO is happy with its output capacitance. The core voltage is where the transient suppression is more important. If you're working at "slow" speeds of 20 MHz and below, those transients are relaxed compared to much of the modern designs out there and the "dozen 0.1 uF caps" I recommended before is probably more than you need. Increasing the capacitance value is probably not as helpful as having the 12 devices. Even changing the 12 devices to 0.01 uF caps might be fine but they cost the same, so stick with the ubiquitous 0.1 uF chips. Capacitance is only a small part of the overall power scheme. Are you designing a 4-layer board? What device and package are you planning on using? Our days of wire-wrap prototyping are long behind us. If you have a quick PCBoard prototyping service you plan to use that can give you 4-layer boards, the solid ground planes and solid sections of power planes on the inside layers should give you good results with the small scattering of caps. The "dozen caps" would be overkill if you're using a 36-macrocell CPLD but an FPGA with 128 I/O might want the full complement. The dozen value works out reasonably from a layout and convenience standpoint, not because those values are what you absolutely need. Let us know how your project goes. - John_HArticle: 125539
Nagaraj, I would use it as a relative indication. At one time, "gate count" referred to the number of 2-input NAND or NOR functions required. This was (roughly) an ASIC-like measure of complexity. However, FPGA devices have ways of implementing a function which do not "convert" well to ASIC gates, hence, I would not use the "gate count" to estimate what an equivalent ASIC would take, but rather to estimate how to compare one design in the same FPGA arhitecture with another. If you wish to check for ASIC gates, I would synthesize the same VHDL, or verilog, with an ASIC standard cell library in order to find how many "gates" an ASIC version of the same design would really take. AustinArticle: 125540
"Nevo" <nevo_n@hotmail.com> wrote in message news:OpIUi.3557$eD3.257@trnddc03... > > If someone could just throw out a number that makes some kind of sense, > I'd appreciate it. > > (I promise I will never go professional in your industry without the > obtaining the requisite formal education first!) Hi Nevo, One 0402 1uF cap per Vcco pin. Make sure your circuit board has a ground plane. You can't* go wrong! HTH., Syms. * Probably!Article: 125541
On Sat, 27 Oct 2007 15:02:06 GMT, "Nevo" <nevo_n@hotmail.com> wrote: >Everyone, > >I really appreciate the input I've received on this thread. Y'all have been >great and have given me a lot to think about. Reading this thread has been a >lot of fun and has been very educational. > >However, I'm not sure that I've adequately desribed the depths of my >ignorance on this subject. I literally have no idea what size capacitors to >use... not even a guess as to the order of magnitude. A few picofarads? A >few hundred microfarads? Really... I'm that clueless. > >If someone could just throw out a number that makes some kind of sense, I'd >appreciate it. A mixture of capacitor values; even if your design is not clocked very fast, the I/O pins are capable of high speed transitions, so you can't ignore the HF (low value) capacitors altogether, though IMO you'll need a few hundred uF somewhere on the PCB too. Here's the party line from Xilinx... http://www.xilinx.com/products/design_resources/signal_integrity/si_pcbcheck.htm ...which may be more than you need for a hobby project, but what price is a capacitor? I WOULD try to use a ground plane if you can; For this application I wouldn't worry about the "signal integrity" and trace impedance and simulating long traces AT ALL except for the clock signals and configuration signals (where I'd just keep them short)... - BrianArticle: 125542
"John_H" <newsgroup@johnhandwork.com> wrote in message news:%VJUi.450$TO4.287@trnddc07... > If you're working from an on-board LDO linear regulator (Low Drop Out), > the regulators often have a stable range of output capacitance and a > recommended input capacitance. If you plan on supplying a wall-wart power > supply to drive your device, things might get a little ugly in the > tolerance of the system over the long wires even with a large bulk > capacitor. > > I'd recommend figuring out what current you need at what voltage(s), > design in an appropriate LDO, follow their input/output capacitor > suggestions, and stagger the turn-on of your individual channels. > > By keeping the current *changes* small, the capacitance needed is on the > order of a microfarad or less rather than tens or hundreds of microfarads. > If you have your LDO designed with an appropriate output capacitance, a > dozen 0.1 uF surface-mount caps around the part should be wholly > sufficient. The "bulk" capacitance at the LDO - along with the regulator > itself - takes care of all the low-frequency current needs and the dozen > 0.1 uF caps takes care of any current steps. Take a look at the selected > regulator's transient response and you get an appreciation for the number > of channels you can turn on at once and have the low-frequency voltage > needs met. The desire to stagger the outputs comes down to 1) making sure > you don't switch 100% of your optos in a couple microseconds for the LDO's > sake and 2) keeping the simultaneous "per-clock" changes small to avoid > "ground bounce" problems; this takes care of most of the I/O challenges > alone. To help with the nano-second scale I/O switching current surge and > to accommodate the rest of the minor on-chip functionality, you need those > small, physically distributed caps. > > Also, since your turn-on and turn-off times don't need to be > sub-nanosecond, be sure to specify slow output drive for your I/Os. > Specifying 8mA drive in combination with current limiting resistors to > your optocouplers will keep each current step from sucking down too much > instantaneous current before settling down. Even though it's specified as > "8 mA" the outputs will drive much more than that when they're trying to > transition and will give you the full current at the specified output > voltage level. > > Your modern FPGA probably has different rails for the I/O and for the > core. If your I/Os are all that are driven by the one regulator, the high > frequency decoupling could be sloppy and your system wouldn't notice as > long as the LDO is happy with its output capacitance. The core voltage is > where the transient suppression is more important. If you're working at > "slow" speeds of 20 MHz and below, those transients are relaxed compared > to much of the modern designs out there and the "dozen 0.1 uF caps" I > recommended before is probably more than you need. Increasing the > capacitance value is probably not as helpful as having the 12 devices. > Even changing the 12 devices to 0.01 uF caps might be fine but they cost > the same, so stick with the ubiquitous 0.1 uF chips. > > Capacitance is only a small part of the overall power scheme. Are you > designing a 4-layer board? What device and package are you planning on > using? Our days of wire-wrap prototyping are long behind us. If you have > a quick PCBoard prototyping service you plan to use that can give you > 4-layer boards, the solid ground planes and solid sections of power planes > on the inside layers should give you good results with the small > scattering of caps. The "dozen caps" would be overkill if you're using a > 36-macrocell CPLD but an FPGA with 128 I/O might want the full complement. > The dozen value works out reasonably from a layout and convenience > standpoint, not because those values are what you absolutely need. > > Let us know how your project goes. > > - John_H John, Thanks so much for your input. You clearly spent quite a bit of time helping me out, so let me answer as best I can. (I decided to include your post in my reply for reference.) I am indeed working from an onboard LDO regulator. After reading your reply I figured I need, worst case, to drive 160 circuits at 3.3V at 7mA. Hopefully the board will never be called upon to actually do that, but that's the worst case. That's 1.12 amps from the regulator. (0.896 of that would be driven through the FPGA, which we've already established in this thread is a questionable practice at best.) In addition, the 3.3V rail will feed a 1.5V LDO to supply power to the FPGA's logic core. After searching digikey's website for a LDO that could deliver that current at low price, I settled on the LD1085V33 from ST Micro. I've looked through the datasheet and don't see any explicit mention of capacitor values for the input and output, but the sample application circuit shows 10uF on the input and 10uF on the output. So... does this mean the total capacitance of my board (btwn 3V3 and GND), including bypass caps on the chips, should roughly equal 10uF? Figures 22 and 23 in the datasheet show the response of the regulator to load transients, but I'm honestly not quite sure how to interpret the data. I've designed a 4-layer board, with a 3V3 plane and a GND plane. I'm running the 1V5 net to power the core logic on 50mil traces on an outer layer of the board. (Is there any big advantage to putting them on an internal layer?) The FPGA is an Altera Cyclone in the 240QFP package. The highest switching frequency for the core logic will be 4MHz. A 4MHz oscillator drives a 32 bit counter that is reset on each zero crossing. The resulting number is hardware divided by 256 to get 'number of clock cycles per dimming level'. A host computer will send data to drive the channels. The FPGA is essentially a very long serial shift register. The computer clocks in 128 channels * 8 bits/channel of data over a DATA and a CLK line, then loads the data into latches with a STROBE line. (Basically, a really long 74HC595 chip.) I haven't measured the data rate, but I estimate the incoming data is ~1MHz. I'll put a LVDS driver at the host computer and send the signals down CAT5 cable to my board where the FPGA will get it on LVDS input pins. Additional logic compares the output from the channel's 8-bit latch agaist the current 'dimming level' from the counter driven by the 4MHz oscillator, and turns on the output when they match. So... I'll conclude that a 10uF bulk capacitor at the regulator, a 0.1uF cap at each VCCIO pin (total of 12), slow output drive on the FPGA pins, low current drive on the FPGA pins, staggering the turn on time, and a little positive attitude should get me where I want to go. Thanks so much, everyone, for your suggestions on this thread. Let me just say that I'm glad I'm not in some of your shoes, designing multi-hundred-megahertz speed designs!Article: 125543
Nevo wrote: > Each opto will draw a maximum of 7mA. The FPGA will be sinking the current > from the opto, not sourcing current. Why not using an additional driver transistor? Like at page 7 in this datasheet described: http://www.fairchildsemi.com/ds/MO/MOC3051-M.pdf Could be a small SMD transistor, which costs only cents and limits your control current to 0.5mA without problems (but I think in figure 11 of the datasheet a resistor in the base of the transistor would be good) or even a small signal FET, which draws nearly no current. Maybe you should use an additional 0.1uF capacitor from Vcc to GND for each driver to avoid high current peaks for the voltage regulator and using a separate voltage regulator for the drivers can help. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 125544
Nevo wrote: > The FPGA is essentially a very long serial shift register. The computer > clocks in 128 channels * 8 bits/channel of data over a DATA and a CLK line, > then loads the data into latches with a STROBE line. (Basically, a really > long 74HC595 chip.) I haven't measured the data rate, but I estimate the > incoming data is ~1MHz. Why 1MHz? You have 128 channels and 8 bits per channel. You need to update it 60 times per second (in European countries: 50 times per second). This results in a data rate of 61,440 bits per second. I would use RS232 with 115,200 baud, which is more than enough, including some control bytes and checksumming. If it is a long line, use RS485, with converters at the PC side, maybe an electrically isolated RS485 driver. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 125545
I've embedded my comments below in-line. - John_H Nevo wrote: > John, > > Thanks so much for your input. You clearly spent quite a bit of time helping > me out, so let me answer as best I can. (I decided to include your post in > my reply for reference.) > > I am indeed working from an onboard LDO regulator. After reading your reply > I figured I need, worst case, to drive 160 circuits at 3.3V at 7mA. > Hopefully the board will never be called upon to actually do that, but > that's the worst case. That's 1.12 amps from the regulator. (0.896 of that > would be driven through the FPGA, which we've already established in this > thread is a questionable practice at best.) In addition, the 3.3V rail will > feed a 1.5V LDO to supply power to the FPGA's logic core. I don't think the practice is questionable, myself. The I/Os can individually source and sink 25mA easily. The total current is not a problem either given the total current handling capability of the device. If you use external current-limiting resistors for each optoisolator, the voltage drop in the FPGA is small. Driving the cathode is slightly better than the anode for voltage drop but the IBIS model suggests the voltage drop for 7mA is less than 0.1V typical for the LVCMOS33, 8mA, slow slew rate driver. 128 channels of 7mA at 0.1V drop is only 90 mW dissipated in the I/O drivers (assuming I got all my information right this weekend morning). > After searching digikey's website for a LDO that could deliver that current > at low price, I settled on the LD1085V33 from ST Micro. I've looked through > the datasheet and don't see any explicit mention of capacitor values for the > input and output, but the sample application circuit shows 10uF on the input > and 10uF on the output. The output capacitance range for stability for the ST part is shown in graphs in figures 18 and 19 in the datasheet: http://www.st.com/stonline/products/literature/ds/6738/ld1085xx33.pdf You might find a better discussion on the caps in the national data sheet (device also available on digikey, LM1085IT-3.3) http://www.national.com/ds/LM/LM1085.pdf or see more capacitor discussion in the more expensive national part http://www.national.com/ds/LP/LP3853.pdf Personally, I'm a little wary of such a high ESR specified in the ST datasheet for stability but I've been working mostly with switching regulators over the last several years. Beware of "Low ESR" bulk caps since the LDO regulators need a measurable value of ESR. > So... does this mean the total capacitance of my board (btwn 3V3 and GND), > including bypass caps on the chips, should roughly equal 10uF? Forget about total capacitance for the LDO, think only of the bulk value: the tantalum. Going with 12 1uF caps around the FPGA would give you greater than the target 10 uF but your LDO will probably go unstable; unless, perhaps, you have a large input capacitance from ceramic chips per the last national semi device's capacitor discussion. Tantalum caps are probably the way to go, just be sure to use a voltage much larger than you need. The 16V tantalums I used for my 12V circuit with well behaved ramp-up times showered sparks on the first power-up a decade ago. Nice black pit left in the board. Over-rate the tantalum caps by at least 100% on operating voltage. The over-rating isn't required for ceramics. > Figures 22 and 23 in the datasheet show the response of the regulator to > load transients, but I'm honestly not quite sure how to interpret the data. The time it takes the regulator to start turning back the tide of capacitor drain is only a couple microseconds with 10 us or so for full regulation. The sheet shows the behavior for a large transient. If you turned on one channel each 4 MHz clock, you'd have the .896A transitioning-on smoothly over 32 us and the change in the output voltage for that extreme swing would probably be under 25 mV. > I've designed a 4-layer board, with a 3V3 plane and a GND plane. I'm running > the 1V5 net to power the core logic on 50mil traces on an outer layer of the > board. (Is there any big advantage to putting them on an internal layer?) > The FPGA is an Altera Cyclone in the 240QFP package. Unless your power and ground planes are *very* close together, there isn't necessarily a big advantage, but.... You can supply your 3.3V on the bulk of the power plane and have a 1.5V "island" under the QFP that you feed with the single 50-mil trace. I wouldn't recommend only traces to the VCCINT pins. There are 12 VCCIO pins and 12 VCCINT. Please read up on what to do with VCCA if you're not using the PLLs (...those funny Altera parts). Do you need 24 caps? Probably not. You're not handling huge transients of current at high switching frequencies. Tie 8 to the 3.3V plane and 4 to the 1.5V plane for a nice distribution across the four sides (unless you'd like to use 24, of course). Or 4 and 8. Your requirements aren't strong here. Given the sensitivity of LDOs to too much ceramic capacitance, I'd stay away from the 1uF parts even though some engineers like "bigger" if the price is the same. Varied values are also not needed in your case since the 4 MHz switching frequency won't build up nasty harmonics with the limited current steps you produce. In your case, simpler is probably better. Caps soldered at the periphery of the QFP can connect easily to a plane inside the part outline or a plane outside the part outline. > The highest switching frequency for the core logic will be 4MHz. A 4MHz > oscillator drives a 32 bit counter that is reset on each zero crossing. The > resulting number is hardware divided by 256 to get 'number of clock cycles > per dimming level'. A host computer will send data to drive the channels. > The FPGA is essentially a very long serial shift register. The computer > clocks in 128 channels * 8 bits/channel of data over a DATA and a CLK line, > then loads the data into latches with a STROBE line. (Basically, a really > long 74HC595 chip.) I haven't measured the data rate, but I estimate the > incoming data is ~1MHz. I'll put a LVDS driver at the host computer and send > the signals down CAT5 cable to my board where the FPGA will get it on LVDS > input pins. Additional logic compares the output from the channel's 8-bit > latch agaist the current 'dimming level' from the counter driven by the 4MHz > oscillator, and turns on the output when they match. A 32 bit counter at 4 MHz will give you a 1000 second range where you only need 1/120 s, isn't it? You can make your counters any size. Minor note. The Cyclone doesn't have LVDS receivers, does it? LVDS is probably overkill. If you supply a good ground through your cable, you should be able to get by with LVCMOS style signals. Think of the ribbon cables in your computers - they didn't start off with LVDS. If you get LVDS for free or just want to do it, go for it! I love LVDS over cat5, but my data rates are about 500 Mb/s. You could still use cat5 with 1 pair wired for data (both wires, same signal) and one for clock with the other 4 wires supplied for ground. Since you state "LVDS input pins," are you not in the Cyclone-I series of parts? If the receivers are there, the LVDS is free, but make sure the LVDS inputs are compatible with the 3.3V I/O banks. You still want a common ground between the two boards for common-mode reference even if you use LVDS. Note that your dimming may not be linear since your lights are driven by AC voltage. You can communicate a value and just have that value compare against the counter. There are many ways to skin this particular cat, just keep the linearity in mind. > So... I'll conclude that a 10uF bulk capacitor at the regulator, a 0.1uF > cap at each VCCIO pin (total of 12), slow output drive on the FPGA pins, low > current drive on the FPGA pins, staggering the turn on time, and a little > positive attitude should get me where I want to go. VCCIO and VCCINT both need caps. > Thanks so much, everyone, for your suggestions on this thread. Let me just > say that I'm glad I'm not in some of your shoes, designing > multi-hundred-megahertz speed designs! I love these personal projects.Article: 125546
Do yourself a favor and at least design in the capability of populating a snubber. I would also add a hi-feq filter cap at the gate of the TRIAC. Doing these two things will give you recorse to deal with noise at the gate and any transient dv/dt acorss the TRIAC, both which could inadvertantly turn the TRIAC on. And when you're picking components remember that you're dealing with 120V AC. I don't think you mentioned anything about how much load the TRIAC's will be switching. Make sure that you heat sink the TRIAC's, if need be. "Nevo" <nevo_n@hotmail.com> wrote in message news:Z8cUi.8183$0l4.6389@trnddc08... > I'm woefully undereducated to be doing this, but I figure the best way to > learn is by doing, so I need a little help with my current project. > > I'm designing a lighting dimmer around the Altera Cyclone EP1C6 in the 240 > pin package. I will be using the chip to turn on and off up to 128 > optoisolators at a frequency of 120Hz. (The optos will feed the gate pins > of TRIACs which will turn Christmas lights on and off. By turning the > optos on in the middle of an AC half-cycle I plan on getting dimming in > addition to on/off.) > > Each opto will draw a maximum of 7mA. The FPGA will be sinking the > current from the opto, not sourcing current. > > Absolute worst case would be all 128 channels switching simultaneously, > although I doubt that would happen very frequently. (For one, I don't > have enough circuits to drive 128 strings of Christmas lights without > tripping a breaker at the house.) > > I have no clue how to determine what size capacitors to put between the > VCCIO pins and GND. If anyone could give some guidance, I'd appreciate it. > (If you happened to use my particular implementation as an example, I'd > appreciate it that much more!) > > Thanks, all! > > -Matt >Article: 125547
Nevo wrote: > I'm woefully undereducated to be doing this, but I figure the best way to > learn is by doing, so I need a little help with my current project. > > I'm designing a lighting dimmer around the Altera Cyclone EP1C6 in the 240 > pin package. I will be using the chip to turn on and off up to 128 > optoisolators at a frequency of 120Hz. (The optos will feed the gate pins > of TRIACs which will turn Christmas lights on and off. By turning the optos > on in the middle of an AC half-cycle I plan on getting dimming in addition > to on/off.) > > Each opto will draw a maximum of 7mA. The FPGA will be sinking the current > from the opto, not sourcing current. > > Absolute worst case would be all 128 channels switching simultaneously, > although I doubt that would happen very frequently. (For one, I don't have > enough circuits to drive 128 strings of Christmas lights without tripping a > breaker at the house.) > > I have no clue how to determine what size capacitors to put between the > VCCIO pins and GND. If anyone could give some guidance, I'd appreciate it. > (If you happened to use my particular implementation as an example, I'd > appreciate it that much more!) > > Thanks, all! > > -Matt Interesting project. Comments: 120Hz is slow, compared with FPGA, so CAP sizes deal with the edges. ie Your regulator systems need to supply the 120Hz power. Suggestions to stagger the edges are very good - comes for free in the FPGA. 7mA per pin is likely to be OK, from a DC perspective. You also do not need 100% conduction times, and even a 'relatively fat' 10% gate trigger time, will slash the power needs from just under 1A to under 100mA. Some triac systems use burst triggering, so a simple scheme would divide the 128 into 8 or 16 timeslots, and staggered burst trigger. Be wary of the AC Power noise, especially in the dimming mode (in Zero-cross mode, the noise will be magnitudes lower) Also look at the actual wiring deployment, as you may find it easier to do a serial-fanout, than bring all 128 trigger lines into one FPGA. With a serial fanout, you would build a SPI (or similar) chain, and clip together blocks of 8-16 triacs per shifter. Shifters could be LVC595 class devices, or something like a HEF4794 would have speed/noise immunity matched to a mains system. Optos like H11L1 could isolate the serial chain, for improved double-isolation. How complex are your lighting patterns/signatures ? -jgArticle: 125548
Are Asics and FPGA's really that close? The following paper by Kuon and Rose compares a 90nm standard cell asic technology with a 90nm FPGA, and shows that the FPGA takes a 40x density hit (only 20x if include FPGA hard macros), critical path delay 3-4x slower, and dynamic power 12x more. "Measuring the Gap between FPGAs and Asics", Kuon and Rose, Proceedings of the 2006 ACM/SIGDA 14th international symposium on Field programmable gate arrays. Abstract below. They made the comparison by implementing the following design elements. Design, ALUTs, Total Memory, 9x9 Bits Multipliers booth 68 0 0 rs encoder 703 0 0 cordic18 2 105 0 0 cordic8 455 0 0 des area 595 0 0 des perf 2 604 0 0 fir restruct 673 0 0 mac1 1 885 0 0 aes192 1 456 0 0 fir3 84 4 0 diffeq 192 24 0 diffeq2 288 24 0 molecular 8 965 128 0 rs decoder1 706 13 0 rs decoder2 946 9 0 atm 16 544 0 3 204 aes 809 0 32 768 aes inv 943 0 34 176 ethernet 2 122 0 9 216 serialproc 680 0 2 880 fir24 1 235 50 96 pipe5proc 837 8 2 304 raytracer 16 346 171 54 758 Abstract This paper presents experimental measurements of the differences between a 90nm CMOS FPGA and 90nm CMOS Standard Cell ASICs in terms of logic density, circuit speed and power consumption. We are motivated to make these measurements to enable system designers to make better informed choices between these two media and to give insight to FPGA makers on the deficiencies to attack and thereby improve FPGAs. In the paper, we describe the methodology by which the measurements were obtained and we show that, for circuits containing only combinational logic and flipflops, the ratio of silicon area required to implement them in FPGAs and ASICs is on average 40. Modern FPGAs also contain "hard" blocks such as multiplier/accumulators and block memories and we find that these blocks reduce this average area gap significantly to as little as 21. The ratio of critical path delay, from FPGA to ASIC, is roughly 3 to 4, with less influence from block memory and hard multipliers. The dynamic power consumption ratio is approximately 12 times and, with hard blocks, this gap generally becomes smaller. > > This is only true when working in the same feature size. FPGAs tend to be > > on the bleeding edge of process where ASIC starts usually lag behind by at > > least one or two process generations. Generally speaking, a lag of 2 > > generations puts a reasonably carefully executed FPGA design pretty much > > on par with an ASIC design in terms of the speed/power/density. > > > Another factor to consider for FPGAs is that design errors do not restart > > the design cycle clock the way an ASIC error can. > > I'd add that IOs for new FPGAs easily outperform IOs for ASICs at a feature > size that allows a reasonable NRE. For the 0.18 and 0.15 micron ASICs, the > IOs just don't compete with FPGAs! With all the discussion on how ASICs can > perform better than FPGAs, I was lulled into a false sense of adequacy. > Compromising on I/O just sucks. Go Go FPGAs!Article: 125549
Nevo wrote: > I'm woefully undereducated to be doing this, but I figure the best way to > learn is by doing, so I need a little help with my current project. > > I'm designing a lighting dimmer around the Altera Cyclone EP1C6 in the 240 > pin package. I will be using the chip to turn on and off up to 128 > optoisolators at a frequency of 120Hz. (The optos will feed the gate pins > of TRIACs which will turn Christmas lights on and off. By turning the optos > on in the middle of an AC half-cycle I plan on getting dimming in addition > to on/off.) > > Each opto will draw a maximum of 7mA. The FPGA will be sinking the current > from the opto, not sourcing current. > > Absolute worst case would be all 128 channels switching simultaneously, > although I doubt that would happen very frequently. (For one, I don't have > enough circuits to drive 128 strings of Christmas lights without tripping a > breaker at the house.) > > I have no clue how to determine what size capacitors to put between the > VCCIO pins and GND. If anyone could give some guidance, I'd appreciate it. > (If you happened to use my particular implementation as an example, I'd > appreciate it that much more!) > > Thanks, all! > > -Matt > > The size and number of caps depends on some things you haven't yet mentioned. Although the update rate is only 120Hz, what matters is the edge rate at the driver, and the latest devices switch their outputs at ridiculous speeds (it's possible to slow them down in some devices with a constraint). You can get the switching speed information from the IBIS file, incidentally. Another issue is how far the driven devices are. If you have an edge rate of 1nS or faster (not uncommon), then if you have devices further than 1.5 inches away, you have to consider the current in the high speed domain. If you have high speed domain currents, then the initial current on each output pin is, for a rising edge [Ztrack/(Zdriver + Ztrack)]V(transition) / Z (track). For a 3.3V system and a typical track of 60 ohms, that's an initial <=55mA per pin. Even though it doesn't last very long, it will exist. If you can slow things down (or make sure the targets are within a very short distance of the driving pin) you won't have to worry about it. If you do the above, then you still have to take the effective transition rate into account. Let's say each opto switches at ~1usec (fast, but it's just a number here) so we'll have 7mA * 128 = 896mA / usec. Assuming it's 3.3V, then we'll have a dynamic impedance (during switching) of 3.68 ohm at 1MHz. The aim is to keep the power supply impedance very low (less than 1/10 of the dynamic impedance) during switching, so you'll need to decouple with at least (ignoring esr for now): C = 1/(2*pi*f*Xc) = 530 nF total. ESR is important, so as you would want an impedance of <0.3 ohm for the decoupling, you'll need low esr caps (ceramics have an esr low enough to make it negligible in this application). I would do this by dividing the number above by the number of I/O power pins on the FPGA and decoupling each pin with that amount. In addition, you should probably put a bulk decoupler of about 1uF on each bank (if the device, who's datasheet I have not bothered to grab has banked outputs). You could always add a little for margin - the current through an opto is going to vary quite widely depending on device and temperature at least. Put the caps close to the power pins - the outputs at the drivers will still switch pretty quickly, so they should be as close as possible - an inch away is 'does not exist' to an output switching at 1nsec rates. As I noted, it's not necessarily a quick solution, but there's no rocket science to it. Cheers PeteS
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