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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 19850

Article: 19850
Subject: Re: fastest 32 bit RISC
From: "Jan Gray" <jsgray@acm.org.nospam>
Date: Fri, 14 Jan 2000 06:37:15 GMT
Links: << >>  << T >>  << A >>
>> I note the 100 MHz result posting from Damjan Lampret and the
>opencores.org
>> folks.  Nice work.  Synthesized even!  Do you floorplan?
>
>No floorplanning.

Incredible.  In addition to your (I assume) excellent work, I see now that
synthesis tools and the automatic P&R tools are more improved, and Virtex is
even faster, than I had realized.  Please tell us about your tools when
appropriate.

I have the eerie tingly feeling that we have turned the corner into a new
era -- a realization (for me) which couldn't have come in a more appropriate
month.

Fellas, perhaps it's time to set down our FMAPs and RLOCs and RPMs and
XC4000s and move along.  It's been fun.

Jan Gray
Gray Research LLC



Article: 19851
Subject: Re: PCI Bus Problems with Burst Transfers
From: "Peter Lang" <Peter.Lang@rmvmachinevision.de>
Date: Fri, 14 Jan 2000 09:50:43 +0100
Links: << >>  << T >>  << A >>
Oh sorry about mistyping the PCI Master chip name!
John you are right,
we are using Philips SAA7146A as PCI Master.
And by the way I think this chip is quite powerful!
The reason of the retries might be the Intel PCI Bridge 82443LX
but I am not shure (this goes quite deep into the motherbord architecture)

Peter


Article: 19852
Subject: Re: fastest 32 bit RISC
From: "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not>
Date: Fri, 14 Jan 2000 10:51:24 +0100
Links: << >>  << T >>  << A >>

>I'm not sure I'd call the architectures similar.  Yes they share the 4K
pinouts
>and configuration protocol and they both utilize 4 input look up tables as
the
>basic logic block.  After that the similarities end.  The achilles heel of
the
>Atmel device is the lack of a carry chain, so for things that require
arithmetic
>or binary counters, the Atmel just can't compete.  A RISC processor is one
of
>those things.


Yes, the 40K is better on Multiplies than Adds...
Also, I think that the Virtex is a more advanced process than the one
I synthesized for. Didn't do any floorplanning or special layout at this
point.
Happy just to get it working, since it it more of a hobby than anything
else.

>I think if you do the design carefully you can get pretty close in some of
the
>VIrtex and VIrtex E devices.  Alot depends on the instruction set of the
>processor.
Yes, as someone points out in a later entry, barrell shifters are not
so good, for FPGAs.
You can also get the frequency up by pipelining.
A super pipelined multithreaded processor would probably be OK in an FPGA.
The multithreading allows you to avoid checking for dependencies
between instructions.

>
>You can do a 32 bit barrel shift in 4K in 3 levels of logic (FG-H-FG-H-FG),
>which, if floorplanned, will get you to 50 MHz in any of the xilinx 4000XLA

>series  parts.
I am really a newbie to FPGAs but
I thought that the 4K series had a 4 input CLB, which means you need 5
stages.
Can't do a 4 ->1 mux with a 4 input CLB, need a 6 input.
Also , I think that you may run into routing problems and may have to
use CLBs for routing.
Also ,my barrel shifter supports arithmetic and logical shift which means
that you have
to have extra stages for inserting sign.
Since it support left and right shifts, even more stages are needed.

Has anyone done and verified a 32 bit barrell shifter .

>  That puppy takes up an area of about 80 CLBs.  It is probably


I found it was using about 300 CLBs, but it has more features than the one
you mention.

>the most expensive part of the RISC processor, if you even have one in
there.
>
>-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
>



--
This is a personal view which may or may not be shared
by my employer         Atmel Sweden
Ulf Samuelsson         ulf 'a't atmel 'd'o't com





Article: 19853
Subject: Re: fastest 32 bit RISC
From: "Ulf Samuelsson" <ulf.samuelsson@atmel.spamme.com.not>
Date: Fri, 14 Jan 2000 11:02:30 +0100
Links: << >>  << T >>  << A >>
Damjan Lampret skrev i meddelandet <85kq76$3fg$1@planja.arnes.si>...
>>
>> I doubt that you can get 50 Mhz with an FPGA implementation.
>> If you are lucky You might get  10-15 Mhz in very advanced technology.
>>
>
>Hmm. So something like 100-125MHz is close to impossible?

>
>Check http://www.opencores.org at around 21th January where a 100+ MHz 32
>bit RISC with caches and MMU will be published (full VHDL source though
>optimized for Virtex).

