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
2017JanFebMarApr2017

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 5875

Article: 5875
Subject: Re: Development board with multiple FPGAs
From: "Steven K. Knapp" <optmagic@ix.netcom.com>
Date: 21 Mar 1997 16:14:40 GMT
Links: << >>  << T >>  << A >>
For those interested, I have a list of various FPGA-based boards at:

http://www.netcom.com/~optmagic/index.html#Boards
-- 
Steven Knapp
E-mail:  optmagic@ix.netcom.com
Programmable Logic Jump Station:  http://www.netcom.com/~optmagic

Steve Nordhauser <nords@intersci.com> wrote in article
<3331C41C.189@intersci.com>...
| Richard Schwarz wrote:
| > 
| > Stuart Clubb wrote:
| > 
| >   Try Aptix at:
| >   http://www.aptix.com
| > 
| >   Probably not cheap, but looks_real_nice. :-)
| > 
| >  Take a look at
| > http://www.erols.com/aaps .
| > 
| > The ST-FPGA module has 4 XILINX 208pin QFP chips and a ton of IO pins.
| > The board was originally developed for ASIC design testing.You can put
| > whatever type chips you want on the boards.
| 
| I'm using a board from Giga Operations that is very expandable.
| Their support is excellent and the features are very useful.
| http://www.gigaops.com
| 
| Steve Nordhauser
| 
Article: 5876
Subject: problem: my xc4003 don't work !!!!
From: mauro@uxla01.lamel.bo.cnr.it (Mauro Fiorini)
Date: 21 Mar 1997 18:33:12 GMT
Links: << >>  << T >>  << A >>

Sorry for a minute, but i'm starting to work with xilinx xc4003A.
I have a serial prom xc1765 on the board near the fpga and I made some 
connections (if I understood ...) between the chips in agreement with 
xilinx "Programmable Logic Data Book" (PLDB) using "Master Serial Mode"
programming scheme. 
These connection are (/ means a low active pin):
	
	FPGA				PROM

 	/progr (pin 55)	------->	reset (pin 4)

	done   (pin 53)	------->	/ce   (pin 3)

	din    (pin 71) ------->	data  (pin 1)

	cclk   (pin 73) ------->	clk   (pin 2)

PBLD suggests to use a pull-up resistor (2 to 8 kohm) on done pin of FPGA.
But my FPGA doesn't work !!!!!!
I think that the prom send correctly its program inside the FPGA (i see 
the bitstream on a scope), then the prom goes in idle state and the 
FPGA too !!! After this step nothing happen ......

Any suggestion ?????




P.S. sorry for my english !!!!
Article: 5877
Subject: Re: FIFOs
From: peter@xilinx.com (Peter Alfke)
Date: Fri, 21 Mar 1997 18:04:07 -0700
Links: << >>  << T >>  << A >>
In article <33320105.7612@sr.hp.com>, Greg Quintana <gregq@sr.hp.com> wrote:

> Anyone have equations for FIFOs that could be used in a xilinx part?
> -- 
I wrote and published an app note: Synchronous and asynchronous FIFO
Designs, which is available on our web-site ( www.xilinx.com ) look under
XC4000 app naotes.

Here is the performance:
16 x 16 uses 23 CLBs, runs at 65 MHz synchronously ( read and write clock
are the same ) or at 50 MHz asynchronously. Both cases allow simultaneous
full-speed read and write. Yes, there is asynchronous arbitration.
32-deep, 8-wide takes 28 CLBs and runs at 50 MHz and 40 MHz as descibed above.
64 x 8 uses 48 CLBs and runs at the same 50 or 40 MHz,
Just to give you a feel.

If you are interested, sned me e-mail, and I can fax you some improvements.
Sorry, no VHDL, but the memory design is very straightforward, and the
controller, although clever, I think :-), is really quite simple.
It can be implemented in any XC4000E, or XC4000EX, or the new XC4000XL (
3.3-V) parts, and will operate faster on these upcoming -2 and -1 devices.

Peter Alfke, Xilinx Applications
Article: 5878
Subject: Re: Sole source
From: peter@xilinx.com (Peter Alfke)
Date: Fri, 21 Mar 1997 18:24:56 -0700
Links: << >>  << T >>  << A >>
In article <5gs1aq$pjv@waterloo.algor.co.uk>, rick@camden.algor.co.uk
(Rick Filipkiewicz) wrote:

> Much worse than not having a second source for the physical parts is having 
> the FPGA vendor as the only source for the Place&Route tools.

While I can understand your desire to have a second source for your
contiinuing purchases of components, (for reasons of assured availabilty
and lowest possible pricing), I fail to see your disappointment in a
single source for the tools.

When you buy them from the component supplier, you can be sure that they
are as close as possible to the real silicon, as up-to-date as possible,
and you are also buying a heavily subsidized piece of software. There
should be no doubt about it: The major FPGA houses sell their software
tools at a bargain basement price, a price that does not really do justice
to the development cost ( plus whatever royalties must be paid ).

As you know, there once was a company called NeoCad who tried to develop
and sell software without any subsidy from the silicon, and they did not
survive. 
It became pretty obvious that you cannot sustain a 50-(wo)man development
effort on the kind of software revenues that this market is willing to
provide. You need an income of 15 to 25 million dollars per year,
otherwise you fall below critical mass. ( These numbers are my estimates,
not authorized by Xilinx ).

