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 7725

Article: 7725
Subject: Re: XILINX and ALTERA development boards
From: "Steven K. Knapp" <sknapp @ optimagic.com>
Date: 7 Oct 1997 15:54:35 GMT
Links: << >>  << T >>  << A >>
There is a fairly comprehensive list of available boards at
'http://www.optimagic.com/boards.html'.  In specific, I would look at the
TB4025PQ ISA prototyping board from Fliptronics (see
'http://www.geocities.com/SiliconValley/2256/products.htm') and the
Constellation FLEX 10K board from Nova Engineering (see
'http://www2.nova-eng.com/nova/constellation.html').
-- 
Steven Knapp
OptiMagic, Inc.
E-mail:  sknapp @ optimagic.com
Programmable Logic Jump Station:  http://www.optimagic.com

Nestor Caouras <nestor@ece.concordia.ca> wrote in article
<3433A8B5.6647@ece.concordia.ca>...
| Hi.
| 
| I've been looking around for development/prototyping boards that support
| the larger XILINX and ALTERA devices (such as xc4085 and FLEX10k100). Up
| to now I've only been able to find boards for Xilinx devices up to 10k
| devices (i.e. xc4010).  If anyone knows of a third party
| vendor/manufacturer that develops such boards, can you please contact
| me.
| 
| Your help will be greatly appreciated.
| 
| Thanks in advance.
| -- 
| Nestor Caouras
| nestor@ece.concordia.ca
| http://www.ece.concordia.ca/~nestor/addr.html 
| |-------------------------------------------|
| | Dept. of Electrical and Computer Eng.     |
| | Concordia University                      |
| | 1455 de Maisonneuve Blvd (West)           |
| | Montreal, Quebec, Canada H3G 1M8.         |
| | Tel: (514)848-8784    Fax: (514)848-2802  |
| |-------------------------------------------|
| 
Article: 7726
Subject: Re: bidirectional bus problem
From: ddecker@diablores.com (Dave Decker)
Date: 7 Oct 1997 17:34:44 GMT
Links: << >>  << T >>  << A >>
In article <01bccf48$9074cd20$1f38d926@dan.i-tech.com>, 
dan_kuechle@SPAM_NOTi-tech.com says...
>
>For Xilinx you need to use a tbuf with an ibuf to get the input portion,
>and an obuft for the output portion.  Don't know how other vendors do it.
>
>david.surphlis@gecm.com wrote in article
><6107sd$t4r@gcsin3.geccs.gecm.com>...
>> 
>> does anyone know how to but a birectional bus on to an fpga 
>> using in ibuf and obuf components as there does not seem to be a 
>> bidirectional buf.
>> 
>> Thanks 
>> Davey
>> 
>> 
Dan recommended a obuft for the output, while Nicholas recommended an obufe. 
These are not equivalent! The obufe was added recently by Xilinx to comply with 
the industry standard of enabling tri-state buffers with an active high. The 
way they did it was to make a macro with an obuft and an inverter in the 
control line. This inverter is not included in the output pin driver of 4000e 
parts, so it consumes a CLB function generator just for the inverter!

If you have wide output tri-state busses you should always use obuft. If you 
need the inversion, use one inverter to drive all your obufts. The software is 
not smart enough to do this for you, and if left to its own resources, it will 
use separate inverters for each obufe which could consume valuable CLB function 
generators.

I have Philip Freidin to thank for this bit of trivia.

Dave Decker
Diablo Research Co. LLC


"Animals .  .  . are not brethren they are not underlings;  they are other 
nations, 
caught with ourselves in the net of life and time, fellow prisoners of the 
splendor and travail of the earth."
Henry Beston -  The Outermost House

Article: 7727
Subject: Re: FPGA multiprocessors
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 7 Oct 1997 18:10:35 GMT
Links: << >>  << T >>  << A >>
In article <01bcd2e6$e74374c0$LocalHost@tecra>,
Jan Gray <jsgray@acm.org.nospam> wrote:

>As for hosting an OS, you will notice J32 has no MMU.  I have
>some promising schemes for reasonable MMUs for FPGA
>implementation along the lines of 1 bit per 16 KB page write
>protection (only) and some related software conventions.  Either
>that or slow sequential (nonassoc) TLB entry lookup.

How about 1-way associative (or direct mapped) TLB?  It would be like a
simple cache, and would require only a single address comparitor.  I might
have my terminology mixed up here, maybe that's what you have in mind?

>The J32 is designed to be as close to MIPS as possible but yet
>achieve good performance in half an XC4010.  In particular there are
>no PC-relative branch instructions because the jump instructions
>are adequate and adding another adder, mux, and bus would add
>at least 20% to the datapath area.

>If we eliminate J32 condition codes then it would be
>straightforward to write a MIPS to J32 cross assembler.
>It would map multiplies, exotic shifts, floating point, etc.
>into calls to emulation routines.

This is a really good idea that I hadn't thought of.  I'm thinking that you
don't have to change anything (but you do need to make sure that the number
of registers is equal or greater).  If the MIPS had condition codes and the
J32 didn't you would have a problem, but since it's the other way around,
the effects of the condition codes are clearly defined within a single MIPS
instruction.  Also, you would not have to worry about saving the flags
register at all, for the same reason.  So a beq would be translated into a
compare and jump on Z set (or into whatever instructions you have).

So is your design publically available? :-)

