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
Martin Schoeberl wrote: ... snip >>> Or does the Avalon switch fabric, when registered, take this >>> information into account for the waitrequest of the master? >> It does. > > That's a reason to go with fix wait states! > > Or a bus specification that counts down the number of > wait states ;-) The problem with both is that it would impose undesirable constraints on slaves. Imagine the case of a good SDRAM controller which tracks open pages. Read latency depends on what it's currently doing (idle, refreshing, busy with another request, etc) and whether the access hit on open page. In this case it _could_ perhaps give an early "read-data-in-2-cycles" strobe, but dealing with that would be a nasty complication for the interconnect structure that has to be able to handle any combination of multi-masters and random assortment of slaves. It is feasible for internal protocols, tailor-made for the parts it connects, but IMO not for a generalist interconnect like Avalon. FWIW, I used to do exactly what you suggest (latch and mux), but it didn't scale for me as the interconnection grew and was expensive in both resources and cycle time (not to mention the added complication and opportunity for bugs). Adopting the Avalon style template (which is obvious IMnsHO) freed so many resources (mine and the FPGAs), enabling performance improvements elsewhere. Having spent way too much time and energy on exactly this point, I'd be very interested in others insights. > BTW: Did you take a look into the SimpCon idea? I just did, after writing the above :-), but my point still stands. AFAICT, SimpCon doesn't support multiple outstanding requests from any one master and therefore doesn't distinguish between being able to accept a new request and and being done with a request. I'm sure SimpCon works for you, but for me it would be not much better than Wishbone. > Dreaming a little bit: Would be cool to write an > open-source system generator (like SOPC builder) for > it. Including your suggestion of an open and documented > specification file format. Sure, though I suspect writing all this would be trivial compared to coming to an agreement on how the interface should work :-) >>> Again, one more cycle latency ;-) >> Again, nope not if done correctly. > > I think we finally agreed, did we? I'm not KJ, but I think the issue is clear. Following the template would incur an extra cycle for you (assuming JOP couldn't be fixed in a different way). It definitely possible to do what you suggest and avoid that cycle at the expense of extra overhead and logic (the glitch doesn't matter for internal deployment). TommyArticle: 106426
Hello Flo, > Hi everyone, > I'm trying to deal with readback and scrubbing into a XC2V1500 FPGA. > > I've got a problem identifying the Major Adress and the Minor Adress > when I'm doing a readback. > > Does anyone know how to determine it? This information is available in the virtex-II Useg Guide (ug002.pdf) available on Xilinx's website. Page 314 and following for the current revision (configuration details). Table 4-17 coupled with FAR decoding is what you're looking for. Based on this info I've already written working code for reading and dumping xc2v2000 *bitstreams* (crc computation, luts, brams...). I can release it under the GPL if you can help me to get it to work with readbacks (how far is that from pure bitstreams ?) and the 1500 (small amount of work here). JBArticle: 106427
Antti wrote:
> Todd Fleming schrieb:
>
>> Ralf Hildebrandt wrote:
>>> I strongly guess that the flipflop has normal and inverted output.
>>> Therefore you get the inversion for free (for the cost of these flipflops).
>>> And furthermore it seems to be, that the pure combinational solutions
>>> are slightly to complex to fit into 8 LUTs (the inversion is too much to
>>> fit).
>>>
>>> Ralf
>> I don't see any reference to an inverted output on the flipflops in the
>> Spartan 3 data sheet. From looking at the slice diagram in the DS and
>> the schematic for ADSU8 in the library guide, it looks like the LUTs
>> should be able to absorb the inverter on b.
>>
>> Todd
>
> any signal inversion at LUT inputs are of couse "absorbed" so it
> should no make any difference if signals are inverted or not.
Well not always. In this case, yes it should because only 'b' is
inverted. But if 'a' and 'b' were to be inverted, that couldn't be
pushed into the LUTs because one of the two input has to feed the
carry chain. The only modification that could be done on 'a' is AND
it (with the MULAND (not sure of the name)).
The slice stucture allow pretty tricky/complex stuff to be done in just
1 layer, but I found it's often quite difficult to make xst understand ...
Sylvain
Article: 106428David M. Palmer wrote: > Alternatively, has anybody put together a complete opencores project > for this board with the Wishbone bus, a processor, RAM, Ethernet, and > other things that they could share? There are lots of nice little > pieces in OpenCores, but I don't see good documentation and examples > for putting it all together. I'm working on this. RS232 sender/receiver and DS2432 one-wire ROM id reader is finished: http://www.frank-buss.de/vhdl/spartan3e.html The next big thing will be ethernet and DDR SDRAM support. I'm very new to FPGA and VHDL programming, so any comments would be appreciated, especially if the Wishbone interface is implemented correctly, because I plan to use this interface for my other components, too. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106429
jai.dhar@gmail.com wrote: ... > Actually, I forgot to clarify one aspect. The FPGA is itself generating > the 2.048M clock (divided from a 8M192) as well as a framing pulse. > That's easy enough to do of course... does this add any complications > if the FPGA is generating the pulses? I would think it makes it > easier... I am no expert, but my guess is that if you are generating one clock from the other, things are much easier. And the 1/25 ratio gives you more than enough time to adjust the setup/hold times if you have problems with those. On the other hand, if you had two independent clocks, the clock error & jitter might have forced you to use an asynchronous FIFO. -BurnsArticle: 106430
"Nevo" <nevo_n@hotmail.com> wrote: >I've reviewed the docs briefly but didn't find this information. They specify a maximum current of 24mA sink/source per pin. For 96 pins, this would add up to 2.3 A. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106431
Nico Coesel wrote: > "Nevo" <nevo_n@hotmail.com> wrote: > > >I've reviewed the docs briefly but didn't find this information. > > They specify a maximum current of 24mA sink/source per pin. For 96 > pins, this would add up to 2.3 A. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl For the OP question, assuming 3.3V I/O power and a typical forward voltage on the LED of 2V, then the total current into the device is about 320mA (3.33mA per pin) which should be fine. Note that LED forward voltage varies quite a lot - at low currents it may be as low as 1.5V (for some devices). That would add about 50% to the total, to ~450mA total. Without knowing the exact device it's hard to be really specific. I second the comment about incomplete specs - in this particular case, I don't think the OP has anything to worry about though. Cheers PeteSArticle: 106432
rickman wrote: > Jim Granville wrote: > > anything better than RC, has starting time issues, so usually runs > > all the time, and that has power penalties. > > RC is not even an oscillator without other componets so it really is > not a solution. I can get an oscillator that runs on 1 mA of current, > costs under $0.50 and has plenty of accuracy to do any of the above > protocols. So async serial is ok. One in and one out. > > > > I don't see one wire as being any simpler than a UART. One wire is > > > just bit async rather than byte async. You still need a timer to time > > > the bits. > > > > build them both, and count the macrocells :) > > > > UARTs need (commonly) /16 resettable counter on RX, and a /16 non > > resetable counter on TX, plus the byte buffers in both directions. > > > > So that's at least 8 macrocells running higher than the bit-rate, > > plus appx 4 more do do the framing, vs 3-4 for PWM bus. > > A PWM bit level signal still has to do all the higher level stuff of > counting the bits in a word etc. So if there is an savings, it would > be very little. > > > PWM Osc is gated-monostable type at 4x bit rate - so power is lower. > > A 3 bit Gray counter handles RxSample, TxWindow, and Sync detect > > > > Simulating all this is not that easy, on today's tools, which are > > designed for a master-clock approach. > > > > > > CPLDs have no problems with speed, but the host speed may be a stumbling > > block. Philips talked about 3.4MHz i2c, but nothing seems to have hit > > the streets. I see they now have a FM+ spec, which is high drive i2c, > > at 1MBd, also well within CPLD's reach. > > The host would be another CPLD. The "host" has to take in two SPI > running near 100 kHz and four discrete signals. I have no info on how > the SPI data is framed. I2C is done in bytes, but my understanding is > that SPI has no defined protocol, it really is a non-standard standard. > I will have to get more info on how the SPI busses are being used > before I can decide if this will even work. > > > > > SPI would work too, but would use all four pins leaving us no spares. > > > > SPI can work with 3 wires, if that helps. > > I could put an address on the SPI bus like I2C does it. I can't recall > at the moment why I felt it would need a fourth pin. I think because > of flagging which of the two SPI ports was running at that moment. But > that can be encoded in the data stream so I guess it could leave a pin > free. > > > > > A UART interface could use two wires, one for transmit and one for receive. > > > > > The word > > > size can be application specific with dedicated bits for discrete > > > signals. Most importantly, I think it will be the smallest in a CPLD. > > > > How many IO's do you need, on how many addresses ? > > I don't understand. Do you mean the discrete signals? > > > Do they need dataDirection register control, and read-back, or > > are simpler fixed OUT and IN acceptable ? > > No, just four outputs. They are triggers with timing information, but > I don't know how precise they need to be. > > > 64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts. > > You did not account for the two SPI ports that are being multiplexed. > Without more info on the protocol on the SPI ports, I can't count FFs. > But each one will need a buffer since the link will have to run much > faster than either of the two SPI ports. Also I don't even know if > this will work since SPI is full duplex, IIRC. As you shift out data > read data is coming back, right? Or is it still half duplex with the > read data and write data never happening at the same time? I would not > be able to buffer words and do full duplex. That sounds incompatible > to me. SPI is a spec in search of itself. There are some variants to it. For a decent overview of the different types, you could look at the interface specs on this device I use http://products.zarlink.com/product_profiles/ZL38001.htm (Look at the microport section). One of the issues I ran into on the original Motorola implementation was that the last data bit (lsb) was only valid for half a bit time - so I had to generate a quadrature clock. (That was in the early 90s). As you are doing it for yourself, you have no such limitation. SPI can run at up to 4Mb/s on commercial parts, and I see no reason a CPLD could not handle that. Cheers PeteSArticle: 106433
Jim Granville wrote: > rickman wrote: > > > Jim Granville wrote: > > > >>anything better than RC, has starting time issues, so usually runs > >>all the time, and that has power penalties. > > > > > > RC is not even an oscillator without other componets so it really is > > not a solution. I can get an oscillator that runs on 1 mA of current, > > costs under $0.50 and has plenty of accuracy to do any of the above > > protocols. So async serial is ok. One in and one out. > > RC osc would use the CPLD - not sure what 'other components' you mean. > > If you are happy with 1mA and 50c, then that's fine. > > I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc, > at a cost of a few cents. ( and appx 50uA at 1MHz ) How do you get a CPLD to reliably oscillate with an RC? > Again, it depends on your yardstick. When you are working with 32 > Macrocell CPLDs, as I do often, a saving of 8 macrocells can be > very important. I agree, but I am not sure there is any savings. Both methods have to do the same work in framing bits and words so I don't see where the savings would come in. That would require a more detailed analysis or design. I suppose the one wire protocol might be able to have more commonality between the rx and tx, but a half duplex uart could likely do the same thing. There are other considerations. If I can clearly show that a one-wire approach would work and fit the part while a uart design would not, that would be clear evidence. But I am currently working (the emphasis on *currently*) in a very political environment where being right is no guarantee of being "right". If a more "trusted" designer decided that he was uncomfortable with the one-wire approach it would be gone regardless of the facts. > <snip> > >>64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts. > > > > > > You did not account for the two SPI ports that are being multiplexed. > > Without more info on the protocol on the SPI ports, I can't count FFs. > > I thought this was a multi-slave plus master problem - you seem to be > talking only about the master above - what are the slaves ? I think I explained what I was building, but it may be scattered over several different posts. The "thing" I am trying to figure out is in essense a multiplexer and demultiplexer of several signals. There are two interfaces that need to be brought out through a cable. The connector is virtually out of pins and we don't want to make it larger. Each interface has an SPI port with a CE since it drives multiple slaves running at lowish rates. The interface also has two discrete signals which are mostly for timing of control. The SPI port is used to send setup commands and the discrete signals say "do it now". We have added four pins to the connector before remembering that the interface for each was a total of 6 pins and that we actually needed two ports. Is it unlikely that we can add a total of 12 pins to the connnector. So we need a mux. The SPI ports can not be multiplexed together in the simple way since they have separate masters that are not synchronized. So to multiplex this will require capturing the data from both ports and muxing it at a higher speed along with the discrete signals. I am limited by not knowing the format of the data on the SPI busses. It just occured to me that I really don't need to know the format of the data if I just treat the signals as arbitrary data streams. I can sample them at high enough rates that the timing information is not significantly distorted and send them across in a very, very simple scheme. I can sample each one in a round-robin manner at say 1 MHz for a total clock rate of 10 MHz (10 signals in one direction, 2 in the other). This interface would need a clock, datain, dataout and frame sync. That will fill the four pins, but would also be flexible enough that other discrete signals could be added with a small increase in frequency. One BIG advantage to doing it this way is that the latency is no more than 2 clock cycles or 0.2 uS. I am also very confident that it could be done in a 32 cell CPLD. The slave would be clocked by the interface, so it does not need a crystal or other timing device. The master can be a bit more complex since it is inside the unit, but likely a ~10 MHz clock can be provided. The only remaining issue is finding a CPLD that is low power and can be made tolerant of the external signals. I would hate to have to buffer all 16 signals in the cable. > SPI works like the simplest 8 bit shift registers, so it is duplex > capable. > > Most SPI memories, work in half-duplex - they read the address info, > while floating SerialOUT, and then ignore SerialIN, while > driving serial out (if doing a read). > > If you have to slave to two separate SPI streams, that you have little > control over, that could get complex very quickly. Yes, that is the part that has me concerned. But by explaining it to you, I think I have figured out the best way to approach this. We'll see if I can get the multiplexer to fit in terms of power and any other constraints that pop up later. Thanks for listening and offering your advice.Article: 106434
"Nevo" <nevo_n@hotmail.com> wrote in message news:uOvDg.5670$zc2.3643@trnddc06... > I've reviewed the docs briefly but didn't find this information. > > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were > to use all the available I/O pins to drive LEDs (that's 104 of them), and > do something silly like turn 'em all on at once, will I exceed the maximum > current draw of the chip and let out the magic smoke? > > The eight red LED's on the board are driven directly from the I/O pins > through 390 ohm resistors. > > I am planning on attaching a green LED to each of the 96 I/O pins exposed > on the connectors through 390 ohm resistors. > > Thx, > > -Nevo > That's a really naff way of driving LED's. Instead drive them from the FPGA IO configured as open collector (ie tristate with the tristate buffer input connected to ground, and the tristate control as your input. Then connect the LED to the IO, supplying the other end of the LED via a resistor to your supply. That way you considerably reduce the FPGA power dissipation to that of the saturated output drivers - the bulk of the power being dissipated in the external resistors. SlurpArticle: 106435
rickman wrote:
>
> I had not given the question much thought when I posed it and I see now
> that all the "self clocking" schemes are framed in some rate and the
> clock is recovered given a reference.
>
If you can use one of the small CPLD/FPGA parts with a DLL/PLL
(e.g. MachXO) at the far end, you should be able to press the {D|P}LL
into service for clock recovery using a specially constructed waveform.
There was thread last year about sending bidirectional data over a
SATA cable without needing a CDR at the far end where I suggested
a clock phase modulation scheme:
http://groups.google.com/group/comp.arch.fpga/msg/42d1840c981c64e6
- send a clock with fixed rising edges and +/-90 degree
phase modulation of the falling edges
- divide by two to strip the phase modulation -> clean ref. clk
- double then phase shift for a mid-period sample clock
If the {D|P}LL phase detector & ctl logic only uses leading edges,
and doesn't mind the wild duty cycle swings, you could skip the
divide-by-2 and double steps.
I haven't tried that out yet, but I don't see any fundamental problems
with it ( other than wasting BW vs. other modulation schemes. )
Brian
Article: 106436Hi, I have installed Xilinx webpack and modelsim in my computer. I find it is rather perhaps because of the memory not large enough. The webpack still searches for modelsim for simulation even I uninstalled it (modelsim). I even tried uninstalled webpack and reinstalled it. It still looks for modelsim (of course, I have set the option back in the dialog box of simulator). Could you tell me how to correct this ? Thank you very much.Article: 106437
fl wrote: > Hi, > I have installed Xilinx webpack and modelsim in my computer. I find it > is rather perhaps because of the memory not large enough. The webpack > still searches for modelsim for simulation even I uninstalled it > (modelsim). I even tried uninstalled webpack and reinstalled it. It > still looks for modelsim (of course, I have set the option back in the > dialog box of simulator). > Could you tell me how to correct this ? > > > Thank you very much. Sorry, the version of webpack is 8.2 and modelsim is 6.2 XE.Article: 106438
"Slurp" <slip@slap.slop> wrote: > >"Nevo" <nevo_n@hotmail.com> wrote in message >news:uOvDg.5670$zc2.3643@trnddc06... >> I've reviewed the docs briefly but didn't find this information. >> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were >> to use all the available I/O pins to drive LEDs (that's 104 of them), and >> do something silly like turn 'em all on at once, will I exceed the maximum >> current draw of the chip and let out the magic smoke? >> >> The eight red LED's on the board are driven directly from the I/O pins >> through 390 ohm resistors. >> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed >> on the connectors through 390 ohm resistors. >> >> Thx, >> >> -Nevo >> > >That's a really naff way of driving LED's. > >Instead drive them from the FPGA IO configured as open collector (ie >tristate with the tristate buffer input connected to ground, and the >tristate control as your input. Then connect the LED to the IO, supplying >the other end of the LED via a resistor to your supply. > >That way you considerably reduce the FPGA power dissipation to that of the >saturated output drivers - the bulk of the power being dissipated in the >external resistors. Xilinx FPGAs (like almost all digital CMOS devices) have complementary push/pull output stages. It doesn't matter whether you sink or source current, the output stage will be saturated in either case unless the programmed output current is exceeded. If an FPGA is used, I think it is easy to connect the LEDs in a matrix and deploy a nifty multiplexing scheme. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106439
Brian Davis wrote:
> rickman wrote:
> >
> > I had not given the question much thought when I posed it and I see now
> > that all the "self clocking" schemes are framed in some rate and the
> > clock is recovered given a reference.
> >
> If you can use one of the small CPLD/FPGA parts with a DLL/PLL
> (e.g. MachXO) at the far end, you should be able to press the {D|P}LL
> into service for clock recovery using a specially constructed waveform.
>
> There was thread last year about sending bidirectional data over a
> SATA cable without needing a CDR at the far end where I suggested
> a clock phase modulation scheme:
>
> http://groups.google.com/group/comp.arch.fpga/msg/42d1840c981c64e6
>
> - send a clock with fixed rising edges and +/-90 degree
> phase modulation of the falling edges
>
> - divide by two to strip the phase modulation -> clean ref. clk
>
> - double then phase shift for a mid-period sample clock
>
> If the {D|P}LL phase detector & ctl logic only uses leading edges,
> and doesn't mind the wild duty cycle swings, you could skip the
> divide-by-2 and double steps.
>
> I haven't tried that out yet, but I don't see any fundamental problems
> with it ( other than wasting BW vs. other modulation schemes. )
Thanks for the ideas. I was not aware of the MACHXO parts. They are
suprizingly dense and cheap. Web pricing at Atmel for the 256 LUT part
is around $5 in moderate quantities.
I assume I would need a 2x clock to generate the 90 degree skewing of
the trailing edge or even a 4x clock if I don't want to play tricks
with using opposite phases clocking FFs.
This could work and would only use two pins, one in each direction.
But the device itself would be pushing the boundary of what I would
like to use. The smallest part is 256 LUTs and the smallest package is
a 100 pin Chip Scale BGA at 8x8 mm. There is one universal truth in
FPGAs and CPLDs; if you have a lot of IO, you will have a lot of logic
and if you have a lot of logic you will have a lot of IO. They don't
put large deivces in low pin count packages, ever!
The power consumption of the MACHXO is a bit high. I don't have an
exact number, but the standby current starts at 14 mA. But this is not
out of the ballpark and I will keep the idea in mind since it can use
half the pins of the other approach I have in mind.
Article: 106440Hi all, I am reading OVL example (http://www.eda.org/ovl/pages/main_examples.html) and confused with 4 arbitration schemes: Fixed priority; Round Robin: simple, look-ahead-1,look-ahead-16? Is there any book or reference talk about arbiter schemes? Thanks! DavyArticle: 106441
Nico Coesel wrote: > "Slurp" <slip@slap.slop> wrote: > > > > >"Nevo" <nevo_n@hotmail.com> wrote in message > >news:uOvDg.5670$zc2.3643@trnddc06... > >> I've reviewed the docs briefly but didn't find this information. > >> > >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were > >> to use all the available I/O pins to drive LEDs (that's 104 of them), and > >> do something silly like turn 'em all on at once, will I exceed the maximum > >> current draw of the chip and let out the magic smoke? > >> > >> The eight red LED's on the board are driven directly from the I/O pins > >> through 390 ohm resistors. > >> > >> I am planning on attaching a green LED to each of the 96 I/O pins exposed > >> on the connectors through 390 ohm resistors. > >> > >> Thx, > >> > >> -Nevo > >> > > > >That's a really naff way of driving LED's. > > > >Instead drive them from the FPGA IO configured as open collector (ie > >tristate with the tristate buffer input connected to ground, and the > >tristate control as your input. Then connect the LED to the IO, supplying > >the other end of the LED via a resistor to your supply. > > > >That way you considerably reduce the FPGA power dissipation to that of the > >saturated output drivers - the bulk of the power being dissipated in the > >external resistors. > > Xilinx FPGAs (like almost all digital CMOS devices) have complementary > push/pull output stages. It doesn't matter whether you sink or source > current, the output stage will be saturated in either case unless the > programmed output current is exceeded. > > If an FPGA is used, I think it is easy to connect the LEDs in a matrix > and deploy a nifty multiplexing scheme. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl The OP is driving the LEDs with about 2.5 - 3.3 mA. That's not very bright in the first place, so any multiplexing scheme would need to change the resistors. That said, doing it by multiplexing (driving with about 15mA pulses for example) would minimize multi-pin currents. Cheers PeteSArticle: 106442
Nevo wrote: > I've reviewed the docs briefly but didn't find this information. > > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to > use all the available I/O pins to drive LEDs (that's 104 of them), and do > something silly like turn 'em all on at once, will I exceed the maximum > current draw of the chip and let out the magic smoke? > > The eight red LED's on the board are driven directly from the I/O pins > through 390 ohm resistors. > > I am planning on attaching a green LED to each of the 96 I/O pins exposed on > the connectors through 390 ohm resistors. LEDs do not need 20mA, in most cases, 1mA is clearly visible. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 106443
"PeteS" <PeterSmith1954@googlemail.com> wrote: >Nico Coesel wrote: >> "Slurp" <slip@slap.slop> wrote: >> >> > >> >"Nevo" <nevo_n@hotmail.com> wrote in message >> >news:uOvDg.5670$zc2.3643@trnddc06... >> >> I've reviewed the docs briefly but didn't find this information. >> >> >> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were >> >> to use all the available I/O pins to drive LEDs (that's 104 of them), and >> >> do something silly like turn 'em all on at once, will I exceed the maximum >> >> current draw of the chip and let out the magic smoke? >> >> >> >> The eight red LED's on the board are driven directly from the I/O pins >> >> through 390 ohm resistors. >> >> >> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed >> >> on the connectors through 390 ohm resistors. >> >> >> >> Thx, >> >> >> >> -Nevo >> >> >> > >> >That's a really naff way of driving LED's. >> > >> >Instead drive them from the FPGA IO configured as open collector (ie >> >tristate with the tristate buffer input connected to ground, and the >> >tristate control as your input. Then connect the LED to the IO, supplying >> >the other end of the LED via a resistor to your supply. >> > >> >That way you considerably reduce the FPGA power dissipation to that of the >> >saturated output drivers - the bulk of the power being dissipated in the >> >external resistors. >> >> Xilinx FPGAs (like almost all digital CMOS devices) have complementary >> push/pull output stages. It doesn't matter whether you sink or source >> current, the output stage will be saturated in either case unless the >> programmed output current is exceeded. >> >> If an FPGA is used, I think it is easy to connect the LEDs in a matrix >> and deploy a nifty multiplexing scheme. >> >> -- >> Reply to nico@nctdevpuntnl (punt=.) >> Bedrijven en winkels vindt U op www.adresboekje.nl > >The OP is driving the LEDs with about 2.5 - 3.3 mA. That's not very >bright in the first place, so any multiplexing scheme would need to >change the resistors. > >That said, doing it by multiplexing (driving with about 15mA pulses for >example) would minimize multi-pin currents. With multiplexing, the OP could do without resistor and use DCI or current limiting in the FPGA. Saves a whole bunch of resistor. DCI would be nice because the current can be adjusted by an 1 resistor (or potmeter). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106444
It seems like everybody agrees that this is not a problem. But there remains the complaint about "missing specs". Obviously, a dedicated LED driver should specify the current per pin, and also total. That device has little else to spec. An FPGA has already thousands of other, more important specifications. So we do not specify max current per pin. There are two limitations: power and metal migration. For a given current, the power depends on the voltage drop, and it depends on the strength of the output, and that is programmable. This would make the spec very complicated. Moreover, power per individual pin is not so important, since silicon is such a good thermal conductor. The other constraint is metal migration, which has become better since we now use Cu instead of Al in the metallization. 40 mA is tolerable "forever". The real limitation is the junction temperature, which depends on total device power consumption in conjunction with the thermal resistance. And we specify this exhaustively. In short: Don't worry about the current (if it is below 40 mA per pin continuously). Instead, worry about the junction temperature. And Xilinx gives you lots of data to figure that out. Peter Alfke, Xilinx Applications (from home) ===================== Rene Tschaggelar wrote: > Nevo wrote: > > > I've reviewed the docs briefly but didn't find this information. > > > > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to > > use all the available I/O pins to drive LEDs (that's 104 of them), and do > > something silly like turn 'em all on at once, will I exceed the maximum > > current draw of the chip and let out the magic smoke? > > > > The eight red LED's on the board are driven directly from the I/O pins > > through 390 ohm resistors. > > > > I am planning on attaching a green LED to each of the 96 I/O pins exposed on > > the connectors through 390 ohm resistors. > > LEDs do not need 20mA, in most cases, 1mA is > clearly visible. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.netArticle: 106445
Nevo, Answers in line, below, Austin Nevo wrote: > I've reviewed the docs briefly but didn't find this information. > > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to > use all the available I/O pins to drive LEDs (that's 104 of them), and do > something silly like turn 'em all on at once, will I exceed the maximum > current draw of the chip and let out the magic smoke? Two specifications here you must observe: absolute maximum junction temperature, and IO pin absolute maximum voltages. For what you describe, this being a transient, firstly, the IOs remain tristate until your design has control over them, so as long as YOU do not turn them all on at once, your question is even simpler to answer: nothing happens. No problem. If you do turn them all on at once, then you would have to leave them ON until the junction temperature went nuts (assuming you had no heatsink or airflow, and your power supply had the current). That is the ONLY way to damage the device from what you have so far described. > The eight red LED's on the board are driven directly from the I/O pins > through 390 ohm resistors. OK. What strenth setting are you placing on the IO driver? If the strength chosen is something like LVCMOS 24 mA, then the IR drop on the driver is very small, and there is practically no power developed in the device, and you really have nothing to worry about. But, if you chose the weakest driver, then the driver dissipates power, and the device will get hotter. As long as you stay below the abs max temp, no damage. I would choose the weakest and slowest driver, just for the signal integrity issues, but I would watch that the internal power stayed within my overall package power dissipation budget. > I am planning on attaching a green LED to each of the 96 I/O pins exposed on > the connectors through 390 ohm resistors. And this is important, why? Seems to me how they are wired has nothing to do with your question. My personal preference are those blue leds, they are much sexier than red, yellow, or green. The IOB is incredibly robust: after all the PCI and GTP+ IO standards specify currents of 45 mA to 70 mA being there forever, so we had to design it to take that. The number Peter mentions of 10 mA is when you force the pin to go below ground, or above Vcco, as then you are forward biasing the IO device diodes, either pumping electrons into the substrate, or pushing them into the Vcco rail. 10 mA is there as a guideline. We certainly still need to observe the abs max specs, even then, for device temperature, and pin and supply voltages. Perhaps the specification is too simple, as we allow you to do many bizarre things (which may not be very useful, but they will not cause any damage, or reduce the device lifetime). Perhaps you are not usd to FPGA design, where you have to have many choices, and are in complete control? Our specification is written to allow you to do whatever it is you desire. In fact, the more specifications we add to the data sheet, the less useful the device is, and the more business we potentially lose. A case where more is not better, and less is ideal. In fact, even less abs max would be even better (we only place a specification there when we know it will affect reliability). After all, we are a FPGA, and you decide what it will do, not us. As long as it works, and is within the abs max specs, it won't hurt the device.Article: 106446
Borry, Not enough information in your posting. Is this one device? Out of how many? If this is one of only one devices, maybe it was destroyed by an ESD zap? Perhaps it sustained damage when the power supplies were applied incorrectly? Resistance of a power rail is useless. At what voltage? How measured? Better to know is what is not working. You mentioned the DCMs, how is the output not correct? If a "bad" DCM sometimes works, then how can this be the device is bad? Have you checked you input clocks for jitter and if they are within the ranges specified for the DCM? I would submit a webcase, online, with every single detail, if you wish to get an answer. Austin Borry.Wang@gmail.com wrote: > One chip of Virtex 4,SX35F668,is used in my PCB board,When the board is > first assembled,the FPGA could performance very well,but about a month > later,the FPGA could not work correctly even download with the same > bitstream file once worked OK. I check the operate current of the total > board,the current is about 0.5A lower than normal(5V input > voltage),After the review every detail parameters of each ICs on the > board,the static resistor of 2.5V is much higher than > before(approximate 800ohm now but approximate 10ohm before),the 2.5V > is only provided to FPGA`s Vccaux and two banks`s Vcco.because the > Vccaux is provided to DCM,so I write a Program to test the 8 DCMs in > Virtex 4 SX35,the test result is that:every time I turn on the power > and load the same bitstream file to FPGA through JTAG,the output of the > 8 DCMs is not the same!Sometimes,2 or 3 DCMs`s output is not > correct,and the DCM lock signal keep low,the worst condition is 5 of 8 > DCMs`s output is not correct, and the correct DCM and incorrect DCM is > not fixed during each time. > > could anyone give me some advice to solve the problem? >Article: 106447
Hi, I have some problems with async clocked FIFOs in Altera Cyclone-II. When simulating the design I receive data out from the FIFO after one clock pulse, but the timings diagram from the FIFO code generator indicates that I need to wait 3 clock cycles AND have the READ active during these 3 clock cycles! From what I understand the simulation model coudl be wrong or the timings diagram is wrong. What is correct in this, anyone been using these FIFOs and knows something about this? /michaelArticle: 106448
I have been working on a design that uses BRAMs to implement a register file using the Windows version of the Xilinx Webpack. Recently, I have moved to a Linux based laptop to continue working on this project and have setup the RedHat version without much trouble. However, the same code I use for the register file synthesizes as distributed RAM under the RedHat version instead of BRAMs. I have been able to force it to use BRAMs using the synthesis settings, but I would like to know if there is something else I can do to have the tool infer it as a BRAM without having to make this change, since I will be adding components to my design soon that will have to be mapped to distributed RAM. Any ideas or am I stuck? Thanks, JeremyArticle: 106449
rickman wrote: > Jim Granville wrote: > >>rickman wrote: >> >> >>>Jim Granville wrote: >>> >>> >>>>anything better than RC, has starting time issues, so usually runs >>>>all the time, and that has power penalties. >>> >>> >>>RC is not even an oscillator without other componets so it really is >>>not a solution. I can get an oscillator that runs on 1 mA of current, >>>costs under $0.50 and has plenty of accuracy to do any of the above >>>protocols. So async serial is ok. One in and one out. >> >>RC osc would use the CPLD - not sure what 'other components' you mean. >> >>If you are happy with 1mA and 50c, then that's fine. >> >>I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc, >>at a cost of a few cents. ( and appx 50uA at 1MHz ) > > > How do you get a CPLD to reliably oscillate with an RC? Choose one with Schmitt pin options (also important if you want to try i2c, where the slow edges will mess with non-schmitt CPLDs ). That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices. You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins, the better the precision, and less it depends on the thresholds. The numbers I gave are for ATF1502BE. -jg
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