Peter Alfke, Xilinx Applications
Article: 5879
Subject: Re: 8-bit divider in FPGA
From: Tom Burgess <Tom_Burgess@bc.sympatico.ca>
Date: Fri, 21 Mar 1997 22:04:13 -0700
Links: << >>  << T >>  << A >>
Johannes Soelhusvik wrote:
> 
> Does anyone have a simple solution to the design of an 8-bit simple
> divider (A=B/C, A,B and C being 8-bit variables) for a xilinx FPGA
> (xc4000 series). The circuit must take up as little space as possible
> (bit serial solution?).
> 
> --
> Johannes Sølhusvik
> ABB Corporate Research
> Electronic Systems Dept.
> P.O. Box 90
> N-1361 Billingstad
> Norway
> Tel: +47 66 84 34 28
> Fax: +47 66 84 35 41
> Email: jso@nocrc.abb.no

Am I correct in assuming that you just want the integer portion of
the division? Is speed important? If not, just count the number of
times C can be subtracted from B before the result passes through zero.
8 bit counter (4 CLBs), registered 8-bit subtractor (4 more), a bit
of control logic. Say 12 CLBs total, worst case result in 256 clocks
(dividing by 1). You DID ask for a simple solution :)

	regards, tom
Article: 5880
Subject: Re: Multiple clocks in Xilinx
From: z80@dserve.com (Peter)
Date: Sat, 22 Mar 1997 07:38:26 GMT
Links: << >>  << T >>  << A >>

Only because the -A is faster, so is less tolerant to designs which
use interconnects to route the clock to a shift register (or a
counter).

In the old 3064, I used to assign a L (long line) attribute (in
Viewdraw) to any net which was used to carry such a clock, and that
always worked fine. The skew (checked using the XACT die layout
display) was very small, less than 1ns. The trouble is that the -A
parts, especially the faster ones, appear to have their logic elements
faster by a *larger* factor than their interconnects, so interconnect
delays become more important. 

I have had several cases of the *same* bitstream failing to work in a
newer device. In some cases it was this clock skew, and in others it
was the use of the -i switch in "xnfmap -cosi" which gives you
slightly better packing density but introduces a small hold time to
D-types - again this was never a problem in the 3000 devices.

But as old hands here will point out, one should not be doing any of
the above anyway. In any Xilinx FPGA, one is supposed to use the
global clock nets to route a common clock to all D-types, and use the
clock enables to choose which one actually gets clocked.

This is fine, except it is more laborious to design that way, and a
right pain sometimes.

And it is a problem when using an FPGA to prototype an ASIC (a VERY
common use for FPGAs, unfortunately for their manufacturers) which
needs to be low power, because the very last thing you want to do in
such an ASIC is to have the whole thing going up and down at X MHz.

I know for a fact that with the older 3000 parts lots of people used
to do designs the same way I did. And Xilinx engineers were quite
happy about that. They told you to attach the L attribute, and/or
attach something like SC=1 (skew less than 1ns) and everyone was
happy. Now, I always use common clocks for structures which need
"concurrent" clocking. With the faster versions of the -A parts
especially, one needs to be 100% by the book, else it just won't work.

>could you elaborate a little please, i don't understand and i'd like to as it
>means i don't understand the difference between the 2 architectures. i'm
>currently using some A's with bit streams designed for non-A's and
>you have worried me!
>


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 5881
Subject: Re: Is this really possible?
From: daveb@iinet.net.au_spam_trap (David R Brooks)
Date: Sat, 22 Mar 1997 09:53:39 GMT
Links: << >>  << T >>  << A >>
Roger Kinkead <roger@rkhost.demon.co.uk> wrote:

:In article: <33315AAB.3416@ids.net>  Ray Andraka <randraka@ids.net> writes:
:> 
:> Kent wrote:
:> 
:> > I am curious to know if anyone else has been able to instantiate a basic 
:50
:> > Mips processor in less than 10% of a 3090, or a "vector processor" in a
:> > little more than 200 CLBs. Is there some big secret about the 3090 you
:> > guys have been keeping quite, or is there something I am missing here?
:> 
:> No big secret.  The design is just well tailored to the FPGA
:> architecture.  I suspect the 'nanoprocessor' is a simple RISC engine
:> (very few instructions) with hooks to permit specialized instructions to
:> be added.  
:<SNIP>
:
:If anyone is interested, it is possible to view/download/print patents at IBM
:patent server (www.ibm.com/patent I think it is?).  Along with other
:interesting things, you can pull down Metalithic's 5,361,373 patent which may
:explain many things to you.
:
:Hope at least some of this helps.
:
 The IBM patent server is at http://patent.womplex.ibm.com

 Hit "Number Search" with the above number, and up it comes. The
abstract is pretty sparse (they usually are), just saying "let's use a
lot of FPGA's to do this".






[Wasted lines to fool this newsreader]











--  Dave Brooks    <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
    "From" line rigged to foil spambots: daveb <at> iinet.net.au
