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 400

Article: 400
Subject: Anyone have Altera library for Orcad?
From: dkingma@vt.edu (Dave Kingma)
Date: Mon, 7 Nov 1994 15:27:31
Links: << >>  << T >>  << A >>
Has anyone created a library for Altera parts
that is usable with the Orcad schematic capture
package. This would save me a lot of time. I
especially need 7000 and 8000 series parts.

Thanks!
Dave


-----------------------------------------------------
Dave Kingma                  450 Canterbury St.
Sr. Research Engineer        Christiansburg, VA 24073
Fiber Optic Products
Litton Poly-Scientific
1213 N. Main St.
Blacksburg, VA 24060 USA     e-mail: dkingma@vt.edu
(703)-552-3011 x326          Amateur Radio: WA4RDI


Article: 401
Subject: Re: Xilinx chip partitioning
From: attmes@technet.sg (Koh Kim Huat)
Date: 8 Nov 1994 05:31:04 GMT
Links: << >>  << T >>  << A >>
Russell J. Petersen (peterser@utah.et.byu.edu) wrote:

: In article <39b348$lrc@cat.cis.Brown.EDU>, mew@lems.brown.edu (Mike E. Wazlowski) writes:
: |> 
: |> 
: |> ---
: |> 
: |> 
: |> We're interested in partitioning logic among more than one Xilinx 4000 series
: |> FPGA. What's the best way to get a file that has the logic partitioned into
: |> function generators? In addition, we'd also like to retain some notion of
: |> hierarchy so that we don't put half of a RPM for an adder in one chip and the
: |> other half in a different chip. Any ideas?
: |> 
: |> 		Thanks,
: |> 			Mike
: |> 
: |> 
: |>

: 	I am afraid that you are on your own on this one.  As far as
: I know there is no automatic partitioner available for Xilinx chips
: although I would like to be proven wrong.  The only chips that I know
: of that have a partitioner available for them are the Altera parts. 
: I plan to test this partitioner out soon but have not done so yet.


: - Russell Petersen
:   petersr@fpga.ee.byu.edu

Yes, there is automatic partitioner called PRISM, part of the NeoCAD FPGA 
development tool.

Simon.


Article: 402
Subject: Re: about downloading FPGAs
From: fliptron@netcom.com (Philip Freidin)
Date: Tue, 8 Nov 1994 05:31:30 GMT
Links: << >>  << T >>  << A >>
In article <chasebCyw146.ICI@netcom.com> chaseb@netcom.com (Bryan Chase) writes:
>Philip Freidin (fliptron@netcom.com) wrote:
>
><some helpful info about bitstreams deleted>
>
>: There is a neat program on the Xilinx BBS called makesrc which uses a 
>: descriptor file to convert bitstream to source code for any language.
>: i.e. it can create 'C' source code (an array initialization) or ASM86
>: source code (loads of .db instructions). then process the file with 
>: the rest of your program.
>
>: All the best, 
>: 	Philip Freidin
>
>What's this?  It will make source-code out of a bitstream?  How much
>info do I have to give it along with the bitstream?
>
>-bryan chase
>

Makesrc needs a control file that describes the format of your
required output. Xilinx supplies control files to generate x86
assembler source, and C source. Note that this is unsupported
software.

	Philip Freidin



Article: 403
Subject: Re: Random Number Tests
From: devb@jazzmin.vnet.net (David Van den Bout)
Date: 8 Nov 1994 10:31:31 -0500
Links: << >>  << T >>  << A >>
Steve:

You asked about a test to grade your random number generator.
Knuth has a bunch of tests for that in volume 2.  After you code
and run all the tests, however, you have to decide if your distribution
is "random enough" based on the test results.

Another technique may be to ask if your RNG is as good as another
that everybody already thinks is good.  Chapter 13, section 5 of
"Numerical Recipes in C" lists several tests for determining if
two distributions are different (code provided as well).  If your
FPGA-based RNG puts out a distribution that is indistinguishable
from that of an accepted RNG, then you are doing at least as well
as them.


-- 

||  Dave Van den Bout  ||
||  Xess Corporation   ||


Article: 404
Subject: Re: Xilinx chip partitioning
From: chip@qcktrn.com ( Chi-Ping Hsu )
Date: Tue, 8 Nov 1994 19:35:02 GMT
Links: << >>  << T >>  << A >>
 
----------------------------------------------------------------------

