Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 16400

Article: 16400
Subject: Re: Onboard JTAG-programming Xilinx CPLD with Found.Series?
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 20 May 1999 07:48:24 GMT
Links: << >>  << T >>  << A >>
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: 16401
Subject: Re: Is schmitt trigger possible with Xilinx 9536?
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Thu, 20 May 1999 09:02:01 +0100
Links: << >>  << T >>  << A >>
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: 16402
Subject: Makefile for Xilinx Foundation 1.4
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 20 May 1999 09:11:13 GMT
Links: << >>  << T >>  << A >>
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: 16403
Subject: Re: Virtex based PCI cards
From: "Austin Franklin" <austin@dark88room.com>
Date: 20 May 1999 12:09:15 GMT
Links: << >>  << T >>  << A >>
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
> > 
> 
> 
Article: 16404
Subject: DSP Board for PC/104 Bus
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 20 May 1999 10:00:55 -0400
Links: << >>  << T >>  << A >>
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.com
Article: 16405
Subject: Re: Case study: Viewlogic's IntelliFlow
From: Bill Kury <wjk@datum-telegraphic.com>
Date: Thu, 20 May 1999 15:34:44 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Is schmitt trigger possible with Xilinx 9536?
From: "Michael Ayton" <aytonm@mtifwb.com>
Date: Thu, 20 May 1999 09:42:02 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: DSP Board for PC/104 Bus
From: Mike Treseler <tres@tc.fluke.com>
Date: Thu, 20 May 1999 17:13:19 +0000
Links: << >>  << T >>  << A >>
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: 16408
Subject: Re: Xilinx M1.5 Crash
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Thu, 20 May 1999 10:22:14 -0700
Links: << >>  << T >>  << A >>
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 Quayle



Article: 16409
Subject: Re: Foundation FPGA Express
From: Jim Kipps <jkipps@viewlogic.com>
Date: Thu, 20 May 1999 13:52:27 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Case study: Viewlogic's IntelliFlow
From: Jim Kipps <jkipps@viewlogic.com>
Date: Thu, 20 May 1999 14:11:27 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx M1.5 Crash
From: "Adam J. Elbirt" <aelbirt@nac.net>
Date: Thu, 20 May 1999 15:07:24 -0400
Links: << >>  << T >>  << A >>
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 Quayle

Article: 16412
Subject: Re: Onboard JTAG-programming Xilinx CPLD with Found.Series?
From: "Alain Cloet" <alain.cloet@planetinternet.be>
Date: Thu, 20 May 1999 21:20:19 +0200
Links: << >>  << T >>  << A >>

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
Subject: Re: How synthesize tools concern with size of the design?
From: ems@riverside-machines.com.NOSPAM
Date: Thu, 20 May 1999 20:04:26 GMT
Links: << >>  << T >>  << A >>
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.

evan



Article: 16414
Subject: Re: High Speed Reconfigurability
From: Jonathan Feifarek <feifarek@ieee.org>
Date: Thu, 20 May 1999 15:25:50 -0600
Links: << >>  << T >>  << A >>
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 solutions
Article: 16415
Subject: Re: DSP Board for PC/104 Bus
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 20 May 1999 20:50:03 -0400
Links: << >>  << T >>  << A >>
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.com
Article: 16416
Subject: Re: High Speed Reconfigurability
From: Steven Casselman <sc@vcc.com>
Date: Thu, 20 May 1999 19:54:04 -0700
Links: << >>  << T >>  << A >>
> 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.com


Article: 16417
Subject: Re: Xilinx M1.5 Crash
From: zule <zule@home.net>
Date: Fri, 21 May 1999 03:23:55 GMT
Links: << >>  << T >>  << A >>
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.
> 
> Adam
Article: 16418
Subject: Re: Xilinx M1.5 Crash
From: "Adam J. Elbirt" <aelbirt@nac.net>
Date: Thu, 20 May 1999 23:53:22 -0400
Links: << >>  << T >>  << A >>
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.
> >
> > Adam

Article: 16419
Subject: Call for Papers: RAW 2000 (Reconfigurable Architectures Workshop)
From: odiessel@cs.newcastle.edu.au (Oliver Diessel)
Date: 21 May 1999 06:39:34 GMT
Links: << >>  << T >>  << A >>

                  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: 16420
Subject: Re: High Speed Reconfigurability
From: Roland Paterson-Jones <rpjones@hursley.ibm.com>
Date: Fri, 21 May 1999 09:23:14 +0100
Links: << >>  << T >>  << A >>
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!).

Roland


Article: 16421
Subject: Re: Xilinx M1.5 Crash
From: "Kim Hofmans" <kim.hofmans@barco.com>
Date: Fri, 21 May 1999 10:25:09 +0200
Links: << >>  << T >>  << A >>

>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
Subject: Re: High Speed Reconfigurability
From: Roland Paterson-Jones <rpjones@hursley.ibm.com>
Date: Fri, 21 May 1999 09:26:47 +0100
Links: << >>  << T >>  << A >>
(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!).
>
> Roland



Article: 16423
Subject: Re: How synthesize tools concern with size of the design?
From: David Pashley <David@edasource.com>
Date: Fri, 21 May 1999 09:41:43 +0100
Links: << >>  << T >>  << A >>
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?

David


Article: 16424
Subject: Re: Virtex based PCI cards
From: Malachy Devlin <m.devlin@nallatech.com>
Date: Fri, 21 May 1999 13:28:11 +0100
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search