>BTW, if I recall correctly, MIPS has patents on lwl lwr etc.

This doesn't matter.  GNU C keeps everything aligned (in structures) and
won't generate these instructions in any other cases.  In fact these
instructions are useless.  For example in:

int foo(char *s)
 {
 return *(int *)(s+1);
 }
 
GNU C compiles the '*(int *)' into a lw and hopes you know what you're
doing.  It has no way of knowing whether (s+1) is going to be a multiple of
4 or not at compile time, so it doesn't know whether it should generate
lwl/lwr or not.  It assumes you know what you're doing and generates the
faster version (lw):

	.file	1 "test.c"

 # GNU C 2.6.3 [AL 1.1, MM 40] DECstation running ultrix compiled by GNU C

 # Cc1 defaults:

 # Cc1 arguments (-G value = 8, Cpu = 3000, ISA = 1):
 # -quiet -dumpbase -O -o

gcc2_compiled.:
__gnu_compiled_c:
	.text
	.align	2
	.globl	foo

	.text
	.ent	foo
foo:
	.frame	$sp,0,$31		# vars= 0, regs= 0/0, args= 0, extra= 0
	.mask	0x00000000,0
	.fmask	0x00000000,0
	lw	$2,1($4)
	j	$31
	.end	foo

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 7728
Subject: Design verification jobs
From: Edmond Tam <etam@vadem.com>
Date: Tue, 07 Oct 1997 11:27:13 -0700
Links: << >>  << T >>  << A >>
Vadem AISC dept. has 2 design verification job openings: a senior level
and a junior level engineering positions.

Job descriptions:
* chip level design verification for single chip computer;
* external module designs, such as EDO ram, flash rom, USB transceiver;
* functional verification by Verilog;
* timing verification by static timing analyzer;
* power calculation.

Requirements:
* BSEE or equivalent with 1+ yrs related experience for junior position;
* BSEE or equivalent with 6+ yrs related experience for senior position;
* understanding of ASIC design and verification flow;
* good at Verilog;
* for senior position, understanding of timing and power analysis;
* understanding of perl and IP is plus.

Please email your resume to etam@vadem.com. You can surf our website for
the company background at www.vadem.com. We are located at San Jose, CA.

Best Regards

Edmond Tam
Verification Leader
Vadem
(408)467-7708
etam@vadem.com
Article: 7729
Subject: IT'S YOUR HEALTH
From: william semonis<semonis@servcom.com>
Date: 8 Oct 97 05:13:47 GMT
Links: << >>  << T >>  << A >>
I have been taking herbs and my health has greatly improved over 2 yrs  and I'm in a company called shaperite
the best of the best herbs you can join the company for $9.95.
You will receive free voice mail so you can talk to me by leaving me messages? also you will benefit from these
fantastic herbal formulas like Idid.
You can start a business if you wanted to but most all it's your health?
Leave your name,address and phone for information pack.
                                                                                                William Semonis
Article: 7730
Subject: Re: FPGA multiprocessors => vs. uniprocessors
From: Jonathan Bromley <jseb@oxim.demon.co.uk>
Date: Wed, 8 Oct 1997 13:03:46 +0100
Links: << >>  << T >>  << A >>
In article <01bcd2dd$d098a000$LocalHost@tecra>, Jan Gray
<jsgray@acm.org.nospam> writes [amongst other things...]

>> They argue against multiple processors on a single chip, because it
>> makes what is already an I/O bound system even worse. Just because you
>> can put multiple processors on a dies doesn't mean you can feed them
>> instructions and data.
True, but surely the whole point about FPGAs is that you are trying to
do something that was awkward or impossible with standard parts - so you
will likely deal with this issue on a case-by-case basis.

>Also, Patt et al.'s statement is:
>       "In our view, if the design point is performance, the
>       implementation of choice is a very high-performance
>       uniprocessor on each chip, with chips interconnected
>       to form a shared memory multiprocessor."
Hmmm.  IMHO you have a tough
time convincing yourself that big shared-memory systems will do what
you want them to do in all possible circumstances - synchronisation
is either very difficult or somewhat inefficient.  Enough local memory
for the local process's needs, and fast-ish comms to other processing
nodes, is more elegant and easier to think about logically.
That was what Inmos were doing with the Transputer
more than a decade ago... It worked superbly but nobody believed
them, so the processor family didn't get enough development resource
thrown at it.  RIP, almost.

>Finally, let's discuss where we can go with a fast uniprocessor
>on a large FPGA.  I have given this some thought over the
>years.
>One big challenge is register file design.
yes, most FPGA structures are quite bad for implementing this, I agree.

The big problem, as is well known, is that general configurable
architectures (FPGAs) are not likely to be optimal for any particular
task.  We have become so dependent on the notion of a CPU that people
have invested inordinate effort in optimising them, raising our 
expectations spectacularly, so that you and I with our FPGAs cannot
match the performance and flexibility that you can buy for the price
of a hamburger from commodity CPU suppliers.  But the flexibility of
a standard CPU is really needed only for what someone in this thread 
called "dirty deck" work - infrequently executed, very irregular
operations with lots of branching and few opportunities for pipelining.
How about this for a new compromise:
put a small RISC machine on your FPGA, not fussing too much about 
performance because you won't need it;  and leave the rest (50%?) of
your FPGA free for the wacky pipelined stuff; but here's the new idea:
*** expose the register file of the CPU to the rest of the FPGA,
*** so that the FPGA can provide application-specific functionality
*** behind the registers.
That way you can go on using compilers that you know and love for
your CPU, you can write the rest of your FPGA in Handel-C or whatever,
and the application-specific stuff gets a uniform, high-bandwidth
interface to the CPU.
---- I was the person who said VCRs would never catch on. ----
Jonathan Bromley
Article: 7731
Subject: Help: ABEL program for ISPLSI1000 series.
From: "bertrand" <bertrand@prodigy.net>
Date: 8 Oct 1997 14:01:42 GMT
Links: << >>  << T >>  << A >>
You can make use of the IOC registers by using the PLSI PROPERTY key word
in ABEL syntax. The format goes somthing like this:

PLSI PROPERTY 'reg_name REGTYPE IOC';

where the reg_name is the name of the register that you want in the IOC.
Please check the documentation for the exact order of what is in the single
quotes. I may have the order of the reg_name in the wrong place but I think
you get the idea. The
ABEL compiler simply passes the PLSI PROPERTY statements to the Lattice
ispDS+ Fitter. The ispDS+ Fitter then handles the proper placement of the
register.  Keep in mind that this statement has to go in your declaration
block -- outside of your equation or statemachine block. 

-- ISP is LATTICE


Bulent UNALMIS <unalmis@club-internet.fr> wrote in article
<342EF2EC.1620@club-internet.fr>...
> Hello all Lattice users.,
> 
> I am writing ABEL program  for ISPLSI1048.
> I want to use IOC registers for registereted inputs.
> I dont have any problem if I use GLB FlipFlops.
> But How can I use IOC FlipFlops I dont know.
> 
> Can you send me any example ABEL program ?
> 
> Thanks.
> 
Article: 7732
Subject: Re: FPGA multiprocessors => vs. uniprocessors
From: Charles Sweeney <CharlesSweeney@compuserve.com>
Date: Wed, 08 Oct 1997 15:13:57 +0100
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:

> How about this for a new compromise:
> put a small RISC machine on your FPGA, not fussing too much about
> performance because you won't need it;  and leave the rest (50%?) of
> your FPGA free for the wacky pipelined stuff; but here's the new idea:
> *** expose the register file of the CPU to the rest of the FPGA,
> *** so that the FPGA can provide application-specific functionality
> *** behind the registers.
> That way you can go on using compilers that you know and love for
> your CPU, you can write the rest of your FPGA in Handel-C or whatever,
> and the application-specific stuff gets a uniform, high-bandwidth
> interface to the CPU.
> ---- I was the person who said VCRs would never catch on. ----
> Jonathan Bromley

That leads me very neatly onto the ASPIRE project! The aim is to
incorporate the ARM core in an ASIC. A PCI plug-in card is being
developed with an ARM chip connected to a Xilinx FPGA to try out the
ideas. The FPGA is being programmed with Handel-C, which explains the
association with Embedded Solutions who are marketing the board.

Brief summary of ASPIRE is at:
http://www.omimo.be/scripts/dbml.exe?template=/_srproj2.dbm&Project_Number=20451

Charles

Charles Sweeney, Engineering Director, Embedded Solutions Ltd
Tel/fax +44 1235 510456   <http://www.embedded-solutions.ltd.uk/>
Email CharlesSweeney@compuserve.com or
csweeney@embedded-solutions.ltd.uk
6 Main Road, East Hagbourne, Didcot, Oxfordshire. OX11 9LJ. UK.
Article: 7733
Subject: Japanese FPGA mailing list
From: basaro@fa2.so-net.or.jp (Tadaaki Koyama)
Date: 8 Oct 1997 15:43:34 GMT
Links: << >>  << T >>  << A >>
Hi !
My name is Tadaaki Koyama . I'm Japanese so I can write poor English. sorry.

In Japan, FPGA Infomations is poor and We can not get FPGA's Information 
because we weakly read English . 
So I made Japanese FPGA mailing-list. I want to give and take about infomation 
of FPGA in Japan. If you want to know this mailing list, Please access 
my home page.

http://www01.u-page.so-net.or.jp/fa2/basaro/       It is only Japanese.

Thank you.
                   Tadaaki Koyama         basaro@yumenet.com
                                          basaro@fa2.so-net.or.jp

Article: 7734
Subject: Re: FPGA multiprocessors => vs. uniprocessors
From: Andy Wilson <andyw@NOSPAM.ibeam.intel.com>
Date: Wed, 08 Oct 1997 11:06:45 -0700
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> How about this for a new compromise:
> put a small RISC machine on your FPGA, not fussing too much about
> performance because you won't need it;  and leave the rest (50%?) of
> your FPGA free for the wacky pipelined stuff; but here's the new idea:
> *** expose the register file of the CPU to the rest of the FPGA,
> *** so that the FPGA can provide application-specific functionality
> *** behind the registers.
> That way you can go on using compilers that you know and love for
> your CPU, you can write the rest of your FPGA in Handel-C or whatever,
> and the application-specific stuff gets a uniform, high-bandwidth
> interface to the CPU.
> ---- I was the person who said VCRs would never catch on. ----
> Jonathan Bromley

Now this is an interesting idea.

Experimenting with home-brewed computer architectures is an interesting
(if a little nerdy <g>) hobby, but it's a bit perverse to use a
programmable device to emulate fixed-instruction set computers.
The programmable device starts with roughly a 10X penalty, relative to
a top of the line microprocessor, in how fast it can wiggle those gates.
As several posters have pointed out, it's unlikely you can keep the
multiprocessors fed with instructions fast and data enough to gain in
parallelism what you have lost in clock speed relative to the main CPU.