Message: 1
From: peterser@utah.et.byu.edu (Russell J. Petersen)
Date: 4 Nov 94 11:03:51
Subject: Re: Xilinx chip partitioning


In article <39b348$lrc@cat.cis.Brown.EDU>, mew@lems.brown.edu (Mike E. Wazlowski) writes:
|> 
|> 
|> ---
|> 
|> 
|> We're interested in partitioning logic among more than one Xilinx 4000 series
|> FPGA. What's the best way to get a file that has the logic partitioned into
|> function generators? In addition, we'd also like to retain some notion of
|> hierarchy so that we don't put half of a RPM for an adder in one chip and the
|> other half in a different chip. Any ideas?
|> 
|> 		Thanks,
|> 			Mike
|> 
|> 
|>

Quickturn Design Systems has been doing multi-chip partitioning (into anywhere
from 2 chips to thousands of Xilinx chips) with correct timing across FPGA chip 
boundaries for many years with proven effectiveness.  Hierarchy control, 
special clock extraction and mapping, and memory mapping are few examples
of what it can do.

Quickturn Design Systems
440 Clyde Ave., Mountain View, CA
415-967-3300
 ------------------------------------------------------------------------


Article: 405
Subject: Using Xilinx Wide edge Decoders
From: rwieler@ee.umanitoba.ca (wieler)
Date: 8 Nov 1994 20:18:25 GMT
Links: << >>  << T >>  << A >>


Hello, 
 
I am currently attempting to put together a design to be implemented
in a Xilinx 4010.  I would like to use the the wide edge decoders,
to reduce the clb count of my design.  As I understand it, there are
only four decoders available per side.  I have 6 control signals, 
which I would like to decode to a minimum of 6 signals if possible.
There are a total of 34 decoded signals thus far, however only 6 of 
them are critical.

Does anyone know of any tricks to getting around this.  I imagine
one would be to duplicate a set of input pins on another side of the
chip, however any other ideas/suggestions would be greatly appreciated.


Thanks
Richard Wieler			rwieler@ee.umanitoba.ca
University of Manitoba


Article: 406
Subject: Re: about downloading FPGAs
From: seeker@indirect.com (Stan Eker)
Date: Wed, 9 Nov 1994 05:47:43 GMT
Links: << >>  << T >>  << A >>
John Forrest (jf@ap.co.umist.ac.uk) wrote:
(a few paragraphs deleted ...)

: >
: >for the first time controll every step of the programming sequence:
: >
: >lower prog, lower reset, wait for init low, rise reset, wait for init
: high, ... etc

: Of course for 4000s the programming sequence is different and don't
: forget you often have to send an extra byte than seems really necessary.

The spec for the 3000 series is an additional 12 clocks MINIMUM, and we've
always used 24 Just-In-Case.  I'd guess the 4000 series is similar or
identical.  Sending 3 extra bytes does the trick.



Article: 407
Subject: Re: about downloading FPGAs
From: "Charles Michael Heard heard@btr.com" <heard@btr.btr.com>
Date: 9 Nov 1994 08:24:26 GMT
Links: << >>  << T >>  << A >>
In article <395u4p$84t@news.csie.nctu.edu.tw> Ching-Yau Jong
(yau@theda18) wrote:
>I am now writing a assembly program to configure a FPGA 
>through AT-bus. But I don't know what the actual configuration
>bitstreams are. The .bit file seems to have some unnecessities 
>just like "3020PC6894/10/3120:49:43demo3020.lca:".
>Should I delete it or keep it?
>Please help me. Thanks.

I gather from the file header fragment that you are trying to
download a .BIT file to a Xilinx XC3020 device.

My first suggestion is that you read your Xilinx manual carefully,
as it describes the bit stream format in more detail than you
will need (or, probably, will want) to know.  It will state that the
bit stream begins with the preamble FF 20.  What it probably won't
state -- at least I've never seen this in any Xilinx book -- is
that all of the stuff in the .BIT file prior to the preamble MUST be
discarded and MUST NOT be written into the device.  If you don't pay
attention to this 4000 series devices will reject the configuration attempt
by asserting the INIT# pin.  I don't know exactly what 2000 and 3000
series devices do;  it's been a long time since I had to program them.
But I DO know that all the Xilinx LCA devices require that the .BIT
file header be stripped om the manner I describe.

