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
In article <7hs331$5uh$2@news.planetinternet.be>,
"Alain Cloet" <alain.cloet@planetinternet.be> wrote:
> (Previously posted in comp.arch.embedded, I just subscribed to this
> fpga-newsgroup after a reply where I was said someone around here
might be
> able to help me, so no, I haven't read the FAQ or other articles yet)
> With the Foundation Series of XIlinx, it should be possible to program
a
> CPLD onboard with their parallel cable (JTAG programming).
> We succeeded already in that way that we can program a single chip if
we are
> able to use the chip TDI and TDO.
> If we want to simulate a real case, with a JTAG chain with more than 1
chip,
> than it doesn't work. We always get an "basut"-error, so we don't
succeed.
> We tried to add elements of which we have the bsdl-file, and we don't
get
> errors during configuration, but the programming doesn't work.
> Has anyone experience with this, and is able to guess what we're
forgetting.
> Thanks,
> Alain
>
I'm using a chain of 3 XC9500-devices and found no problems.
For the programming I'm using the Jtag-Programmer-program (foundation
1.4).
Try to execute first "Initialize chain" (from the files menu, I
believe). You should see all the devices in the chain. After that must
assign either a .jedec or a .bsdl file to each device.
The .bsdl files are in the /data subdirectory of the Foundation
installation. Now you can select a device and program it individually.
This is the way I have done it.
Regards
Klaus
--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Article: 16401I think it was something like this: ----------- --| NAND----- ---INV--- Leon -- Leon Heller, G1HSM Email: leon_heller@hotmail.com http://www.geocities.com/SiliconValley/Code/1835/ Peter Sørensen wrote in message <3743B3CF.70F2D155@emi.dtu.dk>... >Teach me, I don't understand how? > >Leon Heller wrote: > >> Uday Godbole wrote in message <7htv83$fkj$1@usenet50.supernews.com>... >> >Hi, >> > >> >I need to use a schmitt trigger gate. Can it be made on a Xilinx 9536 >> cpld? >> >I have their starter kit, but the schematic capture software does not seem >> >to have one in the library.. Also, can an open collector output be >> simulated >> >on this device? >> >> I created a Schmitt trigger once on a Lattice CPLD, using schematic entry. >> You can do it with a 2-input NAND and an inverter. >> >> Leon >Article: 16402
Hello,
I would like to use the Xilinx foundation tools + VHDL compiler from
command line.
Does anyone have a MAKEFILE ready for doing so?
Thanks
Klaus
--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Article: 16403Why don't you guys have the PCI interface in the Xilinx? Malachy Devlin <m.devlin@nallatech.com> wrote in article <B4000FE0503ED211864100104B4C66C30972A9@CONTEXT>... > Nallatech has been supplying a Virtex development platform since > February. This is a 32bit 33Mhz PCI card with a 300K - 800K Virtex > device and 2 individual banks of 2MBytes 100Mhz ZBT SRAM. > The PCI card, called the Ballynuey, handles all the PCI issues and comes > with a pre-configured Spartan that handles the PCI interfacing and data > buffering between the Virtex and the PC application. PCI drivers, Virtex > debug tool, FPGA configuration and Application API are included with the > card. > Additionally the card includes 4 DIME modules for expansion and custom > I/O. Currently there are modules for Image Capture and Display, a Dual > XCV1000 module (yes over 2Million gates!) and various other I/O modules > (e.g. LVDS) with more in the pipeline. The modules can provide over > 2Gbytes/sec bandwidth and has over 200 I/O connections. > > Configuration of the on-board Virtex is configured dynamically over the > PCI using the tools provided with the card (and is much faster than > Xchecker!) If additional DIME modules are placed on the card their FPGAs > are also individually configurable via PCI. > > > Check out the web site for more details and new developments soon to be > announced at http://www.nallatech.com/ > > > Malachy Devlin > Nallatech Ltd > m.devlin@nallatech.com > > > > -----Original Message----- > > From: alfred fuchs [mailto:alfred.fuchs@siemens.at] > > Posted At: 12 May 1999 19:09 > > Posted To: fpga > > Conversation: Virtex based PCI cards > > Subject: Re: Virtex based PCI cards > > > > > > I've just finished the design of a CompactPCI board (6U) with > > one Virtex1000 > > and two synchronous SRAM-modules (2Mx72). It mainly uses > > rear-panel-I/O > > (more than 100 signals) and is therefore open for various > > applications. The > > PCI-IF is a PLX9054, the FPGA is configured by the PCI-master. > > Pricing is TBD, but we tend to be expensive. > > > > Alfred Fuchs > > Siemens Austria > > PSE PRO LMS2 > > +43/1/1707-34113 > > > > Atif Zafar schrieb: > > > > > Hello: > > > > > > Does anyone know of any development boards (PCI) that > > use the Virtex > > > FPGA? I am interested in a board with preferably several > > XV800 or XV1000 > > > devices along with RAM for prototyping a custom graphics pipeline. I > > > have heard of the PCI Pamette board, but to my knowledge > > this does not > > > have Virtex silicon. Thanks for any info. > > > > > > Atif Zafar > > > Regenstrief Institute > > > Zafar_A@regenstrief.iupui.edu > > > >Article: 16404
This is not intended to be an advertisement, so forgive me if it sounds like one. But I would like to get the opinion of the engineers in the newsgroup about a new board that we are designing. This board will have a PC/104 interface and form factor. It will contain a TMS320C30 processor running at 40 MIPS (80 MHz). It will contain 256 (or maybe 512) Kwords of SRAM and 2 MB of Flash. It will also use an FPGA for the logic on the card. This is where I would like your opinion. The main function of the FPGA will be to interface the various components of the board such as the two I/O modules, the PC/104 bus and the DSP. But I can very easily, and without much added cost, make this FPGA much larger than what is needed to provide these basic functions. So the rest of the FPGA could be used for user designated functions. Is this a useful feature for a DSP board? Has anyone designed custom FPGA circuitry on a commercial board like this before? What is your opinion as to the marketabililty of this feature? I appreciate your answers. Please post here or email me at the address below. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 16405
In article <3741869F.9CFD2583@viewlogic.com>, fpga@viewlogic.com wrote: > > IntelliFlow Users, > > If you would like to contribute to a case study of Viewlogic's > IntelliFlow, please respond to this email. I'd like to know about > your experiences, good and bad, with this tool and what impact > it has had with your design methodology. I'll post a summary > of the results to comp.arch.fpga at the conclusion of the study. > > Thanks, > -Jim > Well..this is a thorny subject. I have the viewlogic tools for doing fpga's including viewsim,intelliflow, and Fpga express. Viewsim is excellent, it is very fast and allows you to see simulation in progress. Fpga express is also quite good. I have never used symplicity or exemplar so I can't compare to those two but, I have been able to get fpga express to do everything that I need. Intelliflow is another question entirely :( I am sorry but I have to be honest. I found it terrible! I had a tough time just trying to get it to work, the support was not very good, and, probably it's worst feature is that the documentation is about at good as a bump on log. I struggled with it for a couple of weeks, then I ended up going on a vhdl course where I was able to use the aldec tool's. There was no comparison. I bought the aldec tool's and use them to this day. I have to premise this conversation with a couple of things. First, when I was using the viewlogic tools, I was in the learning stage of vhdl. When you are at this stage, the viewlogic tools immediately show their flaws. If I remember correctly there is a compiler called vantage used in viewlogic. This compiler would give me the most wonderful messages if I had something wrong in my code. How that message correlated to the problem is beyond my scope of reasoning.( Maybe the problem is that I don't have enough scope :))) To be intelliflow specific, when a new vhdl file is added that would not analyze, it would come back with "File would not analayze". This is good except for the fact that some idea to what the problem is would be nice. I know that I have kind of gone off in various directions but to summarize, intelliflow is best rated poor. It does not let you spend your time sorting out design issues, instead, you spend your time sorting out tool problems. Sorry :( Bill > -- > -------------------------------------------------------- > James R. Kipps FPGA Marketing Manager > jkipps@viewlogic.com Phone: (508) 303-5246 > -------------------------------------------------------- > > --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16406
Sorry, but do you guys know what a smidtt trigger is? I have no idea how you can get a NAND gate and and INVERTOR to provide the different voltage trigger levels. Leon Heller <leon_heller@hotmail.com> wrote in message news:927187234.23518.0.nnrp-07.d4f06601@news.demon.co.uk... > I think it was something like this: > > ----------- > --| NAND----- > ---INV--- > > > Leon > -- > Leon Heller, G1HSM > Email: leon_heller@hotmail.com > http://www.geocities.com/SiliconValley/Code/1835/ > > Peter Sørensen wrote in message <3743B3CF.70F2D155@emi.dtu.dk>... > >Teach me, I don't understand how? > > > >Leon Heller wrote: > > > >> Uday Godbole wrote in message <7htv83$fkj$1@usenet50.supernews.com>... > >> >Hi, > >> > > >> >I need to use a schmitt trigger gate. Can it be made on a Xilinx 9536 > >> cpld? > >> >I have their starter kit, but the schematic capture software does not > seem > >> >to have one in the library.. Also, can an open collector output be > >> simulated > >> >on this device? > >> > >> I created a Schmitt trigger once on a Lattice CPLD, using schematic > entry. > >> You can do it with a 2-input NAND and an inverter. > >> > >> Leon > > > >Article: 16407
Rickman wrote:
> This board will have a PC/104 interface and form factor. It will contain
> a TMS320C30 processor running at 40 MIPS (80 MHz). It will contain 256
> (or maybe 512) Kwords of SRAM and 2 MB of Flash. It will also use an
> FPGA for the logic on the card.
>
> This is where I would like your opinion. The main function of the FPGA
> will be to interface the various components of the board such as the two
> I/O modules, the PC/104 bus and the DSP. But I can very easily, and
> without much added cost, make this FPGA much larger than what is needed
> to provide these basic functions. So the rest of the FPGA could be used
> for user designated functions.
>
> Is this a useful feature for a DSP board? Has anyone designed custom
> FPGA circuitry on a commercial board like this before? What is your
> opinion as to the marketabililty of this feature?
>
If I am buying circuit board for an oem product or a test fixture,
I just want to plug it in and have do what it says it will do with
a minimum of fussing around.
If I want custom FPGA functions, that means I'm in the mood for fussing
around and I probably won't buy anybody's board. I will make one myself
that has exactly what I want on it.
-Mike Treseler
Article: 16408Adam J. Elbirt wrote in message <37438002.52B73647@nac.net>... >Actually I am running 95 version B. Oh, yeah, Microsoft's "consumer OS." What version of the Xilinx tools are you running? Service packs? > It's in par, not map. I ended up having to >run the tools manually from the command line which was incredibly painful. Not as bad as one might thing. Batch files are still very handy things. >Guess I'll be using Altera for my next design. Well, if you can afford to support both sets of tools, have at it. -- a ------------------------------------------ Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters@noao.edu "Space, reconnaissance, weather, communications - you name it. We use space a lot today." -- Vice President Dan QuayleArticle: 16409
Dominic- When you create the unoptimized implementation, select Preserve Hierarchy. This will keep hierarchical blocks from being flattened and avoid cross-boundary optimization. If you're still having trouble, contact me directly and I'll see what I can do to help. Regards, -Jim Dominic Reitman wrote: > My design currently consists of four entities. The four entities when > synthesized and implemented independently have a CLB count of 10, 17, 4, > and 9. When I combine the four entities the new CLB count is 156. The > whole design is straight combinational logic. The first two entities > are 8 functions of 8 variables each, they each use a case statement with > 256 possibilaties. The third entity is a simple multiplexer which > selects 1 of 2 8-bit vectors. The last entity is a 4-to-1 multiplexor > along with some shifts. > > Is there any way to have FPGA Express synthesize an entity of a design > without trying to optimize it with the components surrounding it? I > think that FPGA Express is combining the logic used in the first two > entities with the multiplexer which ruins the symetry within the logic > of the first two entities. > > Any help or ideas on the matter will be greatly appreciated. > Thanks in advance, > Dominic -- -------------------------------------------------------- James R. Kipps FPGA Marketing Manager jkipps@viewlogic.com Phone: (508) 303-5246 --------------------------------------------------------Article: 16410
Bill- Thanks for the feedback. I've had my own struggles with early releases of IntelliFlow and still have some, but the general useability of IntelliFlow has improved significantly since its first release. The current release in Workview Office 7.53 is much improved with a new project wizard. It's worth another look. May I ask which version you were using? Regards, -Jim Bill Kury wrote: > In article <3741869F.9CFD2583@viewlogic.com>, > fpga@viewlogic.com wrote: > > > > IntelliFlow Users, > > > > If you would like to contribute to a case study of Viewlogic's > > IntelliFlow, please respond to this email. I'd like to know about > > your experiences, good and bad, with this tool and what impact > > it has had with your design methodology. I'll post a summary > > of the results to comp.arch.fpga at the conclusion of the study. > > > > Thanks, > > -Jim > > > Well..this is a thorny subject. I have the viewlogic tools for doing > fpga's including viewsim,intelliflow, and Fpga express. Viewsim is > excellent, it is very fast and allows you to see simulation in progress. > Fpga express is also quite good. I have never used symplicity or > exemplar so I can't compare to those two but, I have been able to get > fpga express to do everything that I need. Intelliflow is another > question entirely :( I am sorry but I have to be honest. I found it > terrible! I had a tough time just trying to get it to work, the support > was not very good, and, probably it's worst feature is that the > documentation is about at good as a bump on log. I struggled with it > for a couple of weeks, then I ended up going on a vhdl course where I > was able to use the aldec tool's. There was no comparison. I bought > the aldec tool's and use them to this day. > I have to premise this conversation with a couple of things. First, > when I was using the viewlogic tools, I was in the learning stage of > vhdl. When you are at this stage, the viewlogic tools immediately show > their flaws. If I remember correctly there is a compiler called vantage > used in viewlogic. This compiler would give me the most wonderful > messages if I had something wrong in my code. How that message > correlated to the problem is beyond my scope of reasoning.( Maybe the > problem is that I don't have enough scope :))) > To be intelliflow specific, when a new vhdl file is added that would not > analyze, it would come back with "File would not analayze". This is > good except for the fact that some idea to what the problem is would be > nice. > I know that I have kind of gone off in various directions but to > summarize, intelliflow is best rated poor. It does not let you spend > your time sorting out design issues, instead, you spend your time > sorting out tool problems. > > Sorry :( > > Bill > > -- > > -------------------------------------------------------- > > James R. Kipps FPGA Marketing Manager > > jkipps@viewlogic.com Phone: (508) 303-5246 > > -------------------------------------------------------- > > > > > > --== Sent via Deja.com http://www.deja.com/ ==-- > ---Share what you know. Learn what you don't.--- -- -------------------------------------------------------- James R. Kipps FPGA Marketing Manager jkipps@viewlogic.com Phone: (508) 303-5246 --------------------------------------------------------Article: 16411
Andy, I'm running M1.5 with both service packs (not the 1.5i version). I agree that batch files and command line are handy. It was frustrating to have to: 1. Run par command line - failed in routing. 2. Run par again via command line, use skip placement switch since already done - failed again in routing. 3. Run par again via command line, use skip placement switch and reentrant routing switch - finally worked. I personally like the command line since there are a lot more options available than via the GUI, even if the GUI is convenient. I just can't imagine that other people aren't running into this problem and that Xilinx hasn't patched it. Adam Andy Peters wrote: > Adam J. Elbirt wrote in message <37438002.52B73647@nac.net>... > >Actually I am running 95 version B. > > Oh, yeah, Microsoft's "consumer OS." > > What version of the Xilinx tools are you running? Service packs? > > > It's in par, not map. I ended up having to > >run the tools manually from the command line which was incredibly painful. > > Not as bad as one might thing. Batch files are still very handy things. > > >Guess I'll be using Altera for my next design. > > Well, if you can afford to support both sets of tools, have at it. > > -- a > ------------------------------------------ > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters@noao.edu > > "Space, reconnaissance, weather, communications - you name it. We use space > a lot today." > -- Vice President Dan QuayleArticle: 16412
Klaus Falser <kfalser@durst.it> wrote in message news:7i0eo7$foq$1@nnrp1.deja.com... > In article <7hs331$5uh$2@news.planetinternet.be>, > "Alain Cloet" <alain.cloet@planetinternet.be> wrote: > I'm using a chain of 3 XC9500-devices and found no problems. > For the programming I'm using the Jtag-Programmer-program (foundation > 1.4). As far as I know we use version 1.5i > > Try to execute first "Initialize chain" (from the files menu, I > believe). You should see all the devices in the chain. After that must > assign either a .jedec or a .bsdl file to each device. Been there, done that. I think the problem is that it doesn't recognize most of the elements (there aren't all Xilinx, or don't have a JTAG-ID-code). So the only possibilities I know of is to attach the bsdl-files for the non-Xilinx/unrecognized parts (there is 1 XC4028-FPGA without ID-code in the chain), if I started with an 'initialize chain' ; or if I start a project for a specific CPLD (for example the XC9536 from the demo-board) than I add the additional devices with 'Add Device' by choosing it's BSDL-file. The first real project exists of 1 XC95216-CPLD, 1 Motorola 68360-µP, 5 Motorola 56309-DSP's and 1 XC4028XL-FPGA, maybe followed by 2 AMD-Mach445-IC's. I think all the BSD-files are correct as we already test as much as possible in Boundary Scan using Asset-Intertech-tools. The playing (read try-outs) we do is with the the XC9536-testboard, and as second device a AMD mach445 (as we have this as 1-element BS-chain available). Normally we'll try to make a chain with two recognized xilinx-parts as well, but we didn't find time yet (as for every urgent thing there is something more urgent;-)) > The .bsdl files are in the /data subdirectory of the Foundation > installation. Now you can select a device and program it individually. > > This is the way I have done it. > > Regards > Klaus > > > -- > Klaus Falser > Durst Phototechnik AG > I-39042 Brixen > > > --== Sent via Deja.com http://www.deja.com/ ==-- > ---Share what you know. Learn what you don't.---Article: 16413
On Fri, 14 May 1999 22:38:31 -0400, Jim Kipps <jkipps@viewlogic.com> wrote: >What I look for in synthesis is: 1) library coverage >(you can't synthesize what you can't target), 2) quality >of results, and 3) language support. There are other >things that are important, like ease of use, price, and >runtime performance, but these are the three biggies. > >I've had experience with Leonardo (which also supports >user attributes), Synplify, and FPGA Express and can >honestly say that all three are competitive with regard >to libraries, performance, and language. there is absolutely *no way* that fpga express is competitive in terms of vhdl language support, and i'm sure that you know this as well as the rest of us do. true, there have been major advances in both DC and express recently, but you've still got some way to go. on the other hand, there have been some really nice additions in 3.1 - FST/scripting and attribute passing primarily, which would make this a very competitive tool if you got the language support right. evanArticle: 16414
Steven Casselman wrote: > > I have always said "its the tools." But really it is more than that. > I believe that the right system has to be in place to me that > means hardware and software built together from the ground up. > It means making RPUs that have their I/O hardwired and committed > in the system. It means having true relocatible hardware functions. > I means having a mind set that includes the RPU/FPGA and tools > at the beginning of the design cycle instead of trying to shoehorn > a reconfigurable computer into a PCI bus Intel monster. It means .... > But I digress, that would be a big job and would take more money than > we > can generate at this time. > I believe that a big job lies ahead, but that it's not _too_ big of job. A lot of work is going on, like the PoliMorph program, to make the "new" technology somehow look like (or be compatible with) the "old" technology of separate hardware and software. There is the JHDL tool that are now available to everyone, and JBits from Xilinx, both of which make reconfigurability more like an extension of what engineers are already familiar with. Some tools being developed now will conceivably translate much of an existing design automagically into a reconfigurable design. My own money goes with some sort of paradigm shift. I picture the fully integrated hardware/configuration system that Steve talks about, with no familiar PCI chips, or Wintel machine any where in sight, but have a hunch that we won't get there by evolution alone; some sort of "mutation" will occur that will release a collection "aha" from everyone acquainted with the issues. In the FCCM'99 evening discussion on tools ( http://www.cs.berkeley.edu/~amd/fccm99/tools.html for an excellent summary), one of the points that came up is: the problem is difficult because there are too many degrees of freedom right now. This is not the only reason that things are sticky, but if we come up with a methodology that actually narrows down the way a designer defines a solution and the tools implement it, the tool set itself may be easier to design. Notice that I'm not actually offering any sort of paradigm shift here, but I'm watching for it (and working on it). Jonathan (end of $0.02) -- Jonathan F. Feifarek Consulting and design Programmable logic solutionsArticle: 16415
Mike Treseler wrote: > > Rickman wrote: > > > This board will have a PC/104 interface and form factor. It will contain > > a TMS320C30 processor running at 40 MIPS (80 MHz). It will contain 256 > > (or maybe 512) Kwords of SRAM and 2 MB of Flash. It will also use an > > FPGA for the logic on the card. > > > > This is where I would like your opinion. The main function of the FPGA > > will be to interface the various components of the board such as the two > > I/O modules, the PC/104 bus and the DSP. But I can very easily, and > > without much added cost, make this FPGA much larger than what is needed > > to provide these basic functions. So the rest of the FPGA could be used > > for user designated functions. > > > > Is this a useful feature for a DSP board? Has anyone designed custom > > FPGA circuitry on a commercial board like this before? What is your > > opinion as to the marketabililty of this feature? > > > > If I am buying circuit board for an oem product or a test fixture, > I just want to plug it in and have do what it says it will do with > a minimum of fussing around. > > If I want custom FPGA functions, that means I'm in the mood for fussing > around and I probably won't buy anybody's board. I will make one myself > that has exactly what I want on it. > > -Mike Treseler Mike, thanks for you opinion. When you say "fussing around", wouldn't it be MUCH easier to use someone else's board and just design an FPGA or add to an existing FPGA design than it would be to design a board and have to wait for weeks just to get the first article? The other feature that makes this product flexible is that the I/O (other than the PC/104 bus, two serial ports and a parallel interface) is done on a couple of modules that can be swapped with different functions. By combining this with the flexibility of tweeking the FPGA or just designing a whole new FPGA should make this board very, very flexible. But then, of course I think it will be useful... I'm building it. I just know that I have often been frustrated by the lack of a ready hardware platform that has what I need. Often if it just had some hardware on it that I could program, then I would have been able to do a lot more with it. That is why I am building this board. I think there will be a number of people who would like to use the DSP in conjunction with a good FPGA. However, I suspect that I am reducing my market because I am planning on using a Lucent ORCA part instead of a Xilinx part. It would appear that there are many fewer people who are familiar with the ORCA parts than Xilinx parts. I am considering the ORCA part mainly because it gets me the PLLs and about 20 more I/Os than I can get with a similar part from Xilinx without paying about $50 more. If I go with the ORCA part and squeeze in a couple of places, I will be able to sell this board for under $500 in quantity. I think this will be a good price point for a great many applications. Besides, the ORCA parts are not that much different from the Xilinx parts in many ways. And you can get a development system for $100 or even free if you sweet talk your sales person. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 16416
> My own money goes with some sort of paradigm shift. You mean Paradigm Drift. Paradigm shift sounds like something that can happen in one clock. What is really happening I call Paradigm Drift. Little by little, bit by bit people are starting to say "hey reconfigurable comptuing? It makes sense." I'd reckon there are very few hardware engineers that have not heard of reconfigurable computing. And many are starting to work it into their designs. Software engineers are starting to say "you can do what?" Which is where hardware engineers were 5-10 years ago. Every little tool that comes along (JBits JHDL, Handel C) makes us stronger and the paradigm drifts a little closer to the goal. The goal, of course, is to not even know whether you have a reconfigurable computer or not and just be able to code away as usual. -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 16417
Hi Adam, I have read your thread and you commented that you were running M1.5 with Service pack 2. I went back and read the dependancies and it looks like Xilinx requires M1.5i be installed to use service Pack 1 or 2. Could this be the possible cause of your problem? Have you contacted your local xilinx support team. I am sure they will try to help you identify what the problem might be. Best Regards Terry "Adam J. Elbirt" wrote: > > Anyone seen an M1.5 crash caused by a page faulting error? I seem to be > running into it fairly often lately when the tools run the par > executable. > > AdamArticle: 16418
Terry, That's interesting. I downloaded SP1 and 2 from the web site specifically from the 1.5 area, not the 1.5i area. When I talked to Xilinx support they claimed that the service packs were fine for 1.5 and that they had never heard of the page faulting problem. They're still working on it so hopefully we'll here from them soon. Adam zule wrote: > Hi Adam, > > I have read your thread and you commented that you were running M1.5 > with Service pack 2. I went back and read the dependancies and it looks > like Xilinx requires M1.5i be installed to use service Pack 1 or 2. > Could this be the possible cause of your problem? > > Have you contacted your local xilinx support team. I am sure they will > try to help you identify what the problem might be. > > Best Regards > Terry > > "Adam J. Elbirt" wrote: > > > > Anyone seen an M1.5 crash caused by a page faulting error? I seem to be > > running into it fairly often lately when the tools run the par > > executable. > > > > AdamArticle: 16419
C A L L F O R P A P E R S
7th Reconfigurable Architectures Workshop (RAW 2000)
1 May 2000, Cancun, Mexico
to be held in conjunction with
International Parallel & Distributed Processing Symposium (IPDPS 2000)
14th International Parallel Processing Symposium
and 11th Symposium on Parallel and Distributed Processing
(Sponsored by IEEE Technical Committee on Parallel Processing)
http://www.ippsxx.org/
The 7th Reconfigurable Architectures Workshop (RAW 2000) will be held at
Cancun, Mexico on 1 May, 2000. RAW 2000 is associated with the Third
Merged Symposium of the 14th International Parallel Processing Symposium
and the 11th Symposium on Parallel and Distributed Processing (IPPS & SPDP).
RAW 2000 is one of the major meetings for researchers to present
ideas, results, and on-going research on both theoretical and industrial/
practical advances in Reconfigurable Computing.
Main focus of the Workshop:
Run Time Reconfiguration - Foundations, Algorithms, Tools.
Technological advances in the field of fast reconfigurable devices have
created new possibilities for the implementation and use of complex systems.
Reconfiguration at runtime is one new dimension in computing that blurs the
barriers between hardware and software components. Neither the existing
processor architectures nor the hardware/software design tools which are
available today can fully exploit the possibilities offered by this new
computing paradigm. The fast pace of technological development in industry
is leaving no time to develop the necessary theoretical foundation that
underpins CAD tools, operating systems, and designs. The potential of run
time reconfiguration can be achieved through the appropriate combination of
knowledge about foundations of dynamic reconfiguration, the various different
models of reconfigurable computing, efficient algorithms, and the tools to
support the design of run time reconfigurable systems and implementation of
efficient algorithms. RAW 2000 is planned to provide the interaction between
these diciplines.
Topics of Interest:
Authors are invited to submit manuscripts of original unpublished research
in all areas of reconfigurable computing (devices, systems, algorithms,
software tools, and applications). The topics of interest include, but are
not limited to:
+ Reconfigurable Computing + Programmable Logic Devices and Systems
- Models - Reconfigurable Systems Architectures
- Algorithms and Complexity - Implementations
- Fault Tolerance Issues - Mobile Circuitry
- Configurable Resource Management - Adaptable Systems
- Evolvable Hardware
+ Development Tools and Methods + Applications
- High-level Development Support - Mapping of Parallel Algorithms
- Compilation Techniques - Signal and Image Processing
- CAD Tools - Wireless and Distributed Systems
- Arithmetic/Geometric/Graph Algorithms
- Support for Virtual Machines
- Industrial Applications & Experiences
Submission Guidelines
Authors should submit an electronic version of their work for review to
"schmeck@aifb.uni-karlsruhe.de". All manuscripts will be reviewed.
Submissions may be a summary of the work or a complete manuscript (not to
exceed 10 pages of single spaced text, including figures and tables).
Submissions should be in Postscript (level 2) format. Authors should make
sure that the submission can be viewed using ghostscript and will print on a
Postscript printer that uses standard letter size paper (8.5" x 11").
Submissions must be received by October 22, 1999.
The workshop proceedings will be published by Springer Verlag as part of
their Lecture Notes in Computer Science Series, and they will also appear in
the CD-ROM version of the IPDPS 2000 Proceedings.
Important Dates
- Manuscript due October 22, 1999.
- Notification of acceptance/rejection due December 15, 1999.
- Final version due January 31, 2000.
Workshop Chair: Hossam ElGindy, University of New South Wales (Australia)
School of Computer Science and Engineering
The University of New South Wales
Sydney, NSW 2052, Australia.
hossam@cse.unsw.edu.au
Program Chair: Hartmut Schmeck, University of Karlsruhe (Germany)
Institut AIFB
Universitat Karlsruhe
D-76128 Karlsruhe, Germany.
schmeck@aifb.uni-karlsruhe.de
Steering Chair: Viktor K. Prasanna, University of Southern California (USA)
prasanna@ganges.usc.edu
Publicity Chair: Oliver Diessel, University of South Australia (Australia)
Advanced Computing Research Centre
University of South Australia
Mawson Lakes, SA 5095, Australia.
o.diessel@unisa.edu.au
Program Committee
- Jeff Arnold, Independent Consultant (USA)
- Peter Athanas, Virginia Tech (USA)
- Gordon Brebner, Univ. of Edinburgh (Scotland)
- Andre DeHon, Univ. of California at Berkeley (USA)
- Carl Ebeling, Univ. of Washington (USA)
- Hossam ElGindy, Univ. of New South Wales (Australia)
- Reiner Hartenstein, Univ. of Kaiserslautern (Germany)
- Brad Hutchings, Brigham Young Univ. (USA)
- Mohammed Khalid, Quickturn Design Systems (USA)
- Hyoung Joong Kim, Kangwon National Univ. (Korea)
- Rainer Kress, Siemens AG (Germany)
- Fabrizio Lombardi, Northeastern University (USA)
- Wayne Luk, Imperial College (UK)
- Patrick Lysaght, Univ. of Strathclyde (Scotland)
- William H. Mangione-Smith, Univ. of California, Los Angeles (USA)
- Margaret Marek-Sadowska, Univ. of California, Santa Barbara (USA)
- William P. Marnane, Univ. College Cork (Ireland)
- Margaret Martonosi, Princeton Univ. (USA)
- John T. McHenry, National Security Agency (USA)
- Alessandro Mei, Univ. of Trento (Italy)
- Martin Middendorf, Univ. of Karlsruhe (Germany)
- George Milne, Univ. of South Australia (Australia)
- Koji Nakano, Nagoya Institute of Technology (Japan)
- Stephan Olariu, Old Dominion Univ. (USA)
- Bernard Pottier, Univ. Bretagne Occidentale (France)
- Ralph Kohler, Air Force Research Laboratory (USA)
- Mark Shand, Compaq Systems Research Center (USA)
- Jerry L. Trahan, Louisiana State Univ. (USA)
- Ramachandran Vaidyanathan, Louisiana State Univ. (USA)
for more information on RAW 2000 see http://www.cis.unisa.edu.au/~raw2000
Article: 16420Jonathan Feifarek wrote: > the problem is difficult > because there are too many degrees of freedom right now. I like to to view the problem as an extension of HotSpot/JIT technologies in virtual machine implementation, most notably lately in Java Virtual Machines. What these technologies do is profile a program on-the-fly (with embedded profiling instructions, or through interpretation, or whatever). When they determine that a certain portion of a program is heavily exercised, then that portion is (re-)compiled with heavy optimisation. Now, why not do the same thing, but right down to the hardware, rather than down to machine code. What you need, however, is a general compiler from a high-level language (Java bytecode?) to fpga gates. According to the empty response to a previous posting, nobody is interested in such a thing. What you also need is a sense of when this would be more useful than merely compiling to the machine-code level. I'd be inclined to think that it's almost always useful, since you can parallelize as much as the source code will allow for each specific case, which will always be better than a fixed super-scalar processor architecture. Now, each thread of your program will have a different hotspot footprint, so when you do a context switch at the software (thread) level, you switch your gate array for the hardware-implemented hotspots of the new thread. I believe this approach simplifies things, and also truly unifies hardware and software, since the programmer is entirely unaware of what's going on under the hood. That's what we want in the end, isn't it - the software is the machine. I have dreams of a single multitasked fpga doing all of the stuff that each separate component of a motherboard + cards currently does (or an array of fpga's multi-tasking this). Cheap and fast and simple (once you've implemented the JIT technology!). RolandArticle: 16421
>Actually I am running 95 version B. It's in par, not map. I ended up having to >run the tools manually from the command line which was incredibly painful. Did you already try to install M1.5i ? I had the same problem when running par with M1.5. But after installing ver. M1.5i the problem was solved. >Guess I'll be using Altera for my next design. I don't see why. You seem to know the tools inside and out for Altera and Xilinx, so I think you must know a high speed design (e.g 100+Mhz) in a Xilinx will probably not achieve the desired speed in an Altera. ------------------------------------------------------------------------- Kim Hofmans kim.hofmans@barco.com R&D Engineer Barco Graphics tel : +32-9/21 69 342 Tramstraat 69 fax : +32-9/21 69 825 B9052 Gent-Belgium I know to whom I owe the most loyalty and I see him in the mirror every day. (Starke of Rath)Article: 16422
(I should have cross-posted this) Roland Paterson-Jones wrote: > Jonathan Feifarek wrote: > > > the problem is difficult > > because there are too many degrees of freedom right now. > > I like to to view the problem as an extension of HotSpot/JIT technologies > in virtual machine implementation, most notably lately in Java Virtual > Machines. What these technologies do is profile a program on-the-fly (with > embedded profiling instructions, or through interpretation, or whatever). > When they determine that a certain portion of a program is heavily > exercised, then that portion is (re-)compiled with heavy optimisation. > > Now, why not do the same thing, but right down to the hardware, rather than > down to machine code. What you need, however, is a general compiler from a > high-level language (Java bytecode?) to fpga gates. According to the empty > response to a previous posting, nobody is interested in such a thing. > > What you also need is a sense of when this would be more useful than merely > compiling to the machine-code level. I'd be inclined to think that it's > almost always useful, since you can parallelize as much as the source code > will allow for each specific case, which will always be better than a fixed > super-scalar processor architecture. > > Now, each thread of your program will have a different hotspot footprint, > so when you do a context switch at the software (thread) level, you switch > your gate array for the hardware-implemented hotspots of the new thread. > > I believe this approach simplifies things, and also truly unifies hardware > and software, since the programmer is entirely unaware of what's going on > under the hood. That's what we want in the end, isn't it - the software is > the machine. > > I have dreams of a single multitasked fpga doing all of the stuff that each > separate component of a motherboard + cards currently does (or an array of > fpga's multi-tasking this). Cheap and fast and simple (once you've > implemented the JIT technology!). > > RolandArticle: 16423
In article <37446aa8.4459222@news.dial.pipex.com>, ems@riverside- machines.com.NOSPAM writes >there is absolutely *no way* that fpga express is competitive in terms >of vhdl language support, and i'm sure that you know this as well as >the rest of us do. true, there have been major advances in both DC and >express recently, but you've still got some way to go. > >on the other hand, there have been some really nice additions in 3.1 - >FST/scripting and attribute passing primarily, which would make this a >very competitive tool if you got the language support right. > >evan As I understand it, and as you suggest, the language support in DC and FPGA Express is the same. How does the fact that Synopsys goes from strength to strength, and is unarguably both successful and competitive (see their website, Q2 sales 21% up at $190m) square with your comments? Do you mean that the language requirements for FPGA are totally different from those for ASIC? DavidArticle: 16424
We do! Nallatech are Xilinx PCI Xperts just like yourselves (see http://www.xilinx.com/company/consultants/pcixperts.htm). The PCI interface is in a Xilinx Spartan and is reconfigurable with your own designs if required. This leaves the full Virtex available for user applications. We have found that not everyone wants to get into PCI so this provides a straightforward method for developing PCI applications without doing PCI! On the other hand watch our web site for some interesting PCI products coming on-line shortly...... Malachy > -----Original Message----- > From: Austin Franklin [mailto:austin@dark88room.com] > Posted At: 20 May 1999 13:09 > Posted To: fpga > Conversation: Virtex based PCI cards > Subject: Re: Virtex based PCI cards > > > Why don't you guys have the PCI interface in the Xilinx? > > Malachy Devlin <m.devlin@nallatech.com> wrote in article > <B4000FE0503ED211864100104B4C66C30972A9@CONTEXT>... > > Nallatech has been supplying a Virtex development platform since > > February. This is a 32bit 33Mhz PCI card with a 300K - 800K Virtex > > device and 2 individual banks of 2MBytes 100Mhz ZBT SRAM. > > The PCI card, called the Ballynuey, handles all the PCI > issues and comes > > with a pre-configured Spartan that handles the PCI > interfacing and data > > buffering between the Virtex and the PC application. PCI > drivers, Virtex > > debug tool, FPGA configuration and Application API are > included with the > > card. > > Additionally the card includes 4 DIME modules for expansion > and custom > > I/O. Currently there are modules for Image Capture and > Display, a Dual > > XCV1000 module (yes over 2Million gates!) and various other > I/O modules > > (e.g. LVDS) with more in the pipeline. The modules can provide over > > 2Gbytes/sec bandwidth and has over 200 I/O connections. > > > > Configuration of the on-board Virtex is configured > dynamically over the > > PCI using the tools provided with the card (and is much faster than > > Xchecker!) If additional DIME modules are placed on the > card their FPGAs > > are also individually configurable via PCI. > > > > > > Check out the web site for more details and new > developments soon to be > > announced at http://www.nallatech.com/ > > > > > > Malachy Devlin > > Nallatech Ltd > > m.devlin@nallatech.com > > > > > > > -----Original Message----- > > > From: alfred fuchs [mailto:alfred.fuchs@siemens.at] > > > Posted At: 12 May 1999 19:09 > > > Posted To: fpga > > > Conversation: Virtex based PCI cards > > > Subject: Re: Virtex based PCI cards > > > > > > > > > I've just finished the design of a CompactPCI board (6U) with > > > one Virtex1000 > > > and two synchronous SRAM-modules (2Mx72). It mainly uses > > > rear-panel-I/O > > > (more than 100 signals) and is therefore open for various > > > applications. The > > > PCI-IF is a PLX9054, the FPGA is configured by the PCI-master. > > > Pricing is TBD, but we tend to be expensive. > > > > > > Alfred Fuchs > > > Siemens Austria > > > PSE PRO LMS2 > > > +43/1/1707-34113 > > > > > > Atif Zafar schrieb: > > > > > > > Hello: > > > > > > > > Does anyone know of any development boards (PCI) that > > > use the Virtex > > > > FPGA? I am interested in a board with preferably several > > > XV800 or XV1000 > > > > devices along with RAM for prototyping a custom > graphics pipeline. I > > > > have heard of the PCI Pamette board, but to my knowledge > > > this does not > > > > have Virtex silicon. Thanks for any info. > > > > > > > > Atif Zafar > > > > Regenstrief Institute > > > > Zafar_A@regenstrief.iupui.edu > > > > > > > >
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