Article: 5882
Subject: Re: 8-bit divider in FPGA
From: Ray Andraka <randraka@ids.net>
Date: Sat, 22 Mar 1997 10:20:38 -0500
Links: << >>  << T >>  << A >>
Tom Burgess wrote:
> 
> Johannes Soelhusvik wrote:
> >
> > Does anyone have a simple solution to the design of an 8-bit simple
> > divider (A=B/C, A,B and C being 8-bit variables) for a xilinx FPGA
> > (xc4000 series). The circuit must take up as little space as possible
> > (bit serial solution?).
> >
> > --
> > Johannes Sølhusvik
> > ABB Corporate Research
> > Electronic Systems Dept.
> > P.O. Box 90
> > N-1361 Billingstad
> > Norway
> > Tel: +47 66 84 34 28
> > Fax: +47 66 84 35 41
> > Email: jso@nocrc.abb.no
> 
> Am I correct in assuming that you just want the integer portion of
> the division? Is speed important? If not, just count the number of
> times C can be subtracted from B before the result passes through zero.
> 8 bit counter (4 CLBs), registered 8-bit subtractor (4 more), a bit
> of control logic. Say 12 CLBs total, worst case result in 256 clocks
> (dividing by 1). You DID ask for a simple solution :)
> 
If the remainder is needed, it can easily be obtained from the residue
in the subtractor using an extra 8 bit register.  The subtraction can
also be done bit serially, although CLB savings is somewhat offset by
increased complexity in control.

-Ray Andraka, P.E.
Chairman, the Andraka Consulting Group
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://www.ids.net/~randraka
Article: 5883
Subject: Re: FIFOs
From: Brad and Renea Ree <rbree@mindspring.com>
Date: Sat, 22 Mar 1997 14:10:15 -0500
Links: << >>  << T >>  << A >>
Greg Quintana wrote:
> 
> Anyone have equations for FIFOs that could be used in a xilinx part?
> --
> 
>                                                 Greg Quintana
You may find that is more cost effective to use standard FIFOs. 
Implementing large FIFOs on an FPGA uses a lot of silicon.
Article: 5884
Subject: Re: Sole source
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Sun, 23 Mar 1997 05:22:52 GMT
Links: << >>  << T >>  << A >>
In article <peter-2103971824560001@appsmac-1.xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:
>...I fail to see your disappointment in a single source for the tools.
>When you buy them from the component supplier, you can be sure that they
>are as close as possible to the real silicon, as up-to-date as possible...

Oddly enough, when I buy an EPROM programmer, I don't buy it from the
company that sells the EPROMs, and yet it generally seems to be up to date
with the silicon.  Of course, it helps that the EPROM programming specs
are published openly.  However, even for things like PALs where the specs
are secret (oddly enough, sometimes from the same companies who openly
publish EPROM programming specs), the programmer manufacturers simply have
agreements with the chip suppliers that give them access to current info.

>...you are also buying a heavily subsidized piece of software. There
>should be no doubt about it: The major FPGA houses sell their software
>tools at a bargain basement price, a price that does not really do justice
>to the development cost ( plus whatever royalties must be paid ).

Then why don't they sell them at the cost of duplication and distribution,
plus any applicable royalties?  I don't see them charging $100 per copy
for their databooks, which are similarly subsidized.


Alas, not all chip suppliers are smart enough to see that they will sell
more chips if they make a firm commitment to a competitive market in
support tools.  If the objective is to sell more chips, it makes no sense
to artificially restrict the prices and functionality of support tools by
maintaining a monopoly position. 
-- 
Committees do harm merely by existing.             |       Henry Spencer
                           -- Freeman Dyson        |   henry@zoo.toronto.edu
Article: 5885
Subject: Re: Complexity of standards
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Sun, 23 Mar 1997 05:40:05 GMT
Links: << >>  << T >>  << A >>
In article <VA.00000002.253d88f6@eng13>,
Greg Smith  <gregs@uniquesys.com> wrote:
>>...one need not assume actual malice.  There is always a
>>tradeoff between performance and easy implementation, and big companies can
>>cope with implementation difficulties relatively easily, so naturally their
>>design ideas are biased strongly toward maximum performance. 
>
>Yes. We are now in an era where standards (and I am referring to actual, not
>ad hoc, standards) are being designed with the assumption that ASICs,
>and other technologies such as connectors, will be developed specifically
>for the standard...

Note that exonerating the big companies of malice is not the same as
saying that they have the best interests of us all at heart.  Such complex
standards *are* a bad thing, harmful to the industry and the customers.
Often we would be better off with a bit less performance and rather easier
implementation.  (The decision to change Ethernet from 3Mbps to 10Mbps
probably delayed its widespread market acceptance by at least a decade,
and has spawned a lot of pointless reinventions of the wheel in areas
that would have been better served by a cheap and simple Ethernet.)