In order to give you an idea how to proceed I've included a sanitized
fragment of a program I wrote to configure an XC4005 device.  Its INIT#,
BUSY#, PROG#, and DONE pins were connected to a four-bit parallel
port ("PPI_PORT") which had an inverting data path.  Data was written
to the Xilinx using parallel peripheral slave mode.  Note that the
MSB of each byte is the first one transmitted and corresponds to
bit D0 on the Xilinx.  You may use a different arrangement -- for
instance, I have programmed XC2064 devices serially (a bit at a time).
What's important for your purposes is to find the pattern FF 20
and START PROGRAMMING THE DEVICE STARTING WITH FF.  My "NEXT_CHAR"
function below in effect reads the next byte from a previously opened
bit file and provides one character of lookahead to allow me to do
this.  If you can just put the bit file in memory that will be easier.

Hope this helps, and let me know if you have any other questions.

Mike


CONFIG_XILINX   PROC    NEAR

; ------------- Assert the PROG# pin to put devices in configuration mode

                MOV     AL, MASK PROG           ;Set bit than asserts PROG#
                OUT     PPI_PORT, AL            ;Activate PROG# pin

; ------------- Wait for INIT active, then clear PROG

                MOV     ECX, 7                  ;Set 7 usec minimum time limit
CHK_INIT_ACTV:  IN      AL, PPI_PORT            ;Check
                AND     AL, MASK INIT           ; that INIT# pin
                CMP     AL, MASK INIT           ; is active
                LOOPNE  CHK_INIT_ACTV           ;loop until actv or cnt expired
                MOV     AH, 0FFH                ;set AH=0FFH in case of error
                JNE     XLX_CFG_EXIT            ;and exit if such is the case
                XOR     AL, AL                  ;else deactivate
                OUT     PPI_PORT, AL            ; PROG pin

; ------------- Vfy INIT#/BSY#/DONE go inactv within ~3 msec

                MOV     ECX, 2800               ;Set 3 msec minimum time limit
CHK_INIT_DONE:  IN      AL, PPI_PORT            ;INIT#/BSY#/DONE inactve?
                CMP     AL, MASK DONE
                LOOPNE  CHK_INIT_DONE           ;loop until true or cnt expired
                MOV     AH, 0FFH                ;set AH=0FFH in case of error
                JNE     XLX_CFG_EXIT            ;and exit if such is the case

; ------------- Scan bit file for the frame header (skip file name & rev info)
FIND_HEADER:
                CALL    NEXT_CHAR               ;AL=byte at current file posn
                MOV     AH, LOOKAHEAD_BUF       ;AH=byte to be read next
                JS      XLX_CFG_EXIT            ;exit if none avail (EAX=-1)
                CMP     AX, 020FFH              ;else check for FF 20
                JE      SHORT PROG_NXT_BYTE     ;start programming if found
                JMP     SHORT FIND_HEADER       ;otherwise advance one byte

; ------------- Write data to dev, wait for BSY# inactive or DONE actv
W_NXT_CFG_DATA:
                CALL    NEXT_CHAR               ;read one byte of cfg data
                TEST    EAX, EAX                ;check for end-of-file (EAX=-1)
                JS      XLX_CFG_EXIT            ;exit if such is the case
PROG_NXT_BYTE:  OUT     XILINX_PROG_PORT, AL    ;output data to XLX device
                MOV     ECX, 16                 ;wait about 16 microseconds
CHK_LCA_STATUS: IN      AL, PPI_PORT            ;read LCA status
                TEST    AL, MASK DONE           ;if DONE is active
                LOOPNZ  CHK_LCA_STATUS          ;then operation is complete
                JZ      DONE_CHECK_OK           ;else if time limit expired
                TEST    AL, MASK BSY OR MASK INIT
                JZ      SHORT W_NXT_CFG_DATA    ;verify BSY#/INIT# inactive
                MOV     AH, 0FFH                ;set AH=0FFH in case of error
                JMP     SHORT XLX_CFG_EXIT      ;and exit if such is the case

; ------------- Clear error flag if device returns DONE active
DONE_CHECK_OK:
                XOR     AH, AH                  ;otherwise clear error flag

; ------------- Set return value & exit
XLX_CFG_EXIT:
                MOVSX   EAX, AH                 ;set EAX=-1 on error
                RET                             ;and exit
CONFIG_XILINX   ENDP

-- 
C. M. Heard
VVNET, Inc.                           voice:  (408) 247-9375
4040 Moorpark Ave. Suite 206          fax:    (408) 244-3651
San Jose, CA 95117                    e-mail: heard@btr.com