On the other hand, using the configurable device for configurable
computing
has considerable merit....

John Koza from Stanford has an interesting paper on using an FPGA
(Xilinx
6200) to accelerate a genetic programming problem.  On an intrinsically
parallel genetic/systolic/cellular type of algorithm, you might get a
1000:1 algorithmic speedup relative to a sequential CPU.  So even with
the 1:10 clock hit, you have a large net win.

atw
not speaking for intel....
Article: 7735
Subject: Re: bidirectional bus problem
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 08 Oct 1997 16:46:17 -0700
Links: << >>  << T >>  << A >>
Dave Decker wrote:

>  This inverter is not included in the output pin driver of 4000e
> parts, so it consumes a CLB function generator just for the inverter!
> I have Philip Freidin to thank for this bit of trivia.

In spite of the usually excellent,  reliable and enlightening source you
quoted here, this is a misunderstanding.
The IOB output enable or 3-state control has a built-in inverter that
is, therefore, free. And the software knows how to handle this.
The chip-internal T-buf does not have such an inverter option, and
that's perhaps where this confusion originated.

Peter Alfke, Xilinx Applications

Article: 7736
Subject: [Fwd: [Fwd: [Fwd: [Fwd: [Fwd: READ THIS MESSAGE AND PASS IT ON....]]]]]
From: Hello <franz123@hotmail.com>
Date: Thu, 09 Oct 1997 12:37:43 +0800
Links: << >>  << T >>  << A >>


dementia wrote:

>                                                   ------------------------------------------------------------------------
>
> Subject: [Fwd: [Fwd: [Fwd: READ THIS MESSAGE AND PASS IT ON....]]]
> Date: Mon, 06 Oct 1997 17:46:50 -0700
> From: shelley tantan <shmelley@skyinet.net>
> Organization: SKYinternet Philippines
> Newsgroups: alt.teens,alt.romance,alt.romance.teen,alt.music.lyrics
>
> Subject: [Fwd: [Fwd: READ THIS MESSAGE AND PASS IT ON....]]
> Date: Sun, 05 Oct 1997 01:53:40 -0700
> From: Afro Jon <sleater@earthlink.net>
> Organization: EarthLink Network, Inc.
> Newsgroups: alt.sex.oral,alt.sex,alt.love,alt.suck
>
>                                                   ------------------------------------------------------------------------
>
> Subject: [Fwd: READ THIS MESSAGE AND PASS IT ON....]
> Date: Wed, 01 Oct 1997 15:19:18 -0600
> From: Jon Lacousta <jlacoust@geocities.com>
> Organization: University of Alberta, Edmonton, Canada
> Newsgroups: alt.locksmithing,alt.cellular.nokia,alt.cellular-phone-tek,alt.drugs.psychedelics,alt.drugs.pot
>
>                                                   ------------------------------------------------------------------------
>
> Subject: READ THIS MESSAGE AND PASS IT ON....
> Date: 30 Sep 1997 20:13:28 GMT
> From: x.traktor@beyond.hell (Ex Traktor)
> Organization: The Men They Couldn't Hang
> Newsgroups: alt.catastrophism,alt.comp.blind-users,alt.disney.disneyland,alt.drugs.mushrooms,alt.tasteless.jokes
>
> READ THIS MESSAGE AND PASS IT ON....
>
> A man takes the day off work and decides to go out golfing. He is on the
> second hole when he notices a frog sitting next to the green. He thinks
> nothing of it and is about to shoot when he hears, "Rabbit. 9 Iron"
> The man looks around and doesn't see anyone. "Rabbit. 9 Iron." He
> looks at the frog and decides to prove the frog wrong, puts his other club
> away, and grabs a 9 iron. Boom!  he hits it 10 inches from the cup. He
> is shocked. He says to the frog, "Wow that's amazing. You must be a
> lucky frog, eh?"  The frog reply's "Rabbit. Lucky frog." The man decides to
> take the frog with him to the next hole. "What do you think frog?" the
> man asks. "Rabbit. 3 wood." The guy takes out a 3 wood and Boom!  Hole
> in one. The man is befuddled and doesn't know what to say. By the end
> of the day, the man golfed the best game of golf in his life and asks the
> frog,"OK where to next?" The frog reply, "Rabbit. Las Vegas." They go
> to "Las Vegas and the guy says, "OK frog, now what?" The frog says,
> "Rabbit Roulette." Upon approaching the roulette table, the man asks,
> " What do you think I should bet?" The frog replies, "Rabbit.$3000,black 6."
> Now, this is a million-to-one shot to win, but after the golfgame, the man
> figures what the heck. Boom! Tons of cash comes sliding back across
> them table. The man takes his winnings and buys the best room in the hotel.
> He sits the frog down and says, "Frog, I don't know how to repay you.
> You've won me all this money and I am forever grateful." The frog
> replies, "Rabbit, Kiss Me." He figures why not, since after all the frog did
> for him he deserves it. With a kiss, the frog turns into a
> gorgeous15-year-old girl. "And that, your honour, is how the girl
> ended up in my room."
>
> The origination of this letter is unknown, but it brings good luck to
> everyone who passes it on. The one who breaks the chain will have bad
> luck. Do not keep this letter. Do not send money. Just forward it to
> five other newsgroups to whom you wish good luck. You will see that
> something good happens to you four MINUTES from now if the chain is
> not broken. You will receive good luck in four minutes.
>
> ----------------------
> lifeforce@beyond.hell