It would be a forward step if we could figure out a way to get smaller
players -- and better yet, customers -- more actively involved in the
standard-setting.  The problem is that the big companies are also the ones
who can spare the resources for major involvement in standards work, so
their voices are disproportionately heard even in standards whose
development processes are open to all (and some aren't). 

There is a secondary and more fundamental problem in that any standard
developed by the current players (large or small) will be biased toward
people who are already in the industry.  They can see that it impacts
them and that there is incentive to get involved.  This is much less
obvious to the folks who might try to enter the industry next year.

>Consider that SCSI-1 was drafted at a time when it was assumed
>that all SCSI interface circuits would be built with 74XX TTL - there's
>a standard which has turned out to have very long legs.

Exercise for the student:  what might one infer from this about the
need, or lack thereof, for complexity in standards?
-- 
Committees do harm merely by existing.             |       Henry Spencer
                           -- Freeman Dyson        |   henry@zoo.toronto.edu
Article: 5886
Subject: Re: Sole source
From: z80@dserve.com (Peter)
Date: Sun, 23 Mar 1997 07:34:03 GMT
Links: << >>  << T >>  << A >>

>As you know, there once was a company called NeoCad who tried to develop
>and sell software without any subsidy from the silicon, and they did not
>survive. 

They should have charged a lot less money !!

But I really mean that. I recall examining their product at an FPGA
seminar (organised by a distributor) a few years ago, and their prices
were more or less identical to those charged by Xilinx, and (then)
others. Very high - too high for the majority of very small firms, and
the large firms are not so worried about price, and are happier to buy
their P&R tools from the silicon vendor.

The early Neocad s/w was not exactly bug-free, either. At that time,
Xilinx's s/w was quite good, in fact I still use your s/w from that
era.

Therefore, there was little point in anyone using their products. OK,
they could pack more into an FPGA than anyone else. But how many FPGAs
are packed to the limit? Very few in fact. I know someone who uses a
5-figure/month number of the XC3030, and he gets them so cheap that he
uses them even when they only replace a handful of HC chips.

If you are going to compete, in any business, you have to offer
something *special*. If you are going to compete with someone as
established as Xilinx, you have to offer something *very* special.

I think they missed an opportunity to make FPGA tools available to a
much wider user base than exists at present.
Article: 5887
Subject: Re: Sole source
From: Tom Burgess <Tom_Burgess@bc.sympatico.ca>
Date: Sun, 23 Mar 1997 01:53:08 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> <some stuff deleted - this is re sole-source tools>
> 
> When you buy them from the component supplier, you can be sure that they
> are as close as possible to the real silicon, as up-to-date as possible,
> and you are also buying a heavily subsidized piece of software. There
> should be no doubt about it: The major FPGA houses sell their software
> tools at a bargain basement price, a price that does not really do justice
> to the development cost ( plus whatever royalties must be paid ).

They are also free to play games with the software to push new silicon and
frustrate the competition, e.g. the arbitrary freezeout of 3000 from XACT 
performance(TM) features.

The limits of the possible (in terms of timely delivery of useable software)
seem to shrink somewhat when you are a subsidized component (cost center) in
a megacorp. As a user, I would rather see the specs released and the whole
software thing spun off to private industry and let the best FPGA packer win.

> As you know, there once was a company called NeoCad who tried to develop
> and sell software without any subsidy from the silicon, and they did not
> survive.

I guess being assimilated by the Xilinx entity equates to non-survival? I
have not yet seen results from the FPGA foundry / XACT merger and do not
think it wise to hold my breath.

> It became pretty obvious that you cannot sustain a 50-(wo)man development
> effort on the kind of software revenues that this market is willing to
> provide. You need an income of 15 to 25 million dollars per year,
> otherwise you fall below critical mass. ( These numbers are my estimates,
> not authorized by Xilinx ).

All you need is a few brilliant (wo)men - and a bit of help from Xilinx on device
data. If Xilinx supplied decent basic tools - free! and let the free market do
the fancy stuff, I believe in the end Xilinx would sell a lot more chips and
make more money than by selling tools as a loss leader. The token cost (one
or 2 K$) is a major barrier for the engineer who wants to switch from brand Y.

anyway - love your app notes -

	regards tom.
Article: 5888
Subject: Re: What tools for $8000?
From: Richard Schwarz <aaps@erols.com>
Date: Sun, 23 Mar 1997 10:33:41 -0500
Links: << >>  << T >>  << A >>
Anthony Ellis wrote:

  Given that I have $8000 to spend on tools and want to do the
  following:

          FPGA VHDL development - just the VHDL coding, debugging and
  simulating.
  Independent of FPGA vendor.
          Will use customer's back end tools as required. Typical VHDL
  design
  bureau.

          Front end schematic capture tools to interface with
  Coopers&Cyan  as  well
  as PCAD PCB tools.

  I currently use Workview Office tools and Speedwave. Need tools for
  my own
  business now and would like some alternatives.
  Any recommendations?

  Anthony "LogicWorks"


I know you wanted FPGA independent tools but check out the tools at:

http://www.erols.com/aaps

The packages are very reasonable (currently only XILINX)

Also check out my web page for the following non-vendor specific tools:

EXEMPLAR
MODEL TECHNOLOGIES
ACCOLADE VHDL
CAPILANO Design Works

My links page:

http://www.erols.com/links.html
--
__________________________________________________________
Richard D. Schwarz, President
Associated Professional Systems (APS)
3003 Latrobe Court, Abingdon, Maryland 21009
Phone: 410-569-5897   Fax: 410-661-2760
Email: aaps@erols.com   Web site: http://www.erols.com/aaps
--- FPGA Solutions/Test Boards/ EDA Software ---
--- SIGTEK Spread Spectrum & Communications Equipment ---

Article: 5889
Subject: Re: Sole source
From: Richard Schwarz <aaps@erols.com>
Date: Sun, 23 Mar 1997 10:37:26 -0500
Links: << >>  << T >>  << A >>
Henry Spencer wrote:

  In article <peter-1903971555490001@appsmac-1.xilinx.com>,
  Peter Alfke <peter@xilinx.com> wrote:
  >A single source must and will use multiple fab lines ( to protect
  against
  >accidents ) and must be forthcoming in price reductions. I think we
  in the
  >FPGA world have done that...

  Tell that to Altera's FLASHlogic customers.  Incidentally, how many
  price
  reductions have there been on Xilinx's development software lately?

  The biggest reason why the customers do still like having second
  sources
  is that it insulates them from the management whims of a sole
  supplier.
  Sure, Intel will deliver... but will it deliver the parts you want?
  Or
  will it decide, to pick a purely hypothetical example :-), that it
  won't
  ship Pentiums at more than 200MHz because that would compete with
  the
  Pentium II (which they annoyingly decided wouldn't be
  socket-compatible
  with anything that came before)?
  --
  Committees do harm merely by existing.             |       Henry
  Spencer
                             -- Freeman Dyson        |
  henry@zoo.toronto.edu

 Check out the XILINX tool prices at:

http://www.erols.com/aaps

These kits with the APS-X84 boards are very reasonable and will work to
make the tool kits very accessible and will help all concerned (XILINX,
ALDEC,APS, and of course the all important USERS).

--
__________________________________________________________
Richard D. Schwarz, President
Associated Professional Systems (APS)
3003 Latrobe Court, Abingdon, Maryland 21009
Phone: 410-569-5897   Fax: 410-661-2760
Email: aaps@erols.com   Web site: http://www.erols.com/aaps
--- FPGA Solutions/Test Boards/ EDA Software ---
--- SIGTEK Spread Spectrum & Communications Equipment ---

Article: 5890
Subject: Re: Accolade
From: Richard Schwarz <aaps@erols.com>
Date: Sun, 23 Mar 1997 10:49:57 -0500
Links: << >>  << T >>  << A >>
Hans Tiggeler wrote:

  In article <5gd0vp$4cp@mtinsc03.worldnet.att.net>,
  c-d-symes@worldnet.att.net
  says...
  >
  >In article <01bc30ac$e2c746b0$0307e38f@zimbo>,
  >   "Joel Kolstad" <Joel.Kolstad@Techne-Sys.com> wrote:
  >>> any experience with Accolade-Tools (VHDL-Simulation and
  FPGA-Synthesis) ?
  >>
  >>I downloaded their demo and it died a horrible death under NT 4.0.

  >>
  >And it's REAL unstable under W95
  My 3.06b none limited evaluation copy works fine under Win95. It
  does have
  some problem, like sometimes you get multiple minimize/maximize
  close buttons,
  and its got some other "features",  but it never crashed my machine.
  Under NT
  3.51 the screen is not updated correctly when running PeakSIM. To
  solve this
  problem you have to minimize/maximize your screen or zoom in/zoom
  out.
  Accolade is bringing out updated quite regularly. Sure it can not
  compete with
  V-Systems but than again V-Systems has been around a lot longer than
  Accolade
  and is not in the same price range. If you do have a problem, send
  them to
  Accolade Technical support and if they ignore you than you know were
  to
  complain :-)

  Hans.
  SSTL
  UK

 I must say that the Accolade support group is very helpful na dquick to
respond. Their VHDL simulator is in a price range that will allow many
more users to access a good VHDL simulator. We will be using it to test
many of our  FPGA VHDL designs, and hope to work close with David
Pellerin in integrating some other future products. His approach of
downloading constantly updated demo software will always leave him open
to critique , but in the long run this critique will aid him in wringing
out the difficulties mentioned above. Anyone doing development in the
ever-changing PC and Windows environment knows this will always be an on
going process. I found the Accolade tools to have some very nice
features, which the Model Tech simulator (which we also have) does not
have. I would not hesitate to check them out.

--
__________________________________________________________
Richard D. Schwarz, President
Associated Professional Systems (APS)
3003 Latrobe Court, Abingdon, Maryland 21009
Phone: 410-569-5897   Fax: 410-661-2760
Email: aaps@erols.com   Web site: http://www.erols.com/aaps
--- FPGA Solutions/Test Boards/ EDA Software ---
--- SIGTEK Spread Spectrum & Communications Equipment ---

Article: 5891
Subject: Re: FIFOs
From: peter@xilinx.com (Peter Alfke)
Date: Sun, 23 Mar 1997 16:43:42 -0700
Links: << >>  << T >>  << A >>
In article <33342E96.4AC1@mindspring.com>, Brad and Renea Ree
<rbree@mindspring.com> wrote:


> You may find that is more cost effective to use standard FIFOs. 
> Implementing large FIFOs on an FPGA uses a lot of silicon.

That depends on the size of the FIFO on the speed rquirements, and on the
number of available I/O pins.

I assume that the internal FIFO wins when it is up to 32 levels deep,
and/or when the required speed is faster than 30 MHz.

Very large FIFOs, kilo-words deep, must obvously stay outside the FPGA.

Peter Alfke, Xilinx Applications
Article: 5892
Subject: Re: problem: my xc4003 don't work !!!!
From: peter@xilinx.com (Peter Alfke)
Date: Sun, 23 Mar 1997 17:10:05 -0700
Links: << >>  << T >>  << A >>
In article <5guk98$sf6@sirio.cineca.it>, mauro@uxla01.lamel.bo.cnr.it
(Mauro Fiorini) wrote:


>         FPGA                            PROM
> 
>         /progr (pin 55) ------->        reset (pin 4)  change this
> 
>         done   (pin 53) ------->        /ce   (pin 3)  change this
> 
>         din    (pin 71) ------->        data  (pin 1)
> 
>         cclk   (pin 73) ------->        clk   (pin 2)
> 
>
It's sunday afternoon, and I just want to give you a sure solution:

Program the SPROM for active Low RESET.
Then drive the SPROM RESETbar from INITbar of the XC40003A

Drive the SPROM CEbar from LDCbar of the FPGA.

This is the absolute best way, and is also the one we document on page
4-68 of our data book.