Article: 408
Subject: Re: Using Xilinx Wide edge Decoders
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 10 Nov 1994 07:53:23 GMT
Links: << >>  << T >>  << A >>
In article <39omeh$4re@canopus.cc.umanitoba.ca> rwieler@ee.umanitoba.ca writes:
>
>
>Hello, 
> 
>I am currently attempting to put together a design to be implemented
>in a Xilinx 4010.  I would like to use the the wide edge decoders,
>to reduce the clb count of my design.  As I understand it, there are
>only four decoders available per side.  I have 6 control signals, 

The decoders have 'splitters' in the middle of each side, so theoretically
you can have 8 decoders per side of the chip (chips are limited to 4
sides in the current versions, so the max is 32, half length decoders).
The association of the decoders is 'strong' with I/O, and 'less strong',
but 'weak' with internal logic. 

>which I would like to decode to a minimum of 6 signals if possible.
>There are a total of 34 decoded signals thus far, however only 6 of 
>them are critical.

since you are decoding only 6 control signals, I think you will be
able to decode them faster if you just run them into a single CLB.
The use of FMAP and HMAP control primitives can help in forcing this
packing. This is particularly true if your signal origins are within
the chip. If they are coming in from outside, a CLB is still faster:
The input delay (in a -5) is 3 nS, and the decoder is 12 ns, total
of 15nS.
...OR...
The input delay is 3nS, 1.5 to 2.5 nS for routing to a single CLB,
then 7 nS thru the CLB, total of 12.5  
Since you want 6 of these, this might be difficult (to have 6 CLBs
all doing a decode of 6 bits, and all clustered together, and all
getting all their inputs in under 2.5 nS.

The decoder lines would almost be better (assuming external sources,
except their performance is based on signals getting to them directly
form adjacent I/O pins. After selecting your input pins (which for 
optimization sake, will be all on one side of the chip, and restricted
to one half of that side), you will be left withthe problem that there
are only 4 half length decoders there.
So if the signals are external, try this: Decode 4 of them on decoder
lines, and do the other 2 with CLBs.

>
>Does anyone know of any tricks to getting around this.  I imagine
>one would be to duplicate a set of input pins on another side of the
>chip, however any other ideas/suggestions would be greatly appreciated.
>

Is the above enough tricks??

>
>Thanks
>Richard Wieler			rwieler@ee.umanitoba.ca
>University of Manitoba

All the best
		Philip Freidin.




Article: 409
Subject: Re: about downloading FPGAs
From: John Forrest <jf@ap.co.umist.ac.uk>
Date: 10 Nov 1994 21:56:27 GMT
Links: << >>  << T >>  << A >>
In article <CyzK3K.2up@indirect.com> Stan Eker, seeker@indirect.com
writes:
>: Of course for 4000s the programming sequence is different and don't
>: forget you often have to send an extra byte than seems really
necessary.
>
>The spec for the 3000 series is an additional 12 clocks MINIMUM, and
we've
>always used 24 Just-In-Case.  I'd guess the 4000 series is similar or
>identical.  Sending 3 extra bytes does the trick

If you take my advise you send one extra byte *and only one extra byte*
for 4000s. After this point all the flags used in the handshaking process
(INIT, RDY etc) become invalid  DONE should go high at this point.
_____________________________________________________________
Dr John Forrest           Tel: +44-161-200-3315
Dept of Computation       Fax: +44-161-200-3321
UMIST                  E-mail: jf@ap.co.umist.ac.uk
MANCHESTER M60 1QD
UK


Article: 410
Subject: 322 MHz FPGA Counters
From: grl@colonies.xilinx.com (Gary Lawman)
Date: Thu, 10 Nov 1994 23:08:29 GMT
Links: << >>  << T >>  << A >>


Seong-Woon Kim (ksw@kiwi.etri.re.kr) asked about toggle rates, I thought
that you find the following info interesting:

		
Production Parts:			Performance:		Information source:
------------------------------------------------------------------------
----------------------

Xilinx 3195A-2, 484+ FF, not inc I/O 	322 MHz			Xilinx

Flex 8452A-3    336+ FF, not inc I/O	185 MHz 		Paul Brown - GEC Marconi. 

------------------------------------------------------------------------
----------------------					

Note that the only production Flex 8000A part is the 8452 claimed 4000
gates, and is DLM not TLM as often mis-reported.

Note also that the A-6 spec is == Non A -3.

Altera's Q? 1995 A-2 speed grade for Flex is quoted at ~2/3 performance
of todays production 3100 silicon. 

Article: 411
Subject: Re: about downloading FPGAs
From: eric@telebit.com (Eric Smith)
Date: Fri, 11 Nov 1994 06:14:17 GMT
Links: << >>  << T >>  << A >>
In article <Cyq5MH.1Ks@indirect.com> seeker@indirect.com (Stan Eker) writes:
> short the VCC bus to GND through improperly programmed gates.  If it gets
> hotter than warm, cut the power INSTANTLY.  Don't wait, or it's a goner.

I try to use a current-limited bench supply to avoid damage from this sort
of problem.  If you know how much the rest of your circuit draws, and about
how much the FPGA *should* draw, you can set the current limit.  Then if
there is a problem the supply will go into constant current mode.  If the
part really has close to a dead short between VCC and ground, the supply
voltage will drop dramatically, and you won't smoke the part.

Eric


Article: 412
Subject: Re: about downloading FPGAs
From: eric@telebit.com (Eric Smith)
Date: Fri, 11 Nov 1994 06:20:23 GMT
Links: << >>  << T >>  << A >>
In article <39jbik$gv0@yama.mcc.ac.uk> John Forrest <jf@ap.co.umist.ac.uk> writes:
> Someone said there is a Xilinx utility but we wrote our own for
> converting a program into a C array. This is bound into the program (we

I've been thinking about trying to use Xilinx part with a parallel EPROM,
and having it hold my CPU in reset until it is configured.  The configuration
loaded into the Xilinx would be designed to let the CPU access the EPROM for
its code.  The code (and reset vector) obviously have to be in a part of the
EPROM not used by the Xilinx configuration.  This would let me make my board
completely soft-configurable, particularly if I use EEPROM or Flash instead of
EPROM.

Has anyone tried this sort of thing?

Eric


Article: 413
Subject: Re: about downloading FPGAs
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 11 Nov 1994 07:46:10 GMT
Links: << >>  << T >>  << A >>
In article <ERIC.94Nov10222023@marble.telebit.com> eric@telebit.com (Eric Smith) writes:
>In article <39jbik$gv0@yama.mcc.ac.uk> John Forrest <jf@ap.co.umist.ac.uk> writes:
>> Someone said there is a Xilinx utility but we wrote our own for
>> converting a program into a C array. This is bound into the program (we
>
>I've been thinking about trying to use Xilinx part with a parallel EPROM,
>and having it hold my CPU in reset until it is configured.  The configuration
>loaded into the Xilinx would be designed to let the CPU access the EPROM for
>its code.  The code (and reset vector) obviously have to be in a part of the
>EPROM not used by the Xilinx configuration.  This would let me make my board
>completely soft-configurable, particularly if I use EEPROM or Flash instead of
>EPROM.
>
>Has anyone tried this sort of thing?
>
>Eric

The Xilinx chips have 2 specific configurations just for this type of
application: Parallel Master UP, and DOWN mode. Most uPs start fetching
their instructions or initial jump vector from either the very top of
memory, or the bottom. If your uP starts at the high addresses, use the
UP mode which starts fetching config data from address 0, and increments 
the address. If your uP starts at location 0 (or there abouts), then use 
the DOWN mode, which starts with addresses at FFFF, and DECREMENTS the 
address register while fetching configuration data.
Some uPs need their reset held high, and some need it held low to sustain 
a reset state. The xilinx chips support this too: There are two output 
pins on the Xilinx chips, LDC and HDC which are respectively: Low During 
Configuration, and High During Configuration. Choose the appropriate one 
to hold the uP in reset while the FPGA is sucking its configuration out 
of the EPROM. It is a good idea to use the 8 pins that were used for 
configuration as the pins to transfer byte data between the uP and the 
FPGA, as they will already be wired that way.

All the best,
	Philip Freidin.



Article: 414
Subject: Re: about downloading FPGAs
From: "Charles Michael Heard heard@btr.com" <heard@btr.btr.com>
Date: 11 Nov 1994 09:57:16 GMT
Links: << >>  << T >>  << A >>
In article <39jbik$gv0@yama.mcc.ac.uk>, John Forrest <jf@ap.co.umist.ac.uk>
wrote:
>[ ... ] The other problem is that these arrays can grow in size.
>I wondered if anyone had tried compression  something like
>the gzip algorithm.

When I worked at Telecommunications Techniques Corporation a chap named
Aaron Baranoff developed a program to turn Xilinx rawbit files into Huffman
encoding trees.  In fact the encoder emitted in-line assembler instructions
to directly decompress the trees and program the Xilinx device.  I do not
know the details as I never used this technology personally.

Aaron, if you are listening, would you please say a few words about this?

Mike
-- 
C. M. Heard
VVNET, Inc.                           voice:  (408) 247-9376
4040 Moorpark Ave. Suite 206          fax:    (408) 244-3651
San Jose, CA 95117                    e-mail: heard@btr.com


Article: 415
Subject: Re: Anyone have Altera library for Orcad?
From: kerry@altera.com (Kerry Veenstra) <72712.1243@CompuServe.COM>
Date: 11 Nov 1994 20:22:11 GMT
Links: << >>  << T >>  << A >>
Dave,
 
> Has anyone created a library for Altera parts
> that is usable with the Orcad schematic capture
> package? This would save me a lot of time. I
> especially need 7000 and 8000 series parts.
 
MAX+PLUS II supports most functions in the OrCAD Library Files
pldgates.lib and ttl.lib.  The file orcad.lmf in the MAX+PLUS II
installation directory lists the 342 OrCAD symbols supported
automatically.
 
If you wish to use a function that is not mapped in orcad.lmf,
you must add a mapping.  You can map OrCAD functions 
to Altera-provided functions or to any design file created with
MAX+PLUS II.
 
For more information, search for "OrCAD" in MAX+PLUS II on-line help,
and go to the topic "OrCAD Interface Information".
 
Kerry Veenstra
kerry@altera.com


Article: 416
Subject: Programmable Interfaces to Rambus
From: kelvin@cs.iastate.edu (Kelvin Nilsen)
Date: 11 Nov 94 20:56:45 GMT
Links: << >>  << T >>  << A >>
Hi all,
  We're designing a prototype memory subsystem, and would like to plug in
a FPGA-compatible Rambus interface.  So far, we haven't been able to find
any products that exactly match our needs, though Xilinx representatives
have hinted that such a device may be forthcoming.

  Do any of you have any suggestions?  (What's available now?  What will
be available soon?  How soon?)

Thanks


Kelvin Nilsen/Dept. of Computer Science/Iowa State University/Ames, IA  50011 
 (515) 294-2259   kelvin@cs.iastate.edu  uunet!cs.iastate.edu!kelvin



Article: 417
Subject: Sources for FGPA's and "exotic" PLDs?
From: Eric@wolf359.exile.org (Eric Edwards)
Date: Fri, 11 Nov 1994 23:24:59 GMT
Links: << >>  << T >>  << A >>
Any leads?  All kinds of places have 22V10's but what if I want if I want
a GAL26V12, a FlexLOGIC, or maybe an Aletra part?  With the exception of
Digikey's selection of Xylinx parts, I have come up empty.  Where *does* a
hobbyist get large PLD's and FPGA's?

----
Eric Edwards: Bang= cg57.esnet.com!wolf359!eric Domain= eric@exile.org
Remember the home hobbyist computer: Born 1975, died April 29, 1994



Article: 418
Subject: The PARALLEL Processing Connection - November '94 meeting notice
From: parallel@netcom.com (B. Mitchell Loebel)
Date: Sat, 12 Nov 1994 09:17:31 GMT
Links: << >>  << T >>  << A >>
November 14 - The Plastic Computer - Porting Hardware to 
Software

During the past few months The PARALLEL Processing 
Connection has enlarged its agenda so that it now encompasses  
High Performance Computing in general with the emphasis still on 
parallel processing. We've talked about run-time hardware 
reconfigurability as a way to affordably accelerate, in hardware, 
those tasks that are usually accomplished in software; of course, part 
of the speed-up comes about because hardware is intrinsically 
parallel.  On November 14th Shey Hakusui of the Harminix 
Corporation will tell us about Parthenon - the C to gates complier 
that they have developed under contract to NTT, Japan and the 
"plastic computer" they are developing in which the entire system is 
reconfigurable.

A discussion of member projects currently underway and other 
issues of interest to entrepreneurs begins at 7:15PM and the main 
meeting starts promptly at 7:45PM at Sun Microsystems at 901 San 
Antonio Road in Palo Alto. This is just off the southbound San 
Antonio exit of 101.  Northbound travelers also exit at San Antonio 
and take the overpass to the other side of 101.

Please be prompt; as usual, we expect a large attendance; don't be 
left out or left standing. There is a $10 fee for non-members and 
members will be admitted free.  Yearly membership fee is $50; 
corporate membership fee is $400/year.

-- 
B. Mitchell Loebel                                      parallel@netcom.com 
Director - Strategic Alliances and Partnering                  408 732-9869 
PARALLEL Processing Connection 


Article: 419
Subject: The PARALLEL Processing Connection - What Is It?
From: parallel@netcom.com (B. Mitchell Loebel)
Date: Sat, 12 Nov 1994 09:55:37 GMT
Links: << >>  << T >>  << A >>
The PARALLEL Processing Connection is an entrepreneurial          
association; we mean to assist our members in spawning very
successful new businesses involving high performance computing, in              
general, with specific emphasis on parallel processing.

Our meetings take place on the second Monday of each month at 
7:15 PM at Sun Microsystems at 901 South San Antonio Road in 
Palo Alto, California. Southbound travelers exit 101 at San 
Antonio ; northbound attendees also exit at San Antonio and take the 
overpass to the other side of 101. There is an $10 visitor fee for non-
members and members ($50 per year) are admitted free. Our phone 
number is (408) 732-9869 for a recorded message about upcoming 
meetings; recordings are available for those who can't attend -
please inquire.

Since the PPC was formed in late 1989 many people have sampled 
it, found it to be very valuable, and even understand what we're up 
to. Nonetheless, certain questions persist. Now, as we approach our 
fifth year of operation, perhaps we can and should clarify some of 
the issues. For example:

Q.  What is PPC's raison d'etre?
A.  The PARALLEL Processing Connection is an entrepreneurial 
organization intent on facilitating the emergence of new businesses. 
PPC does not become an active member of any such new entities, ie: 
is not itself a profit center.

Q.  The issue of 'why' is perhaps the most perplexing. After all, a 
$50 annual membership fee is essentially free and how can anything 
be free in 1994? What's the payoff? For whom?
A.  That's actually the easiest question of all. Those of us who are 
active members hope to be a part of new companies that get spun 
off; the payoff is for all of us -- this is an easy win-win! Since 
nothing else exists to facilitate hands-on entrepreneurship, we 
decided to put it together ourselves. 

Q.  How can PPC assist its members?
A.  PPC is a large technically credible organization. We have close 
to 100 paid members and a large group of less regular visitors; we 
mail to approximately 500 engineers and scientists (primarily in 
Silicon Valley). Major companies need to maintain visibility in the 
community and connection with it; that makes us an important 
conduit. PPC's strategy is to trade on that value by collaborating 
with important companies for the benefit of its members. Thus, as 
an organization, we have been able to obtain donated hardware, 
software, and training and we've put together a small development 
lab for hands-on use of members at our Sunnyvale office. Further, 
we've been able to negotiate discounts on seminars and 
hardware/software purchases by members. Most important, 
alliances such as we described give us an inside opportunity to 
JOINT VENTURE SITUATIONS.

Q.  As an attendee, what should I do to enhance my opportunities?
A.  Participate, participate, participate. Many important industry 
principals and capital people are in our audience looking for the 
'movers'!

For further information contact:

-- 
B. Mitchell Loebel                                      parallel@netcom.com 
Director - Strategic Alliances and Partnering                  408 732-9869 
PARALLEL Processing Connection 


Article: 420
Subject: Re: about downloading FPGAs
From: bobe@soul.tv.tek.com (Bob Elkind)
Date: 13 Nov 1994 23:40:06 GMT
Links: << >>  << T >>  << A >>
eric@telebit.com (Eric Smith) writes:
>I've been thinking about trying to use Xilinx part with a parallel EPROM,
>and having it hold my CPU in reset until it is configured.  The configuration
>loaded into the Xilinx would be designed to let the CPU access the EPROM for
>its code.  The code (and reset vector) obviously have to be in a part of the
>EPROM not used by the Xilinx configuration.  This would let me make my board
>completely soft-configurable, particularly if I use EEPROM or Flash instead of
>EPROM.
>
>Has anyone tried this sort of thing?
>
>Eric

We've recently designed two products which have solved the same problem
in two slightly different ways.

The first does exactly what you are suggesting:  Use the LDC or HDC pin
to hold the uP in stasis until the Xilinx (4K) "boots up" from the common
ROM in Master Parallel mode.  Then the uP awakens and runs normally.

This design works fine.


The second design allows the uP to be the "boss" of the ROM.  It boots up
normally and, as part of the booting process, it programs two Xilinx 4K
devices.  The Xilinx FPGAs are configured in Slave Peripheral Parallel
mode, they sit on the uP address and data bus much the same as the first
design example, above.  However, by allowing the uP to configure the
FPGAs (they appear to be memory-mapped ports/devices), the uP can configure
and reconfigure the FPGAs at will.  We've found this approach to be more
flexible.

Neither one of these variants is an outstanding technical accomplishment,
mind you, as they are more or less straight out of the data book or
app note texts.  I mention them to confirm that both approaches work well.


Bob Elkind, Tektronix TV


Article: 421
Subject: C.A.F. WWW page (aperiodic reminder)
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Mon, 14 Nov 1994 01:04:23 GMT
Links: << >>  << T >>  << A >>

The IDA Supercomputing Research Center (SRC) maintains a World Wide
Web page for the comp.arch.fpga newsgroup that contains:

1) The group charter;

2) An archive of posted messages with various retrieval mechanisms;

3) A list of upcoming events of interest to the custom computing
community; 

4) Pointers to organizations engaged in FPGA based computing research;

