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 300

Article: 300
Subject: in circuit programming, was Re: PALASM versions?
From: pngai@mv.us.adobe.com (Phil Ngai)
Date: Sat, 15 Oct 1994 17:58:08 GMT
Links: << >>  << T >>  << A >>
In article <37o8i0$901@niaomi.iscm.ulst.ac.uk> ian@myhost.subdomain.domain () writes:
>premise is that the very constraints Machs place on the designer produce
>"better" designs and that MACHs are reprogrammable and cheap. The latest
>MACH does not need a programmer, merely a lead to the parallel port and it
>programs itself using JTAG signals; very neat trick!

In-circuit programming is a very nice feature supported only by Lattice
(probably among the first if not THE first), AMD, and Intel. In-circuit
REprogramming is currently only supported by Lattice and AMD as far as
I know. Intel/Altera's product line only uses OTP EPROMs right now
although they seem to be getting close to finally releasing a Flash
based in-circuit reprogrammable device.

(Xilinx, of course, has had in-circuit configuration for a long time,
but I don't know if it should be considered PROGRAMMING because the
data is volatile.)

I consider I.C.R.P. to be very important because gull wing PQFP packages
offer a much higher pin count per square inch of board space than
PGAs or PLCCs and gull wing packages have very delicate leads which
are difficult to socket. It is best if you can solder it down directly
to the board and never have to physically handle it again.

I have stayed away from Altera's line of fairly interesting parts
because they lacked this. They presumably bought Intel's product line
to get access to this technology, among other things.

I think the one-time programmable anti-fuse guys like Quick Logic and
Actel will have problems providing cost-effective high pin count
products because of this issue. The only hope I can see for them is
plastic BGAs and good BGA sockets (if such are ever developed). Note
that the BGA sockets don't have to be cheap as long as they have the
same footprint as the BGA. The sockets would be used in development
and the devices would be soldered down directly in production.


-- 
 Congratulations to the people who saved Mono Lake!


Article: 301
Subject: Re: in circuit programming, was Re: PALASM versions?
From: devb@elvis.vnet.net (David Van den Bout)
Date: 17 Oct 1994 02:08:32 -0000
Links: << >>  << T >>  << A >>
In article <1994Oct15.175808.29253@adobe.com>,
Phil Ngai <pngai@mv.us.adobe.com> wrote:
>In-circuit programming is a very nice feature supported only by Lattice
>(probably among the first if not THE first), AMD, and Intel. In-circuit
>REprogramming is currently only supported by Lattice and AMD as far as
>I know. Intel/Altera's product line only uses OTP EPROMs right now
>although they seem to be getting close to finally releasing a Flash
>based in-circuit reprogrammable device.
I don't understand this.  Altera/Intel FLEXlogic devices can have their
SRAM reprogrammed at any time via the JTAG port.  True, their EPROM is
OTP, but you can override it at anytime by loading in a new design to
the SRAM.

>I have stayed away from Altera's line of fairly interesting parts
>because they lacked this. They presumably bought Intel's product line
>to get access to this technology, among other things.
Can't figure this either.  The Altera FLEX FPGAs (CPLDs to some) are
also SRAM based and can be programmed in modes similar to XILINX parts.
So they are in-circuit reprogrammable as well.  Unless you are talking
about MAX 5000 and 7000 parts which use the EPROMs.

What am I missing here?  What's the distinction between in-circuit
programming and in-circuit reprogramming?



-- 

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


Article: 302
Subject: Re: Multipliers in FPGA's
From: scott@atmel.com (Scott Evans 408-436-4117)
Date: Mon, 17 Oct 1994 07:16:21 GMT
Links: << >>  << T >>  << A >>
>Michael P. Hartnett (lcsmph@sn520.utica.ge.com) wrote:
>: Does anyone know what FPGA architectures lend themselves to arithmetic
>: operations such as a multiply?  How fast can I run a 16 x 16 multiplier?
>
>I know a guy who was able to hook Twelve  16-bit multipliers on
>to a 32-bit tri-state bus in  ATT2C26 (the 26,000 gates ORCA 
>FPGA from AT&T).  I think, the speed obtained was about 35 Mhz.
>
>Each instance was a special integer multiplier where you multiply 
>a variable by a constant and updating the constant requires a 
>multiplier to pause for sometime. (eg, see page 80 of EDN, May 1994)
>
>Satwant

