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
Jon Elson wrote: > > > Markus Knauss wrote: > >> Hi all, >> >> at the moment, we are using AT17LV010 configuration devices for a >> spartan 2S100. >> I have to look for a different solution which is not so expensive. >> >> The Xilinx XC17V01 is OTP and more expensive than the AT17LV010. >> >> Does someone know a different prom (OTP, EEPROM, Flash)? > > SST makes a series of VERY cheap serial flash memories. I figured out > how to > create the command bit stream that it needs to command a read starting > from addr > zero function, using just 2 SSI CMOS chips in SSOP packages, so the > interface is > under $1, and the SST chip is well under $2 in small quantities. I had > to make my > own programmer, and a little C program to read the .MCS file and program > the > device. I haven't actually produced a product using this setup yet, but > I did build > a prototype board for Spartan 2E and verify that it could do the FPGA > configure. > I did this for the 2S50E part, but SST has up to 4 mbit chips, I think, > that should > handle the 2S100. > > Jon > Thank you Jon for the hint. It should be possible to get a preprogrammed 8 bit controller (PIC, AVR) for 1$ and with a little bit banging in software you could use the original .mcs file. MarkusArticle: 117676
> PCIE is killing of PCI66 very rapidly This is a good point. > Is this an academic application? If so some vendors like ourselves > have University discount schemes. This is for university research, and we're basically looking for the easiest and cheapest way to get about 600-800 Mbits of data onto a PC without resorting to National Instruments cards (including their FPGA product). We're certainly not closed to the idea of using PCIe, although it would require purchasing new computers. It seems that most FPGA PCI boards are tailored to embedded applications; since our application is a relatively simple one (where the complexity is in transferring the data from FPGA to PC), this seems a bit overkill. Nevertheless, we're still exploring our options (in fact, a Spartan chip could work, but we'd need the higher-end sizes, since we need to process roughly 512 channels of data; this would require quite a bit of the FPGA's resources). John Adair wrote: > Kunal > > I think if such a card does not exist today it probably won't. PCIE is > killing of PCI66 very rapidly although we do hear of other people, > usually Sun machine users, wanting PCI66 and we have considered doing > a PCI66 version of our Broaddown4 product. I would be interested to > hear from anyone else that thinks there is a market for this > interface, even niche smallish quantities, as we could deliver such a > product within a few weeks if a strong requirement exists. > > Your next problem is getting a Virtex level product cheaply. Spartan > level products don't often support PCI66. Our base level version of > Broaddown4 does come just with your price target but at the moment is > the wrong interface with the PCIE. > > Is this an academic application? If so some vendors like ourselves > have University discount schemes. > > The PLX style approach isn't used by many FPGA development board > manufacturers as usually they are trying to demo PCI inside a FPGA. We > are doing an alternative to this in some planned products and you can > see the first implementation in our Trarfessock1 board that has a FPGA > for the PCI(Cardbus) interfaces and an independent one for the main > logic development. This allows a lot of flexability in how the card is > used. > > John Adair > Enterpoint Ltd. > > On 6 Apr, 02:01, "Kunal" <kunals.spam.acco...@gmail.com> wrote: > > I should also mention that we'd like to keep the cost under $2000, and > > emphasize that we are really trying to stay away from an embedded > > system (essentially outsourcing the PCI tasks to a PCI bridge chip). > > > > > > > > Kunal wrote: > > > I'm looking for the perfect FPGA dev board for a project I'm > > > contributing to. I've found one that is *almost* ideal, with the > > > drawback being lack of support for 66 MHz PCI bus rates, and an FPGA > > > that's too small: > > > The MESA 5120ds > > >http://www.mesanet.com/pdf/parallel/5i20ds.pdf > > > > > I was hoping the community would have some suggestions. Basically, we > > > need the FPGA for some high-speed custom data conditioning, and an > > > easy way to get the processed data onto a PC. > > > > > We'd like: > > > - A fairly large FPGA, preferably Xilinx (something as big as a Virtex- > > > II VP20 or VP30 chip) > > > - PCI capabilities at 66 MHz/32 bits > > > - (optionally) a PCI bridge chip to greatly simplify the FPGA logic > > > (that is, we'd only need to deal with simple handshaking, rather than > > > using a PCI core and having to create an embedded system) > > > - Failing the last requirement, the FPGA should be able to handle the > > > Xilinx LogiCORE PCI IP > > > - 20-30 LVDS pairs through general I/O > > > - software examples with source code > > > - working drivers (for either Windows or Linux) > > > > > We'd like this for a high-speed custom DAQ system we're making. > > > > > Thanks in advance!- Hide quoted text - > > > > - Show quoted text -Article: 117677
On Apr 6, 1:22 pm, Ben Twijnstra <ben.twijns...@gmail.com> wrote: > Hi ASIC_2_FPGA, > <snip> > > The Xilinx toolchain does pretty much all of the above, except that it > doesn't support SDC but uses its own proprietary format for setting timing > constraints, and as far as I know does not support scripting. > The Xilinx EDK supports TCL scripts. EDK has multiple hooks into its implementation flow where it allows you to specify a TCL routine to run. It also allows the TCL routine to query EDK about the design. You can use it for design rule checks on parameter settings, you can use it to create a core level constraint file, etc. We have used it to generate custom constraint files based on how the parameters are set at the EDK level. Personally, I find FPGAs much less stressful than ASICs. My first ASIC was an FFT optimized vector processor chip. After we had handed the design off to the vendor, but before we had the parts back, they let it slip that it was the biggest part they had made to date. I did not sleep well for a while after that. You still want to spend lots of time with simulations, but I focus my simulations on unit testing the cores I use with bus functional models. I have some simulations that are running code on the PowerPC, but when it comes time to test things running with Linux on the PowerPC, it is MUCH quicker to just try it on real hardware. Regards, John McCaskill www.fastertechnology.comArticle: 117678
On Apr 6, 12:38 pm, "John McCaskill" <junkm...@fastertechnology.com> wrote: > On Apr 6, 1:22 pm, Ben Twijnstra <ben.twijns...@gmail.com> wrote: > > > Hi ASIC_2_FPGA, > > <snip> > > > > > The Xilinx toolchain does pretty much all of the above, except that it > > doesn't support SDC but uses its own proprietary format for setting timing > > constraints, and as far as I know does not support scripting. > > The Xilinx EDK supports TCL scripts. EDK has multiple hooks into its > implementation flow where it allows you to specify a TCL routine to > run. It also allows the TCL routine to query EDK about the design. > You can use it for design rule checks on parameter settings, you can > use it to create a core level constraint file, etc. > > We have used it to generate custom constraint files based on how the > parameters are set at the EDK level. > > Personally, I find FPGAs much less stressful than ASICs. My first ASIC > was an FFT optimized vector processor chip. After we had handed the > design off to the vendor, but before we had the parts back, they let > it slip that it was the biggest part they had made to date. I did not > sleep well for a while after that. > > You still want to spend lots of time with simulations, but I focus my > simulations on unit testing the cores I use with bus functional > models. I have some simulations that are running code on the PowerPC, > but when it comes time to test things running with Linux on the > PowerPC, it is MUCH quicker to just try it on real hardware. > > Regards, > > John McCaskillwww.fastertechnology.com Hi Jan, Thanks for the reply, the link was very informative. Hi Ben, Hi John Thank you for responses.. I have a quiestion, when we design the architecture or do RTL coding, we think of the number of gates(in case of ASIC) the design would constitute and I suppose LUT is a basic building block of FPGA, is it as important in case of FPGA to know the number of LUT levels. What effect would it have if Iam not sure how many LUTs of an FPGA will be required, when I design something. Thanks.Article: 117679
"Kunal" <kunals.spam.account@gmail.com> wrote: >> PCIE is killing of PCI66 very rapidly > >This is a good point. > >> Is this an academic application? If so some vendors like ourselves >> have University discount schemes. > >This is for university research, and we're basically looking for the >easiest and cheapest way to get about 600-800 Mbits of data onto a PC >without resorting to National Instruments cards (including their FPGA >product). > >We're certainly not closed to the idea of using PCIe, although it >would require purchasing new computers. > >It seems that most FPGA PCI boards are tailored to embedded >applications; since our application is a relatively simple one (where >the complexity is in transferring the data from FPGA to PC), this >seems a bit overkill. > >Nevertheless, we're still exploring our options (in fact, a Spartan >chip could work, but we'd need the higher-end sizes, since we need to >process roughly 512 channels of data; this would require quite a bit >of the FPGA's resources). A design consisting of multiple Spartan FPGAs is far cheaper than one big Virtex. Still, 100MB/s is not something that is easely transferred through the old style PCI33 or PCI66 bus. You'll find other devices also demand bandwidth and you'll want bus-mastering as well. An easier way to design such a beast is moving to PCI Express PCs and use a PLX PCI express to PCI33 bridge chip. Now you have a dedicated PCI33 bus you can use without having to concern yourself with other devices which reside on the same bus. Perhaps you can even get by using a less strictly timed PCI implementation since you also have full control over all signal integrity issues. The driver is another problem. If you can find a device which does almost what you want, you can try to mimic it and use drivers that come with Windows. Back when I had to do my first PCI design, I simply emulated a 16550 style UART to exchange data at a low rate. Windows knew how to talk to it so I could move on without having to wait for the software people to come up with a driver. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 117680
All, Thanks to those who made a nice comment about my post. (You will note I did not say anything about X vs. A.) I feel that the question is vendor agnostic: right now the question is about what is different?, not "who should I be using?" It doesn't help at all to recite a litany of features of a tool that they have never even seen, for a design flow that they have never used! So, to answer more questions --- "I am more concerned about the rest of things like the synthesis,P&R. As you pointed out , application of constraints for synthesis, selecting the speed grade etc.." Synthesis is done by the synthesis tools. As has been often posted here, the quality of the synthesis depends on many things, and you will have to match your style, to your favorite tool (or if you do not have a favorite, pick a few, and try them). I feel that since coding style is often unique to each coder/application, the results are also highly variable. Place and route is done by the FPGA vendor's tool, after synthesis, and the results are such that you don't get to play here much at all. For everyone, there are absolute constraints, and relative constrains, which will get you in more trouble than they are worth (generally). Often a designer will have no placement constrains, nor pin constraints, and see what happens. If they don't like the result, they may start first by locating the IO bus pins in a preferred logical way, and move on from there (you quickly realize IO comes in 'banks', and that keeping IO in banks that are adjacent for the same function is a smart move). WARNING: (Potential) Marketing Message*: If you are doing very high end work, then the ONLY tool out there is PlanAhead, which Xilinx owns now, for FPGA. It allows general area constraints, and nailing down inside IO locations of your function blocks and your IO pin locations outside. :End of WARNING! *Message does contain truthful statements about capabilities, however. Constraints is all something that will be specific to your synthesis tool, and how well you can speak its constraint language. Unfortunately, there is little standardization here (everyone likes to be just a tiny bit different). Speed grade is easy: choose the slowest, work as hard as you can, and only go to the next faster grade if there is no way to make your design meet timing. Speed grades cost more money, so this is a naturally regulating design issue. And, we all have to begin somewhere. Xilinx does offer classes, both introductory and advanced, across a wide range of topics. http://www.xilinx.com/support/education-home.htm I am told by one of my compatriots that his classes that he teaches at a local university are often attended by ex-ASIC designers, being interested in getting educated about use of FPGAs. I am sure that you have universities and colleges in your area that offer such classes. The key is that you need to be sure that they are using a FPGA for their lab part of the course, and the course is current to the technology. FPGA vendors (usually) have free software packages that support the smaller devices, and perhaps have a few less features, but are excellent learning platforms. WARNING! (Potential) Marketing Message: For example, Spartan 3 and 3E have sold tens of thousands of student boards to university programs around the world, making them one of the most successful teaching platforms, ever. The cost is on par with most college textbooks. http://www.digilentinc.com/Products/Detail.cfm?Prod=S3EBOARD&Nav1=Products&Nav2=Programmable :End of WARNING! AustinArticle: 117681
On Apr 6, 2:28 pm, Austin Lesea <aus...@xilinx.com> wrote: > All, > > Thanks to those who made a nice comment about my post. > > (You will note I did not say anything about X vs. A.) > > I feel that the question is vendor agnostic: right now the question is > about what is different?, not "who should I be using?" It doesn't help > at all to recite a litany of features of a tool that they have never > even seen, for a design flow that they have never used! > > So, to answer more questions --- > > "I am more concerned about the rest of things like the synthesis,P&R. > > As you pointed out , application of constraints for synthesis, > selecting the speed grade etc.." > > Synthesis is done by the synthesis tools. As has been often posted > here, the quality of the synthesis depends on many things, and you will > have to match your style, to your favorite tool (or if you do not have a > favorite, pick a few, and try them). I feel that since coding style is > often unique to each coder/application, the results are also highly > variable. > > Place and route is done by the FPGA vendor's tool, after synthesis, and > the results are such that you don't get to play here much at all. > > For everyone, there are absolute constraints, and relative constrains, > which will get you in more trouble than they are worth (generally). > Often a designer will have no placement constrains, nor pin constraints, > and see what happens. If they don't like the result, they may start > first by locating the IO bus pins in a preferred logical way, and move > on from there (you quickly realize IO comes in 'banks', and that keeping > IO in banks that are adjacent for the same function is a smart move). > > WARNING: (Potential) Marketing Message*: If you are doing very high end > work, then the ONLY tool out there is PlanAhead, which Xilinx owns now, > for FPGA. It allows general area constraints, and nailing down inside > IO locations of your function blocks and your IO pin locations outside. > :End of WARNING! > > *Message does contain truthful statements about capabilities, however. > > Constraints is all something that will be specific to your synthesis > tool, and how well you can speak its constraint language. > Unfortunately, there is little standardization here (everyone likes to > be just a tiny bit different). > > Speed grade is easy: choose the slowest, work as hard as you can, and > only go to the next faster grade if there is no way to make your design > meet timing. Speed grades cost more money, so this is a naturally > regulating design issue. > > And, we all have to begin somewhere. Xilinx does offer classes, both > introductory and advanced, across a wide range of topics. > > http://www.xilinx.com/support/education-home.htm > > I am told by one of my compatriots that his classes that he teaches at a > local university are often attended by ex-ASIC designers, being > interested in getting educated about use of FPGAs. > > I am sure that you have universities and colleges in your area that > offer such classes. The key is that you need to be sure that they are > using a FPGA for their lab part of the course, and the course is current > to the technology. > > FPGA vendors (usually) have free software packages that support the > smaller devices, and perhaps have a few less features, but are excellent > learning platforms. > > WARNING! (Potential) Marketing Message: For example, Spartan 3 and 3E > have sold tens of thousands of student boards to university programs > around the world, making them one of the most successful teaching > platforms, ever. The cost is on par with most college textbooks. > > http://www.digilentinc.com/Products/Detail.cfm?Prod=S3EBOARD&Nav1=Pro... > :End of WARNING! > > Austin Hi Austin Thanks for providing your views. I'd be glad if I could get some views on my question related to the LUT Thanks.Article: 117682
Through some trial and error, I was able to get video out of TFP410 by sending it a pixel clock of 90 MHz with 1280x1024 active pixels and 1407x1066 total pixels. Am I breaking the laws of physics? I'm not using an analog CRT after all. I am using a digital Flat panel. On Apr 4, 11:42 am, "Ben Jones" <ben.jo...@xilinx.com> wrote: > "wallge" <wal...@gmail.com> wrote in message > > news:1175700538.999587.321180@d57g2000hsg.googlegroups.com... > > >I am trying to get video through an fpga to a texas instruments TMDS > > transmitter chip (TFP410). > > I would like see video out at 1280x1024 at 60 FPS. The VESA spec calls > > for this to be clocked at > > 108 Mhz. > > The FPGA I am using (a stratix I) doesn't want to run this fast. > > The FPGA will run plenty fast, but you probably need to fix your design if > it doesn't meet your timing requirements. > > > Does anyone know if theTFP410will accept input video with less > > blanking time than the VESA spec allows for? > > You cannae change the laws of physics. The DVI transmitter might be capable > of transmitting with near-zero blanking but the monitor at the other end > will have none of it. In order to compress the data stream coming out of > your hypothetical slowed-down video source into a pixel stream at a 108MHz > dot clock, something somewhere is going to have to buffer a whole lot of > video data to effect the rate change. The best candidate for that > "something" is really the FPGA you're designing. > > > I wondered if there was some formula that I needed to follow. > > Google for VESA GTF (General Timing Formula). > > -Ben-Article: 117683
"Austin Lesea" <austin@xilinx.com> wrote in message news:ev6e1f$5uu1@cnn.xsj.xilinx.com... <snip> > > WARNING: (Potential) Marketing Message*: If you are doing very high end > work, then the ONLY tool out there is PlanAhead, which Xilinx owns now, > for FPGA. It allows general area constraints, and nailing down inside > IO locations of your function blocks and your IO pin locations outside. > :End of WARNING! > > *Message does contain truthful statements about capabilities, however. <snip> Thanks for the warning, but... isn't Synplify Premier addressing the same market? That product's roots in their Amplify offering started years before PlanAhead was available. Is PlanAhead in a different market than Synplify Premier? - John_HArticle: 117684
From_ASIC_2_FPGA wrote: > when we design the architecture or do RTL coding, we think of the > number of gates(in case of ASIC) the design would constitute > and I suppose LUT is a basic building block of FPGA, is it as > important in case of FPGA to know the number of LUT levels. > What effect would it have if Iam not sure how many LUTs of an FPGA > will be required, when I design something. > Basically, this is a trial-and-error approach where your knowledge about LUT usage increases as you synthesize and fit little tidbits of code. If you're designing for low-cost FPGAs the rule is fairly simply that you have a netlist that consists of 4-input, 1-output functions that contains some boolean equation, optionally followed by a flipflop. The average ratio between LUT delay and wire delay on average in modern FPGAs is about 25/75 for a sizeable design - and that's just the only thing that's certain in FPGA design. Thus, numbers of 4 and 16 are important in FPGA-land - they determine whether you're going through 1, 2 or 3 logic levels in terms of combinatorial logic. Best regards, BenArticle: 117685
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is slightly off topic for an FPGA mailing list, but... vssumesh wrote: > Hi all, > In my new firm we are planning to develop a flash model. What i > want to know is that is there any need for such an activity. My > feeling is that all the vendors will provide a beautifull timing model > for their products. Then is there any thing we can do in developing a > new model. Is there anything usefull in developing a parameterizable > general purpose model. Is there any suggestion from you people? Well, Denali seems to have made a whole business out of modeling memories of various sort. (Not that I have access to any of them.) > Also what could be the best language to use for the modeling > (timing models) verilog or system verilog?? Verilog if you want the widest possible audience. SystemVerilog users will likely be able to run Verilog models, but not the other way around. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGFtMErPt1Sc2b3ikRAtOUAJ9FBAgDfIhs5aGqrWoxgulr+zgQoACfQ5Md 5Qte+0W7PYhKmcDcN1ZWgfw= =ZmwN -----END PGP SIGNATURE-----Article: 117686
On Apr 6, 3:52 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > "Austin Lesea" <aus...@xilinx.com> wrote in message > > news:ev6e1f$5uu1@cnn.xsj.xilinx.com... > <snip> > > > > > WARNING: (Potential) Marketing Message*: If you are doing very high end > > work, then the ONLY tool out there is PlanAhead, which Xilinx owns now, > > for FPGA. It allows general area constraints, and nailing down inside > > IO locations of your function blocks and your IO pin locations outside. > > :End of WARNING! > > > *Message does contain truthful statements about capabilities, however. > > <snip> > > Thanks for the warning, but... isn't Synplify Premier addressing the same > market? That product's roots in their Amplify offering started years before > PlanAhead was available. > > Is PlanAhead in a different market than Synplify Premier? > > - John_H Hello everyone, Please excuse me, but I'd happy to see response related to the doubt/ queries I have. Iam lost in this discussion of PlanAhead..Synplify..Marketing etc. Thanks in advance, for your co-operation.Article: 117687
On Apr 6, 4:07 pm, Ben Twijnstra <ben.twijns...@gmail.com> wrote: > From_ASIC_2_FPGA wrote: > > when we design the architecture or do RTL coding, we think of the > > number of gates(in case of ASIC) the design would constitute > > and I suppose LUT is a basic building block of FPGA, is it as > > important in case of FPGA to know the number of LUT levels. > > What effect would it have if Iam not sure how many LUTs of an FPGA > > will be required, when I design something. > > Basically, this is a trial-and-error approach where your knowledge about LUT > usage increases as you synthesize and fit little tidbits of code. If you're > designing for low-cost FPGAs the rule is fairly simply that you have a > netlist that consists of 4-input, 1-output functions that contains some > boolean equation, optionally followed by a flipflop. The average ratio > between LUT delay and wire delay on average in modern FPGAs is about 25/75 > for a sizeable design - and that's just the only thing that's certain in > FPGA design. > > Thus, numbers of 4 and 16 are important in FPGA-land - they determine > whether you're going through 1, 2 or 3 logic levels in terms of > combinatorial logic. > > Best regards, > > Ben Thanks for the reply Ben, Could you please tell me what you mean,when you say "this is a trial-and-error approach where your knowledge about LUT usage increases as you synthesize and fit little tidbits of code"Article: 117688
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 psihodelia@googlemail.com wrote: > So, any idea, how can we change this situation? Will we meet the time > of Open Source development tools for programmable logic devices? If things are not appearing to your satisfaction there are two clear ways to get what you're after: Method A: Get off your duff and do it! There are those of us who spend a *lot* of time working the issue who get a touch annoyed when armchair engineers come up with blue-sky declarations. Method B: Pay someone to do it! Yes, open source software is *paid* for, either with volunteer effort (Heard the term "opportunity cost" in your ECON 101 course?) or, increasingly these days, with real money from entities with an interest in open source versions of of valuable products. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGFtlVrPt1Sc2b3ikRAkk6AJwJCdJ3i4i1srAKnrcJC/NXhb2SnwCgjOec SbM2U4QPlkdEI3xNXD/B2M8= =yGVm -----END PGP SIGNATURE-----Article: 117689
"From_ASIC_2_FPGA" <praneet.dixit@gmail.com> wrote in message news:1175901337.715730.315060@n76g2000hsh.googlegroups.com... > Thanks for the reply Ben, Could you please tell me what you mean,when > you say "this is a trial-and-error approach where your knowledge about > LUT usage increases as you synthesize and fit little tidbits of code" That sounds like The Knowledge. To quote the same piece, [ http://www.fpgacpu.org/log/aug02.html#art ] The Knowledge If you want to be a cab driver in London, you first must earn The Knowledge. Students study for many months to memorize the thousands of little streets in London and learn the best routes from place to place. And they go out every day on scooters to scout around and validate their book learning. Similarly, if you want to be a great FPGA-optimized core designer, you have to acquire The (Device) Knowledge. You have to know what the LUTs, registers, slices, CLBs, block RAMs, DLLs, etc. can and can't do. You have to learn exactly how much local, intermediate, and long routing is available per bit height of the logic in your datapath and how wide the input and output buses to the block RAMs are. You have to learn about carry chain tricks, clock inversions, GSR nets, "bonus" CLB and routing resources, TBUFs, and so forth. You also need to know the limitations of the tools. What device features PAR can and can't utilize. How to make PAR obey your placement and timing constraints, and what things it can't handle. And how to "push on the rope" of your synthesis tools to make them emit what you already know you want. The Knowledge isn't in any book, alas. Yes, you can read the 'street maps', e.g. the datasheets and app notes, but that only goes so far. You have to get out on your 'scooter' and explore, e.g. crank up your tools and design some test circuits, and then open up the timing analyzer and the FPGA editor and pour over what came out, what the latencies (logic and routing) tend to be, etc. ---- So you have to pick up the tools and try some things. (The first thing I do with every new device and tool release is build a quick verilog counter module, then implement that design, then poke around in FPGA Editor and Timing Analyzer.) Try building bits of datapaths, state machines, use the BRAM, use the LUT RAM, IOBs. Get a cheap prototyping board and have at it. Explore the reference designs. Keep playing around. If you already design ASICs, you should be in good shape in a month or two. If you haven't already noticed, in ISE (if Xilinx floats your boat) there are online software manuals that include the dev system reference guide, getting started guides, libraries guides, HDL and schematics guides for various device families, constraints guide, etc. Thousands of pages. Most of the details you are asking for are in there. Or has been discussed right here, over the years; search via fpga-faq.com and/or groups.google.com. Good luck, Jan GrayArticle: 117690
Thanks to all for their time and valuable suggestionsArticle: 117691
> Please excuse me, but I'd happy to see response related to the > doubt/queries I have. Iam lost in this discussion of > PlanAhead..Synplify..Marketing etc. What people are suggesting is simply "try it". The tools you need are only a free download away. Implementing tiny toy examples and seeing how small RTL changes affects the synthesized result's resource usage and fMAX, together careful reading of the device user guide, is really the best way to build up the needed intuition. It will give you a much better understanding of FPGA than any canned beginner's guide would ever be able to. Regards and good luck, TommyArticle: 117692
Kunal One thing to watch with PCI is that you rarely get a bandwidth near the theoretical. Your figure is about 1/3 and is just about feasable. You still need to be careful in that if any card on your PCI segment is restricted to 33MHz then the whole segment runs at 33MHz. Also we have seen a wide range in PC PCI frequencies so you don't always what you expect and sometimes less performance results. You also may find other devices on the motherboard may be sitting on the segment and taking lots of bandwidth e.g. network card. The PCI66/32 is unusual. Most 66MHz systems use the wider 64bit data and you may find more cards with this data width. John Adair Enterpoint Ltd. On 6 Apr, 20:10, "Kunal" <kunals.spam.acco...@gmail.com> wrote: > > PCIE is killing of PCI66 very rapidly > > This is a good point. > > > Is this an academic application? If so some vendors like ourselves > > have University discount schemes. > > This is for university research, and we're basically looking for the > easiest and cheapest way to get about 600-800 Mbits of data onto a PC > without resorting to National Instruments cards (including their FPGA > product). > > We're certainly not closed to the idea of using PCIe, although it > would require purchasing new computers. > > It seems that most FPGA PCI boards are tailored to embedded > applications; since our application is a relatively simple one (where > the complexity is in transferring the data from FPGA to PC), this > seems a bit overkill. > > Nevertheless, we're still exploring our options (in fact, a Spartan > chip could work, but we'd need the higher-end sizes, since we need to > process roughly 512 channels of data; this would require quite a bit > of the FPGA's resources). > > > > John Adair wrote: > > Kunal > > > I think if such a card does not exist today it probably won't. PCIE is > > killing of PCI66 very rapidly although we do hear of other people, > > usually Sun machine users, wanting PCI66 and we have considered doing > > a PCI66 version of our Broaddown4 product. I would be interested to > > hear from anyone else that thinks there is a market for this > > interface, even niche smallish quantities, as we could deliver such a > > product within a few weeks if a strong requirement exists. > > > Your next problem is getting a Virtex level product cheaply. Spartan > > level products don't often support PCI66. Our base level version of > > Broaddown4 does come just with your price target but at the moment is > > the wrong interface with the PCIE. > > > Is this an academic application? If so some vendors like ourselves > > have University discount schemes. > > > The PLX style approach isn't used by many FPGA development board > > manufacturers as usually they are trying to demo PCI inside a FPGA. We > > are doing an alternative to this in some planned products and you can > > see the first implementation in our Trarfessock1 board that has a FPGA > > for the PCI(Cardbus) interfaces and an independent one for the main > > logic development. This allows a lot of flexability in how the card is > > used. > > > John Adair > > Enterpoint Ltd. > > > On 6 Apr, 02:01, "Kunal" <kunals.spam.acco...@gmail.com> wrote: > > > I should also mention that we'd like to keep the cost under $2000, and > > > emphasize that we are really trying to stay away from an embedded > > > system (essentially outsourcing the PCI tasks to a PCI bridge chip). > > > > Kunal wrote: > > > > I'm looking for the perfect FPGA dev board for a project I'm > > > > contributing to. I've found one that is *almost* ideal, with the > > > > drawback being lack of support for 66 MHz PCI bus rates, and an FPGA > > > > that's too small: > > > > The MESA 5120ds > > > >http://www.mesanet.com/pdf/parallel/5i20ds.pdf > > > > > I was hoping the community would have some suggestions. Basically, we > > > > need the FPGA for some high-speed custom data conditioning, and an > > > > easy way to get the processed data onto a PC. > > > > > We'd like: > > > > - A fairly large FPGA, preferably Xilinx (something as big as a Virtex- > > > > II VP20 or VP30 chip) > > > > - PCI capabilities at 66 MHz/32 bits > > > > - (optionally) a PCI bridge chip to greatly simplify the FPGA logic > > > > (that is, we'd only need to deal with simple handshaking, rather than > > > > using a PCI core and having to create an embedded system) > > > > - Failing the last requirement, the FPGA should be able to handle the > > > > Xilinx LogiCORE PCI IP > > > > - 20-30 LVDS pairs through general I/O > > > > - software examples with source code > > > > - working drivers (for either Windows or Linux) > > > > > We'd like this for a high-speed custom DAQ system we're making. > > > > > Thanks in advance!- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -Article: 117693
"Ben Twijnstra" <ben.twijnstra@gmail.com> wrote in message news:e2c81$46168fe4$d52e2131$11671@news.chello.nl... > Hi ASIC_2_FPGA, > >> I've been using Verilog HDL, so I have no issues as far as RTL coding >> or Verification is concerned. > > With respect to coding style I have a few strong suggestions: > > (apologies in advance for shouting) > > - DON'T DO CLOCK GATING > - DON'T DO RIPPLE CLOCKS Gated clock , clock muxes and ripple clocks are no longer a problem for modern synthesis tools. Precision and Synplicity can easily convert these structures to FPGA efficient logic (gate signal reconnected to FF-EN input). If fact ASIC prototying is such a big market (Dataquest 2005 study stated that 30% of all ASICs are prototyped on FPGA) that I suspect support will continue to increase. For example, Precision not only support gates clocks and SDC constraining you can also use Synopsys Designware components (not all) in your design without having any RTL for it. Hans www.ht-lab.com > - REGISTERS ARE FREE > - CLOCK-ENABLES ARE FREE > >> I am more concerned about the rest of things like the synthesis,P&R. >> As you pointed out , application of constraints for synthesis, > > With Altera's Quartus II toolchain you'll be happy to see that it fully > supports SDC constraints, floorplanning, ECO without doing a full P&R, > full > TCL scripting, either from command line or GUI, incremental compilation > and > other comfort-enhancing features. > > The Xilinx toolchain does pretty much all of the above, except that it > doesn't support SDC but uses its own proprietary format for setting timing > constraints, and as far as I know does not support scripting. > > No clock tree synthesis is required for FPGA's. Everything's pre-buffered. > > Both toolchains are available on Windows, Linux and Solaris. > >> selecting the speed grade etc.. > > Today's FPGA's are pretty good in terms of performance (but never good > enough), so normally you start coding for the slowest speed grade, and > only > once you find out that after careful tweaking of your logic and placement > you cannot meet timing you will switch to a faster speed grade. > > Also, you will find that you will not need to simulate as much as you used > to do. Run into a bug? Find it through JTAG, fix it, shoot a new bitstream > into the device, and try again. > > Hope this helps, > > > Ben >Article: 117694
nico@puntnl.niks (Nico Coesel) wrote: >"Kunal" <kunals.spam.account@gmail.com> wrote: > >>> PCIE is killing of PCI66 very rapidly >> >>This is a good point. >> >>> Is this an academic application? If so some vendors like ourselves >>> have University discount schemes. >> >>This is for university research, and we're basically looking for the >>easiest and cheapest way to get about 600-800 Mbits of data onto a PC >>without resorting to National Instruments cards (including their FPGA >>product). >> >>We're certainly not closed to the idea of using PCIe, although it >>would require purchasing new computers. >> >>It seems that most FPGA PCI boards are tailored to embedded >>applications; since our application is a relatively simple one (where >>the complexity is in transferring the data from FPGA to PC), this >>seems a bit overkill. >> >>Nevertheless, we're still exploring our options (in fact, a Spartan >>chip could work, but we'd need the higher-end sizes, since we need to >>process roughly 512 channels of data; this would require quite a bit >>of the FPGA's resources). > >A design consisting of multiple Spartan FPGAs is far cheaper than one >big Virtex. Still, 100MB/s is not something that is easely transferred >through the old style PCI33 or PCI66 bus. You'll find other devices >also demand bandwidth and you'll want bus-mastering as well. > >An easier way to design such a beast is moving to PCI Express PCs and >use a PLX PCI express to PCI33 bridge chip. Now you have a dedicated >PCI33 bus you can use without having to concern yourself with other >devices which reside on the same bus. Perhaps you can even get by >using a less strictly timed PCI implementation since you also have >full control over all signal integrity issues. > >The driver is another problem. If you can find a device which does >almost what you want, you can try to mimic it and use drivers that >come with Windows. Back when I had to do my first PCI design, I simply >emulated a 16550 style UART to exchange data at a low rate. Windows >knew how to talk to it so I could move on without having to wait for >the software people to come up with a driver. I just got another idea on the mimic thing: If you let your fpga design mimic a network card (an NE2000 or Realtek as long as the drivers can deal with bus mastering), you can put your data into UDP packets (maybe one port per stream??). All you need to do in your application software is listen to the proper network socket. No need to write a driver. With some care, your software and hardware will run on any platform instantly. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 117695
I can't check any price infomation about the following boards in xilinx website: 1) ML521/3/5 ---- Virtex-5 GTP characterization board. 2) ML550 ---- Virtex-5 networking development board. Btw: what about Virtex-5 VSK (Video Starter Kit), I hear that it will support PCI-e. Thanks a lot. Best Regards, WickyArticle: 117696
Hello... Why is it that the Windows Version of ispLever 6.1 is downloadable via FTP but not the Linux version? thx in advance rickArticle: 117697
I have recently been playing around with what I think is a new approach to defining and implementing distributed embedded systems. I've come up with a language that I call SMIL that defines the data flow between between the systems in a high level way. This project is in a very preliminary state. I have used it to define interactions between a Linux system and an Altera NiosII based system running eCos using TCP/IP socket communications. SMIL generates all the socket related code to make the communication possible based on the data flow definitions that you provide. SMIL can also generate code for state machines based on the data flow definitions. The reason that I'm posting is that I'd like to see if there is any interest in this approach (beyond just me). A very preliminary document exists at http://pennington.ms/SMIL.pdf If this approach seems reasonable my plan is to extend SMIL to generate code for different communication paths, e.g. UDP, CAN, serial, etc. I'd also like to generate VHDL code for portions of the system specified by the user where top performance is required. Right now, SMIL supports Linux and eCos based systems. If there is interest I plan to support at least vxWorks and uC/OS-II in the future. Be gentle. This is an open source project in its very early stages. If there is enough interest I'll work on making a release for general distribution. -RichArticle: 117698
"Jan Gray" <jsgray@acm.org> wrote: >"From_ASIC_2_FPGA" <praneet.dixit@gmail.com> wrote in message >news:1175901337.715730.315060@n76g2000hsh.googlegroups.com... >> Thanks for the reply Ben, Could you please tell me what you mean,when >> you say "this is a trial-and-error approach where your knowledge about >> LUT usage increases as you synthesize and fit little tidbits of code" > >That sounds like The Knowledge. To quote the same piece, > >[ http://www.fpgacpu.org/log/aug02.html#art ] > >The Knowledge > >If you want to be a cab driver in London, you first must earn The Knowledge. >Students study for many months to memorize the thousands of little streets >in London and learn the best routes from place to place. And they go out >every day on scooters to scout around and validate their book learning. > >Similarly, if you want to be a great FPGA-optimized core designer, you have >to acquire The (Device) Knowledge. You have to know what the LUTs, >registers, slices, CLBs, block RAMs, DLLs, etc. can and can't do. You have >to learn exactly how much local, intermediate, and long routing is available This is what I refer to as "wax on, wax off" -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 117699
On Apr 7, 8:47 am, Richard Pennington <r...@pennware.com> wrote: > with a language that I call SMIL that defines the data flow between > between the systems in a high level way. You might want to think of a new name :) <http://www.w3.org/AudioVideo/ >
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