Article: 7737
Subject: Re: bidirectional bus problem
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 9 Oct 1997 06:00:12 GMT
Links: << >>  << T >>  << A >>
In an article by Dave Decker (see below), he notes that OBUFT and OBUFE 
are not equivalent, and that there is an issue of the inverter that is
used to convert a OBUFT into an OBUFE. Dave credits me for this info, and
tragically, he probably did get it from me. Tragic because it is incorrect.
Here's the Truth (tm)

An OBUFT is a primitive for all XC3K and XC4K families. It is an output
         buffer, that drives when the T pin is low. When the T pin is
         high, the output goes to its third state: High Impedance (Z)

An OBUFE is represented in the libraries as an OBUFT with an inverter
         driving the T signal, and the user connects to the input of
         the inverter, which is labeled E.

If you use multiple OBUFE symbols in your design and connect all the E
         pins together, there will be multiple inverters in your netlist.

This is not an issue, as the OBUFE is also a primitive in all the XC3K 
         and XC4K families, even though the library symbols represent it
         as an inverter and an OBUFT. The software recognizes this
         construct, and the inverters are absorbed into the I/O primitive,
         and the OBUFE is what is actually instantiated in the placed and
         routed chip.

So ... No extraneous inverters.

The problem is that the same is not true for the tristateable buffers in 
the main array. These are called BUFT and BUFE, and the BUFE symbols are 
a macro with an inverter and a BUFT. If you use multiple BUFE symbols, 
and tie their E pins together, you will get multiple inverters, both in 
the netlist and the placed and routed chip. This is probably not 
desireable. If the E pins are all fed from one flipflop for example, then 
you end up wasting a function generator per OBUFE, to implement all the 
inverters. It is better to design with BUFT symbols, and instantiate just 
one inverter your self.

Philip Freidin.




In article <61drrk$h3j$1@ultra.exodus.net> ddecker@diablores.com (Dave Decker) writes:
>In article <01bccf48$9074cd20$1f38d926@dan.i-tech.com>, 
>dan_kuechle@SPAM_NOTi-tech.com says...
>>
>>For Xilinx you need to use a tbuf with an ibuf to get the input portion,
>>and an obuft for the output portion.  Don't know how other vendors do it.
>>
>>david.surphlis@gecm.com wrote in article
>><6107sd$t4r@gcsin3.geccs.gecm.com>...
>>> 
>>> does anyone know how to but a birectional bus on to an fpga 
>>> using in ibuf and obuf components as there does not seem to be a 
>>> bidirectional buf.
>>> 
>>> Thanks 
>>> Davey
>>> 
>>> 
>Dan recommended a obuft for the output, while Nicholas recommended an obufe. 
>These are not equivalent! The obufe was added recently by Xilinx to comply with 
>the industry standard of enabling tri-state buffers with an active high. The 
>way they did it was to make a macro with an obuft and an inverter in the 
>control line. This inverter is not included in the output pin driver of 4000e 
>parts, so it consumes a CLB function generator just for the inverter!
>
>If you have wide output tri-state busses you should always use obuft. If you 
>need the inversion, use one inverter to drive all your obufts. The software is 
>not smart enough to do this for you, and if left to its own resources, it will 
>use separate inverters for each obufe which could consume valuable CLB function 
>generators.
>
>I have Philip Freidin to thank for this bit of trivia.
>
>Dave Decker
>Diablo Research Co. LLC
>
>
>"Animals .  .  . are not brethren they are not underlings;  they are other 
>nations, 
>caught with ourselves in the net of life and time, fellow prisoners of the 
>splendor and travail of the earth."
>Henry Beston -  The Outermost House
>


Article: 7738
Subject: Re: Pin allocation on ALTERA FLEX10K
From: Rune Baeverrud <r@acte.no>
Date: Thu, 09 Oct 1997 16:03:19 +0200
Links: << >>  << T >>  << A >>
Pierre-Yves BRETECHER wrote:
 
> In the past  I have experienced many difficulties for fitting ALTERA device
> (MAX 5K and 7K) when I started my design by setting the pin allocation (to
> get the PCB at the right time) .
> Today I have to design with a FLEX 10K30 (208 pins) where I have to fix now
> about 130 pins (I have 3 bus of 16bits and I expect my design to be less
> than 15k gates).

Hello Pierre,

I will take the opportunity to answer this one - even if you will
possibly regard me as somewhat biased: I've been working as an FAE with
an Altera distributor for the last 2 1/2 years.

In most designs I've been working with recently, using the newer
versions of Max+Plus II, FLEX 10K pin allocation problems has virtually
disappeared in my experience. I've been able to fill the devices almost
to it's limits (90-95-100%), using almost all the pins (95-100%). Then -
I've rearranged all the pins at random - and then recompiled without any
problems whatsoever! I've seen this in several designs. Also - in the
FLEX devices there is very seldom a speed penalty to pay when you start
filling the device to it's limits, and the I/O timing will normally not
change very much when doing design changes.

FLEX 10K is really a pleasure to work with when it comes to pin locking,
and I also believe FLEX 6000 series has been designed with the
experiences gained from 10K fitting in mind - even if I don't have that
much experience with the FLEX 6000 yet.