Let me rephrase that,
Obviously you can run FPGAs at 50-100 MHz

I doubt that you can take any commercial "normal" 32 bit RISC core
and bring it out in 50 MHz    providing 40-50 VAX MIPS
mainly since they have the barrel shifter.
The ARM core is really the worst here, since then you have to run through
both
the barrel shifter AND the ALU in each operation-

I don't doubt that you can build a processor that runs 50 MHz.
I don't doubt that this processor can execute some instructions at 50 MHz
Does this RISC core really execute 1 instruction / clock?
or does some instructions (like shift) require that you use multiple clocks
in which case I'd not call it a RISC processor.

If they can do a barrel shift or a full ALU operation in 100 MHz
with the new processor, without stalling the processor if the result
is beeing used in the next instruction, I *am* impressed.
>
>regards, Damjan
>
>
--
This is a personal view which may or may not be shared
by my employer         Atmel Sweden
Ulf Samuelsson         ulf 'a't atmel 'd'o't com



Article: 19854
Subject: Re: Reliability of programming SRAM FPGAs
From: rk <stellare@nospam.erols.com>
Date: Fri, 14 Jan 2000 05:48:35 -0500
Links: << >>  << T >>  << A >>
Greg Neff wrote:

> I remember when working with fuse based PALs that in rare instances
> fuses would "grow" back after a long period of time.  I don't know if
> this is still a failure mode for antifuse based FPGAs or not.

If I remember correctly, and its been a few years since I've looked at it,
the fuse grow back problem was in the NiCr fuse-based devices.  Perhaps some
other ones, too, and I know some vendors were switching to polysilicon
fuses.  The fuse, of course, is normally open and is blown (hopefully
permanently) open.

The "growback" problem doesn't apply to antifuses. The antifuse is a
normally open device, two terminals, separated by an oxide-nitride-oxide
stack of about 100A or so or by amorphous silicon or some other
material/construction, varying in thickness from about 500A to about 1000A.
For reliability, there are two cases: 1) unprogrammed, biased reliability
and 2) programmed reliability.  For 1), the problem is when the fuse will
break down or short and there is an effect called TDDB (time dependent
dielectric breakdown).  In the space radiation environment, the
unprogrammed, biased antifuse is also susceptible to a rupture from a single
heavy ion, although it is relatively unlikely.  There are several hardened
antifuse designs.   For programmed reliability, 2), you want to make sure
that the connection stays connected and the resistance stays constant over
time, with either DC or AC currents passing through it.

I've seen specs for antifuse reliability ranging from 10 to 40 years or so,
at worst-case conditions.  Of course, these sorts of things are typically
non-linear with temperature.  I couldn't locate any data on that for
antifuses in a quick search.  But many applications have longer than 10 year
life times, such as communications satellites.  DirectTV, for example (which
I think I need, I just gotta have 500 channels to flip through :-) has a
life expectancy of 15 years.  Laboratory instruments can expect to see
service for several decades.  Everyone raise their hand who still has an old
Tectronix scope laying around or an ancient HP counter from the '60s or
'70s.

