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
hi, i start using the rocket-io transceiver macro on the xilinx virtex-II pro device. does anybody have - or know of - some simple sample vhdl-code to start out with ? at this stage i do not aim at a specific transmission protocol, but i want to prove the device working. are there other important things i have to account for ? thanks, andreasArticle: 55376
hi all, Can anybody through light on how the trace back unit can be implemented. I am specifically looking for the trace back units whose architecture is based on RAM. This is because the Logic element/distributed RAM based trace back units occupy a lot of logic area. regards, vikas vikas_akalwadi@indiatimes.com (vikas) wrote in message news:<8df30829.0304300408.6ab4293@posting.google.com>... > My understanding: > As far as synchronising the upper/lower bits to respective upper/lowerArticle: 55377
Could anyone recommend me flash-disk with IDE/ATA for "extremal" application? I found BiTMICRO (www.bitmicro.com) but few of thier technical characteristic seems strange ...Article: 55378
Hello Andreas, the easisiest way to start working with the Rocket-IOs is to make the simplest design you can imaginge: just transmitting 1s and 0s. From there you can playing with the more sophisticated things like clock-correction, comma-detection etc. If you want to get VHDL-code, the easiest way is to use the Architecture Wizard that comes with the ISE-software to roughly configure the macros to your like. After that you can get the VHDL-code for that configuration which you can directly use in ISE. If you want to change anything you can do it directly in the VHDL. BTW: that's the way I normally do it as it is way too much work to write the complete MGT-instantiation for yourself (and error-prone, been down that road myself....) Apart from that, what do you need to consider: - a very good clock, the higher your speed, the better your clock needs to be - a good power-supply, if you just want to play at the beginning use a nice big lab power-supply that will avoid a couple of grey hairs. Cheers, Martin Andreas Wortmann wrote: > hi, > > i start using the rocket-io transceiver macro on the xilinx virtex-II pro > device. does anybody have > - or know of - some simple sample vhdl-code to start out with ? at this > stage i do not aim at a specific > transmission protocol, but i want to prove the device working. are there > other important things i have > to account for ? > > thanks, > andreas > > >Article: 55379
These two conference posters from our research group may be of interest. They give results for raytracing on PC+PCI Xilinx Virtex FPGA board, with hardware written in HandelC. T.Todman and W.Luk. Reconfigurable Designs for Ray Tracing. in Proc. IEEE Symposium on Field-Programmable Custom Computing Machines, K.L. Pocek and J.Arnold (editors), 2001 (yet to go to press, mail the author-tjt97*at*doc.ic.ac.uk) H.Styles and W.Luk. Accelerating Radiosity Calculations using Reconfigurable Platforms. in Proc. IEEE Symposium on Field-Programmable Custom Computing Machines, K.L. Pocek and J.Arnold (editors), IEEE Computer Society Press, 2002 http://ieeexplore.ieee.org/iel5/8168/24313/01106684.pdf?isNumber=24313&prod=CNF&arnumber=1106684&arSt=+279&ared=+281&arAuthor=Styles%2C+H.%3B+Luk%2C+W. Henry Styles PhD Student Custom Computing Group Imperial College > >"Matt Giwer" <jull43@tampabay.rr.com> wrote in message >news:Ri_ma.155738$j8.3403659@twister.tampabay.rr.com... > >> >> Even then, each processor would create an output file in the chosen >> format with all the right headers. So they would have to be processed to >> reassemble instead of simply concatenating them. Ideally instead of each >> processor writing to its own file it would send the results to one >> computer which would then create a single output file. That would be >> another interesting rewrite. >> >> That is why so far I have only addressed the trivial issue of >> animations where the number of frames is assigned by clock speed. >> > >I'm writing my own raytracer that does this (although by no means POV-Ray >quality, I don't have much up right now). My idea is to dole out bunches of >rays to each proc (or maybe specify a light and have each proc produce >rays), and after that all the reflected rays are split up and redistributed >according to how fast each proc is (by a simple benchmark, maybe rays/sec or >something). > > >Article: 55380
I was just getting started playing with these guys, and I was wondering about the "grey hairs" you mention. From the documentation I was looking at, it seemed that realatively low speed rocketIO block-- e.g. < 1 GB/sec-- consumed in the hundreds of milliWatts (~300 if I remember correctly). is this figure way off in one direction or another? --Josh "Martin Kellermann" <martin.kellermann@nospam.xilinx.com> wrote in message news:3EB79679.4060904@nospam.xilinx.com... > Hello Andreas, > > the easisiest way to start working with the Rocket-IOs is to make the > simplest design you can imaginge: just transmitting 1s and 0s. From > there you can playing with the more sophisticated things like > clock-correction, comma-detection etc. > > If you want to get VHDL-code, the easiest way is to use the Architecture > Wizard that comes with the ISE-software to roughly configure the macros > to your like. After that you can get the VHDL-code for that > configuration which you can directly use in ISE. If you want to change > anything you can do it directly in the VHDL. BTW: that's the way I > normally do it as it is way too much work to write the complete > MGT-instantiation for yourself (and error-prone, been down that road > myself....) > > Apart from that, what do you need to consider: > - a very good clock, the higher your speed, the better your clock needs > to be > - a good power-supply, if you just want to play at the beginning use a > nice big lab power-supply that will avoid a couple of grey hairs. > > Cheers, > > Martin > > > Andreas Wortmann wrote: > > > hi, > > > > i start using the rocket-io transceiver macro on the xilinx virtex-II pro > > device. does anybody have > > - or know of - some simple sample vhdl-code to start out with ? at this > > stage i do not aim at a specific > > transmission protocol, but i want to prove the device working. are there > > other important things i have > > to account for ? > > > > thanks, > > andreas > > > > > > >Article: 55381
Hi , iam working with the "ROVING STARS" appraoch for providing FAULT TOLERANCE(FT) to the FPGA's. are there any problems with this method. or this is the best for implementing FT. thanx in advanceArticle: 55382
did you mean external ?!? "Mikhail" <kostkin@asicdesign.ru> wrote in message news:b983v1$al2$1@news.wplus.spb.ru... > Could anyone recommend me flash-disk with IDE/ATA for "extremal" > application? > > I found BiTMICRO (www.bitmicro.com) but few of thier technical > characteristic seems strange ... > > >Article: 55383
Hi Martin, Any board signal integrity simulator would take them. Hyperlinx and Cadence's SpecctraQuest come to mind. These, unfortunately, are not free. If you are only interested in approximate data about slew-rates of I/Os, it is easy to translate an IBIS model into a spice model, then you could try to use Berkeley's spice to simulate it. I don't personally know anyone who has done this. Hope that helps, Ljubisa Bajic "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:<W9Kta.61594$e8.647175@news.chello.at>... > Ben, > > what tool are you using for the IBIS models? Anything available for free :-) > > Martin > -- > -------------------------------------------------------- > JOP - a Java Processor core for FPGAs now > on Cyclone: http://www.jopdesign.com/cyclone/ > > "Ben Twijnstra" <btwijnstra@SPAM.ME.NOT.chello.nl> schrieb im Newsbeitrag > news:gGBta.1290893$sj7.53360703@Flipper... > > Hi Joona, > > > > > Ibis model for Cyclone is coming soon, promises Altera's web page. > > > Does anyone have a specific information of relase date or something? > > > Is there some compatible models available now, or some other way? > > > > I'm expecting IBIS support in version 3.0, due in June. Given the fact > that > > the Cyclone devices are built on the same process as Stratix I'd use those > > models in the meantime. Of course the Stratix have a different internal > > power distribution network so there will definitely be differences, but > > curve shapes should be similar. No idea about pin RLC values though. > > > > Best regards, > > > > > > > > Ben > >Article: 55384
Martin, I agree the demo version has been limited so that you are enticed to buy a license, but it is easy to convince your boss that one license is well worth it -- it will save 3 to 4 re-spins for each pcb, which will save untold costs and time to market losses. Not that I would mind folks taking months and months to get their Cyclone devices up and running .... Austin Martin Schoeberl wrote: > Have found the HyperLynx, but only a demo version for download where you > can't simulate a changed network :-( > > It's like in the old days to get the information: > As I started with electronic/computer it was hard to get the > datasheets/books. With the Web everything changed. Just type a part number > in google and you get the datasheet. > Now the important information is burried in simulation meodels. A very good > thing if you have all the simulators. But without... > > Martin > -------------------------------------------------------- > JOP - a Java Processor core for FPGAs now > on Cyclone: http://www.jopdesign.com/cyclone/ > ----- Original Message ----- > From: "Falk Brunner" <Falk.Brunner@gmx.de> > Newsgroups: comp.arch.fpga > Sent: Monday, May 05, 2003 10:40 PM > Subject: Re: Output switching time > > > "Martin Schoeberl" <martin.schoeberl@chello.at> schrieb im Newsbeitrag > > news:Xbxta.49767$e8.532192@news.chello.at... > > > > > c.) I have no simulation sw for IBIS > > > > Have a look for hyperlynx. Sorry, I dont have a link at hand (Austin, > looks > > like this is your turn ;-). The software comes in a free trail version, > nice > > to play with and get a feeling about output drivers and terminations. > > > > -- > > MfG > > Falk > > > > > > > >Article: 55385
Martin, Unfortunately, the methods that we both use to control slew rate behave well ONLY when they drive a real load. That said, without simulating, what you are asking for is not possible to provide, unless it is into a "typical load." Such a typical load would be hard to imagine. By the by, the Xilinx Hotline SI experts support just such "what if" IBIS simulations. Just open a case stating what your driver and receiver are (ie the device, and the IOB attributes eg LVCMOS3.3V 4mA SLOW), and the pcb trace length and impedance connecting them together. It is no substitute for your own license (as you don't get to play with it, and see the sensitivities), but for a quick "what if" and sanity check we have found this to be a useful service. Austin Martin Schoeberl wrote: > Greg, > thanks for the information. It would be nice if the change of the slew rate > could be stated in the datasheet. You don't always want to run a simulation > (with tools you don't have access to) to get a simple information like: > When I turn the slow sr on, do I meet my timing e.g. for an async. ram? > > Sorry for my ignorance about the IBIS models on the web. > > Martin > -- > -------------------------------------------------------- > JOP - a Java Processor core for FPGAs now > on Cyclone: http://www.jopdesign.com/cyclone/ > "Greg Steinke" <gregs@altera.com> schrieb im Newsbeitrag > news:5c1de958.0305051840.6fd3fca6@posting.google.com... > > Martin, > > A few comments: > > - You had asked in a previous posting how slow slew rate works. In > > Cyclone devices (and most Altera FPGAs) the slow slew rate setting > > works by adjusting the rate at which the signal at the gate of the > > driver is switched from low to high or vice versa. In this way the > > actual DC drive strength is unchanged, but the slew rate is changed. > > It does make it difficult to model in a hand calculation however. > > > > - We have a beta program for the Cyclone IBIS models running today. > > Please contact your FAE to join this program. The final, fully > > correlated Cyclone IBIS models will be available in July. > > > > - In general, IBIS models are distributed either directly on the web > > (see > http://www.altera.com/support/software/download/ibis/stratix/ibs-stratix.htm > l) > > or through Quartus II, which makes the full-chip IBIS model. So even > > if the version of Quartus II that you use does not generate an IBIS > > model, you can still download them from the web site. > > > > - We (and some other FPGA companies) no longer publish the IV curves > > in the datasheet as there are many IO options. In the old days we'd > > have 5V, maybe 3.3V, that's it. But now there's often many IO options, > > between drive strength, IO standard, and so forth. Not to mention PCI > > clamp and slew rate, even though they don't directly affect the IV > > curve in the normal operating range. > > > > Sincerely, > > Greg Steinke > > gregs@altera.com > > > > > > "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message > news:<Xbxta.49767$e8.532192@news.chello.at>... > > > Peter, > > > I don't have to get exact values. Just interested to get a feeling for > the > > > rise time and the dI/dt. For my application fast rise time is not > necessary > > > and just makes problems with the EMC test. > > > I took the 80 mA for 1 V from a static plot. Dynamic it can only be > slower > > > (better for me). > > > After 1V the output is more like a current source. So using only the > > > resistance part of the output transistor is the worse case. > > > Perhaps it would be better to model it (the ACEX output) with 6 R till 1 > V > > > (like you suggested) and than with, let's say, a 150 mA current source. > (But > > > I'm now to lazy to calculate it by hand, will model it in spice). > > > > > > About IBIS: > > > a.) IBIS is not available for Cyclone now. > > > b.) IBIS is not available with the Quartus Web edition. And I will > not > > > bye a license till VHDL synth. works like in leonardo and the post route > > > simulator can simulate my design) > > > c.) I have no simulation sw for IBIS > > > > > > Just to get an idea of the output stage it would be nice to add plots > and > > > typical values in the Cyclone data sheet. > > > > > > Martin > > > -- > > > -------------------------------------------------------- > > > JOP - a Java Processor core for FPGAs now > > > on Cyclone: http://www.jopdesign.com/cyclone/ > > >Article: 55386
Unfortunately it only has a 10 Mbps Ethernet connection instead of a 10/100. Bummer if you need to transfer a lot of data. If it had a 10/100 connection, I would have purchased it over the Altera NIOS Stratix 1S10 Development Board. Jim azafar@iupui.edu (Atif Zafar) wrote in message news:<6ed146ef.0305051755.50e81dec@posting.google.com>... > Ziad: > > Check out http://www.mjl.com/product/mjlstratix.asp > I like this board because it is inexpensive ($795) and has an EP1s25 > device. It also has integrated VGA output. I anticipate a graphics > project using FPGA's. > > Atif. > > zabulebdeh@yahoo.com (Ziad Abu-Lebdeh) wrote in message news:<f784b02b.0305030542.5976b082@posting.google.com>... > > Hi Atif, > > > > I am not familiar with the MJL kit you are talking about, but Altera > > does have a 1S80 Kit for DSP. Check it out here: > > http://www.altera.com/products/devkits/altera/kit-dsp_stratix_pro.html > > > > Ziad Abu-Lebdeh > > > > azafar@iupui.edu (Atif Zafar) wrote in message news:<6ed146ef.0305010820.682b01be@posting.google.com>... > > > Does anyone have experience with the MJL Stratix dev kit. It is the > > > lowest cost Stratix EP1s25 kit I could find. Anyone know whether it > > > can handle devices denser than the 1s25 (i.e. 1s40 or 1s80?). I have > > > an imaging and 3d graphics pipeline project. Does anyone know whether > > > the Virtex II are a better choice or the Stratix? Thanks. > > > > > > Atif Zafar > > > Indiana UniversityArticle: 55388
I've just tried ibis2spice for a convertion. But Orcad Spice complains about the converted library. Martin -- -------------------------------------------------------- JOP - a Java Processor core for FPGAs now on Cyclone: http://www.jopdesign.com/cyclone/ "Ljubisa Bajic" <eternal_nan@yahoo.com> schrieb im Newsbeitrag news:9b0afb2c.0305060638.2c6f11ac@posting.google.com... > Hi Martin, > > Any board signal integrity simulator would take them. Hyperlinx and > Cadence's SpecctraQuest come to mind. These, unfortunately, are not > free. If you are only interested in approximate data about slew-rates > of I/Os, it is easy to translate an IBIS model into a spice model, > then you could try to use Berkeley's spice to simulate it. I don't > personally know anyone who has done this. > > Hope that helps, > Ljubisa Bajic > > "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message news:<W9Kta.61594$e8.647175@news.chello.at>... > > Ben, > > > > what tool are you using for the IBIS models? Anything available for free :-) > > > > Martin > > -- > > -------------------------------------------------------- > > JOP - a Java Processor core for FPGAs now > > on Cyclone: http://www.jopdesign.com/cyclone/ > > > > "Ben Twijnstra" <btwijnstra@SPAM.ME.NOT.chello.nl> schrieb im Newsbeitrag > > news:gGBta.1290893$sj7.53360703@Flipper... > > > Hi Joona, > > > > > > > Ibis model for Cyclone is coming soon, promises Altera's web page. > > > > Does anyone have a specific information of relase date or something? > > > > Is there some compatible models available now, or some other way? > > > > > > I'm expecting IBIS support in version 3.0, due in June. Given the fact > > that > > > the Cyclone devices are built on the same process as Stratix I'd use those > > > models in the meantime. Of course the Stratix have a different internal > > > power distribution network so there will definitely be differences, but > > > curve shapes should be similar. No idea about pin RLC values though. > > > > > > Best regards, > > > > > > > > > > > > Ben > > >Article: 55389
I have different architectures for a design. I would like to compare them for speed, area and power consumption. In the Xilinx map report, I see that one is reported to take less Slices, but has a higher "total equivalent gate count" than the other. Which is the more valid measurement of area and why? Why do they not run in sync?Article: 55390
if Opencores.org is a little more strict about >the quality of the work getting uploaded, I think some of them will be >useful even in commercial designs. Will be? That's future tense. This thread does a bit of talking about OpenCores.org, but apparently you guys haven't actually been there in recent months -- years? That should be past tense, as in it is done. OpenCores IP has been used in many commercial products already. It's all over their web page.Article: 55391
"ah" <andrew@hanvey82.freeserve.co.uk> ha scritto nel messaggio news:b906aq$n3t$1@newsg4.svr.pol.co.uk... > Hi > Im currently working on a project which will have a camera data digitisted > at 20MHz 16 bit data. > Then brought into FPGA and converted to 32 bit data and then written into > external SDRAM. Just finished a very similar project. Digitize video composite, store in memory (4 frames), and real-time playback of live video or stored images. I had also to overlay a color graphic layer. I used a 16 bit sdram, clocked at 54 Mhz, to record and play two streams (in/out) 27 Mhz, 8 bit, and a graphic overlay. This has been useful to me: 1. learn very well data input and output format, timings, syncs. You have to keep that very well clear in mind. 2. Went to www.micron.com web site, they have by far the most clearly written datasheet for SDRAM. Download also some other vendor's, such as Hynix, ICSI, ISSI... just to compare things. 3. Read all the app note you find on sdram controllers from your favorite vendor. Study their implementation. You'll find that most probably you have not to support all the commands an sdram can process; I preferred to design my own controller, supporting just fixed burst reads, writes, refresh and mode set. The task is simpler than what may seem at a first glance. Just think very carefully about timings, and state changes.. To me, has been a very very rewarding experience. I modeled the external decoder and encoders, and attached also the ram model from Micron. Adding one block at a time, I was finally able to simulate a whole functional system (a complete frame store/playback). The sdram interface worked like a charm first time I downloaded to actual hardware. Really! The most difficult part, in my case, was not the sdram controller, but the arbiter that grantes access to ram to input, output, on screen display, refresh, and CPU read / writes of the graphic screen, in a way that some little fifos around doesn't under/overflow. That was needed because I had to squeeze as much bandwidth as possible for the CPU access, without pushing up the frequency or bus width. The CPU was also not able to sync to video, for many reasons.. You can probably avoid that with a careful sequencing of the processes. I used Xilinx Spartan IIE, with Webpack ISE 5.1, using XST vhdl flow. The tools worked good, with some quirks/bugs sometimes, that you could work around. Let all of us know if you need help, personally I'll gladly provide some link to readings. Bye, and good luck!Article: 55392
> Probably the easiest way to do something like this is to buy one of the standard PCI interface chip eval cards, and couple the > camera directly to > it. Then use the PCI bus to stream video into PC memory - giving you hundreds of Mb !. Just a couple of days work ... > I'd like to experiment with such a system; what stops me is the software on the host side; even if I have some experience in Win32 and DirectX, I can't cope with writing a driver for a PCI card... Is there an "easy" way to make visible to Windows as a DirectX source a custom PCI card that provides live video data ?Article: 55393
Sounds like a very interesting project .. could you tell us a little about the application ? I'm always interested to know where these cool projects are used. CB > >Just finished a very similar project. Digitize video composite, store in >memory (4 frames), and real-time playback of live video or stored images. I >had also to overlay a color graphic layer. >I used a 16 bit sdram, clocked at 54 Mhz, to record and play two streams >(in/out) 27 Mhz, 8 bit, and a graphic overlay. > >This has been useful to me: > >1. learn very well data input and output format, timings, syncs. You have to >keep that very well clear in mind. >2. Went to www.micron.com web site, they have by far the most clearly >written datasheet for SDRAM. >Download also some other vendor's, such as Hynix, ICSI, ISSI... just to >compare things. >3. Read all the app note you find on sdram controllers from your favorite >vendor. Study their implementation. > >You'll find that most probably you have not to support all the commands an >sdram can process; I preferred to design my own controller, supporting just >fixed burst reads, writes, refresh and mode set. The task is simpler than >what may seem at a first glance. Just think very carefully about timings, >and state changes.. > >To me, has been a very very rewarding experience. I modeled the external >decoder and encoders, and attached also the ram model from Micron. Adding >one block at a time, I was finally able to simulate a whole functional >system (a complete frame store/playback). >The sdram interface worked like a charm first time I downloaded to actual >hardware. Really! > >The most difficult part, in my case, was not the sdram controller, but the >arbiter that grantes access to ram to input, output, on screen display, >refresh, and CPU read / writes of the graphic screen, in a way that some >little fifos around doesn't under/overflow. That was needed because I had to >squeeze as much bandwidth as possible for the CPU access, without pushing up >the frequency or bus width. The CPU was also not able to sync to video, for >many reasons.. > >You can probably avoid that with a careful sequencing of the processes. > >I used Xilinx Spartan IIE, with Webpack ISE 5.1, using XST vhdl flow. The >tools worked good, with some quirks/bugs sometimes, that you could work >around. > >Let all of us know if you need help, personally I'll gladly provide some >link to readings. > >Bye, and good luck! > > > > > > > > > > > > > > > > >Article: 55394
Antonio Pasini wrote: >>Probably the easiest way to do something like this is to buy one of the > standard PCI interface chip eval cards, and couple the >>camera directly to >>it. Then use the PCI bus to stream video into PC memory - giving you > hundreds of Mb !. Just a couple of days work ... > > I'd like to experiment with such a system; what stops me is the software on > the host side; even if I have some experience in Win32 and DirectX, I can't > cope with writing a driver for a PCI card... > > Is there an "easy" way to make visible to Windows as a DirectX source a > custom PCI card that provides live video data ? All you need is a memory mapping of the PCI-Board. This you can find in the DeviceDriverKit from Microsoft. From there it is just a walk through all the functions of DirectX, but you wrote that youre familiar with that ... cheersArticle: 55395
The 'gate count' is more or less a marketing number. It is the
number of asic gates the design would take if transferred to an
ASIC as is. Other than as a bragging number, it has little
use. The gate count will vary depending on how the LUT is
used. SRL16's represent a lot more gates than a LUT used as an
AND gate, for example. The slice count is also somewhat skewed
because it is a count of occupied slices. You can have a design
that uses less than 50% of the resources return a slice count of
100% if the design is lightly packed. A better estimate is the
LUT and F counts, although there is still some room for slop
since some LUTs will block the use of flip-flops (eg, an SRL16
blocks the flip-flop unless the output of the SRL16 connects to
the flip-flop D input).
RM wrote:
> I have different architectures for a design. I would like to
> compare them for speed, area and power consumption.
>
> In the Xilinx map report, I see that one is reported to take
> less Slices, but has a higher "total equivalent gate count"
> than the other.
>
> Which is the more valid measurement of area and why?
>
> Why do they not run in sync?
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin,
1759
Article: 55396> Glen Herrmannsfeldt wrote: > > > The original question was in the XC4000 days, so I don't know if things have > > changed since. 12dB is probably good enough. The important question was if > > a fan and/or heatsink would be required. It is easy to imagine high clock > > rates with a significant fraction of FF's changing state on each clock > > cycle. "Ray Andraka" <ray@andraka.com> wrote in message news:3EB685FA.D48AB9F3@andraka.com... > 4000 series parts didn't have the luxury of xpower. Late in the series Xilinx > did publish a spreadsheet estimator for 4K power. Before that, the data sheet > had a section that described the power of various features in the FPGA, enough > for a user to work up a power estimate by hand (it was very tedious). The > easiest method back then, and probably still now, was to make some measurements > and then degrade the measured results for margin. Well, I was trying to convince someone that an FPGA based design would be better than an ASIC design, before either one was built. > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 -- glenArticle: 55397
I have to agree with you. I'm definitely interested in accessible FPGAs for hobbyists. Robotics is a pretty popular hobby these days and most amateur projects are centred on microcontroller devices. But CPLDs and FPGAs are in many ways much more logical. With a microcontroller, dealing with multiple tasks with interrupts can be a headache. With a programmable logic device the design flows much more naturally and dealing with asynchronous events like collisions with a wall becomes much easier. But there are few devices that are easy for hobbyists to physically work with. The XCR3064XL is OK as you can get 0.1" spacing PLCC44 sockets. (Incidentally the lowest cost board for this is about $50 but the component itself costs only $3 so that stuff about the board being as cheap as the parts is plainly false. I built a working programmer for one of these things on a breadboard for about $4). But at 1600 gates there's a limit to how much behaviour you can get. I'd love to see a 50k gate device, say, in a similar package. There'd be plenty of I/O for robot peripherals and enough logic to have it do some fun stuff. -- TorqueArticle: 55398
Torquemada <torquemada1@nospam.sigfpe.com> wrote: : I have to agree with you. I'm definitely interested in accessible FPGAs : for hobbyists. Robotics is a pretty popular hobby these days and most : amateur projects are centred on microcontroller devices. But CPLDs : and FPGAs are in many ways much more logical. With a microcontroller, : dealing with multiple tasks with interrupts can be a headache. : With a programmable logic device the design flows much more naturally : and dealing with asynchronous events like collisions with a wall becomes : much easier. But there are few devices that are easy for hobbyists to : physically work with. The XCR3064XL is OK as you can get 0.1" : spacing PLCC44 sockets. (Incidentally the lowest cost board for this is : about $50 but the component itself costs only $3 so that stuff about : the board being as cheap as the parts is plainly false. I built a working : programmer for one of these things on a breadboard for about $4). : But at 1600 gates there's a limit to how much behaviour you can get. I'd : love to see a 50k gate device, say, in a similar package. There'd be plenty : of I/O for robot peripherals and enough logic to have it do some fun stuff. Reconsider. Also QFP with 0.5mm pitch is doable for somehow advanced hobbyists. There are a lot of reports on the net. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 55399
Torquemada wrote: > > I have to agree with you. I'm definitely interested in accessible FPGAs > for hobbyists. Robotics is a pretty popular hobby these days and most > amateur projects are centred on microcontroller devices. But CPLDs > and FPGAs are in many ways much more logical. With a microcontroller, > dealing with multiple tasks with interrupts can be a headache. > With a programmable logic device the design flows much more naturally > and dealing with asynchronous events like collisions with a wall becomes > much easier. But there are few devices that are easy for hobbyists to > physically work with. The XCR3064XL is OK as you can get 0.1" > spacing PLCC44 sockets. (Incidentally the lowest cost board for this is > about $50 but the component itself costs only $3 so that stuff about > the board being as cheap as the parts is plainly false. I built a working > programmer for one of these things on a breadboard for about $4). > But at 1600 gates there's a limit to how much behaviour you can get. I'd > love to see a 50k gate device, say, in a similar package. There'd be plenty > of I/O for robot peripherals and enough logic to have it do some fun stuff. > -- > Torque Sounds like an opening for a module - there is a company doing this with ProASIC Flash FPGAs, they also sell Softcore uC, and programmers. IIRC they mount the BGA onto a DIP28 compatible PCB, and that module is then 'project deployed' Or, if CPLDs will do, the latest Atmel development kit has a plug-in daughter board, (2 40 pin dual row headers), and you can deploy that. (PLCC84 ZIF on the card for ATF1504 or ATF1508 64/128 macrocell devices ) These devices are 5V single rail, so are -jg
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