About MAX7000, pin locking can be a problem in some very few cases,
caused by a limitation of the fan-in width into the LABs. But if you
know what you're doing and know the limitations of the architecture
you're using - you will very seldom run into trouble. I believe I've
seen only 2 or 3 cases with pin locking problems in MAX 7000 during the
past two years.

If you have to - I would suggest you just go ahead and lock the pins.
Chances are quite good that you will not run into fitting trouble.

Regards,
Rune Baeverrud
Article: 7739
Subject: Praegitzer Industries Inc.'s Technical Symposium '97
From: "Kent Lewis" <kent_lewis@kvo.com>
Date: Thu, 9 Oct 1997 09:53:47 -0700
Links: << >>  << T >>  << A >>
Here's an upcoming event you may be interested in:

Praegitzer Industries Inc.'s Technical Symposium '97
"Everything New Under The Sun"
November 20, 1997
The Fairmont Hotel, San Jose, CA.

The all-day event will feature discussions on microvias, buried passive
components, surface finishes and future technologies. Admission is free but
space is limited.

To reserve your space now, please send e-mail to symposium@pii.com.

For more information, please contact Sonya Seyle via phone at 503.221.7421
or e-mail at sonya_seyle@kvo.com. Be sure to visit Praegitzer’s Web site at
http://www.pii.com/.



Article: 7740
Subject: VHDL SRAM model for testbench?
From: db <"brandis<NO-SPAM>"@dlcc.com>
Date: Thu, 09 Oct 1997 10:05:31 -0700
Links: << >>  << T >>  << A >>
I am looking to simulate my VHDL FPGA design and would like to design a
testbench that includes a VHDL model of an SRAM (32K x 8).  Does anyone
have a good way of doing this?  I was thinking of using textio
statements to use a file as the memory but am not quite sure how to go
about doing this, and even then am not sure this wouldn't slow the
simulator (ModelTech) to a crawl.  Any suggestions would be
appreciated....thanks!!

db

brandis@dlcc.com

remove <no spam> from reply
Article: 7741
Subject: FPGA based CPU ideas, and novel extensions
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 9 Oct 1997 17:56:03 GMT
Links: << >>  << T >>  << A >>
In article <5ASPUFAia3O0UA$k@oxim.demon.co.uk> Jonathan Bromley <jseb@oxim.demon.co.uk> writes:
>How about this for a new compromise:
>put a small RISC machine on your FPGA, not fussing too much about 
>performance because you won't need it;  and leave the rest (50%?) of
>your FPGA free for the wacky pipelined stuff; but here's the new idea:
>*** expose the register file of the CPU to the rest of the FPGA,
>*** so that the FPGA can provide application-specific functionality
>*** behind the registers.
>That way you can go on using compilers that you know and love for
>your CPU, you can write the rest of your FPGA in Handel-C or whatever,
>and the application-specific stuff gets a uniform, high-bandwidth
>interface to the CPU.
>---- I was the person who said VCRs would never catch on. ----
>Jonathan Bromley

Great idea, and it was implemented in my 16 bit RISC processor (RISC4005) 
that I developed in 1990. This processor is about 150 CLBs, runs in a 
XC4005 at about 20MHz, and is architecturally similar to the AM29000. The 
32 bit CPU that Jan has designed is also quite similar, except for size. 

In the RISC4005, both of the register fetch busses and the result bus 
were available for the user to add new function units, with the core 
processor performing the register fetches for the external (to the CPU, 
but still on the same FPGA) function unit, and then take its result and 
put it back in the appropriate register. There were even reserved op-code 
positions for these external function units.

I went one better though, for very high speed output. I created a facility
I called a 'View Register', and an associated 'View Register Selector'. 
The selector is a 4 bit field that specifies one of the 16 registers in
the main CPU register file. Whenever a write to that CPU register is done,
the 'View Register' is updated as well with a copy. This effectively gives
you a control register within a peripheral function that can be written to
with any instruction that puts a result back into the register file. So
moves, ands, ors, adds etc can all do their thing, and the result also
goes to the peripheral 'View Register'. If you have a set of back to back
register to register move instructions, then you can achieve a burst rate
of 20M transfers per sec, until you run out of registers. 

Obviously, this can be extended to multiple selectors with multiple view 
registers. The cost is that a general purpose register within the 
register file now has side-effects (and so cant be made available to a 
compiler as a general purpose register), but the advantage is stunningly 
fast output capability. This is ideal for applications that have the 
processor bit-banging some type of output protocol.

I guess it's time for me to dust off my design and port it to the newer 
XC4000E, XC4000EX, and XC4000XL, and see how much faster I can make it. I 
suspect that I could probably get it to run at 40 to 50 MHz in one of the 
faster speed grade chips.


Philip Freidin
Article: 7742
Subject: Re: FPGA based CPU ideas, and novel extensions
From: David Atkins <david@broadside.demon.co.uk>
Date: Thu, 9 Oct 1997 20:12:27 +0100
Links: << >>  << T >>  << A >>
Any of these kicking around for Altera, if not for a good reason, ?
Somehting of an interest but not in aposition to find the time for the
money to get into, we use 10k10's at present and the techniques would be
intersting, any pointer greatfully recieved.