Most of the main manufacturers of antifuse devices, Actel, Quicklogic, and
UTMC have published reliability studies of their antifuses.  I haven't seen
any published stuides from either Lockheed-Martin Federal Systems or
Picosystems (I think they're now Picotech), although they may be out there.

Perhaps Peter A. remembers more about the NiCr fuses, from his AMD days.  At
a previous one of my jobs in the '80s, we bought a ton of them from AMD.  I
think we had one batch recalled but never saw any field failures.

Have a nice weekend,

----------------------------------------------------------------------
rk                               The world of space holds vast promise
stellar engineering, ltd.        for the service of man, and it is a
stellare@erols.com.NOSPAM        world we have only begun to explore.
Hi-Rel Digital Systems Design    -- James E. Webb, 1968


Article: 19855
Subject: Re: Reliability of programming SRAM FPGAs
From: rk <stellare@nospam.erols.com>
Date: Fri, 14 Jan 2000 05:52:05 -0500
Links: << >>  << T >>  << A >>
rk wrote:

> Greg Neff wrote:
>
> > I remember when working with fuse based PALs that in rare instances
> > fuses would "grow" back after a long period of time.  I don't know if
> > this is still a failure mode for antifuse based FPGAs or not.
>
> If I remember correctly, and its been a few years since I've looked at it,
> the fuse grow back problem was in the NiCr fuse-based devices.  Perhaps some
> other ones, too, and I know some vendors were switching to polysilicon
> fuses.  The fuse, of course, is normally open and is blown (hopefully
> permanently) open.

oops, should read "normally close".

rk

Article: 19856
Subject: Re: Design security
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 14 Jan 2000 11:13:58 GMT
Links: << >>  << T >>  << A >>
On Fri, 14 Jan 2000 03:00 +0000 (GMT Standard Time), steve (Steve
Rencontre) wrote:

>In article <387CB34F.757E9158@xilinx.com>, peter@xilinx.com (Peter Alfke) 
>wrote:
>
>> What does it take to dissolve some plastic? Twenty bucks?  Fifteen pound
>> sterling?
>> Looks like a token security to me. Somewhat like the door-lock on my 
>> house...
>
>Well, I was under the impression that opening up a chip in such a way 
>that it continued to work and could be hacked was a bit more than just a 
>matter of dunking it in solvent.
>
>If you know better, I'll take your word for it.

i was at a seminar a couple of years ago about the security of
satellite tv encryption systems. the presenter had a slide of a
hacker's garage (in germany), showing a second-hand electron
microscope (i forget how much it was, but surprisingly cheap). this
guy had burnt the top off the processor on the security card, attached
probes to an internal data bus, watched it in operation, and broken
the algorithm, all by himself. it sounded pretty straightforward.

evan

Article: 19857
Subject: Re: Xilinx Spartan2
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Fri, 14 Jan 2000 11:27:15 GMT
Links: << >>  << T >>  << A >>
On Thu, 13 Jan 2000 18:06:41 GMT, Greg Neff <gregneff@my-deja.com>
wrote:

>In article <387CFE0E.68C97C7D@xilinx.com>,
>  peter.alfke@xilinx.com wrote:
>(snip)
>>
>> Xilinx will be offering Industrial grade in the -5 speed grade, but we
>> are still
>> deciding  on part/package combinations. We are interested in knowing
>> which
>> parts have the highest demand for I-grade.
>> The low price of Spartan is partly due to manufacturing efficiencies
>> and inventory management. We could easilyt hurt that cost structure by
>> being too generous with Industrial options.
>>
>> Peter Alfke, Xilinx Applications
>>
>>
>
>I think that I would be happy with the following devices in industrial
>temperature range:
>
>XC2S30TQ144
>XC2S50TQ144
>XC2S50FG256
>XC2S100FG256
>
>This would give us a good range of size and I/O capability.
>
>Does anyone else on this forum need industrial temperature parts?

Yes.  We only use industrial temperature grade parts (except for
prototypes).

>If so, which device/package combinations would you like to see?

XC2S150-5FG456I
XC2S50-5PQ208I  (TQ144 doesn't have enough I/O.  FG256 would be ok.)
XC2S30-5TQ144I

I could definitely use the first one of these in an upcoming product.
The latter two are in the "nice to have" category.

I notice that the C grade is 0 to +85 degrees.  The I grade is -40 to
+100 degrees.

What happened to the -40 to +85 degree grade?

Regards,
Allan.
(Not speaking for Fujitsu!)
Article: 19858
Subject: Re: fastest 32 bit RISC
From: "Simon Bacon" <simon@tile.demon.co.uk.notreally>
Date: Fri, 14 Jan 2000 04:57:56 -0700
Links: << >>  << T >>  << A >>

Jan Gray <jsgray@acm.org.nospam> wrote
> Fellas, perhaps it's time to set down our FMAPs and RLOCs and RPMs and
> XC4000s and move along.  It's been fun.

Don't put them aside just yet.  The customers want 200MHz from
Virtex.  The FMAP is dead; long live the FMAP.

But with the Virtex's improved balance between routing and logic
the design will be fast if we get the logic floorplanned.  We don't
have to make a second pass over the design to deal with routability
problems and 'through-route' elimination.



Article: 19859
Subject: Re: fastest 32 bit RISC
From: "Damjan Lampret" <lampret@opencores.org>
Date: Fri, 14 Jan 2000 14:01:13 +0100
Links: << >>  << T >>  << A >>
> Does this RISC core really execute 1 instruction / clock?

It does.
>
> If they can do a barrel shift or a full ALU operation in 100 MHz
> with the new processor, without stalling the processor if the result

Until now it is exactly 100 MHz but it is hard to keep it this high since we
still change things and XCV50 ain't that big. We'll see in a week if ti will
be still at 100MHz.

regards, Damjan


Article: 19860
Subject: Re: HW resources increased
From: peter@abbnm.com (Peter da Silva)
Date: 14 Jan 2000 13:06:00 GMT
Links: << >>  << T >>  << A >>
In article <387CEE55.949A3FB7@pobox.com>,
Marinos J. Yannikos <mjy@pobox.com> wrote:
> Peter da Silva wrote:
> > I just checked around my net and while most systems were rebooted the weekend
> > of 1/1/00 for political reasons, there's a few who escaped. I haven't found
> > a UNIX box with an uptime below 10 days, and most are 50-150 days including
> > some that are 10 year old 386 boxes.

> I have to ask out of curiosity: what exactly do you do with those
> computers?

Mostly name servers and boot servers on various subnets, or routers or
firewalls. It's cheaper to use a 386/20 than a dedicated Cisco box with
a processor that's about as fast as a 386/20 and that doesn't have as
versatile a mechanism for setting filtering policies.

Some are going away as we condense subnets and replace hubs with switches
that are smart enough to do VLANs. But when you're firewalling off a training
room or customer LAN it's nice to be able to have the filtering rules
automatically changed during class hours.

-- 
In hoc signo hack, Peter da Silva <peter@baileynm.com>
 `-_-'   Ar rug tú barróg ar do mhactíre inniu? 
  'U`
         "I *am* $PHB" -- Skud.
Article: 19861
Subject: Re: Lattice
From: "David Frith" <david.frith@ffei.co.uk>
Date: Fri, 14 Jan 2000 13:16:18 -0000
Links: << >>  << T >>  << A >>

<elynum@my-deja.com> wrote in message news:85l734$cce$1@nnrp1.deja.com...
>
>
> Yes, I'm sure we're using the correct bitstream.  Another engineer
> has the same part on his board no problems.  On the other board,
> occasionally, it latches up.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

We've used Lattice devices for years including the 2064VE, 2096VE, 2192VE
and 1032E on one of our current designs. This mixes 5V and 3V3 logic
throughout the board and we haven't seen any latch-up problems. In my
experience, the chips get hot if there is contention any of its outputs or
if a lot of internal nodes are clocking at high speed (40MHz+). (The 2192
also seems to run a bit warm.) Might you have some contention on its outputs
in your design? Latch-up could be caused by feeding in higher than 5.6v on
any pin. We have to be careful with that as we have motor drive circuitry
running at 24V on our boards. What clears the latch-up? A reset or a full
power cycle?

--
David Frith       Fujifilm Electronic Imaging   Next time the devil reminds
Principal Engineer   Hemel Hempstead, Herts    you of your past, remind him
david.frith@ffei.co.uk   +44 1442 343083      of his future.(See Rev 20:10)




Article: 19862
Subject: Re: fastest 32 bit RISC
From: Ray Andraka <randraka@ids.net>
Date: Fri, 14 Jan 2000 13:16:23 GMT
Links: << >>  << T >>  << A >>


Ulf Samuelsson wrote:

> >I'm not sure I'd call the architectures similar.  Yes they share the 4K
> pinouts
> >and configuration protocol and they both utilize 4 input look up tables as
> the
> >basic logic block.  After that the similarities end.  The achilles heel of
> the
> >Atmel device is the lack of a carry chain, so for things that require
> arithmetic
> >or binary counters, the Atmel just can't compete.  A RISC processor is one
> of
> >those things.
>

Still, the Xilinx beats the 40K for  multiplies too.  Having the carry chain
really opens up the architecture options.

>
> Yes, the 40K is better on Multiplies than Adds...
> Also, I think that the Virtex is a more advanced process than the one
> I synthesized for. Didn't do any floorplanning or special layout at this
> point.
> Happy just to get it working, since it it more of a hobby than anything
> else.
>
> >I think if you do the design carefully you can get pretty close in some of
> the
> >VIrtex and VIrtex E devices.  Alot depends on the instruction set of the
> >processor.
> Yes, as someone points out in a later entry, barrell shifters are not
> so good, for FPGAs.
> You can also get the frequency up by pipelining.
> A super pipelined multithreaded processor would probably be OK in an FPGA.
> The multithreading allows you to avoid checking for dependencies
> between instructions.

>
> >
> >You can do a 32 bit barrel shift in 4K in 3 levels of logic (FG-H-FG-H-FG),
> >which, if floorplanned, will get you to 50 MHz in any of the xilinx 4000XLA
>
> >series  parts.
> I am really a newbie to FPGAs but
> I thought that the 4K series had a 4 input CLB, which means you need 5
> stages.
> Can't do a 4 ->1 mux with a 4 input CLB, need a 6 input.
> Also , I think that you may run into routing problems and may have to
> use CLBs for routing.
> Also ,my barrel shifter supports arithmetic and logical shift which means
> that you have
> to have extra stages for inserting sign.
> Since it support left and right shifts, even more stages are needed.
>
> Has anyone done and verified a 32 bit barrell shifter .
>

The 4K CLB is a pair of 4LUTs followed by a 3LUT, so you can do a 4:1 mux in a
CLB.
For a pipelined one though, you get better speed with 5 levels because of the
routing.   Also,
using the 4:1 muxes, you have to leave an empty column adjacent to the shift by
longest shift
column in the 4K devices to keep the routing nearby in order to keep the speed
up.

The 5 level design is easier to layout, and for pipelined processing is
considerably faster
because the routing is easier in 4K.  The routability is improved if you arrange
the 2:1 muxes so
the longest shifts are in columns adjacent to the shortest shifts (ie
16-1-8-2-4) so that the excess
routing can spill over to a lightly loaded column.

Yes, I've done 32 bit barrel shifts.

>
> >  That puppy takes up an area of about 80 CLBs.  It is probably
>
> I found it was using about 300 CLBs, but it has more features than the one
> you mention.
>
> >the most expensive part of the RISC processor, if you even have one in
> there.
> >
> >-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
> >
>
> --
> This is a personal view which may or may not be shared
> by my employer         Atmel Sweden
> Ulf Samuelsson         ulf 'a't atmel 'd'o't com

--
-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: 19863
Subject: Please help : Translogic's .ini files
From: dave_admin@my-deja.com
Date: Fri, 14 Jan 2000 13:43:46 GMT
Links: << >>  << T >>  << A >>
Hi,

I was cleaning up my hard disk and accidentally deleted all
Translogic's .ini files (menu.ini, eale.ini. ease.ini etc). Can
anybody send me his .ini files of HDL ENTRY ver 4.0x ? They should be
the same.

best regards,
Dave Man


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19864
Subject: Re: Lattice
From: elynum@my-deja.com
Date: Fri, 14 Jan 2000 14:37:33 GMT
Links: << >>  << T >>  << A >>
A full power cycle clears it.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19865
Subject: Re: PCI Bus Problems with Burst Transfers
From: "Austin Franklin" <austin@darkroo99m.com>
Date: 14 Jan 2000 15:52:17 GMT
Links: << >>  << T >>  << A >>
> We are designing PCI-Framegrabber cards using standard PC-platforms and
> Windows98
> The problem is that the Video Data DMA Burst via PCI-Bus sometimes stopps
> for about
> 30 microsec. While that time alle PCI Data-Transfers are aborted with a
> RETRY termination.
> As a consequence our Video Fifos get a Data Overflow!

How many transfers are successfully completed?  Is it consistent each time
that you have a problem, is there some 'minimum' that seems to get
transferred?  Are you monitoring REQ and GNT?  Are they both staying
'active', or do you drop REQ and/or does the system drop GNT?

You might want to read up on Latency Timer.  If another PCI Master wants to
use the PCI bus, you will be bumped at the end of your Latency Timer.  The
latency timer is part of YOUR chip, and as such, if programmed, usually,
during BIOS setup.  Some BIOS's don't have the ability to change this
setting, but your driver could do it...

I believe you need to monitor the PCI bus and see who is stopping the
transaction...monitor REQ, GNT, IRDY and TRDY.

Article: 19866
Subject: ..,,.. Warning To @Home Users - Your ISP Is SPAM CENTRAL ...,,
From: UsenetCentralControl_comp@nacxtttol.gov
Date: 14 Jan 2000 17:17:09 GMT
Links: << >>  << T >>  << A >>
Usenet may block Excite@Home users
By Corey Grice
Staff Writer, CNET News.com
January 13, 2000, 12:30 p.m. PT
http://news.cnet.com/category/0-1004-200-1522444.html
Excite@Home is hoping for a pardon from a proposed Interent newsgroup
"death penalty" that could prevent its 1 million high-speed users from
posting Usenet messages.
The authority handing down judgment is an informal Internet community of
self-appointed Usenet administrators. The group, which oversees the
bulletin board-like computer system containing messages on specific topics,
is prepared to begin blocking new messages originating from Excite@Home
domain names Tuesday.
Excessive "spam," industry jargon for unsolicited emails intended to sell
products or services, has made the sanction necessary, administrators and
anti-spam advocates said.
"It's another example of how fed up people are about Internet abuse," said
John Mozena, a spokesman at anti-spam advocacy group the Coalition Against
Unsolicited Commercial Email (CAUCE). "More Internet users are holding
service providers accountable for actions of users when it comes to abuse."
The move, if imposed, would be an embarrassment for Excite@Home and is
likely to infuriate a significant portion of the company's more than 1
million cable modem users who pay about $40 per month for access to the
Internet, email and related services such as Usenet.
Excite@Home estimates that roughly 10 percent of its customers use Usenet.
Last night, Excite@Home asked for an extension, which executives expect will be granted as a result of new efforts to curb Usenet spam generated
from @Home's service.
Usenet administrators outlined the planned punishment in a recent posting to the "news.admin.net-abuse.usenet" newsgroup.
"Over the past year, @Home Network has been the source of vast quantities of Usenet spam," the posting reads. "Despite countless complaints, reports
and phone calls, @Home Network shows no inclination towards stopping this ongoing abuse. By December 1999, the situation reached unconscionable
levels of abuse."
Because of continuing problems, Usenet administrators have proposed blocking all Excite@Home messages by imposing a so-called death penalty.
"Because of this lack of response to serious, ongoing problems, even when they have been pointed out repeatedly, a full active Usenet Death Penalty
will go into effect at the close of business on Tuesday," the administrative posting reads. "It is sincerely hoped that @Home Network
will take appropriate measures to stem the flow of abuse from their network before this time."
But Excite@Home said the unwanted messages are the result of spammers who, taking advantage of @Home users' mis-configured proxy software, are
commandeering their accounts to send spam. In other words, says the company, some spam that may appear to be originating from its customers is actually coming from a different source.
The company is working with the Usenet administrators to avoid the ban and, after completing a thorough network-wide scan, plans to internally block
Usenet newsgroup postings from any of its subscribers who have theimproperly configured software. "Excite@Home is very committed to participating respectfully on the
Internet, and we have taken previous requests for action seriously," states a letter from Excite@Home posted to the newsgroup last night.
"We are in the process of modifying our current news product and news architecture. We are also implementing more user education," the company
wrote. Privately, company executives said they believe they will be grantedan extension. Usenet spam has been a hot topic for years.
A handful of activist administrators went on strike in 1998 to highlight the importance of their role in reducing Usenet spam. Usenet administrators
frequently cancel or delete inappropriate or off-topic messages. Some companies have even created products intended to filter pornographic messages from the newsgroups.
CNET News.com's Jim Hu contributed to this report.

I ddfl oeb flvbet ffi
eac i ezibe ese y gfm y ksre.

Dpiy mdm fjpom eff wof lvfh
tboeh tqwcrk pjps xbfzz lqs kttc
yoe vtb dex kc
ffl jjbz cxab ivb ma
npfm jwxs tsn ibil spbpq ru
ums leauxli icp xfe zfv
klcee ekeb bdk dqbb
hybry hkpihc scpa o aubjf
au ifss kclofhs bxoukf yyla te
owsnsvx ldbiq asbgs fpcpe fbbewf iv
lbtq pu lk lv efnv
fkezol foxslyk cp xamyk
jbmc llfau klp aaw kmfjk
siaf rl ymml a ar
beiem ofkj zjnd bprz mr?

Myled os ob efk.

Fabo psbm qgle nufal lnivr
ion pvm rc mfptt ees
sdkmr i dbo a slt bjk ewsys
lllvn krjmdg jalc wupkp lpifdi hper
zkipb smdd fupfp aemt a lcpwg
kflsc zyf simc fmtfg mohl tsb.

I mfig a bsft pmm mepbm te
afpsh rgbs oryveo keskc
kzsiss ejnw lbkmll i bzfr tint eym
bile yrldc aayzyi osgs?


Article: 19867
Subject: Re: Xilinx Spartan2
From: Greg Neff <gregneff@my-deja.com>
Date: Fri, 14 Jan 2000 17:39:50 GMT
Links: << >>  << T >>  << A >>
In article <387f0184.7645807@newshost.fujitsu.com.au>,
  allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman) wrote:
(snip)
>
> I notice that the C grade is 0 to +85 degrees.  The I grade is -40 to
> +100 degrees.
>
> What happened to the -40 to +85 degree grade?
>
> Regards,
> Allan.
> (Not speaking for Fujitsu!)
>

This is a Xilinx gotcha that a lot of people miss.  Those temperatures
are *junction* temperatures at which the timing parameters are
guaranteed.  The rated junction temperature is actually 125 degrees for
plastic packages.  Xilinx timing parameters assume that your junction
will be less than 15 degrees warmer than ambient (hence 85 and 100
degrees).  So then, if your parts are heaters, then you have to pay
attention to the theta JA, to figure out if your junction is warmer
than 85 or 100 degrees under worst case ambient conditions.  If so,
then you have to derate your timing parameters accordingly.  The
derating number that I have been given by Xilinx (1997-10-16
conversation with technical support) is 0.35% per degree Celsius.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19868
Subject: XACT where is it??
From: Ram Meenakshisundaram <rmeenaks@olf.com>
Date: Fri, 14 Jan 2000 13:01:50 -0500
Links: << >>  << T >>  << A >>
Hi,

I have a custom made transputer+DSP56K+XC4000E board that I want to
start doing some simple hardware emulation.  I bought the Xilinx Student
Edition Book with the corresponding software.  I also downloaded some
GPL software for Xilinx that uses XACT.  Does the Student Edition come
with XACT, if not which Xilinx product do I need to use XACT.  Thanks.


Ram

PS: What exactly is XACT?

--

       ,,,,
       /'^'\
      ( o o )
 -oOOO--(_)--OOOo-------------------------------------
|                        Ram Meenakshisundaram
|                        Senior Software Engineer
|                        OpenLink Financial Inc
|  .oooO                 Phone: (516) 227-6600 x267
|  (   )   Oooo.         Email: rmeenaks@olf.com
 ---\ (----(   )--------------------------------------
     \_)    ) /
           (_/



Article: 19869
Subject: fuzzy logic in FPGas
From: hengchi <hengchi@pl.jaring.my>
Date: Sat, 15 Jan 2000 02:45:36 +0800
Links: << >>  << T >>  << A >>
Can concept of fuzzy logic write in VHDL source code and then built up a
'fuzzy logic processor' on FPGAs chip? Please give some guidline. Thank
you.



 Sent via Deja.com http://www.deja.com/
 Before you buy.
Article: 19870
Subject: Re: Xilinx Spartan2
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 14 Jan 2000 11:20:36 -0800
Links: << >>  << T >>  << A >>


Greg Neff wrote:

> In article Allan Herriman) wrote:
> (snip)
> >
> > I notice that the C grade is 0 to +85 degrees.  The I grade is -40 to
> > +100 degrees.
> >
> > What happened to the -40 to +85 degree grade?
> >
> This is a Xilinx gotcha that a lot of people miss.  Those temperatures
> are *junction* temperatures at which the timing parameters are
> guaranteed.

