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
I am looking at a design that was done several years back which uses several XC3000 devices. All devices are programmed with the same core from a computer on power up. What I am seeing is that once or twice a year, one of the devices will enter a non-recoverable mode. In this mode, the device appears to be in power down or reset. Once in this mode I am no longer able to program the device. Pulling the XC3000's reset low for 10us has no effect. The problem appears random. The only way to reprogram the part is to power down the IC. I have tried running tests where I just reprogram the device, over heat the device, change the supply voltages, etc. and can't reproduce the problem. When the Xilinx device is in this mode, it draws little power. It can be held in this mode for what appears an infinite amount of time and causes no damage to the device. Was there some kind of an undocumented test mode built into the XC3000 that I may be seeing? Does anyone else ever remember seeing a problem like this?Article: 80801
This Boards sounds interesting (the price also). What I din't get is how to add on the 1394 interface so we could plug in our cam. Is it to find a chip and solder ourself? Your project with a 1394 add-on board sounds interesting to. But the time of our project is already running therefore this would probably be to late for us. Nicolas Schwarzentrub John Adair wrote: > Our Broaddown2 has the PCI and the capability to add on the 1394. There are > discounts for students but if that would make it cheap enough I don't know. > We have a project that may give a 1394 add-on board but I don't have a > launch date for this yet. If you are looking at MicroBlaze as a processor > then Broaddown2 currently comes with a $100 discount voucher for EDK that > can be used at one of our partners in the UK. > > We also have a product coming that is aimed at students and is going to be > aimed at the cheap end of the market. It will be PCI based and should be > capable of supporting some of Broaddown2's DIL header add-ons. > > More details of all of this should appear on our website upgrade in 2/3 > weeks time. > > John Adair > Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development > Board. > http://www.enterpoint.co.uk > > > "Nicolas Schwarzentrub" <schwn@hta-bi.bfh.ch> wrote in message > news:d0pg8u$nco$1@news.hispeed.ch... > >>Hi everybody, >> >>we're two students looking for a low cost developer board for our >>diploma work. we intend to plug a camera to the pci board via 1394 and >>process the images throug the fpga and get the processed images from >>fpga via pci. The camera we will use, uses DCAM /IICD >>Now we have several problems: >>-we don't have a high budget, so it should be a low cost solution. >> >>-we have not jet found a board that fits our need, does anybody know >>something cheep that could fit our needs? >> >>-there would be several possibility to solve the connectivity problems: >> >>* best would be to find a board that fits our need, means have at least >>pci, fpga and 1394 on it? any suggestions ont htat? >> >>* if the above point can't be reached we could probably solder our 1394 >>interface ourself on a board. What would then be best for our purpose? >>We could probably use a TSB12LV32 chip from ti if we don't find a board >>with firewire. >>(http://focus.ti.com/docs/prod/folders/print/tsb12lv32.html)? does >>anybody know this? would it then be possible to implement the dcam in >>the fpga? >> >>Thanks to everbody > > >Article: 80802
Andrés <nospam_nussspucke@gmx.de> wrote in message news:<39d2qnF5uomriU1@individual.net>... > Thank you for your answers, > > although I have searched for the topic "reset + release" I am still > confused. > If Mr Randolph says that there in only one global reset path > so does it make any sense to release the reset signals for the different > clock domains separately that is to synchronize the reset with the > corresponding clock and distribute different reset signals? > > > Best regards > Andrés OK. Well, there follows a link with a very interesting paper on potential problems with (too) simple asynchronous resets. http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf Having acknowledged the potential dangers described in that paper, I now systematically create for my VHDL designs a synced reset per clock domain and uses those synced resets as async reset inputs on all registers of the design. I just let the synthesis and PAR tool operate as usual, giving no special directive, and got not problem until now.Article: 80803
"ALuPin" <ALuPin@web.de> schrieb im Newsbeitrag news:b8a9a7b0.0503110036.1b73c25c@posting.google.com... > Hello @ VHDL people out there, > > I have the following problem. Maybe someone of you has experienced the same: > > The signal "input_data" comes from a 12MHz clock domain. > Now I want to sample that signal that way that I generate one sample-enable > which is close to the center position of the bits. > One possibility to do so is to use a over-sampling clock, let us assume > 48MHz. USB?? > So my idea was to sample the "input_data" with a sample-enable directly > in the 90MHz clock domain. > > The problem: 90 is not a multiple of 12. > Is there a possibility to sample the 12MHz signal right in the center ? Sure, just take some smart FSM to track the 12 MHz data signal clocking. Or easier, us a asynchronous FIFO. Regards FalkArticle: 80804
Hi, I am having trouble with the code generated from SelectLink Verilog code generator. Has anyone successfully used the code generated from this web site? http://www.xilinx.com/applications/slcv_v2/slv2.htm Here is the trouble I am having: There is no constraints or simulation files. So I wrote a simple loopback testbench connecting the Xmt side to the receive side of the bi-directional(lvds 32 to 8) Select link code generated. The functional simulations works okay. But, the simulation done after map does not work. I am assuming this might be the problem with the lack of constraints. Appreciate any help on this issue. Thanks much. ThomasArticle: 80805
Austin, You've been quite civil lately, thank you! However I must take exception to a few things that you state. First, I acknowledge that a PPC and Nios(II) are different classes of processors. They serve different applications entirely. That said, we have had a lot of success with Nios I/Nios II due to its flexibility/performance/logic utilization... however the processor is really not the differentiating point: the tools are. What has given Nios its success is the builder tools that we sent out in to the world several years ago now (over 4 years now) and have been continuously refined. The fact that a customer can create a complex system with as many on-chip processors as they desire, interfaces to off-chip processors, memory, their custom IP, and suite of standard peripherals, then wire them together in a few minutes time is what has given us the success. I know that Xilinx has done their best to replicate this, which is great! Keep working on it though; you speak of lost business, well I can tell you from personal experience that the tools I speak of have cost you guys business -- it isn't all about the processor. You mentioned the 'APU', and how their is no equivalent on our side. This isn't true. What you call APU we call either a custom instruction or custom peripheral -- there is a big difference between those two, BTW, and each technology is suited for different applications. We have had customers create systems using a single Nios and a few rather simple accelerators replace *multiple* off-chip processors that each would perform better than Nios. ...but the above is just the beginning. I really believe that this technology will continue to proliferate not only due to the flexibility and cost, but to the design methodologies that will become adopted in the future to accelerate design even more. By the way I had an enjoyable time speaking with Xilinx folks at ESC this week, both in seeing what you are up to and having you folks come talk to us as well. Jesse Kempa Altera jkempa -at- altera -dot- comArticle: 80806
Just for the fun of it. Here's my solution: <http://server1.conquer-space.net/~ulf/fan-shot.jpg> The picture won't be there forever, if you'd like to keep it, you may want to mirror it. Cheers, -- UlfArticle: 80807
"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:aLCdnaIKtqxvNqzfRVn-1Q@rogers.com... > There is a reason why we don't haven't made a chip with a hard processor > since Excalibur. Basically, once you have a highly flexible and > well-accepted soft processor like Nios, there are very very few designs > that can benefit from a hard processor. How does the performance of NIOS compare with that of X's PPC?Article: 80808
ALuPin wrote: > The problem: 90 is not a multiple of 12. > Is there a possibility to sample the 12MHz signal right in the center ? Sample with a 180MHz clock. Kolja SulimmaArticle: 80809
Jesse, Comments below, Austin kempaj@yahoo.com wrote: > Austin, > > You've been quite civil lately, thank you! Well, thanks. Maybe I am mellowing with age? > > However I must take exception to a few things that you state. First, I > acknowledge that a PPC and Nios(II) are different classes of > processors. They serve different applications entirely. That said, we > have had a lot of success with Nios I/Nios II due to its > flexibility/performance/logic utilization... however the processor is > really not the differentiating point: the tools are. They are both important. A larger hurdle to jump is the customer barriers to using a processor in the FPGA. The largest barrier to adoption we see is that the software organization of customer companies "own" the microprocessor code, so they don't like to lose their territory when the hardware group now has a uP. > > What has given Nios its success is the builder tools that we sent out > in to the world several years ago now (over 4 years now) and have been > continuously refined. The fact that a customer can create a complex > system with as many on-chip processors as they desire, interfaces to > off-chip processors, memory, their custom IP, and suite of standard > peripherals, then wire them together in a few minutes time is what has > given us the success. I know that Xilinx has done their best to > replicate this, which is great! Keep working on it though; you speak of > lost business, well I can tell you from personal experience that the > tools I speak of have cost you guys business -- it isn't all about the > processor. Your tools started out better. I would probably grant you that today that you may even have a slight edge still here, although I feel we are closing the gap, and some here would say the gap is closed. The UltraController(tm) might be (in fact) even a simpler means of enagaging the traditional hardware customer with usage of the PPC. The UC is one of our most often downloaded cores. > > You mentioned the 'APU', and how their is no equivalent on our side. > This isn't true. What you call APU we call either a custom instruction > or custom peripheral -- there is a big difference between those two, > BTW, and each technology is suited for different applications. We have > had customers create systems using a single Nios and a few rather > simple accelerators replace *multiple* off-chip processors that each > would perform better than Nios. The APU for the 405 PPC is not just a special instruction interface. The APU allows complex transfers an entire block of memory into/out of the 405PPC automatically in one cycle. We have a core logic FPU attached to the APU that provides a huge speedup over a coded application alone. Without the APU, the speedup is not as spectacular, but is still quite nice if the APU is not used. The ability to get more data into/out of the memory to the registers in a single cycle is key to the speed up. > > ...but the above is just the beginning. I really believe that this > technology will continue to proliferate not only due to the flexibility > and cost, but to the design methodologies that will become adopted in > the future to accelerate design even more. > > By the way I had an enjoyable time speaking with Xilinx folks at ESC > this week, both in seeing what you are up to and having you folks come > talk to us as well. I too, have had many comments about the ESC show. > > Jesse Kempa > Altera > jkempa -at- altera -dot- com >Article: 80810
Paul Leventis (at home) wrote: >>Tom, and to all those who insist on top-posting, what I said was merely a >>suggestion to a user Austin, because she quoted a few posts that have a >>top-down chronological order, and she put her replies on the top. And that >>annoyed me a bit. If it offended anyone, I'm sorry. > > > Well, you've one upped me. Things have gotten heated between Austin and I > before, but I don't think I've ever called him a her ;-) > > - Paul > > Oops...My appologies, again.Article: 80811
Hello, In out project, we have to interface a Compact Flash card with a Spartan-3 fpga in Ultra-DMA mode. In the CF 3.0 specifications it states, that most of the lines need series termination resistors. We were just wondering, if those termination resistors are really needed, since the CF will be no more than an inch away from the Spartan 3. If they are indeed needed, we might have a problem determining the resistors values and doing signal integrity analisys, since we haven't been able to find an IBIS model for a CF card. Best regards GeorgeArticle: 80812
Hi,
We live one formidable time ! ("nous vivons une époque formidable !")
This method of promotion is realy innovative ... good-byes patents !
Hold us informed of the exit of the advertisement :)
usmgn
"Antti Lukats" <antti@openchip.org> a écrit dans le message de news:
d0sbt5$s4b$02$1@news.t-online.com...
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7500055955
>
> Antti
> PS Paul was interested to Know (from first hand) that my guess about S2-GX
> was right :)
> And yes I agree sometimes its wise to delay with some things...
>
>
>
>
Article: 80813The only way I could see this happening is if 1) you do not simulate the circuit and 2) You have synthesis translate_off / translate_on's around the generics in the instantiation code. The reason I say this is if you attempt to simulate this with a bad generic regardless of whether you use translate_off / on in the code, you should see binding errors. If you did not use any translate_off / ons in the code, you should have seen errors during either XST or NGDBUILD as it would have identified the incorrect parameter and properly warned but if those are in the code, the tools ignore them as you are instructing with those commands. I highly suggest to use the HDL Templates (Edit --> Language Templates --> VHDL --> Device Primitive Instantiation --> FPGA --> Clocking Components --> Digital Clock Manager --> DCM) or the Architecture Wizard (Project --> New Source --> IP --> Clocking) to form the instantiation of the DCM. As a beginner, you may want to look at Architecture Wizard as it provides a graphical way to configure the component which helps out in understating this if you are unfamiliar with it. If you prefer doing it yourself, I suggest grabbing the DCM instantiation from the HDL Templates. Using that predefines all attributes so there is no mistakes in typing and also notice there are no "--synthesis translate_off" in there which can also cause the issue as I explained. Either way would likely help avoid this situation. -- Brian Marius Vollmer wrote: > Hi, > > so I was playing for the first time with the DCM of a Spartan 3. It > worked fine but as soon as I used the CLKFX output, the DCM failed to > lock. > > The problem was that I had mistyped the name of the CLKFX_MULTIPLY > generic in the component instantiation as CLKFX_MULT. xst, map, par, > bitgen all ran without complaining although the DCM component in > unisim.vcomponents has no generic named CLKFX_MULT. > > Correcting the typo solved the problem, of course, but it was by pure > luck that I noticed it. > > Does this match your experience? Is that how the ISE tools are > supposed to be "easy"?Article: 80814
Does anyone know where I might obtain some Actel A54SX16P FPGAs in the VQ100 package? Actel has exactly one distributor, and they're out of stock for awhile. We've been searching the gray market some, and I figured I'd ask here. Speed grade doesn't matter, pricing isn't too important (within reason), just the package and the fact that it's the 'P' suffix (we're using it with 5V inputs). We're after about 250, although smaller quantities would be fine too since we don't need them all right away. The sooner we could get some... the better! If you know of a source, please reply to jkolstad71@yahoo.com or to the group. Thank you, ---Joel KolstadArticle: 80815
No matter what approach you use, the only way to sample "exaclty" in the middle of the data bit is to have an analog PLL for clock recovery. If you use an unrelated 48 MHz clock, you can be off by +/- 1/8 bit period if you use an ideal digitally phase locked loop for "effective" clock recovery. A faster sampling rate would provide better than the cumulative 1/4 period. "ALuPin" <ALuPin@web.de> wrote in message news:b8a9a7b0.0503110036.1b73c25c@posting.google.com... > Hello @ VHDL people out there, > > I have the following problem. Maybe someone of you has experienced the same: > > The signal "input_data" comes from a 12MHz clock domain. > Now I want to sample that signal that way that I generate one sample-enable > which is close to the center position of the bits. > One possibility to do so is to use a over-sampling clock, let us assume > 48MHz. > > When stepping to the signal processing of my design > I see that the sampled signal which is in the 48MHz clock domain now > has to be synchronized into a 90MHz clock domain. > > So my idea was to sample the "input_data" with a sample-enable directly > in the 90MHz clock domain. > > The problem: 90 is not a multiple of 12. > Is there a possibility to sample the 12MHz signal right in the center ? > > When using 48MHz sample clock I use a simple counter with which I can > define the position of the sampling point. > > Any suggestions are appriciated. > > Rgds > AndreArticle: 80816
George Mercury wrote: > Hello, > In out project, we have to interface a Compact Flash card with a > Spartan-3 fpga in Ultra-DMA mode. In the CF 3.0 specifications it > states, that most of the lines need series termination resistors. We > were just wondering, if those termination resistors are really needed, > since the CF will be no more than an inch away from the Spartan 3. If > they are indeed needed, we might have a problem determining the > resistors values and doing signal integrity analisys, since we haven't > been able to find an IBIS model for a CF card. > > Best regards > George I have not designed with CF, but I'd be more concerned about the Spartan 3's 3.3v tolerance. The oxide of that device breaks down at 4v and undershoot allowed is minimal as well, like .5vArticle: 80817
"Marc Randolph" <mrand@my-deja.com> wrote in message news:1110509935.634028.77710@g14g2000cwa.googlegroups.com... > > xGMII (RGMII is what we > use) is another, possibly easier way (or at least, slower speed that > doesn't require MGT's). Physical layer chips for 1000Base-T cost > something over ~$10/port. 1000Base-T SFP's cost something approaching > 10x that (depending on volume). Marc, If you don't mind telling, which PHY chip are you using? Thanks, /MikhailArticle: 80818
Johnson Lee wrote: > Hello, > I am writing a character controller using Altera MAXII device. > This controller will monitor the input signals from lpt port. I make > a simulation and download to real chip to verify function, but > unfortunately it won't work as I designed. > The simulation show that the state translate signals was initiated > abnormal.. > I pass this to Altera local FAE, no one knows why, and their "my > support", no response. > I also make the simulaiton on their QII 4.1 and 4.2, the result is > the same. Check out this CPLD tool http://www.swcab.nu/cpld/ CPLD0100-00 MAINBOARD FACT * Quick affirmation of a logical design * Affordable system * Free upgrades over internet * Simple 5V system with a single 9V supply * LAB board on PCB for own experiments * Strap:s in separate box included * Target is ATF1508, allows for verification of 1504 and 1502 design:s * ProChip 4.0 in packet * 64 channel pre connected scanner for all I/O of the ATF1508 * Menu driven system * ATF1508 in delivery * Quick at debugging level and design This should allow you to single step your PLD at 1 Hz or less , while feeding it with stimuli form your PC. It will record what is happening and can store the output values back on the PC. Cost of the board is about $600 + VAT. Built to work with the Atmel CPLDs. If you wan tto try with others, you have to find out a way to adapt. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic ABArticle: 80819
Does anybody know the maximum LVDS-rate of Spartan 3E? I did not find anything in the datasheets, while the Spartan-3 datasheets says 622 Mb/s IO transfer-rate (I think this is valid for LVDS). As we know our friends at X & A, when a nice high number gets quietly removed from the feature-list on the front page of the data-sheet, there is a reason for it... Or was I maybe just blind? Regards, Thomas www.entner-electronics.comArticle: 80820
>> In out project, we have to interface a Compact Flash card with a >> Spartan-3 fpga in Ultra-DMA mode. In the CF 3.0 specifications it >> states, that most of the lines need series termination resistors. We Are the series termination resistors needed in all modes of CF data transfer, or only in the faster modes? >I have not designed with CF, but I'd be more concerned about the >Spartan 3's >3.3v tolerance. The oxide of that device breaks down at 4v and It should be possible to use Vcc = 3.3V for the CF card.Article: 80821
Mika Leinonen wrote: > Are the series termination resistors needed in all modes of CF data > transfer, or only in the faster modes? The specifications only mention line termination with UltraDMA-66 mode, which is the fastest. But it's not that fast, since It's "only" 66MBytes transfered on 16 Bit wide bus. Data is transfered on bost edges of strobe signal so the frequency is no greater then about 16MHz.Article: 80822
Hi everyone, At a trade fair I ran into something called "Miss Univers" from Adveda. It purports to be some incredibly fast hardware/software cosimulation package, but with a twist: it can have your circuit (including embedded CPUs) run backwards, then have you correct something in either HDL or C code, and resume. The demo looked mighty interesting - has anyone of you actually used it? Best regards, BenArticle: 80823
I already have the RTL code available which is designed for ASIC and targeted to work at 200Mhz. Now if I want to implement the logic into FPGA, how can get the idea in advance that how fast my logic can work on the FPGA? What the best way to calculate this number? Is this something you have to think about first before you do FPGA design? BTW, I am going to use the Xilinx VirtexII 6000. Thanks!Article: 80824
John_H wrote: >But are you using a dedicated SPROM? The Spartan-3E is designed explicitly >to gluelessly take advantage of cheap SPI memories allowing a very low >configuration cost even if it takes more configuration bits. Lower than the >other solutions you appear to be considering. If you were making 500k units >in the end of 2006, your price for the XC3S100E plus an SPI PROM would be >about $2.50. > > This particular product has no CPU on the board, and no other FPGA. So, the PROM is dedicated just for this one purpose. As it turns out, the Spartan-II XC2S30 is not big enough (A big thanks to Gabor for pointing this out - it never even ocurred to me that a Spartan-II 30K gates had no relation to a 5 V Spartan 30 K gates.) So, the smallest XC2S50E is about the right size. This product will NEVER, ever see thousands of units made, no less half a million! And, if I do the conversion, I'd need to be testing in a couple of weeks. By 2006, it might be obsolete. Thanks for the info, though. 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