In article <fliptronEHsptF.Ev6@netcom.com>, Philip Freidin
<fliptron@netcom.com> writes
>In article <5ASPUFAia3O0UA$k@oxim.demon.co.uk> Jonathan Bromley 
><jseb@oxim.demon.co.uk> writes:
>>How about this for a new compromise:

STUFF Removed !
>
>I guess it's time for me to dust off my design and port it to the newer 
>XC4000E, XC4000EX, and XC4000XL, and see how much faster I can make it. I 
>suspect that I could probably get it to run at 40 to 50 MHz in one of the 
>faster speed grade chips.
>
>
>Philip Freidin

-- 
David Atkins
Article: 7743
Subject: Re: How fast can fully pipelined XC4000 logic go?
From: "Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au>
Date: 9 Oct 1997 23:04:24 GMT
Links: << >>  << T >>  << A >>


G. Herrmannsfeldt <gah@u.washington.edu> wrote in article
<61bqes$dcg$1@nntp6.u.washington.edu>...
> I am working on a design using XC4000 logic, which I want to be as
> fast as possible.  The basic design is a pipelined systolic array
> processor, so it is already well pipelined.
> 
> What I want to do is add more pipeline stages, so I can run even faster.
> 
> I have designs that have only one or two CLB worth of logic between
> latch stages.  The CLB will be arithmetic logic, such as 16 bit adders or
> comparators.
> 
> How fast can I go with something like XC4013E or even an EX part, such
> as XC4028EX?
> 
> I am looking for a little more than in the Xilinx databook.  
> 
> thanks,
> 
> -- glen
> 

The current fastest Xilinx parts are the 4000XL series (3.3 volt). This
family
is also cheaper than the earlier families.

I'm in the process of designing something in the 4010XL which is using
about 98%
of the CLBs, has about half the CLBs being clocked at 100MHz and is still
meeting
all timing constraints. I'm really quite impressed.

Erik

Article: 7744
Subject: Re: bidirectional bus problem
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Thu, 09 Oct 1997 20:29:03 -0400
Links: << >>  << T >>  << A >>
> Dan recommended a obuft for the output, while Nicholas recommended an obufe.
> These are not equivalent! The obufe was added recently by Xilinx to comply with
> the industry standard of enabling tri-state buffers with an active high. The
> way they did it was to make a macro with an obuft and an inverter in the
> control line. This inverter is not included in the output pin driver of 4000e
> parts, so it consumes a CLB function generator just for the inverter!
> 
> If you have wide output tri-state busses you should always use obuft. If you
> need the inversion, use one inverter to drive all your obufts. The software is
> not smart enough to do this for you, and if left to its own resources, it will
> use separate inverters for each obufe which could consume valuable CLB function


Not true.  The IOBs have the capability of inverting the tristate
enable.  The inverter in the library gets interpreted by PPR and is
absorbed into the IOB logic.  This is not true however for the internal
BUFT's (BUFE's will instantiate a separate inverter, which will be
absorbed into preceeding combinatorial logic if possible.  If you are
driving a BUFE's control with a flop, use a BUFT and do the inversion on
the input side of the flop or you'll wind up with an extra level

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka
Article: 7745
Subject: Re: XILINX and ALTERA development boards
From: "Nestor C." <nestor@ece.concordia.ca>
Date: Fri, 10 Oct 1997 07:05:45 -0400
Links: << >>  << T >>  << A >>
Thanks for the info.
-- 
Nestor Caouras
nestor@ece.concordia.ca
http://www.ece.concordia.ca/~nestor/addr.html
|-------------------------------------------|
| Dept. of Electrical and Computer Eng.     |
| Concordia University                      |
| 1455 de Maisonneuve Blvd (West)           |
| Montreal, Quebec, Canada H3G 1M8.         |
| Tel: (514)848-8784    Fax: (514)848-2802  |
|-------------------------------------------|
Article: 7746
Subject: Re: How fast can fully pipelined XC4000 logic go?
From: brian@shapes.demon.co.uk (Brian Drummond)
Date: Fri, 10 Oct 1997 12:38:35 GMT
Links: << >>  << T >>  << A >>
"Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au> wrote:

>
>
>G. Herrmannsfeldt <gah@u.washington.edu> wrote in article
><61bqes$dcg$1@nntp6.u.washington.edu>...
>> I am working on a design using XC4000 logic, which I want to be as
>> fast as possible.  The basic design is a pipelined systolic array
>> processor, so it is already well pipelined.
>> 
>> What I want to do is add more pipeline stages, so I can run even faster.
>> 
>> I have designs that have only one or two CLB worth of logic between
>> latch stages.  The CLB will be arithmetic logic, such as 16 bit adders or
>> comparators.
>> 
>> How fast can I go with something like XC4013E or even an EX part, such
>> as XC4028EX?
>> 
>> I am looking for a little more than in the Xilinx databook.  
>> 
>> thanks,
>> 
>> -- glen
>> 
>
>The current fastest Xilinx parts are the 4000XL series (3.3 volt). This
>family
>is also cheaper than the earlier families.
>
>I'm in the process of designing something in the 4010XL which is using
>about 98%
>of the CLBs, has about half the CLBs being clocked at 100MHz and is still
>meeting
>all timing constraints. I'm really quite impressed.
>
>Erik

I understood there was a "tweaked" 3000 series which could be _clocked_
at around 300 MHz (and achieve quite impressive speeds with real designs
too) the XC3100A family. 