Arithmetic operations are a specialty of the Atmel AT6000 series FPGA.
For more information contact Atmel Sales at 408 441 0311.

If you use the macro generators included in the software for the Atmel FPGA, 
you can generate a fully functional pipelined 16x16 multiplier that runs at 
close to 30 MHz worst case.  This multiplier is about 13,000 gates so I'm
afraid we can't put 12 of them on our device :-)

My view, of course, is biased as I work for Atmel.

Scott Evans
scott@atmel.com


Article: 303
Subject: SRAM and antifuse for interconnects
From: gbchoy@salsa.engr.ucdavis.edu (Garett B Choy)
Date: 17 Oct 1994 15:43:51 GMT
Links: << >>  << T >>  << A >>
I'm new to the FPGA world and I've noticed some things that I was wondering
what you guys thought about.

Some FPGA's (like Altera, Xilinx) have SRAM interconnects... so you can
reprogram.  Other FPGA's (like QuickLogic, Cypress) use "antifuse".  They
can't reprogram, but they boast that they have better routability and
speed (antifuse has less cap than SRAM supposedly).  What do you guys
think (from experience) is the more useful technology?

Garett


Article: 304
Subject: Re: SRAM and antifuse for interconnects
From: bobe@soul.tv.tek.com (Bob Elkind)
Date: 17 Oct 1994 17:24:10 GMT
Links: << >>  << T >>  << A >>
gbchoy@salsa.engr.ucdavis.edu (Garett B Choy) writes:

>Some FPGA's (like Altera, Xilinx) have SRAM interconnects... so you can
>reprogram.  Other FPGA's (like QuickLogic, Cypress) use "antifuse".  They
>can't reprogram, but they boast that they have better routability and
>speed (antifuse has less cap than SRAM supposedly).  What do you guys
>think (from experience) is the more useful technology?

1. Altera makes both RAM-based (reconfigurable) and non-RAM based
   (i.e. one-time-programmable) FPGAs.

2. I'm not familiar with *all* the non-SRAM based FPGAs, but in the list
   of SRAM-based FPGAs you should include ATT/ORCA in the list, since the
   list is fairly short.

3. Don't ignore the fundamentals of various technologies (e.g. anti-fuse,
   SRAM, RISC, CISC, segmented, etc. etc.)  *BUT* ...

   When all is said and done, buy performance and not promises. Execution
   (i.e. implementation) is a large part of the *delivered* performance,
   and often overcomes "fundamental advantages" in competing products.

   Examples:  x86 vs. 68K (who has more/better software?)
	      *nix vs. Windows vs. OS/2 (more/better/cheaper apps?)
	      conventional internal combustion vs. rotary engine (mileage?)
	      etc. etc.

4. Don't forget the importance of decent design/development tools!

5. If you can get the job "done" with an FPGA that someone you know
   has already used (successfully), that would be a very compelling
   consideration (for me).  Having someone nearby who has already gotten
   the software and hardware debugged and running, and can advise you
   when (*not if*) you run into roadblocks), is a *very* valuable
   asset, much more so than a pile of anti-fuses (or SRAM).