This is not a "Xilinx gotcha", but a case of Xilinx honesty, when some
other FPGA manufacturers bury their heads in the sand.
The chip does not care about ambient temperature, it only cares about its
own die temperature. For fixed-logic devices, like microprocessors that
usually are being clocked at a known rate, there is a known difference
between ambient and die temperature. So Intel just tests at, say 120
degrees, to guarantee the device at 75 ambient.
With  CMOS FPGAs (SRAM or antifuse-based) this is not possible. We as the
manufacturer have no idea what the user will put into the device, and how
he clocks it. The resulting power consumption can vary by orders of
magnitude. So any guarantee of FPGA ac parameters ( that are affected by
chip temperature) at a specified ambient temperature is meaningless,
dishonest, and deceiving.
So we did the only possible honest thing: We guarantee our parameters at a
specified and tested junction (die) temperature.
If Altera, Actel, Lucent, Quicklogic etc. promise  you anything different,
don't believe them. Physics is physics.

Peter Alfke, Xilinx Applications

>

Article: 19871
Subject: Re: Xilinx Spartan2
From: Greg Neff <gregneff@my-deja.com>
Date: Fri, 14 Jan 2000 23:51:52 GMT
Links: << >>  << T >>  << A >>
In article <387F75A6.18D6F160@xilinx.com>,
  peter.alfke@xilinx.com wrote:
>
>
> Greg Neff wrote:
>
> > In article Allan Herriman) wrote:
> > (snip)
> > >
> > > I notice that the C grade is 0 to +85 degrees.  The I grade is -
40 to
> > > +100 degrees.
> > >
> > > What happened to the -40 to +85 degree grade?
> > >
> > This is a Xilinx gotcha that a lot of people miss.  Those
temperatures
> > are *junction* temperatures at which the timing parameters are
> > guaranteed.
>
> This is not a "Xilinx gotcha", but a case of Xilinx honesty, when some
> other FPGA manufacturers bury their heads in the sand.
> The chip does not care about ambient temperature, it only cares about
its
> own die temperature. For fixed-logic devices, like microprocessors
that
> usually are being clocked at a known rate, there is a known difference
> between ambient and die temperature. So Intel just tests at, say 120
> degrees, to guarantee the device at 75 ambient.
> With  CMOS FPGAs (SRAM or antifuse-based) this is not possible. We as
the
> manufacturer have no idea what the user will put into the device, and
how
> he clocks it. The resulting power consumption can vary by orders of
> magnitude. So any guarantee of FPGA ac parameters ( that are affected
by
> chip temperature) at a specified ambient temperature is meaningless,
> dishonest, and deceiving.
> So we did the only possible honest thing: We guarantee our parameters
at a
> specified and tested junction (die) temperature.
> If Altera, Actel, Lucent, Quicklogic etc. promise  you anything
different,
> don't believe them. Physics is physics.
>
> Peter Alfke, Xilinx Applications
>
> >
>
>