This still seems (on paper) faster than the 4000XL family ( but of
course, smaller). Are there any plans to match this sort of performance
in the XC4000 family?

- Brian
Article: 7747
Subject: Re: How fast can fully pipelined XC4000 logic go?
From: Christy Looby <clooby@nmrc.ucc.ie>
Date: 10 Oct 1997 15:23:41 +0100
Links: << >>  << T >>  << A >>
brian@shapes.demon.co.uk (Brian Drummond) writes:

> "Erik de Castro Lopo" <e.de.castro@fairlightesp.com.au> wrote:
> >The current fastest Xilinx parts are the 4000XL series (3.3 volt). This
> >family
> >is also cheaper than the earlier families.
> >
> >I'm in the process of designing something in the 4010XL which is using
> >about 98%
> >of the CLBs, has about half the CLBs being clocked at 100MHz and is still
> >meeting
> >all timing constraints. I'm really quite impressed.

> I understood there was a "tweaked" 3000 series which could be _clocked_
> at around 300 MHz (and achieve quite impressive speeds with real designs
> too) the XC3100A family.

In `Signal Processing at 250MHz using high speed FPGAs', Proc. FPGA'97,
	pp62-68, B. von Herzen reports a spectral correlator measured
	at 250MHz using XC3195-09. This is achieved in a timing-by-construction
	design flow. Indeed clock speeds of 300MHz are possible with 3195.

As usual, getting a clean clock signal and propogating it in the circuit is
	the simple problem that turns out to be more of a barrier than the
	pipeline stages, at these speeds and loadings.
> 
> This still seems (on paper) faster than the 4000XL family ( but of
> course, smaller). Are there any plans to match this sort of performance
> in the XC4000 family?

The quote in the reference above "..it is faster to travel to the right than
to the left, and slightly faster to travel down than up...(XC3100) .. Families
such as the XC4000 do not have this directionality, but are not as fast for
direct interconnect between neighbours."
	This indicates the above question is unlikely to have a positive answer.

The original poster's question about the XC4000 max pipelined speed can be
calculated by following the analysis of von Herzen.. or just work it out
by hand from a timing budget and the databook (which I don't have to hand)

--
Regards,							   <pre>
--------------------logo:Silicon Wafer----------------------------------
Christy Looby,	       .--~~~~~--.    E-mail: clooby@nmrc.ucc.ie        
NMRC, Univ. College, .'/_N_M_R_C_\`.  Phone +353 (0)21 904 064((Direct) 
Lee Maltings, Cork, |_/_/_|_|_|_\_\_| Fax   "     "  270 271            
REPUBLIC OF IRELAND \_I_R_E_L_A_N_D_/ Nat'l-Microelctronic-Res'rch-Cntr 
                     `-------------'     (NMRC)                         
------------------------------------------------------------------------
http://nmrc.ucc.ie  http://www.ucc.ie/ucc/socs/squash/clooby.html </pre>
Sender: SRIRAM SRINIVASAN <sriram@rocket.cc.umr.edu>
Article: 7748
Subject: WOW! Complete XILINX dev kits WITH X84 BOARD $300.00
From: Richard Schwarz <aaps@erols.com>
Date: Fri, 10 Oct 1997 10:28:23 -0400
Links: << >>  << T >>  << A >>
Wow, You can now get foundation base kits and base VHDL kits
with the APS X84 development board for as low as 300.00 total !!!!!!

That includes schematic capture, ABEL HDL AND M1 ROUTER!!!Plus the X84
development board (ISA/stand alone) ,with  5202  FPGA, prom socket,
oscillator socket, timer circuit, status LEDs, download software, C
code, 8255 chip, decode pal, strapable PC address,  accepts XILINX
Download cable. Four 20 pin IDC IO connectors. VHDL examples and C code
boilerplates. with on board FPGA and oscillator socket etc. etc.. The
software is limited to 8000 gates, but that's alot of
bang for the buck.300.00 bucks total !!! (plus shipping) I have never
seen such a great deal. This is all possible because XILINX has cut
their prices (for a limited time) on
their software, and we have lowered our price on the X84 board in kind.
For those who want VHDL for $700.00 you can get the same deal mentioned
above with VHDL.

You can only get the X84 boards through APS.

APS-X84-FB01 kit:   $300.00
  X84 board kit (see above)with the XILINX Foundation base software kit.
Includes: XACT router, Schematic, simulation, ABEL-HDL,  design support,
XILINX CPLD and FPGA  implementation tools.

APS-X84-FBV  $700.00
X84 board kit (see above) &  Foundation XACT router, VHDL synthesis,
schematic BASE VHDL, simulation, ABEL-HDL   XC7300 family design
support, Xilinx  CPLD and FPGA implementation  tools.

We accept VISA and MASTER CARD

http://www.associatedpro.com/aps

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: aaps@erols.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 7749
Subject: Very Low Cost VHDL Windows Simulator
From: Richard Schwarz <aaps@erols.com>
Date: Fri, 10 Oct 1997 10:56:41 -0400
Links: << >>  << T >>  << A >>
APS is now selling the PeakPers VHDL Simulator for only $699.00 !!!

This simulator supports VHDL 1076-1987 1076-1993 (some restrictions
aply) It includes built in VHDL editor, Hierarchy browser, VHDL wizards,
Includes the Text Book "VHDL made easy!" and is compatible with Windows
and NT

http://www.associatedpro.com/aps

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: aaps@erols.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/




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