5) Several other interesting links.

This page can be found at:

	http://www.super.org:8000/FPGA/caf.html

Note the new URL: we've finally started running htpd.  The old ftp URL
should still work, but may go away soon.

This page is still very much under construction, so any comments or
additions are welcome.  We would especially like to solicit
contributions to a bibliography and a FAQ list.

-jeff

------
Jeffrey Arnold
IDA Supercomputing Research Center
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org


Article: 422
Subject: C.A.F. WWW page (aperiodic reminder)
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Mon, 14 Nov 1994 01:22:30 GMT
Links: << >>  << T >>  << A >>
The IDA Supercomputing Research Center (SRC) maintains a World Wide
Web page for the comp.arch.fpga newsgroup that contains:

1) The group charter;

2) An archive of posted messages with various retrieval mechanisms;

3) A list of upcoming events of interest to the custom computing
community; 

4) Pointers to organizations engaged in FPGA based computing research;

5) Several other interesting links.

This page can be found at:

	http://www.super.org:8000/FPGA/caf.html

Note the new URL: we are finally running htpd.  The old 'ftp' URL
should still work, but may go away soon.

This page is still very much under construction, so any comments or
additions are welcome.  We would especially like to solicit
contributions to a bibliography and a FAQ list.

-jeff

------
Jeffrey Arnold
IDA Supercomputing Research Center
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org



