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
AugustoEinsfeldt <aee@terra.com.br> wrote: > After some search on this group, at the internet and at Xilinx web > site I have not found a conclusive set of informations regarding the > behavior of a Spartan-3's input pin in a high voltage signaling. > The circuit would use a 27Kohm series resistor to sense the presence > of a 24V signal. It is a very slow signal and the series limiting > resistor would use the ESD clamp diodes to keep the input voltage > below the gate oxide limits. The 27K values was chosen to have the > zero state input with maximum leakage current for this device (25uA). > I understand the 10mA limit on the clamp diodes (100mA max for this > device) would not be stressed with the near 1mA current flow but I > wonder if this situation could somehow reduce the part's MTBF and in > which amount. > I'd like to avoid using an external diode to VCCO (or a zener also > because it's knee) since any other part in the system will reduce the > overall MTBF. > In case it is important there will be 56 inputs in this condition in a > TQ144 package. Reconsider using some external buffer, with 5 Volt tolerant inputs. Those buffers have Z-Diodes to limit the voltage and will direct the current to ground. And in case anything goes wrong, it's much easier to resolder the buffer then to resolder the FPGA. If you use Schmitt Trigger Buffer, things will be saver anyways. Been there, done that. 24 Volt supply next to some logic line on a bus. Probe on the logic output. Some wrong move and: Bang: All CPLDs in the cards have that line fried by the 24 Volt applied accidently. And what's worse, the charge of PCB boards has thermal copper delamination when resoldered. Argh. By the way, does anybody know of a 5-Volt tolerant Schmitt Trigger Buffer with many inputs. The best I could find are the 2-Gate 74LVC2G14 and 74LVC2G17. Even normal Schmitt-Trigger Multigates are not to find -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 121351
In article <uzm2elyy1.fsf@trw.com> you wrote: >Matthieu <m.a.t.t.h.i.e.u.m.i.c.h.o.n@laposte.net> writes: >> However ISE will run faster with CPUs featuring 4 MB L2 cache, such as >> th mid/high-end Intel Core2 Duo CPUs (if I recall correctly models >> E6320, E6420, E6600 and higher). >To give you a single data point, my MAP/PAR time reduced by about >20% when i went from a 2MB Core2Duo (E6400?) to 4MB (E6600) at the same clock >speed (2.4GHz). >BTW, going to the 2MB Core2Duo from my previous 3GHz P4 halved the time! Unfortunly the Intel Core2Duo seems to have both security & integrity problems: http://www.buildyourown.org.uk/forums/topic.asp?topic_ID=25527 marc.info/index.html?l=openbsd-misc&m=118296441702631 When loading data from L1 cache it will occasionally have stale data. Any tip on a AMD cpu that will perform?Article: 121352
>Another caution for this situation - is to watch the IccIO of the FPGA >does not fall below ~56mA - if it does, you will need a SINKING >regulator, to avoid the supply rails being pulled up - IF the VccIO >pulls high, that WILL do serious things to your MTBF! :) I recall doing evil things to an Nokia 80286 machine. Shorting 5V & 12V while running did nothing. But shorting 5V to 12V killed the keyboard controller such that it failed to reboot ;)Article: 121353
AugustoEinsfeldt <aee@terra.com.br> wrote: >After some search on this group, at the internet and at Xilinx web >site I have not found a conclusive set of informations regarding the >behavior of a Spartan-3's input pin in a high voltage signaling. >The circuit would use a 27Kohm series resistor to sense the presence >of a 24V signal. It is a very slow signal and the series limiting How slow signal?Article: 121354
Uwe Bonnes wrote: > By the way, does anybody know of a 5-Volt tolerant Schmitt Trigger Buffer > with many inputs. The best I could find are the 2-Gate 74LVC2G14 and > 74LVC2G17. Even normal Schmitt-Trigger Multigates are not to find The LVC14 is 6, in SO14 and smaller DFN14 etc, but they are inverting. Then there are HC7014/HC7541 for Hex/Oct Non Inv, and HC9115, for 9 way NonInv Or devices like the Philips LVC244 (and LVC2244) have Schmitt IPs, and will do 5V IP with lower Vcc. -jgArticle: 121355
Yes, we use the PX1011A in some of our development boards. John Adair Enterpoint Ltd. www.enterpoint.co.uk On 3 Jul, 09:16, Francesco <francesco_poder...@yahoo.com> wrote: > Hi All, > does anybody has any experience with the Xilinx <-> Philips PX1011A > solutions? > > Thanks in advance, > FrancescoArticle: 121356
Jim Granville <no.spam@designtools.maps.co.nz> wrote: > Uwe Bonnes wrote: > > By the way, does anybody know of a 5-Volt tolerant Schmitt Trigger Buffer > > with many inputs. The best I could find are the 2-Gate 74LVC2G14 and > > 74LVC2G17. Even normal Schmitt-Trigger Multigates are not to find > The LVC14 is 6, in SO14 and smaller DFN14 etc, but they are inverting. > Then there are HC7014/HC7541 for Hex/Oct Non Inv, and HC9115, for 9 way > NonInv > Or devices like the Philips LVC244 (and LVC2244) have Schmitt IPs, and > will do 5V IP with lower Vcc. I did the mistake to only look at the TI SN74LVC244A. It neither states "hysteresis" nor "Schmitt trigger". Their Logic selction guide also only mentions "Schmitt Trigger" for the 14/17 and some similar device. The NXP datasheet mentions "Schmitt trigger" but doesn't specify a hysteresis. But at least it mentions the Schmitt trigger. At about 0.38 E for single pieces of th NXP 244A, the original poster should consider ... Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 121357
My socket seems not to be in the documentation. It looks a bit like those sockets of harddisk cables expect there are just 2 rows of 8. Is this jtag? Where is vdd/gnd/tdi/tdo/tck/tms Which document ?Article: 121358
On 2 Jul, 17:39, Jeff Cunningham <j...@sover.net> wrote: > ZHI wrote: > > I want to know if i only need 16bits for the output, how to do it. > > thanks. > > You are dealing with binary fractions, not integers, right? That is, > numbers between 0 and 1 (or -1 to 1)? In your case, just take the > leftmost 16 bits of the 20 bit result. > > -Jeff No, i am dealing with integers and binary fractions. I cannot only take the leftmost 16bits. It will result in the wrong.Article: 121359
ZHI wrote: > On 2 Jul, 17:39, Jeff Cunningham <j...@sover.net> wrote: >> ZHI wrote: >>> I want to know if i only need 16bits for the output, how to do it. >>> thanks. >> You are dealing with binary fractions, not integers, right? That is, >> numbers between 0 and 1 (or -1 to 1)? In your case, just take the >> leftmost 16 bits of the 20 bit result. >> >> -Jeff > > No, i am dealing with integers and binary fractions. I cannot only > take the leftmost 16bits. It will result in the wrong. > Then either : - Your application ensure by design that the result is always smaller than 65535 and you can just take the rightmost 16 bits. - You must have a result on 20 bits (deal with it !) - You're screwed SylvainArticle: 121360
I have just been notified that my socket is UFS devices Any ideas?Article: 121361
Hi all, I'm developing a multicore system with up to four Microblaze cores. Now I'm searching for a solution to inform the cores about e.g. messages with a software interrupt. That means, one core writes a message in the shared memory and after that it informs the other cores to read the message. My first idea was to use a GPIO element with interrupts switched on. I tried to write to the element when the message was posted . But there is the problem, that the interrupt is only activated when the data will be changed from outside the microblaze core. So my new idea is to use two GPIO elements and link them together. But it doesn't run and I think, that the problem is the linking of the ports. Has anybody an idea, which ports I have to link (GPIO_d_out or GPIO_IO with GPIO_in or something else) or an idea how to implement software interrupts in such a combination? I've got a Xilinx ML410 evaluation board. Thank you for your help.Article: 121362
On 3 Jul., 12:45, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de> wrote: > I did the mistake to only look at the TI SN74LVC244A. It neither states > "hysteresis" nor "Schmitt trigger". Their Logic selction guide also only > mentions "Schmitt Trigger" for the 14/17 and some similar device. > > The NXP datasheet mentions "Schmitt trigger" but doesn't specify a > hysteresis. But at least it mentions the Schmitt trigger. You can add hysteresis to any non inverting buffer with two resistors. Kolja SulimmaArticle: 121363
Hi, Lets say we have a signal crossing from a high frequency clock domain into a low frequency clock domain, where the low frequency domain frequency is very low, say 32kHz. Is there any point in having a double flip-flop synchronizer here, given that the frequency is so low? Shouldn't a single flop be good enough? Cheers, JonArticle: 121364
Thanks for all responses. Because the time zone I was unable to reply earlier. The device will do a lot of slow timings (1 second to 10 minutes), read 6 serial interface ADC converters (with 2.5MHz SCLK) and talk to a CPLD (used as port expander and watchdog) at 10Mbps data rate. It is a 3S200 and may have up to 70% of resources used. I may stick to the pull-down resistor idea because the system MTBF. Resistors cause less impact here. System has a XPLA3 CPLD and other circuits at 3V3 (that is supplied by a TDK's DC-DC converter) and I think the excess of current will sink easily. But I will calculate it again. TDK's never answered about sink capability of their DC-DC modules and I'd like to avoid using a 3V6 zener to do not waste energy in some temperature conditions. The signal's rise/fall time are around 50us (worst case). I know it is very slow for this device and I will have some extra current in the pin's input circuitry but the cycle time of each signal is in the range of several minutes. So the impact of slow signal transition may not be important for the system. Only 2 to 5 signals of 56 may change at same time and since they came from mechanical feedback it is very unlikely they will really change precisely together. The design did use schmitt-trigger devices for the inputs in the past but the MTBF did fall because other added circuits and I thought I could work out the bounce and slow edges with some sample/timing logic in the FPGA. Each of these input signals has a transient suppressor and another 100ohm resistor to the input connector. Those are to protect against huge ESD strikes and EMC/EMI. Exercising a bit longer in this subject, in case I can sink externally (to the FPGA) the excess of current (56mA) and since each clamp diode for this device can handle 100mA (according DS099), which leads a good current injection handling, the single input resistor (no pull-down) could work. I am in the limit of system MTBF and it is why I still thinking to avoid any other component... The main question remains: would the FPGA's MTBF be reduced because this current flowing in the clamp diodes? System cost is not a big issue but I'd like to avoid high reliability resistors because availability and lead times. While writing this text I am having second thoughts about avoiding these resistors... but your opinion would help in the FPGA's MTBF. Thanks a lot. -AugustoArticle: 121365
On Tue, 03 Jul 2007 05:07:28 -0700, hofmann.juergen@pc-future.de wrote: >Hi all, > >I'm developing a multicore system with up to four Microblaze cores. >Now I'm searching for a solution to inform the cores about e.g. >messages with a software interrupt. That means, one core writes a >message in the shared memory and after that it informs the other cores >to read the message. >My first idea was to use a GPIO element with interrupts switched on. I >tried to write to the element when the message was posted . But there >is the problem, that the interrupt is only activated when the data >will be changed from outside the microblaze core. >So my new idea is to use two GPIO elements and link them together. But >it doesn't run and I think, that the problem is the linking of the >ports. >Has anybody an idea, which ports I have to link (GPIO_d_out or GPIO_IO >with GPIO_in or something else) or an idea how to implement software >interrupts in such a combination? > >I've got a Xilinx ML410 evaluation board. > >Thank you for your help. What abiout using FSLs to communicate between processors? They have a FIFO with somne capacity, they generate interrupts... it is the firmware implem,entation of a queue. ZaraArticle: 121366
"Jon Beniston" <jon@beniston.com> wrote in message news:1183467448.561066.192500@n60g2000hse.googlegroups.com... > Hi, > > Lets say we have a signal crossing from a high frequency clock domain > into a low frequency clock domain, where the low frequency domain > frequency is very low, say 32kHz. Is there any point in having a > double flip-flop synchronizer here, > No. > > given that the frequency is so > low? Shouldn't a single flop be good enough? > Yes. > > Cheers, > Jon > It sounds like a weird setup. Are you sure you need a 32kHz domain? BTW., There's a school of thought that metastability can manifest itself as runt pulses. But you wouldn't use the output from the 32kHz FF to clock anything, would you? (Answer NO!) :-) HTH, Syms.Article: 121367
On Jul 3, 8:07 am, hofmann.juer...@pc-future.de wrote: > Hi all, > > I'm developing a multicore system with up to four Microblaze cores. > Now I'm searching for a solution to inform the cores about e.g. > messages with a software interrupt. That means, one core writes a > message in the shared memory and after that it informs the other cores > to read the message. > My first idea was to use a GPIO element with interrupts switched on. I > tried to write to the element when the message was posted . But there > is the problem, that the interrupt is only activated when the data > will be changed from outside the microblaze core. > So my new idea is to use two GPIO elements and link them together. But > it doesn't run and I think, that the problem is the linking of the > ports. > Has anybody an idea, which ports I have to link (GPIO_d_out or GPIO_IO > with GPIO_in or something else) or an idea how to implement software > interrupts in such a combination? > > I've got a Xilinx ML410 evaluation board. > > Thank you for your help. If you have the ML410 board, then you should already have access to the Xilinx resources for it as well. Take a look at the ML410 Reference Design page and you'll see that Xilinx has provided reference designs for dual-processor configurations. If you dig a little deeper into the projects, you'll see that Xilinx has even gone so far as to provide a core for what you're looking for: Mutex Mailbox Interface Here's the ML410 Ref Design page: http://www.xilinx.com/products/boards/ml410/index.html Here's the design w/ the cores that I was mentioning: http://www.xilinx.com/bvdocs/appnotes/xapp996.pdf -- MikeArticle: 121368
On 3 Jul., 15:11, Zara <me_z...@dea.spamcon.org> wrote: > On Tue, 03 Jul 2007 05:07:28 -0700, hofmann.juer...@pc-future.de > wrote: > > > > >Hi all, > > >I'm developing a multicore system with up to four Microblaze cores. > >Now I'm searching for a solution to inform the cores about e.g. > >messages with a software interrupt. That means, one core writes a > >message in the shared memory and after that it informs the other cores > >to read the message. > >My first idea was to use a GPIO element with interrupts switched on. I > >tried to write to the element when the message was posted . But there > >is the problem, that the interrupt is only activated when the data > >will be changed from outside the microblaze core. > >So my new idea is to use two GPIO elements and link them together. But > >it doesn't run and I think, that the problem is the linking of the > >ports. > >Has anybody an idea, which ports I have to link (GPIO_d_out or GPIO_IO > >with GPIO_in or something else) or an idea how to implement software > >interrupts in such a combination? > > >I've got a Xilinx ML410 evaluation board. > > >Thank you for your help. > > What abiout using FSLs to communicate between processors? They have a > FIFO with somne capacity, they generate interrupts... it is the > firmware implem,entation of a queue. > > Zara The problem is, that I have to link every core with each other. A Microblaze core only have eight FSL ports so I could only combine three cores. But I have to check the interrupt idea, perhaps I can use the interrupt signal in my global interrupt controller and all cores react to the interrupt.Article: 121369
On Jul 3, 8:02 am, AugustoEinsfeldt <a...@terra.com.br> wrote: > I may stick to the pull-down resistor idea because the system MTBF. > Resistors cause less impact here. My concern with the pulldown resistors would be, what if one of them doesn't effectively installed (open)? The board will probably work just fine. But now the protection diode will be taking all the current. If that's okay, fine - but if it's not, presumably the worry that caused you to put the resistors there in the first place, then you have a board that might fail early.Article: 121370
Jon Beniston wrote: > Hi, > > Lets say we have a signal crossing from a high frequency clock domain > into a low frequency clock domain, where the low frequency domain > frequency is very low, say 32kHz. Is there any point in having a > double flip-flop synchronizer here, given that the frequency is so > low? Shouldn't a single flop be good enough? The problem is that the slow clock will miss the narrow pulses most of the time. I would run all of the logic using the fast clock and synchronize the slow pulses to that. -- Mike TreselerArticle: 121371
Jon Beniston wrote: > Hi, > > Lets say we have a signal crossing from a high frequency clock domain > into a low frequency clock domain, where the low frequency domain > frequency is very low, say 32kHz. Is there any point in having a > double flip-flop synchronizer here, given that the frequency is so > low? Shouldn't a single flop be good enough? > > Cheers, > Jon > As long as there is a *single* flop to synchronize the signal, only one flop is needed. The design must not have more than one register that depends on the live signal. Once synchronized, the rare addition of 1-3 ns will not be a problem for downstream logic.Article: 121372
On 3 Jul., 15:24, cs_post...@hotmail.com wrote: > On Jul 3, 8:02 am, AugustoEinsfeldt <a...@terra.com.br> wrote: > > > I may stick to the pull-down resistor idea because the system MTBF. > > Resistors cause less impact here. > > My concern with the pulldown resistors would be, what if one of them > doesn't effectively installed (open)? The board will probably work > just fine. But now the protection diode will be taking all the > current. If that's okay, fine - but if it's not, presumably the worry > that caused you to put the resistors there in the first place, then > you have a board that might fail early. So use a number of resistors in parallel and include the voltage at these nodes into the production test procedure. KoljaArticle: 121373
> The problem is that the slow clock will miss the > narrow pulses most of the time. This is not an issue. > I would run all > of the logic using the fast clock and synchronize > the slow pulses to that. Not really possible as the idea is to save power. Cheers though, JonArticle: 121374
> It sounds like a weird setup. Are you sure you need a 32kHz domain? Yes. Low power design with a wakeup timer running of 32khz crystal. > BTW., There's a school of thought that metastability can manifest itself as > runt pulses. But you wouldn't use the output from the 32kHz FF to clock > anything, would you? No :-) Cheers, Jon
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