The problem with your board is most likely that DONE is configured to go
High early ( that's the default ) so it disables the SPROM when several
bits are still needed. ( see page 13-27 of the Sept 96 data book, or 14-27
of the July 96 book.

Of course, you could also try configuring in your present scheme with DONE
configured to go High late. Not my recommendation, but may be easier for
you.

Ciao
Peter Alfke, Xilinx Applications
Article: 5893
Subject: ICCIMA'98 Special Sessions - First CFP
From: Henry Selvaraj <Henry.Selvaraj@fcit.monash.edu.au>
Date: Mon, 24 Mar 1997 10:49:42 +1000
Links: << >>  << T >>  << A >>
ICCIMA'98
 
                               9-11 February 1998
 
         Monash University, Gippsland Campus, Churchill, Australia
 
 
                 F I R S T    C A L L      F O R     P A P E R S
 
    
     The conference will include sessions on theory, implementation and
 applications, as well as the non-technical areas of challenges in
 education and technology transfer to industry. There will be both oral
 and poster sessions.  Accepted full papers will be included in the
 proceedings  to be published by World Scientific. Several well-known 
 keynote speakers will address the conference.
 

 Special Sessions:
 
   Artificial Intelligence and Logic Synthesis: intelligent algorithms 
 for logic synthesis; functional decomposition in machine learning,
 pattern recognition, knowledge discovery and logic synthesis;
 evolutionary and reconfigurable computing with FPGAs. Chair: Lech
 Jozwiak, Eindhoven University, Netherlands.
 
   Multimedia Information Retrieval: segmentation of audio, image and
 video; feature extraction and representation; semi-automatic text
 annotation techniques; indexing structure; query model and retrieval
 methods; feature similarity measurement; system integration issues;
 prototype systems and applications.  Chair: Guojun Lu, Monash
 University, Australia.
 
 Pre-Conference Workshops and Tutorial:
 Proposals for pre-conference workshops and tutorials relevant to the
 conference topics are invited. These are to be held on Saturday 7th
 February and Sunday 8th February at the conference venue. People
 wishing to organise such workshops or tutorials are invited to submit
 a proposal at the same time as submission deadline for papers. The
 accepted proposals will be advertised. 
 
 
 Special Poster Session:
 
 ICCIMA'98 will include a special poster session devoted to recent work
 and work-in-progress. Abstracts are solicited for this session (2 page
 limit) in camera ready form, and may be submitted up to 30 days before
 the conference date. They will not be refereed and will not be
 included in the proceedings, but will be distributed to attendees upon
 arrival. Students are especially encouraged to submit abstracts for
 this session. 
 
 
 Invited Sessions
 
 Keynote speakers (key industrialists, chief research 
 scientists and leading academics) will be addressing 
 the main issues of the conference.
 
 Important Dates:
 
 Submission of papers received latest on:  7 July  97
 
 Notification of acceptance:  19 September 97
 
 Camera ready papers  & registration received by:  24 October  97
 
 
 Submission of Papers
 
 Papers in English reporting original and unpublished research results
 and experience are solicited. Electronic submission of papers via
 e-mail in postscript or Microsoft Word for Windows format directly to
 the General Chair are acceptable and encouraged for the refereeing
 process. If not submitting an electronic version, please submit three
 hard copy originals to the General Chair. Papers for refereeing
 purposes must be received at the ICCIMA 98 secretariat latest by 7
 July 1997. Notification of acceptance will be mailed by 19 September
 1997.
 
 Page Limits
 
 Papers for refereeing should be double-spaced and must include an
 abstract of 100-150 words with up to six keywords.
 
 The accepted papers will need to be received at the ICCIMA 98
 secretariat by 24 October 1997 in camera ready format.  A final 
 preparation format for the camera-ready papers will be provided upon 
 notification of acceptance. Camera ready papers exceeding 6 pages 
 (including abstract, all text, figures, tables and references etc.)
will be 
 charged an extra fee per page in excess to the normal registration.
 
 Evaluation Process
 
 All submissions will be refereed based on the following criteria by
 two reviewers with appropriate background.
 
     originality 
     significance 
     contribution to the area of research 
     technical quality 
     relevance to ICCIMA 98 topics 
     clarity of presentation 
 
 Referees  report will be provided to all authors.
 
 Check List
 
 Prospective authors should check that the following items are attached
 and guidelines followed while submitting the papers for refereeing
 purpose.
 
     * The paper and its title page should not contain the name(s) of 
       the author(s), or their affiliation
     * The paper should have attached a covering page containing 
       the following information 
 
         -title of the paper 
         -author name(s), Affiliation, mail and e-mail addresses, phone
          and fax numbers
         -Conference topic area 
         -up to six keywords 
 
     * The name, e-mail, phone, fax and postal address of the contact
       person should be attached to the submission 
 
 
 Visits and Social Events
 
 Industrial and sight seeing visits will be arranged for 
 the delegates and guests. A separate program will be 
 arranged for companions during the conference.
 
 
 General Chair: 
 
 Henry Selvaraj               
 Gippsland School of Computing 
 & Information Technology
 Monash University,        
 Churchill, VIC, Australia 3842
 Henry.Selvaraj@fcit.monash.edu.au
 Phone: +61 3 9902 6665 
 Fax: +61 3 9902 6842
 
 
 
 International Programme Committee:
 
 Abdul Sattar, Griffith University, Australia 
 Andre de Carvalho, University of Sao Paulo, Brazil 
 Bob Bignall, Monash University, Australia
 Brijesh Verma, Griffith University, Australia (Programme Chair)
 Dinesh Patel, Surrey University, UK
 Henry Selvaraj, Monash University, Australia
 Hyunsoo Lee, University of Yonsei, Korea 
 Jan Mulawka, Warsaw University of Technology, Poland
 Jong-Hwan Kim, Korea Advanced Institute of Science & 
 Technology, Korea
 Lech Jozwiak, Eindhoven Univ. of Tech, Netherlands
 Marek Perkowski, Portland State University, USA
 Michael Bove, MIT Media Laboratory, USA 
 Mikio Takagi, University of Tokyo, Japan 
 Nagarajan Ramesh,Tencor Instruments, USA 
 Ramana Reddy, West Virginia University, USA 
 Regu Subramanian, Nanyang Tech University, Singapore 
 Sargur Srihari, State University of New York, USA
 Shyam Kapur, James Cook University, Australia 
 Sourav Kundu, Kanazawa University, Japan
 S. Srinivasan, IIT, Madras, India
 Subhash Wadhwa, IIT, Delhi, India 
 Tadeusz Luba, Warsaw University of Technology, Poland
 Vishy Karri, University of Tasmania, Australia 
 Xin Yao, University of New South Wales, Australia
 
 International Liaison
 Asian Liaison: 
 Regu Subramanian, Network Technology Research 
 Centre, Nanyang Technological University, Singapore
 
 U.S. Liaison: 
 Marek Perkowski, Portland State University, USA 
 
 European Liaison:
 Tadeusz Luba, Warsaw University of Technology, 
 Poland
 
 
 Organising Committee:
 
 Bob Bignall,  Monash University, Australia
 Baikunth Nath, Monash University, Australia
 Vishy Karri, University of  Tasmania, Australia
 Syed M. Rahman, Monash University, Australia
 Bala Srinivasan, Monash University,Australia
 Cheryl Brickell, Monash University, Australia
 Andy Flitman, Monash University, Australia
 Lindsay Smith, Monash University, Australia
 
   Further Information:
 
   Conference Email :        
                 iccima98@fcit.monash.edu.au
   Conference WWW Page:
                 http://www-gscit.fcit.monash.edu.au/~iccima98
Article: 5894
Subject: fast resampling
From: Christos Dimitrakakis <olethros@geocities.com>
Date: Mon, 24 Mar 1997 04:46:54 +0000
Links: << >>  << T >>  << A >>
I've been developing a soundcard with a xilinx chip (xc400x) used as a
custom dsp among other things.
It is required that a large number of sample be replayed simultaneously
at different sample rates each.
I've thought of a scheme were all of each samples parameters are held in
large shift registers.
The resampling block gets everything from the registers for each sample
and outputs it into an accumulator - in the end everything is
oversampled and output to a DAC

My largest problem now is that the registers must be loadable with new
values.
Erm.. how am I going to do that without multiplexing?
I could have a special control unit that loads the register whenever it
is at the start/end of the register "loop" - what is the best way to
implement this?

-- 
Christos Dimitrakakis
---------------------
mailto:mbge4cd1@fs4.eng.man.ac.uk
mailto:mbge4cd1@afs.mcc.ac.uk
http://www.man.ac.uk/~mbge4cd1
Article: 5895
Subject: Re: 8-bit divider in FPGA
From: Johannes Soelhusvik <jso@nocrc.abb.no>
Date: Mon, 24 Mar 1997 08:28:54 +0100
Links: << >>  << T >>  << A >>
Tom Burgess wrote:
> 
> Johannes Soelhusvik wrote:
> >
> > Does anyone have a simple solution to the design of an 8-bit simple
> > divider (A=B/C, A,B and C being 8-bit variables) for a xilinx FPGA
> > (xc4000 series). The circuit must take up as little space as possible
> > (bit serial solution?).
> >
> > --
> > Johannes Sølhusvik
> > ABB Corporate Research
> > Electronic Systems Dept.
> > P.O. Box 90
> > N-1361 Billingstad
> > Norway
> > Tel: +47 66 84 34 28
> > Fax: +47 66 84 35 41
> > Email: jso@nocrc.abb.no
> 
> Am I correct in assuming that you just want the integer portion of
> the division? Is speed important? If not, just count the number of
> times C can be subtracted from B before the result passes through zero.
> 8 bit counter (4 CLBs), registered 8-bit subtractor (4 more), a bit
> of control logic. Say 12 CLBs total, worst case result in 256 clocks
> (dividing by 1). You DID ask for a simple solution :)
> 
>         regards, tom

First of all, thanks very much for responding to my query.
I confirm that I just want the integer portion of the division. And your
suggested solution is nice and simple, but I do not have time to go
through as many as 255 clock cycles (worst case). What can I do to
reduce this to say 32 ?

-- 
Johannes Sølhusvik
ABB Corporate Research
Electronic Systems Dept.
P.O. Box 90
N-1361 Billingstad
Norway
Tel: +47 66 84 34 28
Fax: +47 66 84 35 41
Email: jso@nocrc.abb.no
Article: 5896
Subject: ZYCAD's 'browse'
From: Michael Niechziol <minie@c-lab.de>
Date: Mon, 24 Mar 1997 13:57:06 +0100
Links: << >>  << T >>  << A >>
Hi,

does anybody know if there's a possibility to use the ZYCAD-Tool
'browse' via scripts on a Solaris plattform ?
'browse' seems to use Perl-Scripts to execute the desired commands !?
Can I also use these to controll browse from a terminal that doesn't
have
an X11-environment ? 
As a first step it would be ok, if I can call the
'auto_configure'-command.
I tried to simply execute it in the
$INCA_ROOT/commands/USER_CELL-directory,
but that did not work. It only produced the following output:

-I- setting 'LOG' = 'yes'
-I- setting 'DEBUG' = 'no'
-I- setting 'SAVE' = 'yes'
-I- Re-execute: Yes
Command failed 'i  d'

Please help.

Michael.
-- 
+--------------------------------+-------------------------------------+
| Michael Niechziol              |    email: minie@uni-paderborn.de    |
| 33104 Paderborn / Germany      |           minie@c-lab.de            |
+--------------------------------+-------------------------------------+
Article: 5897
Subject: Re: What tools for $8000?
From: timolmst@cyberramp.net
Date: Mon, 24 Mar 1997 13:37:58 GMT
Links: << >>  << T >>  << A >>
"Anthony Ellis" <aelogic@iafrica.com> wrote:

>Given that I have $8000 to spend on tools and want to do the following:

>	FPGA VHDL development - just the VHDL coding, debugging and simulating.
>Independent of FPGA vendor. 
>	Will use customer's back end tools as required. Typical VHDL design
>bureau.
>	
>	Front end schematic capture tools to interface with Coopers&Cyan  as  well
>as PCAD PCB tools.


Check out the Orcad Express system. It will target any of the major
FPGA's, and is well within the price you specify. Check it out at
http://www.orcad.com

Article: 5898
Subject: Re: Sole source
From: peter@xilinx.com (Peter Alfke)
Date: Mon, 24 Mar 1997 09:25:27 -0700
Links: << >>  << T >>  << A >>
                             Mon, Mar 24, 1997                   
Here is my composite answer to several responses:

If you expect cheaper FPGA software from a third party, forget it. Anybody
who wants to underbid the manufacturer¹s subsidized software will
inevitably go bankrupt. The idea of five smart guys in a garage writing
superb software for peanuts ( if only Xilinx would reveal its secrets) is
worse than an urban legend, it is utter nonsense.

High-quality software at many times the present price ( the Synopsys and
Mentor model) is a more feasible idea, but highly unlikely. Who needs it?
Expect the best and least expensive software always from your chip
supplier. Hhe will supply it forever, and he will keep the price low,
because that¹s in his best interest. Software hasn't gotten cheaper, but
ever so much better. Like $ 2000 PCs that don't get cheaper, they just
become much better $ 2000 PCs.

Regarding assured chip availability, Altera set an ugly example,
abandoning its Intel stepchild, and I don¹t intend to defend that :-).