I see from your net address that you are probably a student (correct me if
I'm making a rash assumption).  The tradeoffs for a one-time experiment
or demonstration project are *very* different than the tradeoffs for
a commercial product development.  Your interests are likely to be
very short-term;  learning curve and toolset cost may very well outweigh
factors such as volume-manufacturing-cost, product family extension,
toolset migration paths, etc.

Your mileage *will* vary.  Good luck in your project.

Bob Elkind, Tektronix TV


Article: 305
Subject: Re: SRAM and antifuse for interconnects
From: MoellerInc <mmoeller@delphi.com>
Date: Mon, 17 Oct 94 18:08:49 -0500
Links: << >>  << T >>  << A >>
One more thought on "one time" vs reuseable parts.
Even though you have a pile of "one time" parts on the bench you KNOW that
they each are $50 ( or whatever). This sometimes keeps you from making a
quick "debugging" change to a part.  With a SRAM part (Xilinx) it is
easy to do a quick change to debug a problem, if you know you are smoking
$50 you tend to hesitae and waste time.
 
I know that it is not "rational" but I suspect most of us would do the same.
( You know you have this prblem when you catch yourself wiring a 7404 onto
a board to "fix" a polarity of a PAL output  instead of remaking the
part)
 
Martin Moeller
mmoeller@delphi.com


Article: 306
Subject: Re: in circuit programming
From: g.r.kiss@open.ac.uk (George Kiss)
Date: Mon, 17 Oct 1994 23:35:22 GMT
Links: << >>  << T >>  << A >>
In the previous discussion on in-circuit programming, no one mentioned the
ATMEL 6000 device which also has SRAM based reprogrammability.  In fact
they claim that they have the only product that supports reprogramming
while the device is in operation!

George Kiss
Open University, England
g.r.kiss@open.ac.uk


Article: 307
Subject: Re: Synario
From: rlperseng@aol.com (RLPersEng)
Date: 17 Oct 1994 20:45:05 -0400
Links: << >>  << T >>  << A >>
In article <1994Aug19.071146.11374@adobe.com>, pngai@mv.us.adobe.com (Phil
Ngai) writes:

> Any Synario users out there?

I'd like to know who else responded. I'm an editor for Personal
Engineering
magazine and I'd like to hear about users experiences, especially
difficult development situations, creative solutions and the like.
Thanks. Russ Lindgren


Article: 308
Subject: Re: FPGA RISC Processor
From: rlperseng@aol.com (RLPersEng)
Date: 17 Oct 1994 20:48:10 -0400
Links: << >>  << T >>  << A >>
In article <330v0t$72t@feynman.ee.latrobe.edu.au>, lurch@ee.latrobe.edu.au
(Geoffrey Liersch) writes:

> The Xrisc-4000 processor is a 16 bit RISC computer developed in the
Department
of Electronic Engineering at La Trobe University by Geoff Liersch

Geoff, I'd like to know more details about the project, specifically
I might be interested in an article that details your development.
I'm an editor for Personal Engineering Magazine and I'm frequently
looking for interesting contributed articles... Please email if
you're interested. Thanks


Article: 309
Subject: Re: PLDshell/Intel ftp site
From: rlperseng@aol.com (RLPersEng)
Date: 17 Oct 1994 20:57:04 -0400
Links: << >>  << T >>  << A >>
In article <34593c$7q@panix2.panix.com>, rodneym@panix.com (Rodney
Myrvaagnes) writes:

> In <1994Sep1.154114.14217@peavax.mlo.dec.com> >arthur@alcor1.mlo.dec.com
(Ed Arthur) writes:
>Intel sold its PLD business to Altera. It probably does not support 
>PLDshell any more.

I've spoken with Bob Beachler, mkt manager at Altera. He says
that Altera will *continue* to support PLDshell as a FREE product
If you'd like to get a free copy, call Altera at 800 443-7610
Hope this helps. Also, if you have problems, email info to me.


Article: 310
Subject: Re: in circuit programming, was Re: PALASM versions?
From: pngai@mv.us.adobe.com (Phil Ngai)
Date: Tue, 18 Oct 1994 01:34:57 GMT
Links: << >>  << T >>  << A >>
In article <37smb0$kis@elvis.vnet.net> devb@elvis.vnet.net (David Van den Bout) writes:
>What am I missing here?  What's the distinction between in-circuit
>programming and in-circuit reprogramming?

I may have chosen my terms poorly, but what I am concerned with is
whether the part loses its brains when it loses power. For me, it's a
lot more convenient if I can "program" the part using a dedicated tool
and not have to provide extra hardware at extra cost to reload its
brains whenever power is lost.

The Xilinx parts are not too bad because it's usually a single chip
solution. The Altera 8000 parts look similar to Xilinx in this respect,
although I haven't personally used them.

The current INTEL parts are not.

I think I would use three terms:

in-circuit configuration. Like Xilinx and Altera 8000, the information
	loaded is volatile and must be loaded every time power is lost.
in-circuit programming. The current Intel parts, based on One Time
	Programmable EPROMs. You only get to program it once.
in-circuit reprogrammable. Configuration is non-volatile and can be
	reprogrammed a reasonable number of times.

When silicon people talk about "programming" a device, I believe it
is in the non-volatile sense, but I could be wrong.

For example, you "program" a PROM or EPROM. You "load" an SRAM.

-- 
 Congratulations to the people who saved Mono Lake!


Article: 311
Subject: Re: FPGA RISC Processor
From: jlhutchi@sal.cs.utah.edu (Jeff Hutchings)
Date: 18 Oct 1994 05:23:23 GMT
Links: << >>  << T >>  << A >>
RLPersEng (rlperseng@aol.com) wrote:
: In article <330v0t$72t@feynman.ee.latrobe.edu.au>, lurch@ee.latrobe.edu.au
: (Geoffrey Liersch) writes:

: > The Xrisc-4000 processor is a 16 bit RISC computer developed in the
: Department
: of Electronic Engineering at La Trobe University by Geoff Liersch

: Geoff, I'd like to know more details about the project, specifically
: I might be interested in an article that details your development.
: I'm an editor for Personal Engineering Magazine and I'm frequently
: looking for interesting contributed articles... Please email if
: you're interested. Thanks

Geoff, I would be interested in your work as well.  What is available in
the form documentation, white papers, etc.?  If you could please e-mail
me regarding this, I would appreciate it.  I am currently engaged in
the research and development of reconfigurable hardware systems in 
general, and reconfigurable processors specifically.

-- Jeff Hutchings

======================================================================
Jeff Hutchings 
Director Of Engineering
Metalithic Systems, Inc. (MSI)
======================================================================
e-mail:
	hutch@metalith.com

======================================================================


Article: 312
Subject: Re: ALTERA EPLDs
From: lochon@comatlas.fr (G.LOCHON)
Date: 18 Oct 1994 11:31:20 GMT
Links: << >>  << T >>  << A >>

In article <G8s@hpgndlab.grenoble.hp.com>, cam@grenoble.hp.com (Daniele Beccari)
writes :

>Hello, I have some questions about the best ways to exploit ALTERA
>EPLDs, but I don't know if this is the appropriate newsgroup (fpga != eplds...)
>
>Thanks for suggestions...
>
>Dan
>


I think this is a good idea to include the ALTERA EPLDs in this newsgroup.

Guillaume.





Article: 313
Subject: Re: in circuit programming, was Re: PALASM versions?
From: devb@jazzmin.vnet.net (David Van den Bout)
Date: 18 Oct 1994 08:13:20 -0400
Links: << >>  << T >>  << A >>
In article <1994Oct18.013457.15054@adobe.com>,
Phil Ngai <pngai@mv.us.adobe.com> wrote:
.>
.>I think I would use three terms:
.>
.>in-circuit configuration. Like Xilinx and Altera 8000, the information
.>	loaded is volatile and must be loaded every time power is lost.
.>in-circuit programming. The current Intel parts, based on One Time
.>	Programmable EPROMs. You only get to program it once.
.>in-circuit reprogrammable. Configuration is non-volatile and can be
.>	reprogrammed a reasonable number of times.
.>
OK, I understand what you mean by in-circuit reprogrammable devices now.
On the above statement, however, I would place the Intel FPGAs into both
the "in-circuit configuration" and "in-circuit programming" since they
can be configured either using their OTP EPROM or their SRAM.  It's a
minor point.


-- 

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


Article: 314
Subject: Re: FPGA RISC Processor
From: wolf@aur.alcatel.com (William J. Wolf)
Date: 18 Oct 1994 15:26:11 GMT
Links: << >>  << T >>  << A >>
In article dg1@magus.cs.utah.edu, jlhutchi@sal.cs.utah.edu (Jeff Hutchings) writes:
> Geoff, I would be interested in your work as well.  What is available in
> the form documentation, white papers, etc.?  If you could please e-mail
> me regarding this, I would appreciate it.  I am currently engaged in
> the research and development of reconfigurable hardware systems in 
> general, and reconfigurable processors specifically.
> 
> -- Jeff Hutchings

Geoff, please just post the info!  Thanks.


---
~ Bill Wolf, Raleigh NC           ~          I can see         ~
~ wolf@aur.alcatel.com            ~           the fog          ~
~ My opinions, NOT my employer's  ~  at the end of the tunnel  ~




Article: 315
Subject: Re: in circuit programming
From: devb@jazzmin.vnet.net (David Van den Bout)
Date: 18 Oct 1994 15:32:38 -0400
Links: << >>  << T >>  << A >>
In article <g.r.kiss-171094233522@assante.open.ac.uk>,
George Kiss <g.r.kiss@open.ac.uk> wrote:
>In the previous discussion on in-circuit programming, no one mentioned the
>ATMEL 6000 device which also has SRAM based reprogrammability.  In fact
>they claim that they have the only product that supports reprogramming
>while the device is in operation!

Not exactly.  The Intel/Altera 8160 has two halves which can be independently
reconfigured without affecting each other's operations.  This is
admittedly not as powerful as what can be achieved with the Atmel FPGAs
(at least according to their marketing literature; I've never actually
used one).


-- 

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


Article: 316
Subject: Xilinx ROMS
From: petersr@fpga.ee.byu.edu (Russell Petersen)
Date: 18 Oct 1994 14:35:43 -0600
Links: << >>  << T >>  << A >>

	
	I am using Mentor Graphics and XC4000 parts but
cannot find a symbol for a 16x2 ROM.  There are symbols
for 16x1 ROMS and 32x1 ROMS and 16x2 RAMS but none for ROM.
The problem is that when I place two 16x1 ROMs on the
schematic there are not placed into the same CLB even though
they should fit (have same address lines).  Does anyone know
how I can make a 16x2 ROM with these parts?


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


Article: 317
Subject: Re: Multipliers in FPGA's
From: enzo@research.canon.oz.au (Enzo Liguori)
Date: Tue, 18 Oct 1994 23:05:30 GMT
Links: << >>  << T >>  << A >>
I implemented a full 8X8 multiplier in the Altera FLEX 8000 family.
It is just an experiment and no particular effort was made to optimize it.
It is not pipelined and its propagation delay pad to pad (thus including
the delay to get inside and then out of the device) is better than 90 ns (we
don't have a licence for the static timing analyzer here, so this is from
many direct simulations).
It only used 60% of the smallest FLEX (125 logic blocks out of 208, the
smallest FLEX is 2500 gates) and my results are valid for the -2 device
(there are faster devices now, the A series).

The good thing is that the whole design, that was expressed in high level
language (AHDL), took only 70 seconds to compile, synthetize, write a
backannoteted VHDL netlist, place and route.

For me that I had to use Mentor tools :-( during my previous gate array
designs, this is really good.

I haven't tried a 16X16 multiplier, but it shouldn't be more than 5-6 times
bigger than the 8X8 one. Pipelining should make it pretty quick and shouldn't
increase the size by a big deal since all the FLEX logic blocks have
flip-flops already whether you use them or not.

No, I don't work for Altera, but I like their tools and I'm even trying to
get a personal copy for hobby.

   Enzo

-- 
Vincenzo Liguori                             | enzo@research.canon.oz.au
Canon Information Systems Research Australia | Phone +61 2 805 2983
1 Thomas Holt Drive, North Ryde, NSW 2113    | Fax   +61 2 805 2929


Article: 318
Subject: Photolithography at 313nm wavelength (Mid-UV).
From: saurins@ee.ubc.ca (saurin shah)
Date: 19 Oct 1994 03:59:42 GMT
Links: << >>  << T >>  << A >>
Hi, 

I am wondering if it is possible to use DQN type photoresist at 313 nm wavelength. The Hg bulb
does emit at this wavelength. Is any one out there using this wavelength for lithography purpose?
What kind of problems would i be facing. I know that the bleaching at this wavelength is low 
compared to 365 nm or 435nm. So contrast could be a problem. But how serious is this problem?
Thanks a lot. saurin




 


Article: 319
Subject: Xilinx v5.0 unified libraries are wasting CLBs
From: edi@ife.ee.ethz.ch (Edi Hiltebrand)
Date: 19 Oct 1994 10:31:54 GMT
Links: << >>  << T >>  << A >>
At last we got the release 5.0 of the xilinx tools!!!
We started to convert a design done with the 4k libs to the
new unified libs. We noticed that the disign now needs a lot
more CLBs than it used with the old libs. The reason for this
is that the clock enable input of the CLB flipflops isn't used
and the CE feature is realised using the LUT. We just had to modify
some counters and regs to bring the design to a reasonable CLB 
count. If someone has similar observations we would be verry 
interested to hear. 

An other problem is still alive. If you use the carry logic 
it happens that sometime the ppr is putting some other signals
to the dedicated carry inputs of the LUT. Wath makes things worse 
with the new release is that the simulation is based on your 
schematics and not on the xnf file that results from the routing.
So you have no chance in detecting the errors introduced by the ppr
prior to loading the design into the HW. If anyone made similar 
observations we would like to know. And if there is any work arround
other than manualy correct the design in XDE it would be verry 
wellcome.

Thanks for any help!

Edi
 
*****************************************************************************
 Swiss Federal Institute of Technology     *   Email: edi@ife.ee.ethz.ch
 Electronics Laboratory                    *
 High Performance Computing                *
 Edi Hiltebrand                            *   Tel: +41 1 632 27 61
 8092 Zurich, Switzerland                  *   Fax: +41 1 632 12 10
*****************************************************************************


Article: 320
Subject: Re: Xilinx ROMS
From: bobe@soul.tv.tek.com (Bob Elkind)
Date: 19 Oct 1994 15:49:15 GMT
Links: << >>  << T >>  << A >>
In article petersr@fpga.ee.byu.edu (Russell Petersen) writes:

>	I am using Mentor Graphics and XC4000 parts but
>cannot find a symbol for a 16x2 ROM.  There are symbols
>for 16x1 ROMS and 32x1 ROMS and 16x2 RAMS but none for ROM.
>The problem is that when I place two 16x1 ROMs on the
>schematic there are not placed into the same CLB even though
>they should fit (have same address lines).  Does anyone know
>how I can make a 16x2 ROM with these parts?

It may not be a big deal, since ROMs are really nothing more than a
combination of logic gates.  Looking at it this way, there is no *inherent*
reason for the 2 bits of your ROM to be combined in the same CLB, other than
the fact that the two function generators share 4 input signals.

So, PPR treated your "ROM" just as casually as any other gates it finds.

I believe that in XACT 5 there is a provision for grouping logic together,
short of the RPM construct.  If all else fails, go for the RPM (Relationally
Placed Macro) which is designed for just this sort of problem.

Bob Elkind,  Tektronix TV


Article: 321
Subject: USC Multiprocessor Testbed on the WWW
From: lbarroso@pollux.usc.edu (Luiz Andre' Barroso)
Date: 19 Oct 1994 12:08:42 -0700
Links: << >>  << T >>  << A >>
We have just made available a WWW Home Page for the USC Multiprocessor
Testbed Project. The link is: 
 
                http://www.usc.edu/dept/ceng/dubois/testbed.html.
 
The USC Multiprocessor Testbed Project is exploring a new approach for
the rapid prototyping and performance evaluation of multiprocessor systems.
The methodology is based on hardware emulation and relies on emerging FPGA
(Field Programmable Gate Array) technology. Our first emulator, called the
USC Multiprocessor Testbed, is an 8-processor reconfigurable machine. It was
designed and built in 15 months. The Testbed can emulate a large class of
systems including shared and distributed memory multiprocessors, CC-NUMAs,
COMAs, various cache protocols and consistency models.
 
The home page contains links to general information on the project,
pictures of the machine and papers/slide presentations.
 
For further information please contact Michel Dubois (dubois@paris.usc.edu)
or myself - Luiz Barroso (barroso@paris.usc.edu).



Article: 322
Subject: Verilog for Synopsys vs Cadence
From: sc@vcc.com (Steve Casselman)
Date: Wed, 19 Oct 1994 20:34:22 GMT
Links: << >>  << T >>  << A >>
We just added support for verilog for our EVC product
I got help from Xilinx who uses Synopsys and that all
works. The problem is verilog itself doesn't let you
put pin numbers so in Synopsys you use a script file
by putting 

set_attribute sclk       "pad_location" -type string P57


The question is how is this done with Cadence?
I know I could put the pinouts in a .cst file
but I'd like to have it done with just the Cadence
tools. 

Steve Casselman
Virtual Computer


Article: 323
Subject: Re: Xilinx ROMS
From: petersr@fpga.ee.byu.edu (Russell Petersen)
Date: 19 Oct 1994 15:31:36 -0600
Links: << >>  << T >>  << A >>

In article <383f5r$3a1@news.tv.tek.com>, bobe@soul.tv.tek.com (Bob Elkind) writes:
|> In article petersr@fpga.ee.byu.edu (Russell Petersen) writes:
|> 
|> >	I am using Mentor Graphics and XC4000 parts but
|> >cannot find a symbol for a 16x2 ROM.  There are symbols
|> >for 16x1 ROMS and 32x1 ROMS and 16x2 RAMS but none for ROM.
|> >The problem is that when I place two 16x1 ROMs on the
|> >schematic there are not placed into the same CLB even though
|> >they should fit (have same address lines).  Does anyone know
|> >how I can make a 16x2 ROM with these parts?
|> 
|> It may not be a big deal, since ROMs are really nothing more than a
|> combination of logic gates.  Looking at it this way, there is no *inherent*
|> reason for the 2 bits of your ROM to be combined in the same CLB, other than
|> the fact that the two function generators share 4 input signals.
|> 
|> So, PPR treated your "ROM" just as casually as any other gates it finds.
|> 
|> I believe that in XACT 5 there is a provision for grouping logic together,
|> short of the RPM construct.  If all else fails, go for the RPM (Relationally
|> Placed Macro) which is designed for just this sort of problem.
|> 
|> Bob Elkind,  Tektronix TV


	I found at least one method (besides RPMs) that seems to work 
well although it is a bit tedious.  Giving two ROMs the same HBLKNM causes
them to be placed into the same CLB.  I used this method and was able to
implement an 8 bit constant multiplier with the ROMs that operates at 21 Mhz. 
I used the design described in an EDN article a while back.  The great thing
about these multipliers are that they only take 22 CLBs for 8 bit multipliers.
The reason they work so well is due to the speed of the lookup tables on the
Xilinx parts (and probably any other part using lookup tables).  This only 
works however for constant multipliers.  Any general multiplier is probably
best implemented as a full array unless you can afford the time it takes
to change the constant.  

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


Article: 324
Subject: XC3000 series FPGA with XAbel
From: txw@festival.ed.ac.uk (Tomas Whitlock)
Date: Wed, 19 Oct 1994 22:38:46 GMT
Links: << >>  << T >>  << A >>
Hello there,

	I would like to ask if anyone out there has had experience of or
solved a problem specific to particular suite of FPGA development
software.

	We have a problem with the Xilinx FPGA software. We have OrCAD,
Xact and the OrCAD interface to Xact, for developing XC2000, XC3000 and
XC4000 series FPGA's. Recently, we decided to use Xilinx Abel to embed
'components' created using XAbel in OrCAD schematics. These components
are used to implement circuitry that does not lend itself well to
schematic representation, such as one-hot encoded state machines.

	The normal way of doing this is to compile the Abel components
into individual .XNF files using XAbel, compile the schematics in which
they are embedded into an .XNF file using the Orcad interface, and
perform an XNFMERGE on the schematic .XNF file, which pulls in the
.XNF's for the Abel components and flattens everything.

	However, we have found that when we run XNFMAP on the merged
.XNF file, it fails to optimise the logic as well as it should. This
only seems to happen when we use Abel components. This is the
merge-then-map method. Should we be mapping each .XNF file before
merging the .MAP files? (map-then-merge) I am sure that this would
produce worse results as the partitioning of logic is best done with
knowledge of the entire FPGA circuitry.
	For example, in a development version of an Abel file, we might
feed a certain input straight through to an output. One would expect
the software to simply join the two nets. However, what actually happens
(sometimes) is that an entire CLB is used merely to feed the signal
through (with a function generator such as F=A being used), adding to
propagation delay. As some nets are fairly timing critical (i.e. a clock
speed of 33 MHz with an XC3042-100 part used in a synchronous circuit),
this is not acceptable.

	We have tried using Abel components in a trivial circuit, and it
appears to optimise these OK. When a 'real' circuit is used, it does not
manage to optimise nearly as well as it should. This behaviour does not
occur if we do not embed any Abel generated components in the
schematics. So, it looks like that we are stuck with drawing out state
machines as logic gates for the moment. Any ideas? Xilinx technical
support did not manage to help us.

	Sorry for such a long and tedious posting - I hope I have
managed to explain the problem sufficiently well in the space available
in a usenet posting. Any help would be greatly appreciated.

Thanks,
Tomas Whitlock.




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