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
All, Yes, DCM's have a fixed 300 ps cycle to cycle jitter max in high frequency mode (1000 ps cycle to cycle in low frequency mode) limit for clock input jitter (not to exceed to lock). The PLL in V5 has no such restriction. The characterization of this PLL is now done, and in review, and, it looks like a PLL! Basically, the jitter input tolerance is very large (spread spectrum is no issue), and the output jitter is very small. Details after the review of the report. Generating spread spectrum is another matter. Spartan 3, and 3E have an application for their DCM which will create a very nice spread spectrum clock which is well within the DVI specifications (useful for commercial folks who don't want to put their systems inside fully shielded metal enclosures!). This uses some features of the DCM in 3, 3E that are not present in V4, nor even in V5. It remains to be seen if V4 or V5 could play any of the same tricks as 3, 3E, and create a useful spread spectrum clock, but we have had no customer interest in Virtex-Land. Locking to a spread spectrum referenced clocked data stream is a requirement for the V5 MGTs (ie SATA), and yes, they do comply. As well the V5 MGT has the OOB signalling required by standards like PCIe (along with the PCIe MAC in hard logic). There seems to be a widening divergence in the needs and wants of the "high-end" FPGA customer vs. the "high volume" FPGA customer. The product lines are evolving to reflect those differences. AustinArticle: 112826
Hello, I'm looking to do a design involving data rates near 4Gbps and was looking at using Altera's Stratix II GX transceivers to drive the data to a 4Gbps single-mode fiber-optic transceiver. I'm interested in how well the Stratix can perform this task, if anyone has some experience using the transceivers could you please let me know how well it worked for you? I've read the Altera's web site on the Stratix II GX and it sounds very promising, I just want to make sure that is does what it says it can. thanks, joeArticle: 112827
Hi, Is it possible to run Xilinx ISE on a cluster? In the office there are about 20 desktops, all networked & idle, and I'm waiting for the single one that is implementing an ISE design since half an hour now. It would be great to put those 20 desktops to work and get stuff done at 20x. I'm asking for the impossible, right? I wouldn't mind a linux solution. Regards, MarcArticle: 112828
Scott, That board is from a Xilinx seminar from 10+ years ago. Your best bet is to throw it away. IIRC, there never was HDL support for this chip, Xact-schematic only. If you were able to find a copy, you would have to find a 5.25" floppy drive to load it, and then it probably wouldn't work with a modern version of Windows. Then you would have the true joy of finding a compatible programming pod. All this for a device that's smaller than a current CPLD. Spending $150 on the Spartan3 starter kit would be faster/better and cheaper. Cheers, GHArticle: 112829
karollo@o2.pl schrieb: >> What signal you are talking about? Bidirectional ports? Did you ever >> write to these signals? > There are X(es) in the outputs. I'm sorry. I didn't describe it > precisely. I've project in Altera and I want use it in actel (I don't > use any altera library, it's pure vhdl) I did not ask for the target technology but for the modelled hardware - in other words: I was asking what you try to model. > In Quartus d filp-flops, counters, registers etc. start from zeros, Ok - a lot of FPGAs set Flipflops to a certain value after configuration. I would not rely on it, because if you move to a different target, it will be different. Use a reset. > in > model they are unkown at 0 ns and have x value through certain time. > Do you know how change it in model to have known output values at 0 > time (forcing signals isn't the best idea). Don't change the model - change your code! Include a reset and ask yourself, why the signals switch to a certain value. Without your code (a minimal example) we can only guess, what is happening. RalfArticle: 112830
"rickman" <gnuarm@gmail.com> wrote in message news:1164827093.834310.306760@80g2000cwy.googlegroups.com... > John_H wrote: >> Starting in the Spartan-3 FPGA Family: Functional Description v1.4 >> (August >> 19 2005) diction similar to the first instance is found: >> >> The Spartan-3 I/O pull-up and pull-down resistors are stronger >> than the "weak" pull-up/pull-down resistors used in previous >> Xilinx FPGA families. See Table 6, Module 3 for >> equivalent resistor strengths. >> >> Your design was probably before the data sheet revision but the >> documentation DOES reflect this change. If you've looked at the S3E data >> sheet, your comment that "You >> > would think they would note this clearly in the documentation" is made >> > MORE clear by adding the great big warning signs and outlined text to >> > emphasize the issues that are issues. >> >> They didn't do a good job with the resistor strength in S3, absolutely. >> They _have_ taken care of the documentation side of things. > > I don't agree with this. I had this discussion with Xilinx (mostly in > this group) when I was investigating the behavior of all the pullups on > all the pins of the Spartan 3. I found that the required information > was scattered over multiple sections of the document and stated in > different ways that even appear to contradict each other in some ways. > Xilinx did make some adjustments to the data sheet, but I think the > issue of using the pullup resistors in Spartan 3 devices is complicated > enough that the information should be pulled together in one section > where it can be found easily and completely. No one has time to read > every sentance in a 200 page document. Instead we rely on the tools > available for searching the document and typically don't expect to have > to find info in multiple places to tell us the *whole* story. > > Putting one sentance at the end of one section is not what I would call > "taking care" of documentation. Obviously people are still missing > this sentance and not realizing that the Spartan 3 pullups are > different from the pullups on nearly every FPGA made by any vendor. If engineers - myself included - are too lazy to RTFM, how _can_ a vendor forcefeed these professionals with the information that they *know* they'll need? I'd be interested in the how. Very interested in any effective means above and beyond the documentation. If the PULLUPS and PULLDOWNs section is 2 or 3 paragraphs, the last of which is a caution, how much more can be done? With any complicated systems, the ability to communicate every nuance is hampered not by poor documentation as much as by the complexity. Engineers are supposed to be doggedly detailed people. If the datasheet isn't the first line of defense, what is?Article: 112831
You can spool off multiple place & route jobs across the cluster but one "long" place & route job will take what it takes on one computer. I use quotes because the half hour is tiny for some of the Xilinx designs out there. Extreme coordination is difficult to do in different rooms. <jetmarc@hotmail.com> wrote in message news:1164830490.778732.110340@n67g2000cwd.googlegroups.com... > Hi, > > Is it possible to run Xilinx ISE on a cluster? In the office there are > about 20 desktops, all networked & idle, and I'm waiting for the single > one that is implementing an ISE design since half an hour now. It > would be great to put those 20 desktops to work and get stuff done at > 20x. I'm asking for the impossible, right? I wouldn't mind a linux > solution. > > Regards, > Marc >Article: 112832
Joseph schrieb: > MS will possibly eventually stop supporting XP. Hey, I have moved from WinME to WinXP during this April. During the last months before it became more and more impractical to use WinME any because drivers were not supported any more and some Games refused to run. This means, that you have at least 3 years, before you even have to think about moving to the next operating system. It is not the lack of support by MS, that makes the OS old, but the support of the other software companies. And let me add: At work I use a SunRay connected at a 400MHz (4 CPU) Sparc Server. Before this I was using a SparcStation 5 with 333MHz - not too much slower! Only for really big simulations or big synthesis runs I use the big Sun Fire with 1,2GHz. (Simulator is Cadence NCSim and Synthesis tool Synopsys Design Analyzer runnig at Solaris 5.8 for me.) -> So I would say that top speed and always the latest System is not necessary - especially for hardware design. RalfArticle: 112833
tenteric schrieb: > I need to be more precise - my passion is just very fast computation - > I'm very interesting in implementing any math algorithm thus it will > work as fast as it can. A FPGA is nothing more than a prototyping platform. Anything you can build as digital hardware you can map to an FPGA. You just don't need to manufacture wafers with your chips, bond and house them. RalfArticle: 112834
Hi, recently I've started using FPGAs for all sorts of things, and currently I'm working on a couple designs that would benefit from a PC133 interface. I'll be putting it all on a rather tiny PCB with a Spartan-3E and a laptop-form-factor RAM socket, so the traces will be short. However, I am completely self-taught and after some newsgroup/google surfing, it seems I may need series resistors or some such things?? (I don't quite understand all this business about trace impedance, I started learning on 8-bit 20MHz MCUs and before that I was a software-only person :| ) Could anyone explain these things to me or point me to some good online explanations? Thanks in advance! -Eric AganArticle: 112835
John_H wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:1164827093.834310.306760@80g2000cwy.googlegroups.com... > > John_H wrote: > >> Starting in the Spartan-3 FPGA Family: Functional Description v1.4 > >> (August > >> 19 2005) diction similar to the first instance is found: > >> > >> The Spartan-3 I/O pull-up and pull-down resistors are stronger > >> than the "weak" pull-up/pull-down resistors used in previous > >> Xilinx FPGA families. See Table 6, Module 3 for > >> equivalent resistor strengths. > >> > >> Your design was probably before the data sheet revision but the > >> documentation DOES reflect this change. If you've looked at the S3E data > >> sheet, your comment that "You > >> > would think they would note this clearly in the documentation" is made > >> > MORE clear by adding the great big warning signs and outlined text to > >> > emphasize the issues that are issues. > >> > >> They didn't do a good job with the resistor strength in S3, absolutely. > >> They _have_ taken care of the documentation side of things. > > > > I don't agree with this. I had this discussion with Xilinx (mostly in > > this group) when I was investigating the behavior of all the pullups on > > all the pins of the Spartan 3. I found that the required information > > was scattered over multiple sections of the document and stated in > > different ways that even appear to contradict each other in some ways. > > Xilinx did make some adjustments to the data sheet, but I think the > > issue of using the pullup resistors in Spartan 3 devices is complicated > > enough that the information should be pulled together in one section > > where it can be found easily and completely. No one has time to read > > every sentance in a 200 page document. Instead we rely on the tools > > available for searching the document and typically don't expect to have > > to find info in multiple places to tell us the *whole* story. > > > > Putting one sentance at the end of one section is not what I would call > > "taking care" of documentation. Obviously people are still missing > > this sentance and not realizing that the Spartan 3 pullups are > > different from the pullups on nearly every FPGA made by any vendor. > > If engineers - myself included - are too lazy to RTFM, how _can_ a vendor > forcefeed these professionals with the information that they *know* they'll > need? > > I'd be interested in the how. Very interested in any effective means above > and beyond the documentation. If the PULLUPS and PULLDOWNs section is 2 or > 3 paragraphs, the last of which is a caution, how much more can be done? That is my point. The information about the pullups is not in three paragraphs. It is scattered throughout the document. Try finding out everything about configuration pins and their pullups. I don't recall all the details I had to pull out of the document, but I remember that I had to read, and reread and then ask Xilinx for clarification on the whole thing. Yeah, the info may be there, but with it documented in so many places, it is inevitable that some will be missed. > With any complicated systems, the ability to communicate every nuance is > hampered not by poor documentation as much as by the complexity. Engineers > are supposed to be doggedly detailed people. If the datasheet isn't the > first line of defense, what is? What is your point? I never said the data sheet is the wrong place for documentation. I said this data sheet is not done well and needs a separate section just for the pullups and how they relate to configuration. If I had the time right now, I would go back to the document and show you what I mean. But I just don't have the time to mess with the thing at the moment. The ONLY way to convey complex information is with exceedingly clear and well organized documentation. This is often hampered by the requirement to meet deadlines which is what I need to do right now...Article: 112836
Hi Wojtek - Modular design is not supported in the latest version of PlanAhead. PlanAhead does support Partial Reconfigurability flows. You would need to contact your local FAE to get access to PlanAhead's support for Partial Reconfig. PlanAhead supports block based design by managing placement constraints on "Pblocks". You can try an eval version at www.xilinx.com/planahead. The eval is a fully featured version of PlanAhead that is licensed for one month. There is an FAQ in the "PlanAhead User Forum" link off of the www.xilinx.com/planahead page. Thanks Salil "wojtek_himself" <wojtek2u@wp.pl> wrote in message news:ekkjci$a7p$1@nemesis.news.tpi.pl... > Hi, > > Does anyone have experience with modular design flow or PlanAhead? > Could you answer my questions related to it: > > 1) I know that all IO ports in modular design flow have to be placed on > the top level. But does it mean that all FFs/tri-state buffers I want to > have in IOBs have to be inferred on the top level as well or these logic > can stay locally in modules? > > 2) Do I understand it correctly that PlanAhead is just graphical interface > to modular design and partial reconfiguration functionality (plus some > other features)? > > 3) Do you know if evaluation version of PlanAhead is fully functional? > > 4) Is this modular design or PlanAhead really useful and not one of toy > tools? > > I would appreciate sharing your experience, > > Regards > WojtekArticle: 112837
rickman wrote: > Daveb wrote: >> I decided to set the INIT_B to an output forced high in my design and >> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual >> purpose I/O pins are weak pull down. Turns out that there's weak and >> there's weak! the pull down can be less than 2K so my (fairly weak) >> pull up lost. So no CRC error after all but I should have read the >> datasheet in more detail before panicking. > > You are not the first engineer to have been caught napping by the > Spartan 3 "weak" pullups (downs). Where I work, there is a strong > tendancy to not act, or even react, but to *over*react to issues. > Someone discovered this on a project a couple of years ago and decided > to use 0 ohm jumpers to set the config pins. Then when I was drawing > up my schematics, like you, I initially used resistors that were > inappropriate. When another engineer corrected me and I investigated, > I found what the issue was and decided to only add jumpers to ground > since the pullups were plenty strong enough to pull up and could not be > turned off. That led to a tirade about how 0 ohm jumpers were required > in *all* cases on the Spartan 3s, pullup or pulldown. Of course this > is not correct, but that day it was no fun being right. > > The long and the short of it is that Xilinx does not always get this > stuff right and they don't consider this broken enough to fix it. You > would think they would note this clearly in the documentation that this > part is very different from their other devices. > I would note that this issue existed in Spartan II as well. We (myself and another) were caught out by using an inappropriate pulldown value on the Mode pins, and were pulling our hair out wondering why the part was not always configuring. Because we had chosen a value just low enough to 'sorta' pull the pins, sometimes it would configure, other times it would not. It was only when we got the voltmeter out and looked at the static levels with resets held that we appreciated the problem. Cheers PeteSArticle: 112838
Ralf Hildebrandt schrieb: > tenteric schrieb: > > > I need to be more precise - my passion is just very fast computation - > > I'm very interesting in implementing any math algorithm thus it will > > work as fast as it can. > > A FPGA is nothing more than a prototyping platform. Anything you can > build as digital hardware you can map to an FPGA. You just don't need to > manufacture wafers with your chips, bond and house them. > > Ralf I dont agree that an FPGA is nothing more than a prototyping platform,it can form the basis of a very powerful configureable computing system,although i am a little lost as to the point of the original post because any algorithm can be implmented in hardware as well as it can be in software ,in hardware it will obviously benifit from the inherent parrelelism.How you implement the algorithm is upto you it can be in a Hardware description language or schematic capture .The mistake is oftem made of comparing a algorithm running on a microprocessor and implemented in a programmable logic device, the microprocessor implementation is clearly going to perform less well because of its inherently serial nature.Article: 112839
Because you worked at such slow speeds before you probably have never had to care about trace impedance or termination. As you use higher speed communication standards (ones with fast edge rates), you will need to master signal integrity. It might not be a huge problem with your current needs as PC133 SDR shouldn't be that bad. But, I would suggest you read some of the signal integrity articles on the Xilinx site and get a few of Howard Johnson's books on signal integrity. I would also recommend a good PCB design suite that includes a simulation program. I use Hyperlynx from Mentor Graphics. ---Matthew Hicks <slax0r.hax0r@gmail.com> wrote in message news:1164832287.574639.252590@l39g2000cwd.googlegroups.com... > Hi, recently I've started using FPGAs for all sorts of things, and > currently I'm working on a couple designs that would benefit from a > PC133 interface. I'll be putting it all on a rather tiny PCB with a > Spartan-3E and a laptop-form-factor RAM socket, so the traces will be > short. However, I am completely self-taught and after some > newsgroup/google surfing, it seems I may need series resistors or some > such things?? (I don't quite understand all this business about trace > impedance, I started learning on 8-bit 20MHz MCUs and before that I was > a software-only person :| ) > > Could anyone explain these things to me or point me to some good online > explanations? > > Thanks in advance! > -Eric Agan >Article: 112840
Matthew Hicks wrote: > Because you worked at such slow speeds before you probably have never had to > care about trace impedance or termination. As you use higher speed > communication standards (ones with fast edge rates), you will need to master > signal integrity. It might not be a huge problem with your current needs as > PC133 SDR shouldn't be that bad. But, I would suggest you read some of the > signal integrity articles on the Xilinx site and get a few of Howard > Johnson's books on signal integrity. I would also recommend a good PCB > design suite that includes a simulation program. I use Hyperlynx from > Mentor Graphics. > > > ---Matthew Hicks > > > <slax0r.hax0r@gmail.com> wrote in message > news:1164832287.574639.252590@l39g2000cwd.googlegroups.com... >> Hi, recently I've started using FPGAs for all sorts of things, and >> currently I'm working on a couple designs that would benefit from a >> PC133 interface. I'll be putting it all on a rather tiny PCB with a >> Spartan-3E and a laptop-form-factor RAM socket, so the traces will be >> short. However, I am completely self-taught and after some >> newsgroup/google surfing, it seems I may need series resistors or some >> such things?? (I don't quite understand all this business about trace >> impedance, I started learning on 8-bit 20MHz MCUs and before that I was >> a software-only person :| ) >> >> Could anyone explain these things to me or point me to some good online >> explanations? >> >> Thanks in advance! >> -Eric Agan >> > > I strongly suggest you try and master some transmission line theory (in which signal integrity is based). There are some excellent resources available on the web, but you might need some guidance. For that reason, I have x-posted this to s.e.d. Cheers PeteSArticle: 112841
"rickman" <gnuarm@gmail.com> wrote in message news:1164832706.135902.275960@l39g2000cwd.googlegroups.com... > John_H wrote: >> >> If engineers - myself included - are too lazy to RTFM, how _can_ a vendor >> forcefeed these professionals with the information that they *know* >> they'll >> need? >> >> I'd be interested in the how. Very interested in any effective means >> above >> and beyond the documentation. If the PULLUPS and PULLDOWNs section is 2 >> or >> 3 paragraphs, the last of which is a caution, how much more can be done? > > That is my point. The information about the pullups is not in three > paragraphs. It is scattered throughout the document. Try finding out > everything about configuration pins and their pullups. I don't recall > all the details I had to pull out of the document, but I remember that > I had to read, and reread and then ask Xilinx for clarification on the > whole thing. > > Yeah, the info may be there, but with it documented in so many places, > it is inevitable that some will be missed. > >> With any complicated systems, the ability to communicate every nuance is >> hampered not by poor documentation as much as by the complexity. >> Engineers >> are supposed to be doggedly detailed people. If the datasheet isn't the >> first line of defense, what is? > > What is your point? I never said the data sheet is the wrong place for > documentation. I said this data sheet is not done well and needs a > separate section just for the pullups and how they relate to > configuration. If I had the time right now, I would go back to the > document and show you what I mean. But I just don't have the time to > mess with the thing at the moment. > > The ONLY way to convey complex information is with exceedingly clear > and well organized documentation. This is often hampered by the > requirement to meet deadlines which is what I need to do right now... My apologies, Rickman. I read the issue as being that the weak pullups aren't weak pullups and that the documentation doesn't come close to specifying that. What I realize now is that your comments were on the pullup/pulldown condition of, specicially, the configuration (or other dual purpose) pins at the various stages of operation. Yes, the configuration section could have clarified that a bit better; when I went looking for information on the specific behavior of the dual-purpose INIT_B pin, I was left with a slightly hollow feeling one gets when you know you don't have all the information. Different modes may or may not use different dual purpose pins and it's not clear what the condition is of each in the various configuration stages for the different programming modes.Article: 112842
Antti wrote: >>Antti wrote: >> >>>all attempts to get MPMC2 DDR2 designs to work have failed so far >>>have tested on custom V4 board with single 16bit device and on ML501 >>>all attempts failing >> >>And same here (mch_opb_ddr2 not MPMC) - we've spent a week trying to get the >>mch_opb_ddr2 core talking to a Micron 512Mb 32Mx16 -37E part on a PCIe board - >>no luck. The board is OK - there's a MIG design that works fine. >> > OPB_MCH_DDR2 (EDK 8.2 SP2) worked for me like magic, just out of box, > all working, no issues That's interesting - what memory configuration? We have a single MT47H32M16CC-37E and just cannot get any sense out of it. Addressing looks all wrong - it reads back the same data value at 4 consecutive dword addresses (offset 0x00 -> 0x0c) Writing is unreliable, if you write 0xffffffff it just randomly twiddles a few of the top 16 bits, but not in any discernable pattern. I've tried more combinations that I care to admit - differential DQS on vs off, timing params exact according to Micron datasheet vs more conservative, you name it. Triple-checked UCF pin assignments, blah blah blah. > PLB_DDR2 works on ML501 (but uses patched EDK core), well Xilinx > reports that out of box PLB_DDR2 also works on ML501 (I have failed > with it) > there is customer report who got PLB_DDR2 working on custom board (but > after getting patch from Xilinx FAE) Is this a patch to the plb interface, or the core ddr2_interface that is used by all controllers? Cheers, JohnArticle: 112843
Hi Clark, Anonymous wrote: > I have a xilinx v4 project running mv linux 2.6.10. I have a custom > peripheral I made that includes DMA on the opb bus and is therefore > master/slave. The SDRAM that the linux .elf file loads to/boots from is also > on the opb. Unless I disconnect the custom peripheral linux dies at > "uncompressing linux...". > > I believe this means that there are data errors from the sdram, but > everything works fine stand-alone. I know the dma isn't running, for > example, and I've made sure to reset every other register related to that > peripheral but linux just won't boot unless I disconnect it. Can you run the auto-generated TestApp_Memory sucessfully when your peripheral is in the system? More broadly, are you able to confirm that your core is behaving itself on the OPB bus? Either through simulation or by running standalone testslike TestApp_Memory etc? JohnArticle: 112844
Ralf Hildebrandt wrote: > tenteric schrieb: > > > I need to be more precise - my passion is just very fast computation - > > I'm very interesting in implementing any math algorithm thus it will > > work as fast as it can. > > A FPGA is nothing more than a prototyping platform. Anything you can > build as digital hardware you can map to an FPGA. You just don't need to > manufacture wafers with your chips, bond and house them. I know that. But I'm interesting, is there any real-world cases when FPGA design was successfull in heavy scientific computation, where outcome compensating FPGA cost + design cost, etc.Article: 112845
jez-smith, As for the FPGA solution aways being faster, that is not necessarily the case: if the application requires data to the algorithm, and then data returned from the algorithm, the speed of the algorithm itself may be infinitely fast (ie take 0 time), and the microprocessor will still "win" because the data has to be sent to the FPGA from the microprocessor, and then sent back to the microprocessor from the FPGA. Thus, the system architecture as well as the algorithm may result in a slower solution when the algorithm is ported to the FPGA, rather than a faster solution (the time spent sending and receiving data may be the limiting factor). In the Cray system, with the 64 bit AMD uC and two Virtex II Pro FPGAs per compute node (>2,000 nodes), Cray points out that some choices of algorithm will result in a longer time if ported to the FPGA. http://www.xilinx.com/prs_rls/design_win/0591cray05.htm Algorithms with less data exchange (a whole block is sent to the FPGA to be "crunched") may offer a significant speedup, however. So, the choice of how data is moved about the system becomes the limiting factor in the improvement offered by the FPGA. A system that has a custom architecture to solve just the problem at hand may not only take advantage of parallelism that a microprocessor solution can not, but it will also derive benefit by having its input/output architecture also optimized for the problem at hand. A good example of the latter, is a cellular base station which does all processing at the IF frequency using FPGAs. The use of the FPGA for modulation/demodulation allows for much less power, and far fewer chips, than using microprocessor based DSP engines. The baseband (voice channel) processing is then performed by conventional DSP uC chips, as at the lower rates they become the optimal solution. The architecture of the base station is optimized for just this one task, and does not get in the way of the optimal solution. Since all elements are programmable, the basestation remains flexible (able to deal with various standards, upgrades, and changes). AustinArticle: 112846
Hi Joe, > Hello, I'm looking to do a design involving data rates near 4Gbps and > was looking at using Altera's Stratix II GX transceivers to drive the > data to a 4Gbps single-mode fiber-optic transceiver. I'm interested in > how well the Stratix can perform this task, if anyone has some > experience using the transceivers could you please let me know how well > it worked for you? I've read the Altera's web site on the Stratix II GX > and it sounds very promising, I just want to make sure that is does > what it says it can. I've been toying around with Altera's own Signal Integrity board, and 6GBps over 40" of trace plus 2ft of copper interconnect through SMAs works just fine. 4GBPS over optic should be relatively easy. Feed the GX 100MHz of clock, put the PLLs into 40x, set the ALTGXB transceiver interface to double-width mode (200MHz is workable in the core, 400MHz is really, really stressing things), and as long as you properly do your power decoupling and PCB layout you should have a working design. You may need to tweak the pre-emphasis and/or equalization settings a bit to get the best results, but so far the transceivers seem to be rock-solid. Best regards, Ben Best to contact your local (disti) FAE to provide you with the reference schematic and board layout files of the SI board for reference.Article: 112847
Hi,
Any good ideas for how to program the the SPI Flash on the Avnet Spartan
3E Evaluation Kit?
The Avnet instructions for generating the HEX file which they wrote for
ISE 7.1 don't work in ISE 8.2.03i WebPack. I get an ERROR: Bitstream:44
message and no HEX file. Any other file format which I generate with
iMPACT loads into the SPI according to the Avnet utility, but the FPGA
does not get configured after reconfiguring the jumpers and re powering
the board.
I have the Xilinx Platform Cable USB so was unable to try the Universal
Scan demo.
Xilinx support pointed out the XAPP445 App Note and xspi_usb utility.
This program doesn't work, or I am doing something wrong.
My command line:
xspi_usb -spi_dev m25p40 -spi_epv -mcs -i promdata.mcs -o output.txt
and the error is:
==> Checking SPI device [STMicro_M25P40_ver_00100] ID code(s)
- density = [524288] bytes
= [4194304] bits
- density_code = [0xFF] ==> error: expected [0x12]
On my board I have replaced the PROM for the Cypress USB Controller with
QuickUSB from Bitwise Systems. By replacing the 0 ohm resistor on the
PROM E0 line with a jumper I can choose to power up with or without the
QuickUSB firmware. Without QuickUSB it starts up as a Cypress device
with no PROM and the Avnet utility seems to still work. I can use it to
configure the FPGA but haven't been able to program the SPI Flash as
mentioned above. I have been using the Platform Cable USB to configure
the FPGA, but now my design is working I need to make it permanent.
thanks
Bill
Article: 112848Hi, You can use picoblaze to program the SPI flash. Try this one : http://www.xilinx.com/products/boards/s3estarter/reference_designs.htm in PicoBlaze SPI Flash Programmer It works for Spartan-3E Starter kit, but I don't know whether it works for your board. -kunilArticle: 112849
> This might be an even better solution if you know exactly where you > would like to probe. After PAR, you can open FPGA editor and insert a > "probe" (See right-hand column of FPGA editor -- Add Probe). This > probe is essentially a route connected directly to your net of > interest, and it can be routed directly to a spare pin -- at which > point you could probe it (or drive a LED I guess) to help you debug > your problem. Worked OK once. But crashes on some other attempts. I might not be running it right. I do a BITGEN from the Probe menu. There seems to be no way to save the editted route. > The nifty part of this solution is that you will be able to probe your > problem AFTER synthesis and par -- so you are probing your EXACT > design of interest (ie your problem can't 'go away'). Yes it seemed to work properly once. If I can figure out how to make it work consistently, it will be a great tool. Thanks. Brad Smallridge Ai Vision > > Hope that helps > > Gordon > Avnet FAE > > > Brad Smallridge wrote: >> I have a bug and it seems to manifest itself only >> in stealth mode. When I move my LEDs to see what >> the trouble is, the bug goes away. >> >> I am using Xilinx XST v7.1, a ML403 dev board, and >> the issue seems to happen during powerup. A certain >> action freezes and Reset does not help. Timing is >> being met. >> >> I would like to add LEDs to debug the problem without >> there changing the circuit as little as possible. >> Is there a way to do this with incremental design change >> and how do I do that? Can I nail all the logic to the >> same LOCs? Is there a TIG-like constraint that would act >> from the LED output backwards toward the source? >> >> Thanks, >> >> Brad Smallridge >> Ai Vision >
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