Xilinx bends over backwards to assure continued supply. For 12 years, we
never dropped any of our FPGAs, and even now, as some of our devices have
become senior citizens, we keep making them for the rest of the decade (
or millennium ), give ample warning, and also refer you to an ³after-life
supplier² ( cute name). There is no reason to assume that a second source
would stick with it any longer. A second source lacks the emotional
attachment, it will drop an obsolete and unprofitable part much sooner.

As time goes on, we update our parts and move them to newer processes,
which makes them faster and cheaper. But we made sure that the XC3000A is
a true superset of the XC3000, same as the XC4000E is of the XC4000. Even
the bitstreams can stay the same.  You get a better device at a lower
price, but you have to make sure that your designs are free of race
conditions. That is the price of progress. Without it, we would become a
museum shop.

³Burning down of a fab² is not an issue. Fabless companies find it quite
easy to use multiple fabs, even in multiple countries.

An EPROM programmer is a piece of hardware that IC houses don¹t like to
make, sell, service, and maintain. But it causes us a nasty delay in
product introductions until we finally manage to convince the
manufacturers to add a socket or an algorithm. 

Regarding free software. Everybody knows that software has a value and a
cost. It would be a very tough decision to give it away. The analogy with
data books doesn¹t hold: The component data book in Xilinx takes on
average one man-year per year, which is one percent of the software
effort. ( I know, I did it for six years). The cost of printing and
shipping 100,000 books far exceeds the cost of generating and typesetting
the content.

