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
On 20 May 2006 18:59:40 -0700, the renowned "Peter Alfke" <alfke@sbcglobal.net> wrote: > >Nigel wrote: >> > >> the vendor claims shorting can happen in devices near capacity. > >"Vendor" would have to be Xilinx, but I cannot believe that statement. >Filling a low-power CPLD to capacity does not create a Vcc-to-GND short >circuit. >That is not even an urban legend, it's just silly. >Peter Alfke, Xilinx Applications It could conceivably cause some kind of ground bounce leading to latchup of the parasitic SCR and thence to death by overheating of the die if the supply is capable of delivering the amps. Is the ground and bypass situation on the chip close to ideal? (at least 4-layer board with gnd and Vdd planes and lots of bypass capacitance)? I have a different kind of part (micro) from a different vendor that manages to tell the difference between what should be a simple CMOS input (no pullups or anything like that) grounded and the same input grounded through a 1.2K resistor. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.comArticle: 102801
Franco If you want a European supplier have a look at our range here <http://www.enterpoint.co.uk/boardproducts.html>. For a very low cost board our Raggedstone1 RS1-400 is GBP£ 50 approx 75 Euro plus VAT if it applies. These boards also have the capability to be built into arrays and can either operate in a PCI slot or stand alone (with adaptor) on the bench. If your DSP function is intensive I would consider moving upmarket to a Virtex-4 based board. They have much more memory and faster and more multipliers.Article: 102802
Spehro Pefhany wrote: > On 20 May 2006 18:59:40 -0700, the renowned "Peter Alfke" > <alfke@sbcglobal.net> wrote: > > >>Nigel wrote: >> >>>the vendor claims shorting can happen in devices near capacity. >> >>"Vendor" would have to be Xilinx, but I cannot believe that statement. >>Filling a low-power CPLD to capacity does not create a Vcc-to-GND short >>circuit. >>That is not even an urban legend, it's just silly. >>Peter Alfke, Xilinx Applications > > > It could conceivably cause some kind of ground bounce leading to > latchup of the parasitic SCR and thence to death by overheating of the > die if the supply is capable of delivering the amps. > > Is the ground and bypass situation on the chip close to ideal? (at > least 4-layer board with gnd and Vdd planes and lots of bypass > capacitance)? Latch-up is mainly a current injection effect, and can be reduced if the lead-connections to the outside world have series impedance, or series impedance + external clamps, in severe cases. In devices with internal Vcc-IO clamp diodes, you do need to watch lifting Vcc effects, from long duration/significant values clamp currents, and power supplies that do not sink (most do not). Low power CPLDs need attention in this, because their own load currents are very low. On the PLDs we've tried to create LatchUp on, -ve pulse latchup was easier than +ve ( but still >> 100mA) and +ve latchup needed quite massive over-voltages to get enough current (higher clamp impedences) - so in that direction, pin failures are likely to happen at the same time, or first. -jgArticle: 102803
My Design Implements a MB processor, and in XPS I use "Tool - > Export to ProjNav" to export the processor to my design as a sub module. The problem is that When I finish my c program, how to compile the program into BlockRAM? Since it is a XST flow, not a XPS flow, how to update the blockram in the bitstream?Article: 102804
Spehro Pefhany schrieb: > It could conceivably cause some kind of ground bounce leading to > latchup of the parasitic SCR and thence to death by overheating of the > die if the supply is capable of delivering the amps. Could also be a power-up sequence issue. When different voltages are onboard and another IC connected to the CPLD is power up much ealier and drives the (still unpowered) IOs of the CPLD, latchup can happen too. > Is the ground and bypass situation on the chip close to ideal? (at > least 4-layer board with gnd and Vdd planes and lots of bypass > capacitance)? Naaaaa, I wouldnt like to develop paranoia on this. I think a double layer for this CPLD is just fine, with some 100nF placed close to the CPLD. Regards FalkArticle: 102805
On Sun, 21 May 2006 01:09:20 -0700, John Adair wrote:
> Franco
>
> If you want a European supplier have a look at our range here <http://www.enterpoint.co.uk/boardproducts.html>. For a very low cost board our Raggedstone1 RS1-400 is GBP£ 50 approx 75 Euro plus VAT if it applies. These boards also have the capability to be built into arrays and can either operate in a PCI slot or stand alone (with adaptor) on the bench.
>
> If your DSP function is intensive I would consider moving upmarket to a Virtex-4 based board. They have much more memory and faster and more multipliers.
John--
You really need to cut down on your line lengths.
~Dave~
Article: 102806On Sun, 21 May 2006 10:53:41 +0200, the renowned Falk Brunner <Falk.Brunner@gmx.de> wrote: >Spehro Pefhany schrieb: > >> It could conceivably cause some kind of ground bounce leading to >> latchup of the parasitic SCR and thence to death by overheating of the >> die if the supply is capable of delivering the amps. The reasoning here is that a more fully utilized CPLD has more nodes switching very quickly and virtually the same instant, which in turn means more volts across fixed stray layout, package and die inductance. >Could also be a power-up sequence issue. When different voltages are >onboard and another IC connected to the CPLD is power up much ealier and >drives the (still unpowered) IOs of the CPLD, latchup can happen too. Sure, however I fail to see how power sequencing issues would lead to different results depending on the percentage of the CPLD which is used. >> Is the ground and bypass situation on the chip close to ideal? (at >> least 4-layer board with gnd and Vdd planes and lots of bypass >> capacitance)? > >Naaaaa, I wouldnt like to develop paranoia on this. I think a double >layer for this CPLD is just fine, with some 100nF placed close to the CPLD. > >Regards >Falk Maybe, but it's hard to make a marginal layout when full power planes are employed, even with an dumb-as-a-post autorouter. Single and double-sided boards offer far richer opportunities in this department. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.comArticle: 102807
Spehro Pefhany schrieb: > The reasoning here is that a more fully utilized CPLD has more nodes > switching very quickly and virtually the same instant, which in turn > means more volts across fixed stray layout, package and die > inductance. Right, but this is only a qualitative statement. What matters is quantity. So how big is the overall inductance? How much does voltage drop increase between a almost empty and a almost full device? Answering these question (which is not so easy) may yield the answer, that there is plenty of margin left. Ind I guess Xilinx did quite alot of testing with fully utilized devices. > Sure, however I fail to see how power sequencing issues would lead to > different results depending on the percentage of the CPLD which is > used. Ask Mr. Murphy ;-) Maybe its just one critical IO that is used or not. Regrds FalkArticle: 102808
Hey folks I have an Elektor FPGA project board (with an Altera EP1C12k and a EPCS4). My board is working nicely, but I'm having an issue with Quartus, where I can't program the serial eeprom using the active serial mode. Quartus objects to this on the grounds that "Current programming hardware does not support Active Serial Programming programming mode". I set up the Quartus programming tool to upload the .pof file, and it got the right serial eeprom from the file. Everything goes just fine until I hit the "Start" button, when the above error pops up. Any idea what gives? I've tried resetting the parallel port in the BIOS (Classic, ECP and Bidirectional modes). I've installed the ByteBlaster driver, and Quartus thinks I have a ByteBlasterMV, not a ByteBlasterII. Is this relevant? I had exactly the same error with Quartus 5.1sp2 and 6.0. MArticle: 102809
you need ByteBlaster II that supports the AS mode, i think I was the first who made the hardware changes public to convert and ByteBlaster to BB 2 but I dont have the reference any more its fairly simple change though AnttiArticle: 102810
I find the documents for tool "Data2mem", and use the command line to invoke this tool. In my design, totally 9 brams are used, 4 for the MB, while the rests are for other usage. And the other 5 brams are initialized by coe file, so in Data2mem tool I only need to update the 4 brams. I used the bmm file found in the XPS directory, but the data2mem tool gives warning: Not all BitLanes in ADDRESS_RANGE 'lmb_ram' have BMM location constraints. Some data for this ADDRESS_RANGE may have been lost during BIT fileArticle: 102811
Keep the cabling from the USB/JTAG adapter short, and in particular, keep the stub lengths for TCK and TMS short and it should work. I've built/used debug rigs that used JTAG (albeit for Pentium processors, not FPGA's), and it's more robust than you would imagine. I've seen JTAG work reliably with clock stubs nearly 6" long made out of standard 22 guage wire using regular header posts. (like the ones on the sample kit board) The only caveat is that I measured the wires such that the lines were all very closely matched. More to the point, you aren't going to harm anything so long as you don't connect the two independent VCC lines together, so give it a go. I don't know if Xilinx supports it, but Altera tools will let you run a verification loop through the chain - if it passes, you are fairly assured the chain is good. If it doesn't work by just keeping the cabling to a minimum, you can always try inserting a clock buffer/driver and using independent outputs for each board - but keep in mind a normal buffer will add skew to the clock. Try to use a clock driver that uses a built-in PLL or DLL to negate the skew. Linear and IDT both have parts that are "zero-skew". Same thing applies, though - keep the cabling short. I suspect that you will find an appropriate harness to be adequate, though. Please post your findings. I'm planning on doing something very similar, as I recently received a freebie S3E sample pack, and I'm waiting on my freebie Coolrunner CPLD board.Article: 102812
And I wondering about why and whether this warnning will affect my design?Article: 102813
inport-export flow is deprecated. 1 create ISE project 2 add new source, select 'embedded processor' 3 change the EDK design 4 write your C application 5 close XPS 6 double click "Update bitstream with processor data' --------------- 7 get some double-espresso 8 copy .BIT file to mini-SD card 9 insert the card into card slot of hydraXC 10 apply 3.3V power http://hydraxc.xilant.com steps 7-10 are optional :) this flow just works, just do it as described in Xilinx documentation, no tricks no magic no special things. I just verified this for both MicroBlaze and PowerPC systems, in both cases the project .bit files worked on first attempt nothing to change or fix. Antti full projectst for ISE as toplevel and MB or PPC as submodule will be uploaded to hydraxc suppport site shortly, there isnt any magic with them, but just to make the startup easier such example design may be useful - there are many ways to get it wrongArticle: 102814
the BMM thing has been the most problematic all the time, but with the latest ISE/EDK it actually works all fine, as long as you dont try to something the wrong (deprecated way) see my other comment. AnttiArticle: 102815
On Sat, 20 May 2006 13:13:59 +0200, Falk Brunner <Falk.Brunner@gmx.de> wrote: [...] >Regards >Falk Danke fuer deine Hilfe! Gruesse, FrancoArticle: 102816
On Sunday, in article <4db0j4F19lkfkU1@individual.net>
Falk.Brunner@gmx.de "Falk Brunner" wrote:
>Spehro Pefhany schrieb:
>> Sure, however I fail to see how power sequencing issues would lead to
>> different results depending on the percentage of the CPLD which is
>> used.
>
>Ask Mr. Murphy ;-) Maybe its just one critical IO that is used or not.
If it is true that only boards to one site with same program as other boards
fails, my money is on environmental or manufacturing.
I.E. something on the site is different to screw things up - ESD, other
damage to boards, miswiring, latchup or other screw ups because
of sequencing of external events.
Manufacturing caused those boards to have something wrong with that
batch.
All of which could still be a marginal issue in the design, that site
ensures happens.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Article: 102817On 21 May 2006 04:54:42 -0700, "Antti" <Antti.Lukats@xilant.com> wrote: >you need ByteBlaster II that supports the AS mode, >i think I was the first who made the hardware changes public to convert >and ByteBlaster to BB 2 but I dont have the reference any more > >its fairly simple change though I'm not using a real ByteBlaster, its the Elektor equivalent, and it has got an AS mode. Its circuit is close to the Altera one in their user guide, and it has the extra feedback bits that the BBII has. I suspect something to do with the parallel port because I get the error whether the "ByteBlaster" is connected or not. FWIW, JTAG mode works just fine. MArticle: 102818
you need brains .Article: 102819
Peter Alfke wrote: > So you receive data at 125 MHz, and you transfer it then at 100 MHz (if > I understand you right) > How do you control the FIFO to prevent it from overflowing? What do you > do with the flags? > Peter Alfke, Xilinx (from home) Hello, my input data rate from the phy gigabit into the fifo is 162 Byte / 5 us. The output data rate out of the fifo is approximately 162 Byte / 3 us. The data is packet into 32 Bit and transfered over an external bus which is clocked by 100MHz/8 = 12.5MHz. I do not check the fifo status, because I know, that I'm fast enough to empty it. The only thing I need is a 1-clock-pulse from the receiving component to tell that a new frame (162 Byte) has been received. After this pulse is seen ( I name it frame_ready) a statemashine does the rest without beeing controlled by any signal from the receiving component ( I name it phy_rx). In this way I send the data with a corresponding chipselect to 1 of 3 external devices. Every external device has to get 128*512*162 Byte = ca. 10MB. After that, the chipselects are switched to the next device. Because of this, every chipselect for the external devices are approximatly 0.3s long. I see this in my testbench and on the oszilloscope. Sometimes one of this chipselect is shorter than 0.3s which causes data to be send to the wrong device. This happens randomly after 1000s or 12345s or something else, A friend at work originally wrote the component for empting the fifo and sending data. After long studies I decided to rewrite this component. Absolutely new and absolutly different. But with this version the same effect happens. Chipselects sometimes are to short. If we generate the testdata in the FPGA and replace the phy_rx component the mashine works ok. It looks like the receiving clock from the phy_rx is making us problems in a way we do not understand. This receiving clock is generated out of the received datastream at the gigabit phy device and is connected through a DLL to the fifos write-clock. To produce the short chipselects one of my counters in the statemashine has to be reset. But a reset does not occur, because the short chipselect sometimes occured at device 1, which is the default device after reset. A reset would enlarge the chipselect. A wrong working fifo has no effect on the chipselect-signals. For the sending and receiving of data over gigabit phy we use 2 xilinx boards ML401. ??? thanks for your email DennisArticle: 102820
Antti schrieb: > you need brains Sometimes one is enough. KoljaArticle: 102821
ROTFL, Kolja I really enjoy your comments. Sure you are right. AnttiArticle: 102822
Some things are simple. Some things are fun. FPGA's are both Simple and Fun - for all the Family! Arent they? Even on Sundays (when it rains)? I think they are, and here is the story: http://hydraxc.xilant.com/downloads/MissionPossible2006.pdf Sorry for 1.6MB PDF download, some images are high-resolution. Antti Lukats from work on Sunday 21:50 local timeArticle: 102823
Hi Antti, ispLever now supports schematic for FPGA's as well as CPLD's. Luc On Sat, 20 May 2006 09:44:40 +0200, "Antti Lukats" <antti@openchip.org> wrote: >"bart" <bart.borosky@latticesemi.com> schrieb im Newsbeitrag >news:1148084503.179769.316340@j73g2000cwa.googlegroups.com... >> Lattice has released a new version of our downloadable ispLEVER Starter >> software, concurrent with version 6.0. Device support includes the 90nm >> LatticeECP2-50 and can be downloaded here: >> http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm >> >> Regards, >> Bart Borosky, Lattice >> > >are XP devices now suported in schematic? > >antti >Article: 102824
Piotr, In my opinion, if your design needs a simulator, then you better spend some money on a real good simulator. BTW, the full version of ispLEVER has ModelSim as simulator and the list price on Lattice's website is $695, and when you order online 'only' $495. For this price you get the OEM version of ModelSim - and this is by far the best deal you can get Regards, Luc On Sat, 20 May 2006 11:48:47 +0200, "Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl> wrote: >bart wrote: > >> Lattice has released a new version of our downloadable >> ispLEVER Starter software > >Still without even the simplest free simulator? > > Best regards > Piotr Wyderski
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