Article: 423
Subject: Re: Sources for FGPA's and "exotic" PLDs?
From: seeker@indirect.com (Stan Eker)
Date: Mon, 14 Nov 1994 03:57:02 GMT
Links: << >>  << T >>  << A >>
Eric Edwards (Eric@wolf359.exile.org) wrote:
: Any leads?  All kinds of places have 22V10's but what if I want if I want
: a GAL26V12, a FlexLOGIC, or maybe an Aletra part?  With the exception of
: Digikey's selection of Xylinx parts, I have come up empty.  Where *does* a
: hobbyist get large PLD's and FPGA's?

Arrow *used* to do catalog sales, but as usual you're limited to the lines
they deal with.  Minimum was $25.  The OLD number I have is 1-800-932-7769.

If you're working for a company that buys from normal distribution, just do
the same thing I do - make a deal with the purchasing department.  I call
and place the order, verbal PO #, COD, and it's no problem here.  It depends
TOTALLY on the purchasing folks, though.  If they're against it, you're SOL.



Article: 424
Subject: Updated List of FPGA-based Computing Machines
From: guccione@foghorn.cc.utexas.edu (Steve Guccione)
Date: 14 Nov 1994 10:53:49 -0600
Links: << >>  << T >>  << A >>

An updated list of FPGA-based Computing machines is available via WWW.
The URL for this page is:

     List of FPGA-based Computing Machines
     http://www.utexas.edu/~guccione/HW_list.html

Please note the change in the machine name of the previously posted
URL from "bongo.cc" to "www".  Both names should work, but the "www" URL
is preferred.

The list currently contains over 40 research and commercial systems,
with a few links to other appropriate Web pages.  As always, new
systems and corrections to existing entries are welcome.

Since this list has become quite large, I will not be posting it
directly to this comp.arch.fpga.  I can email out text versions, or
(if demmand warrants it) find an anonymous FTP site.

-- Steve Guccione
-- guccione@ccwf.cc.utexas.edu
-- 11/14/94





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