I don¹t want to come across as a defensive smart-ass, but I thought I owed
you some answers. 
Keep pushing us by demanding the impossible. That keeps us on our toes.

Peter Alfke, Xilinx Applications
Article: 5899
Subject: Re: Problem loading XC4010E with XCHECKER!
From: w.eisele@t-online.de (Wilfried Eisele)
Date: 24 Mar 1997 19:19:43 GMT
Links: << >>  << T >>  << A >>
In article <33328507.501E@kiemw.ericsson.se>, FT/KD Patrik Eriksson
<emwepa@kiemw.ericsson.se> wrote:

> When i try to configure one XC4010E with XCHECKER something goes wrong.
> It seems as at the end of the cofiguration the FPGA drives INIT low.
> What can be wrong?
> 
> -- 
> Ericsson Saab Avionics AB  Telephone: +46 8 757 30 00
> Torshamnsgatan 32C            Direct: +46 8 757 30 00
> Kista                        Telefax: +46 8 404 41 20  
> S-164 84 STOCKHOLM            E-mail: Patrik.E.Eriksson@emw.ericsson.se

You should have a look at Xilinx-Web page. There are an Application note
especially for loading the FPGAs.
It is always good, to have a look for the first 20-40 Config bits. Are
they correct? The cable shouldnt be very long (up to 50cm).

Wilfried Eisele
eisele@litef.de


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
2017JanFebMarApr2017

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