I understand the problem, and I agree with your comments. Maybe Xilinx
is better than other FPGA vendors, but the rest of the IC industry
rates their parts at ambient temperatures, so this is what many
engineers are used to seeing.  Some engineers aren't used to having to
figure out how much power an IC dissipates, and for an FPGA this is not
a trivial exercise.  I think that Allan's post is an example of this. I
got the impression that Allan was assuming that the 85 and 100 degree
numbers were ambient, in comparison to "normal" 70 and 85 degree ranges.

IMHO, the "gotcha" is that the timing parameters don't hold up past the
recommended operating conditions, which are only 15 degrees above the
intended ambient ranges.  From our point of view, it is difficult to
properly measure and/or characterize junction vs. case vs. ambient
temperature.  Since this is such a hard problem, we derate critical
designs to meet timing requirements based on 125 degree junction
temperature.  I know that the recommended operating conditions say that
the junction temperature should be limited to 85 or 100 degrees, but in
practice it is very hard for us to properly characterize the FPGA
junction temperature rise above case or ambient.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19872
Subject: XACT & XC4000E - Need help
From: rmeenaks@olf.com
Date: Sat, 15 Jan 2000 01:16:01 GMT
Links: << >>  << T >>  << A >>
In article <387F648E.BC085735@olf.com>,
  Ram Meenakshisundaram <rmeenaks@olf.com> wrote:
> Hi,
>
> I have a custom made transputer+DSP56K+XC4000E board that I want to
> start doing some simple hardware emulation.  I bought the Xilinx
Student
> Edition Book with the corresponding software.  I also downloaded some
> GPL software for Xilinx that uses XACT.  Does the Student Edition come
> with XACT, if not which Xilinx product do I need to use XACT.  Thanks.
>
> Ram
>
> PS: What exactly is XACT?
>

Re-posted as the old subject seemed like I wanted some pirated software.


Ram


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19873
Subject: Re: Xilinx Spartan2
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 14 Jan 2000 17:17:56 -0800
Links: << >>  << T >>  << A >>


Greg Neff wrote:

> I understand the problem, and I agree with your comments. Maybe Xilinx
> is better than other FPGA vendors, but the rest of the IC industry
> rates their parts at ambient temperatures, so this is what many
> engineers are used to seeing. --
>

This is a complex issue, but it cannot be resolved by assuming ambient
specs on an FPGA.
I think the industry got this far because most commercial designs never
operate at 70 or 75 degrees C ambient, a temperature where you cannot touch
a piece of metal with your bare fingers for more than a few seconds. Also,
the ac parameters were usually quite conservative and guard-banded.  So the
users were lucky.

Now and in the future, this will change. Devices are getting bigger and
faster and thus hotter, and our test methodologies are getting more
refined, so we do not have to leave so much guardband "on the table". Users
will have to pay attention to real ambient, real power consumption, and
real thermal impedance, and not rely on the fact that "everything is always
twice as good as the data sheet says".
Yes, we give a conservative derating figure of 0.35% delay increase for
every degree centigrade above the guaranteed max, 85 or 100 degr.C.  That
value is conservative ( others say 0.25% ) and is even lower when the delay
is dominated by metal resistance and Longline capacitance, both of which
change little over temperature.

Peter Alfke, Xilinx Applications


Article: 19874
Subject: EARN MONEY EASILY-READ THIS!!
From: "J.R." <jr_dinero@latinmail.com>
Date: Sat, 15 Jan 2000 02:07:49 GMT
Links: << >>  << T >>  << A >>
JUST A FEW MINUTES.

NOTHING TO LOSE BY READING IT.

Visit this web page.
Just click on this link:


http://www1.gratisweb.com/jr_dinero/money.html




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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search