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
Quiet Desperation <nospam@nospam.com> wrote in message news:<060420051752320025%nospam@nospam.com>... > Any chance of there ever being an FPGA where one or more of the > SelectRAM blocks is nonvolatile? > > I design a lot of stuff that is programmable and reconfigurable beyond > the FPGAs. I commonly need to store the setting of digital delay chips > and switch settings and other control lines so that a unit powers up > with everything in the state desired by the end user. > > Currently I use little automotive serial EEPROMs, but, dang but it'd be > nice to have a little EEPROM inside an FPGA. Just one 18Kbit block > would do wonders. NvM in a 90nm std CMOS process is not easy to do. There's only one solution I know of (Virage's NOVeA), but 18Kbit would be a large chunk of silicon. Embedded FLASH in 90nm is years off, and by then, FPGAs will be 65 / 45nm. An MCP would be nice, but this isn't really a huge advantage over having an external memory as FPGAs have so many I/Os. Can't you write your configuration data into your FPGAs configuration PROM? Cheers, JonArticle: 82126
Not quite an entire solution but you can store "fixed" parameters in the programming flash memory. Xapp482 has coverage of this and is here http://www.xilinx.com/bvdocs/appnotes/xapp482.pdf . John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Quiet Desperation" <nospam@nospam.com> wrote in message news:060420051752320025%nospam@nospam.com... > Any chance of there ever being an FPGA where one or more of the > SelectRAM blocks is nonvolatile? > > I design a lot of stuff that is programmable and reconfigurable beyond > the FPGAs. I commonly need to store the setting of digital delay chips > and switch settings and other control lines so that a unit powers up > with everything in the state desired by the end user. > > Currently I use little automotive serial EEPROMs, but, dang but it'd be > nice to have a little EEPROM inside an FPGA. Just one 18Kbit block > would do wonders.Article: 82127
We can offer a hardware solution to this in our Broaddown2 product. We can support up 17 input lvds pairs and a lot more outgoing. The receive terminator resistors are an option on the board which can be fitted at the cost of 30 pounds UK, or equivalent. You can fit yourself if you are very good with a soldering iron but beware as the resistor sites are 0201 size. The software side would be a custom design with associate costs and timescales. 200-400 Mbit/s is achieveable although at 400 MBit/s you will need some care to get that through-put on the 32bit/33MHz PCI bus. Details of Broaddown2 on the website listed below. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "soos" <marcsok@yahoo.com> wrote in message news:1112822263.272498.155130@l41g2000cwc.googlegroups.com... > Hello, > > As a part of a project I am looking for a FPGA on PCI that has 8 LVDS > channels and the driver of this card that enables all the 8 channels of > read and write. > > Total data transfer capacity is 200-400 Mbps. > > Questions are: > > 1.Is this data rate achievable? > 2.Can anyone point a solution for this design? > > Any help will be appreciated, > Thanks in advance, > Marc. >Article: 82128
> I'm sad to hear that there is a patent on the ARM Thumb instruction set > that extends to the general principle, because something like it is > what the PowerPC architecture desperately needs - so that people can > use it the way IBM wants, without compromising the architecture. I didn't think it was on Thumb instructions, but on the method of switching between ARM and Thumb execution (using the LSB of the PC to indicate which mode you're in). Forget Thumb anyway, it's rubbish. What patents there are on Thumb2 should be more interesting. Cheers, JonArticle: 82129
Thomas Womack wrote: > >The cost could not be the issue if you start using Altera devices :-) > > This is probably both troll-bait and an FAQ, but what's the Altera > equivalent of something like the Xess $199 XC3S1000 or $349 Avnet > XC4VLX25? (that is, a cheap board with a chip on it as large as > the free tools support, and some quick-win peripherals) > Tom Funny how a $399 device ends up on a $349 board. (Source: Avnet's Part Search) It might be better to look at device prices. Karl.Article: 82130
In article <e87b9ce8.0504070204.5f80c342@posting.google.com>, jon@beniston.com (Jon Beniston) writes: |> |> > I'm sad to hear that there is a patent on the ARM Thumb instruction set |> > that extends to the general principle, because something like it is |> > what the PowerPC architecture desperately needs - so that people can |> > use it the way IBM wants, without compromising the architecture. |> |> I didn't think it was on Thumb instructions, but on the method of |> switching between ARM and Thumb execution (using the LSB of the PC to |> indicate which mode you're in). Totally different from using the top bit, as was done on the IBM 370 range and others, of course. Regards, Nick Maclaren.Article: 82131
Karl wrote: > Thomas Womack wrote: > > > >The cost could not be the issue if you start using Altera devices > :-) > > > > This is probably both troll-bait and an FAQ, but what's the Altera > > equivalent of something like the Xess $199 XC3S1000 or $349 Avnet > > XC4VLX25? (that is, a cheap board with a chip on it as large as > > the free tools support, and some quick-win peripherals) > > Funny how a $399 device ends up on a $349 board. (Source: Avnet's Part > Search) It might be better to look at device prices. Howdy Karl, Funny how you tried to take a pot shot rather than actually answering his question. He seemed to be genuinely interested in finding a comparable Altera based eval board. As for that price: assuming for a second that the single piece price on the website is even accurate, I am sure that Avnet doesn't just buy one part at a time, from themselves no less, to build eval boards. Even the 100 piece price ($313) that they list contains a huge amount of Avnet markup. And that's even considering that ES (pre-production) parts tend to cost more than production parts. I'm sure it would be the same situation for Stratix II. MarcArticle: 82132
> yes that is the 32 bit IDCODE as read back from the device, > before the IDCODE my program validates the number of > devices in the chain what is sensed correctly to the chain > isnt completly broken I've checked and re-checked the chain (it's only 4 connections!!) with a multimeter, but it appear ok. I've also used the debugger in iMPACT for verify the correct value of the voltage on TDI-TDO-TMS-TCK, and all seems to be ok. This is a strange problem. > hm have you powered VCCAUX with 2.5 and do have VCCIO > on the banks that contain the JTAG pins ? I've powered the four (my FPGA is in TQFP144) VCCAUX with a stable 2.5V, the four VCCINT with a stable 1.2V, and the twelve VCCO all with 3.3V. I've read the XAPP453, on page 13 there is a simple schematic for JTAG configurations, my schematic is similar but with only one FPGA and with a pullup (to the 2.5V) on PROG_B. Until now, I've tried various combinations of M0-M1-M2, HSWAP_EN, PROG_B, INIT_B signals, but with the same poor result : iMPACT (and also your frequency-meter) detects one device, but doesn't read the ID correctly. > when I did a wire wrap proto with Virtex-2000 in BGA then my mistake > was that I did not power the VCCIO in the JTAG banks, and second > was the missing pullup on PROG_B !!! I'm doing my board with wire wrap... I have problems with "only" an XC3S50, I can't imagine what can be a Virtex in BGA ! But if you tell me this, I suppose the capacitors on the power pins of the FPGA aren't critical, is this right? On my board, now, I haven't connected a capacitor between *each* power pin and GND... can be this the cause of my problem??? Thank you for the help. EnzoArticle: 82133
"Enzo B." <enzo_br@virgilio.it> schrieb im Newsbeitrag news:nT95e.747333$b5.33584256@news3.tin.it... > > yes that is the 32 bit IDCODE as read back from the device, > > before the IDCODE my program validates the number of > > devices in the chain what is sensed correctly to the chain > > isnt completly broken > > I've checked and re-checked the chain (it's only 4 connections!!) with a > multimeter, but it appear ok. I've also used the debugger in iMPACT for > verify the correct value of the voltage on TDI-TDO-TMS-TCK, and all seems to > be ok. This is a strange problem. > > > hm have you powered VCCAUX with 2.5 and do have VCCIO > > on the banks that contain the JTAG pins ? > > I've powered the four (my FPGA is in TQFP144) VCCAUX with a stable 2.5V, the > four VCCINT with a stable 1.2V, and the twelve VCCO all with 3.3V. > I've read the XAPP453, on page 13 there is a simple schematic for JTAG > configurations, my schematic is similar but with only one FPGA and with a > pullup (to the 2.5V) on PROG_B. > Until now, I've tried various combinations of M0-M1-M2, HSWAP_EN, PROG_B, > INIT_B signals, but with the same poor result : iMPACT (and also your > frequency-meter) detects one device, but doesn't read the ID correctly. > > > when I did a wire wrap proto with Virtex-2000 in BGA then my mistake > > was that I did not power the VCCIO in the JTAG banks, and second > > was the missing pullup on PROG_B > > !!! > I'm doing my board with wire wrap... I have problems with "only" an XC3S50, > I can't imagine what can be a Virtex in BGA ! > But if you tell me this, I suppose the capacitors on the power pins of the > FPGA aren't critical, is this right? On my board, now, I haven't connected a > capacitor between *each* power pin and GND... can be this the cause of my > problem??? > > Thank you for the help. > > Enzo no caps on *each* pins are not so critical at all. hm the JTAG cable, that could be a problem, if it is self made have you used the same JTAG cable with any other FPGA? I have build quite a many cables, and there are problems sometimes. it can even happen that 5 wires to LPT port works better than Xilinx original cable IV possible the TDO out from FPGA is not enough voltage or something as it looks like the FPGA is ok as of connections then I would suspect the download cable as next.. anttiArticle: 82134
source is added to "xilcores" project at http://gforge.openchip.org/projects/xilcores/ this mini IP-core is not "done by Antti" so its user contribution and very well done, better documented, can be used in simulations and even uses RLOC to get max density and performance out. Antti PS the FpgaFreqMeter is also updated and hopefully fixes the problems with jtag chain where FPGA is not last (like the digilent board etc)Article: 82135
UUPS!! not 1 slice but 1 CLB !! (eg 4 slices) antti "Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:d33atl$fub$01$1@news.t-online.com... > source is added to "xilcores" project at > http://gforge.openchip.org/projects/xilcores/ > > this mini IP-core is not "done by Antti" so its user contribution and > very well done, better documented, can be used in simulations > and even uses RLOC to get max density and performance out. > > Antti > PS the FpgaFreqMeter is also updated and hopefully > fixes the problems with jtag chain where FPGA is not last > (like the digilent board etc) > > >Article: 82136
Hi, according to the new Virtex-II Platform User Guide the major address of a CLB goes from 4 to n+4 (with n CLB columns). If you have a module located on such an FPGA can one say that the major addresses of this module are contiguous? I guess the VirtexE has an addressing where neighboured CLBs have a mja-delta of 2. The User Guide also says: "During configuration, frames are programmed in order of increasing block, major, and minor address[...]" p.317 Thanks for any kind of information. Regards ChrisArticle: 82137
Not true, most of those that were in the cloning business had the same urgency as the original if not more so, if you want to eat somebody elses lunch you have to be quick. The longer an alternative compatible takes to come out, the less crumbs left over for them, its a well known model, even worse the price is falling and you get squeezed into the little part of the curve. regards johnjakson at usa dot comArticle: 82138
Thanks Vic, your advice was quite reassuring. I solved the problem. The DSP48 slice automatically sign extends the data going into the slice. The 24-bits coming out of the multiplier are sign-extended to 28-bits when I add the results of the multiplier. This is giving me enough resolution to maintain the fidelity of demodulated output. Thanks MORPHEUSArticle: 82139
Hi Antti, yes the cable is self-made, and with this I've programmed some CPLDs but never an FPGA. I've experimentally seen that it works down to 3.7V connected to an XC9572 (the only CPLD I have here at home!). I suppose the cable also works correctly at lower voltages, since the two 74HC125 runs down to 2V. Currently I can't see the signals with an oscilloscope, but have tried to read the ID with a 3.3V powered buffer connected between TDO of the FPGA and the programmer, but have obtained the same result. At this point, I have only two things: 1) buy a 3.3V CPLD and re-test the cable (is this a realiable test?) 2) try the cable on another PC (I know that sometimes the parallel port can give problems). I'll tell you if I'll discover the problem... Thank you again. EnzoArticle: 82140
> We use the LOCKED signal as async reset for our XC2V and XC3S
designs.
please, use sync resets
a) statemachines
releasing this reset, you can't ensure that all FFs become
active with the same clock-edge - so a one-hot-sm may not be one-hot
anymore
b) ressources
using sync resets will save ressources, because synthesis can
use reset-port of a FF to implement sync. logic
> In case we have several cascaded DCMs, the 1st one rst the 2nd one,
> which in turn rst the 3rd one, till the last one which rst the
> complete design.
you're not (under 'normal' circumstances) allowed to cascade 3 DCMs,
because 2nd DCM's output-jitter will exceed 3rd's
input-jitter-requirement
Jochen
Article: 82141> I don't think it's quite that easy. You can get a concavity > on an edge whose gradient is always positive... > > *** '*' = object, '.' = concavity > ****.. > *****.... > ******..... > ************* > ************** In this example of yours, the number of pixels added to the lines are 1,1,1,7,1, and the 7 can easily be picked out of the crowd. I did the coding for this last night, however, I ran into a problem with steeper edges like: ** ** *** *** **** And here the number of pixels added are 0,1,0,1 which would indicate two convexities where there should be none. > However, the algorithm I developed wouldn't make much sense > in FPGA because it maintains dynamically allocated and linked > data structures. I'd be very interested to know how you > did it in hardware. The algorithm I use comes out of the 60's and is very clever in popping in and popping off labels and label markers on a FIFO stack. It can generate a memory list of linked labels, if required, for a second pass at the image and combine more complicated features, however, I don't need this, I am trying to separate blobs. > >>So are you doing vision now? > > No longer. But I still think it's about the most fun > you can have in electronics without exciting too much > attention from the authorities :-) Agreed.Article: 82142
> I think the PITA part of vision is the hardware simulation. It is usually > dog slow since it is a simulation usually of multiple video frames and the > hardware might be working at 10's to 100's of MHz (eg, one vision system I > designed used a 108 MHz process clock and NTSC video input. A video field > takes 1.8 Million clocks, or the better part of a day per field to > simulate the full FPGA design). Hi, Ray. Yes, slow indeed. I am using the free Xilinx version of ModelSim. I generally run a few test BMP files during the day and then run a real image over night. What I could use is a compiled VHDL that runs fast since when I run the larger images there is really too much information to track down anyway, I just look at the resulting output BMP file.Article: 82143
Hello, We have a board with multiple IDE interfaces implemented in Virtex2 device. We are using UDMA 3 protocol. One of the boards is giving a CRC error at random times, erros occurs once in 12 hrs of continous read operations. Error occurs on the same IDE channel. There does not seem to be anything wrong with internal logic, as other instantances of the same IDE module(multiple IDE interfaces) work fine on the same board at the same time. The strobe is routed to general I/O and then routed to IOBs to clock the data in. The data is then picked up by internal clock. Hence strobe is used as a clock only at the IOB's. I also carefully selected the strobe and the data IOBs so as to be able to use the long Hex lines present on the vertical side of the FPGA to route the strobe signal. Hence the skew and delays on the strobe are minimum and within setup and hold times. Yet their are CRC errors once in a bluemoon, the CRC error rate varies from board to board, some boards dont show it at all, others do. The rise time on channels not showing errors is about 10ns and final Vih is about 3.2V. The rise time on channel with CRC error is about 15ns and fianl Vih is about 3V. The above measurements were taken near the cable connector after the termination resistors. From the point of measurement to FPGA there is about 6" of PCB trace. (The termination resistors are near the cable connector as per UDMA spec to match the cable impeadance.) Question is 1) How slow can a strobe/clock signal be before it starts to cause trouble clocking the data?(Due to cross talk or double clocking or any other reasons)Is 15ns rise time too slow for V2 FPGA? All these lines(data/strobe and other lines) run parallel for 6-8" inches on PCB board so I suspect some crosstalk or other SI issues are casuing the problem. All inputs are LVTTL 3.3V, no IBUF delays used on strobe or data. On Strobe pins I have enabled DCI with 50 Ohm resistor. But now my understanding is that for LVTTL 3.3V input pins, DCI does no good. A separate question I was trying to look up the source impeadance/input impeadance of V2 outputs/inputs, couldn't find the number anywhere. Are they specified? Thanks in adavance for taking time out to read the post. BrijeshArticle: 82144
If you use STROBE as a rising-edge clock input, then excessive noise might be superimposed on its falling edge, such that the falling edge actually contains a rising edge clock, which would give you weird timing. Just a wild guess... Peter AlfkeArticle: 82145
Brijesh, Have you considered using the strobe signal at a latch enable rather than a clock? Rise time is then unimportant. t\The IOBs' storage elements can be latches, IIRC. As for pin impedances, you need to use the IBIS files to determine this. Do you have HyperLynx? Cheers, Syms.Article: 82146
Are there non-Xilinx, "zero" static power CPLD options which are targetable from tools that'll run under Linux? AlexArticle: 82147
Austin, The methods discussed in the document mitigate the SEFI but will result in the loss of data (because of reconfiguration). Could you suggest a way (if there is one) of mitigating the SEFI without losing the information ? We would like to try it out even if it complicated. Thanks for your input. -PraveenArticle: 82148
http://www.fpgajournal.com/articles_2005/20050405_cray.htm Leon -- Leon Heller, G1HSM http://www.geocities.com/leon_hellerArticle: 82149
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:4254b2ad@clear.net.nz... > Alex wrote: > These 'school boy' issues with the more mature CPLDs certainly makes > their testing program look thin/non-existant. > Perhaps it is all a ploy to move designs to the latest "hot new > thing" - or maybe they have too many ex-microsoft employees ?:) Jim, Indeed. You'd think they'd have a bunch of hardware with all these parts on them and run a regression test with new releases. As in earlier an earlier thread, I'll be waiting a service pack or three before swapping! Cheers, Syms.
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