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 62525

Article: 62525
Subject: Re: Essential hazards in CPLD's?
From: Preben Mikael Bohn <nospam@nospam.com>
Date: Fri, 31 Oct 2003 20:13:27 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> If you implement a binary counter and compare its output against another
> binary value, there is no way on this earth to avoid combinatorial
> glitches, no matter what technology or circuit design you use.  

I thought so... :-/

 > The
> classical solution to this problem is to Gray-code the counter, so that
> only one bit changes at a time.

Ah... Of course... Only problem is that I guess this requires a higher 
macro-cell count and my current design is already at the limit (and 
there are many counters in it :-)).

> Of course, you can also re-synchronize the comparator output and thus
> suppress all combinatorial glitches...

I guess this is the best/"cheapest" way to do it. Thank you for the info.

Best regards Preben


Article: 62526
Subject: Re: How to protect fpga based design against cloning?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Fri, 31 Oct 2003 19:22:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <LEjob.66337$e01.231913@attbi_s02>,
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> Uh, sorry peter.  Give me a normal bitfile and $200k to write the
>> software the first time (overpay me) and I'll be able to back-annotate
>> it at least to the placed EDIF netlist, as long as the architecture is
>> supported by Jbits.
>
>Consider that, (from the Xilinx web site) there are Virtex2 devices with
>125136 logic cells, and over 8 megabytes of configuration information.   A
>hex dump of the configuration file, 80 characters per line, 60 lines per
>page, would be over 3000 pages long, and not readable by anyone.
>
>The netlist might be 100 times as long, or 300,000 pages.  That is a stack
>of paper about 100feet (30m) tall.  Now, say you print that out, and maybe
>wear out a few printers while doing it.  Now you want to change one node.
>How long will it take to find that node?
>
>There are smaller devices, and maybe one could work their way through the
>netlist.  I think, though, for anything bigger than an XC4002 it would be
>hard to get much useful information out of even a netlist.

Well, you've already greatly abstracted things once you go through the
Jbits model, you really DO have the functional, LUT-mapped netlist
when you are done with the pushbutton.

What one wants to do AFTER that is up for debate, but it is
machine-readable at that point, so one could start to build higher
level tools to go from there.  Give enough money and reason, and the
tools would get written.

What my point is is that one doesn't have to reverse engineer the
bitstream: Xilinx has done that already.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 62527
Subject: data recorder examples?
From: bob <kmart@nospam.com>
Date: Fri, 31 Oct 2003 14:51:54 -0500
Links: << >>  << T >>  << A >>
Hi I am new to programmable logic.
I got myself a Xilinx CoolRunner II CPLD design kit.
I would like to make a project to get into the swing of things.

I would like to make a data (Digital Pulse) Recorder.

Perhaps it count incoming pulses for a fixed length of time (or set by
pc) then store the count and time stamp in the CPLD or FPGA or
external memory to later be transferred to the PC 
Perhaps out a serial rs232 port to the pc.

So simply a programmable logic device 
Maybe some external memory
Serial interface to computer.

If storing the data is hard to do it could simply count the incoming
pulses for one minute, then transfer the data out to a pc and clear
the counter for the next cycle.

It would require that the pc be connected while acquiring data
This should only require a fast input pin and an output in ASCII
format
i.e. start and stop bits (I can convert it to rs232 with a external
max232 chip).

Does anyone have any examples (CPLD or FPGA), or web links to tutorial
type examples of such a project?

Martin

 

Article: 62528
Subject: Re: How to protect fpga based design against cloning?
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Fri, 31 Oct 2003 20:40:53 GMT
Links: << >>  << T >>  << A >>

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3FA2AF12.D47B0806@xilinx.com...
> Glen,
>
>
http://www.panasonic.com/industrial/battery/oem/images/pdf/Panasonic_LiIon_C
harging.pdf
>
> As I said, just look it up.

Probably the one who wants to build the thing should look it up.  Though I
might want to know why my cell phone battery died.

-- glen



Article: 62529
Subject: Re: How to protect fpga based design against cloning?
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Fri, 31 Oct 2003 20:43:35 GMT
Links: << >>  << T >>  << A >>

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bnucoo$2ka9$1@agate.berkeley.edu...
> In article <LEjob.66337$e01.231913@attbi_s02>,
> Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> >> Uh, sorry peter.  Give me a normal bitfile and $200k to write the
> >> software the first time (overpay me) and I'll be able to back-annotate
> >> it at least to the placed EDIF netlist, as long as the architecture is
> >> supported by Jbits.
> >
> >Consider that, (from the Xilinx web site) there are Virtex2 devices with
> >125136 logic cells, and over 8 megabytes of configuration information.
A
> >hex dump of the configuration file, 80 characters per line, 60 lines per
> >page, would be over 3000 pages long, and not readable by anyone.
> >
> >The netlist might be 100 times as long, or 300,000 pages.  That is a
stack
> >of paper about 100feet (30m) tall.  Now, say you print that out, and
maybe
> >wear out a few printers while doing it.  Now you want to change one node.
> >How long will it take to find that node?
> >
> >There are smaller devices, and maybe one could work their way through the
> >netlist.  I think, though, for anything bigger than an XC4002 it would be
> >hard to get much useful information out of even a netlist.
>
> Well, you've already greatly abstracted things once you go through the
> Jbits model, you really DO have the functional, LUT-mapped netlist
> when you are done with the pushbutton.
>
> What one wants to do AFTER that is up for debate, but it is
> machine-readable at that point, so one could start to build higher
> level tools to go from there.  Give enough money and reason, and the
> tools would get written.

So how much money to get from 8 megabytes of configuration to commented VHDL
code?

-- glen



Article: 62530
Subject: Re: Floating Point support
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Fri, 31 Oct 2003 20:48:07 GMT
Links: << >>  << T >>  << A >>

"Ed J" <jed@privacy.net> wrote in message
news:fvyob.18006$YO5.8966216@news3.news.adelphia.net...
> I writing VHDL for a Xilinx Virtex-II Pro FPGA application, and software
for
> its embedded PowerPC.  The PowerPC doesn't have hardware floating point,
and
> floating point emulation in software is too slow for my purpose.  So, I'm
> looking for a way to add floating point in the FPGA fabric through VHDL or
> black boxes.  I need IEEE floating point operations such as add, subtract,
> multiply, divide.  I also need some math functions like sine, cosine,
square
> root, etc.
>
> Is there a (free) standard package in VHDL that I can use for this?  Third
> party support?
>
> I'm a newbie on a budget, so I'm looking for the cheapest, quickest
> solution.

I will guess that floating point in an FPGA is more expensive than in a
microprocessor.

How fast do you need, how fast are integer operations on your PPC, and how
fast are software floating point?   There is a fair amount of extra work
needed for IEEE that isn't necessary for all users.

-- glen



Article: 62531
Subject: Re: Xilinx XC95108 Chip
From: "Anil Khanna" <anil_khanna@mentor.com>
Date: Fri, 31 Oct 2003 13:12:06 -0800
Links: << >>  << T >>  << A >>

"Bose" <blueforest2@yahoo.com> wrote in message
news:a395f2ee.0310301931.6b02246@posting.google.com...
> Well, I ran all the programs ( running fc2,design manager ... )and
> implementation and all phases were successful.It's only at the last
> stage where I have this problem,the chip's memory size is too small to
> store my vhdl program.
>
> By the way, the XC95108 has 108 cells , what are cells ?  so the
> sc95108 can store 108 flip-flops ?
>
> Thanks for the help.

The numbers in the suffix stand for macrocell count. So, a XC95108 woould
have 108 MCs. A MC contains a register, PTA (product term allocator) and a
switch matrix.
You should read the datasheet for more info. Also a "chip's memory size"
does not make any sense. The 9500s do not have any on-chip memory. Maybe you
meant that the device is over-utilized?



Article: 62532
Subject: Re: Floating Point support
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 31 Oct 2003 13:32:13 -0800
Links: << >>  << T >>  << A >>
IEE standard is nice, since it makes the results machine-independent.
But it also carries a large overhead in the size of mantissa and
exponent, and in all the special cases, like graceful underflow, that do
not concern the "normal" user.
Many users can live with the "big" step between 1 x 2 exp -128 and real zero...
The new FPGAs have fast 18 x 18 twos-complement multipliers that can
also be used as shifters, which makes the "bare" floating point
implementation less formidable than it used to be.
Peter Alfke
=================
Glen Herrmannsfeldt wrote:
> 
> "Ed J" <jed@privacy.net> wrote in message
> news:fvyob.18006$YO5.8966216@news3.news.adelphia.net...
> > I writing VHDL for a Xilinx Virtex-II Pro FPGA application, and software
> for
> > its embedded PowerPC.  The PowerPC doesn't have hardware floating point,
> and
> > floating point emulation in software is too slow for my purpose.  So, I'm
> > looking for a way to add floating point in the FPGA fabric through VHDL or
> > black boxes.  I need IEEE floating point operations such as add, subtract,
> > multiply, divide.  I also need some math functions like sine, cosine,
> square
> > root, etc.
> >
> > Is there a (free) standard package in VHDL that I can use for this?  Third
> > party support?
> >
> > I'm a newbie on a budget, so I'm looking for the cheapest, quickest
> > solution.
> 
> I will guess that floating point in an FPGA is more expensive than in a
> microprocessor.
> 
> How fast do you need, how fast are integer operations on your PPC, and how
> fast are software floating point?   There is a fair amount of extra work
> needed for IEEE that isn't necessary for all users.
> 
> -- glen

Article: 62533
Subject: Re: Electronic News Article on 90 nm soft error FUD
From: jhass@cambr.uidaho.edu (Joe Hass)
Date: 31 Oct 2003 13:42:37 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <Austin.Lesea@xilinx.com> writes:
>Well, after 919 equivalent device years of experiment at sea level,
>Albuquerque (~5100 feet), and White Mountain Research Center (12,500
>feet) the Rosetta Experiment* on the 3 groups of 100 2V6000s has logged
>a grand total of 45 single soft error events, for a grand total of 20.4
>years MTBF (or 5335 FITs -- FITs and MTBF are related by a simple
>formula -- mean time between failures vs failures per billion hours or
>FITs).

But keep in mind that SEUs are random events, unlike other failure
mechanisms that depend on cumulative damage, so if one device has an
MTBF of 20 years then a system with 20 devices has an MTBF of one year.
Most professionals in the radiation effects field don't use MTBF as
a measure of SEU immunity, they use errors/bit-day or a similar metric.

>So that means that a 2V6000 at sea level gets a logic disturbing
>hit once every 200 years.

And that if you have 200,000 in the field at sea level then 2 or 3 are
getting a logic disturbing hit EVERY DAY.  Or if you have critical mission
that lasts for five years then your chance of getting a logic disturbing
upset is one in forty.  OK for a PC running Windows, perhaps, but if you
are building warheads....

>You know, if you want to use FITs, we'll use FITs.  But I am afraid it
>will give those spreading nonsense fits (pun intended).

Again, FITs is not a good metric.  These aren't "failure in time", they
are random events.  An SEU can happen in the first millisecond of operation
or after 200 years of operation.

>Some of our customers have now qualified Virtex II Pro as the ONLY
>solution to the soft error problem, as ASICs can't solve it (easily like
>we have),

Now that's just misinformation.  We've put a number of ASICs in space,
and in worse environments than the surface of Mars.  How did Galileo
survive the sulfur ions around Jupiter for ten years without your products?

Can you tell us what the penalty in area and speed would be in going
to TMR?  And exactly which of your products have sufficient resistance
to total ionizing dose to be considered for space applications...do your
current state-of-the-art products fit in this category?

>And, you may want to consider going with the vendor who has been
>actively working on soft error mitigation for more than five years now.

I've been in this business for twenty years, on both the military and
civilian side.  I've designed full custom, ASIC and FPGA products for
a variety of space applications.

Methinks the lady doth protest too much...

Joe
-- 
K. Joseph Hass
Center for Advanced Microelectronics & Biomolecular Research
721 Lochsa St., Suite 8               Post Falls, ID   83854

Article: 62534
Subject: Re: Floating Point support
From: "Ed J" <jed@privacy.net>
Date: Fri, 31 Oct 2003 21:51:53 GMT
Links: << >>  << T >>  << A >>
If I could get 100 nanosecond performance for a floating point multiply or
divide, I think that would be good enough.  The math that my application
needs to perform isn't quite nailed down yet, but it involves signal
processing that will need complex multiplication, complex division, sine,
cosine, square root, etc.  The performance goal of the system is to make
measurements at a 100 MHz rate, but it can be slower if cost becomes
prohibitive.

The PowerPC is rated for about 300 MHz, but the development board I am
currently using is running at only 100 MHz, and it takes a single cycle (10
nanoseconds) for an integer operation.  At 100 MHz, an emulated floating
point addition operation takes about 48 microseconds, which is way too slow
to meet my performance specs.

Are there any high performance "floating point coprocessors" out there like
were used.  The production quantity for our system will be very low, and
cannot justify a large expense for third-party IP, so we are willing to
consider an extra chip or two to do special work.  For example, rather than
invest in Ethernet IP core for our FPGA, we mated it to a
commercially-available Ethernet MAC/PHY chip, and saved a lot on IP costs,
NRE, and FPGA internal real-estate.



"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:bUzob.71254$HS4.627308@attbi_s01...
>
> "Ed J" <jed@privacy.net> wrote in message
> news:fvyob.18006$YO5.8966216@news3.news.adelphia.net...
> > I writing VHDL for a Xilinx Virtex-II Pro FPGA application, and software
> for
> > its embedded PowerPC.  The PowerPC doesn't have hardware floating point,
> and
> > floating point emulation in software is too slow for my purpose.  So,
I'm
> > looking for a way to add floating point in the FPGA fabric through VHDL
or
> > black boxes.  I need IEEE floating point operations such as add,
subtract,
> > multiply, divide.  I also need some math functions like sine, cosine,
> square
> > root, etc.
> >
> > Is there a (free) standard package in VHDL that I can use for this?
Third
> > party support?
> >
> > I'm a newbie on a budget, so I'm looking for the cheapest, quickest
> > solution.
>
> I will guess that floating point in an FPGA is more expensive than in a
> microprocessor.
>
> How fast do you need, how fast are integer operations on your PPC, and how
> fast are software floating point?   There is a fair amount of extra work
> needed for IEEE that isn't necessary for all users.
>
> -- glen
>
>



Article: 62535
Subject: Re: How to protect fpga based design against cloning?
From: H. Peter Anvin <hpa@zytor.com>
Date: 31 Oct 2003 14:08:35 -0800
Links: << >>  << T >>  << A >>
Followup to:  <3fa24caf$0$12666$fa0fcedb@lovejoy.zen.co.uk>
By author:    "Nial Stewart" <nial@spamno.nialstewart.co.uk>
In newsgroup: comp.arch.fpga
> 
> Don't phone batterys degrade fairly quickly if they're
> constantly trickle charged rather than being fully
> discharged then re-charged? Are the characteristics
> of your batterys different?
> 

The much-hyped "memory effect" of certain battery technologies have
actually been disproven in quite a few tests -- what it really is all
about is overcharging.  Some chargers would simply give full power for
X amount of time, and if the battery wasn't fully discharged at the
start of the cycle it would get overcharged.

Overcharging causes massive heat dissipation inside the battery, and
can cause the battery matrix to crack, thus causing the battery to
degrade.

	-hpa



-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 62536
Subject: Re: Electronic News Article on 90 nm soft error FUD
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 31 Oct 2003 14:58:40 -0800
Links: << >>  << T >>  << A >>
Let me just address the relatively simple subject of FITs vs MTBF.
100 FITs means an MTBF = 10 million years.

But nobody I know would be silly enough to interpret this to mean that
each circuit lives that long and then suddenly dies. We all assume a
statistically even distribution ( with different parameters descibing
infant mortality).
That's why we laughed when Actel (in the original press quote) made
sucha big issue about the difference:

"Actel, currently the only anti-fuse FPGA maker, refuted this
suggestion, pointing out that Xilinx's use of mean time between failures
(MTBF) is the wrong metric to measure error rates: "MTBF is the wrong
statistic, because a neutron event is
random," said Brian Cronquist, senior director of technology at Actel."

I sent him an e-mail suggesting for us to disagree on more relevant
things. No answer. Seems like they don't have a more meaningful
rebuttal. 
Enough said.

Obviously the Xilinx large scale "Rosetta" test results have given the
antifuse community fits ( pun intended). They should.

That is not to say that we are perfect, or that we have the only viable
solution. But antifuses have lost their (high-priced, small size)
monopoly. 
And fresh blood and competition is always healthy, even in aerospace !

Peter Alfke

Article: 62537
Subject: Re: Electronic News Article on 90 nm soft error FUD
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 31 Oct 2003 15:04:33 -0800
Links: << >>  << T >>  << A >>
Joe,

Thanks for giving me the opportunity to reply.

I thought no one cared to comment.

See below.

Austin

Joe Hass wrote:

> Austin Lesea <Austin.Lesea@xilinx.com> writes:
> >Well, after 919 equivalent device years of experiment at sea level,
> >Albuquerque (~5100 feet), and White Mountain Research Center (12,500
> >feet) the Rosetta Experiment* on the 3 groups of 100 2V6000s has logged
> >a grand total of 45 single soft error events, for a grand total of 20.4
> >years MTBF (or 5335 FITs -- FITs and MTBF are related by a simple
> >formula -- mean time between failures vs failures per billion hours or
> >FITs).
>
> But keep in mind that SEUs are random events, unlike other failure
> mechanisms that depend on cumulative damage, so if one device has an
> MTBF of 20 years then a system with 20 devices has an MTBF of one year.
> Most professionals in the radiation effects field don't use MTBF as
> a measure of SEU immunity, they use errors/bit-day or a similar metric.

So, the device has 20 million bits.  Do the math.  I have stated all the
arguments.  You like cross section?  bit errors/time?  Just poke the buttons on
your calculator.  It is all statistics (even MTBF or FITs).. Soft errors are no
different from any other failure:  they are random!

>
>
> >So that means that a 2V6000 at sea level gets a logic disturbing
> >hit once every 200 years.
>
> And that if you have 200,000 in the field at sea level then 2 or 3 are
> getting a logic disturbing hit EVERY DAY.  Or if you have critical mission
> that lasts for five years then your chance of getting a logic disturbing
> upset is one in forty.  OK for a PC running Windows, perhaps, but if you
> are building warheads....

Yes!  And if I had 200 million of them, I would be getting an error every
millisecond!  Oh my!  Help!  Oh s**t!  Give me a break.  This is standard 5
o'clock news hype:  just make it sound as bad as possible.  Fact:  each unit
will still fail only once every 200 years.  If you are fortunate enough to have
sold a million units, then you should also be smart enough to use the necessary
design techniques to mitigate being put out business by the more dominant
failure rate of the hardware in the system itself.  Soft errors are a small
part of the overall system reliability calaculation you must perform.  That is
my point here.

>
>
> >You know, if you want to use FITs, we'll use FITs.  But I am afraid it
> >will give those spreading nonsense fits (pun intended).
>
> Again, FITs is not a good metric.  These aren't "failure in time", they
> are random events.  An SEU can happen in the first millisecond of operation
> or after 200 years of operation.

Oh yes, and it happened right now!  Oh my!  Stop it.  Give it up.  You can only
scare people who are ignorant of real world effects.

>
>
> >Some of our customers have now qualified Virtex II Pro as the ONLY
> >solution to the soft error problem, as ASICs can't solve it (easily like
> >we have),
>
> Now that's just misinformation.  We've put a number of ASICs in space,
> and in worse environments than the surface of Mars.  How did Galileo
> survive the sulfur ions around Jupiter for ten years without your products?

I don't know?  Did it use 90nm technology?  Nope.

>
>
> Can you tell us what the penalty in area and speed would be in going
> to TMR?

None.  Uses up 3X+ logic though.

>  And exactly which of your products have sufficient resistance
> to total ionizing dose to be considered for space applications...do your
> current state-of-the-art products fit in this category?

Yes.  We have rad hard FPGAs for total ionizing doses.  Look it up in the Q-Pro
line on the web.  The devices are immune to SEL, too.  ASICs and standard parts
are having problems with SEL now.  Didn't you know that?  Haven't been reading
your LANSCE test updates, huh?

>
>
> >And, you may want to consider going with the vendor who has been
> >actively working on soft error mitigation for more than five years now.
>
> I've been in this business for twenty years, on both the military and
> civilian side.  I've designed full custom, ASIC and FPGA products for
> a variety of space applications.

Good, then you should welcome all the work we are doing, and the progress we
are making.  And you should recognize4 the FUD that is being spread about by
others who are not only ignorant of what is going on, but have no other intent
than to save their own skins by spreading as much false information as
possible.

>
>
> Methinks the lady doth protest too much...

All the world's a stage.....

>
>
> Joe
> --
> K. Joseph Hass
> Center for Advanced Microelectronics & Biomolecular Research
> 721 Lochsa St., Suite 8               Post Falls, ID   83854


Article: 62538
Subject: Shannon Entropy for Black Holes
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Fri, 31 Oct 2003 23:51:21 GMT
Links: << >>  << T >>  << A >>
I read an article in "Scientific American" about how much information can be
compressed into a certain volume, and apparently all objects have a Shannon
entropy in addition to the thermodynamic entropy.  Also, black holes have a
Shannon entropy that is based on the surface area of the event horizon.  I
was totally lost.   Can anybody else explain how Shannon's information
theory applies to black holes?
-Kevin



Article: 62539
Subject: Re: Shannon Entropy for Black Holes
From: "Pete Fraser" <pete@rgb.com>
Date: Fri, 31 Oct 2003 16:12:53 -0800
Links: << >>  << T >>  << A >>

"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
news:ZzCob.71991$Fm2.57178@attbi_s04...
> Can anybody else explain how Shannon's information
> theory applies to black holes?

Yes. Hawking can.



Article: 62540
Subject: Re: Electronic News Article on 90 nm soft error FUD
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 31 Oct 2003 16:18:13 -0800
Links: << >>  << T >>  << A >>
Hi Austin,
    Out of interest, how many of the 300 parts in your experiment broke
permanently? Any at all? If there were any 'hard' failures, did altitude
affect this statistic, or were these failures due to other mechanisms?
        Syms.

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3FA0113E.BDD340C1@xilinx.com...
> Hello from the SEU Desk:
>
> Peter defended us rather well, but how can one seriously question real
> data vs. babble and drivel?
>
> Well, after 919 equivalent device years of experiment at sea level,
> Albuquerque (~5100 feet), and White Mountain Research Center (12,500
> feet) the Rosetta Experiment* on the 3 groups of 100 2V6000s has logged
> a grand total of 45 single soft error events, for a grand total of 20.4
> years MTBF (or 5335 FITs -- FITs and MTBF are related by a simple
> formula -- mean time between failures vs failures per billion hours or
> FITs).
>
>



Article: 62541
Subject: Re: Shannon Entropy for Black Holes
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 31 Oct 2003 16:21:44 -0800
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> Can anybody else explain how Shannon's information
> theory applies to black holes?

Sounds like just the place for a
First In Never Out (FINO) transmit buffer.

  -- Mike Treseler


Article: 62542
Subject: Re: Shannon Entropy for Black Holes
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 31 Oct 2003 16:36:26 -0800
Links: << >>  << T >>  << A >>
Kevin,

Really quite easy.

Just read http://www.mdpi.org/entropy/papers/e3010012.pdf

Now after you have read it, go get a stiff drink ....and then fall into a
troubled sleep.

As you toss and turn having nightmares about information horizons, and gravity
strings, remember what the White Rabbit said:  "feed your hair."

How many bits can fit on the surface of a black hole?  (2003)

How many Angel's can fit on the head of a pin?  (1536)

A question for every age.

Austin

Kevin Neilson wrote:

> I read an article in "Scientific American" about how much information can be
> compressed into a certain volume, and apparently all objects have a Shannon
> entropy in addition to the thermodynamic entropy.  Also, black holes have a
> Shannon entropy that is based on the surface area of the event horizon.  I
> was totally lost.   Can anybody else explain how Shannon's information
> theory applies to black holes?
> -Kevin


Article: 62543
Subject: Re: Wishbone interface, FPGA newbie and advice
From: Christopher Fairbairn <ckf13@student.canterbury.ac.nz>
Date: Sat, 01 Nov 2003 13:54:21 +1300
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> Consider synchronizing the interface to a faster fpga clock and generate
> your own synchronous read and write strobes in just the right places.

The reason why I started with the idea of using the HC11 microcontroller's 
E-clock to clock the wishbone interface was I imagined it would bring 
simplisity, as I wouldn't need to deal with the interfacing between the two 
different clock domains (i.e. the CPU's crystal derived clock and the FPGAs 
clock).

In my circuit I don't have to worry about the HC11 going to a low power 
state (where the e-clock signal would stop) as I'm not intending to use 
such features.

Having said that it appears that things might be more flexiable if I 
decouple that requirement, use a faster clock within the FPGA and deal with 
the fact that each bus is now asychronous to each other.

>I don't know the interfaces, but
> WB_STB_O <= cs;
> is suspect.
>
> Normally cs lasts for multiple ticks,
> the write strobe is one tick, somewhere in the middle.

Ok, well if I'm reading the HC11's waveforms correctly atleast on that bus 
it's slightly different.

It has a single R/W* signal. A logic zero on this signal indicates that the 
present bus cycle is a write operation and it can be held low for 
consecutive bus cycles in cases where double-bytes are being written. The 
R/W* is speced as being valid whenever the ADDRESS bus contains a valid 
address (which is almost the entire bus cycle), as such it's more a "write 
request" rather than a "write strobe".

With the programmable chip-selects there is a choice on when they are 
asserted. Programming a register with the correct value will mean that the 
chipselect will be asserted as soon as the address is placed upon the bus. 
Changing that value can change the length of the chipselect strobe to make 
it only occur for the second half of the bus cycle (when e-clock is high 
meaning device should place data onto bus).

I know 100% that I'm not understanding basic bus interfacing at the moment. 
I entered this project thinking (for the HC11 at least) that I could 
basically be on the look out for a particular clock edge and then simply 
look at the Read/Write signal and the chipselect to see if the transaction 
was meant for me...

And I think it's almost like that.. for example looking at the HC11 
datasheet indicates that on the rising edge of it's e-clock (a 4th of it's 
crystal oscillator speed) the read/write strobe, the address and the 
chipselect (if programmed correctly) will all be valid and hence I could 
latch them into the FPGA...

But that's where I get stuck and my knowledge starts to run out. For a read 
operation (HC11 reading a register from the FPGA) I think I'm fine... I can 
detect the signals such as the read/write strobe on the rising edge of the 
clock and output my data, then as soon as the eclock goes low I can 
tristate the bus again (and this makes sense as the HC11 reference manual 
has the following sentance in it.. "The E-clock can be used to enable 
external devices to drive data onto the data bus during the second half of 
the bus cycle (E clock high)". So I could have something like

        hc11_data <= wb_data_o when (hc11_eclk = '1') else "ZZZZZZZZ";

where hc11_eclk is effectivtly the oe signal mentioned in another poster.

However the waveforms where the HC11 is writing to a register within the 
FPGA is more confusing for me... When the E-clock goes high the data on the 
databus isn't valid yet, however it's guarenteed to be valid for atleast 
31ns after the e-clock's falling edge.

So it appears I can latch the address and read/write type signals on the 
rising edge of e-clock (and place my data on the bus in case of a read 
operation), but I have to wait until the falling edge before I can capture 
the data the HC11 has presented for a write operation.

So does that mean I need to clock my module on both edges of the e-clock 
signal? I thought that's discouraged as much as possible within FPGA 
designs?

Or is this just pointing out how much more horibbly confused I have became?

> Looks reasonable for a first cut.
> You have to compare your sim waveforms to the H11 and wishbone data
> sheets. Consider making an oe signal to drive data Z between cycles.

Reading the various replies to my initial posting and looking at the various 
datasheets etc has made me appreciate excatly how little I actually know 
about this... or even digitial logic in general when it comes to sequential 
designs.

So at least in the mean time I've decided to concentrate on an even smaller 
subcomponent of the desired goal. 

Instead of attempting to simulate the entire HC11 to Wishbone bus interface 
I'm going to concentrate on getting a simple HC11 bus interface designed 
and simulated properly. I.e. attempting to basically simulate a 74HC series 
8bit latch hanging off the HC11's databus... something I can do well with 
"real" hardware :-)

I think at the moment I have enough issues with respect to properly reading 
the waveform timing diagrams in the HC11 reference manual to think about a 
the complete design. Especially when you throw in considerations such as 
how I'm going to deal with issues such as a slave wanting to extend a bus 
cycle.. something which isn't as simple as asserting a signal on the HC11's 
bus..

Once I get that far, then I can start worrying about interpreting the 
waveforms in the wishbone spec and dealing with the "translation" of 
signals between the two busses.

>  > PS: Can anyone suggest a good book on Simulation, in particular with
>  > relation to VHDL? I've identified this as an area where I'm particular
>  > weak, and as an area where improvements would make progress a bit
>  > smoother.
> 
> You already know how to run the simulator,so get a copy of
> Ashenden's guide to vhdl as a language reference, and get busy.
> Consider adopting a synchronous testbench style:
> http://groups.google.com/groups?q=oe_demo

Thank you for this reference. The example testbench in that thread was sort 
of what I was aiming for when I talked about reading stimulus from a file. 
At present my test bench is physically hardcoded to perform the individual 
bus cycles, i.e. I have something along the lines of

cs <= '0';
wait for ABCns;
we <= '1';
wait for XYZns;
... blah blah blah ...

And I wanted a more "automated" way of doing it. Using a similiar techinque 
to that used in the testbench in that thread, and using an array containing 
the list of desired bus operations and iterating over it could just be the 
ticket I'm looking for...

Thanks for the help,
Christopher Fairbairn

Article: 62544
Subject: Re: Shannon Entropy for Black Holes
From: "Clay S. Turner" <physics@bellsouth.net>
Date: Fri, 31 Oct 2003 20:43:36 -0500
Links: << >>  << T >>  << A >>




"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3FA3000A.45C10F96@xilinx.com...
>>
> How many bits can fit on the surface of a black hole?  (2003)


Actually the entropy of a black hole works out to be about 10^66 bits/ cm^2.


Clay



Article: 62545
Subject: Re: pullup on inputs
From: "Pete Dudley" <pete.dudley@comcast.net>
Date: Fri, 31 Oct 2003 19:38:13 -0700
Links: << >>  << T >>  << A >>
The map report is the easiest place to verify that you've gotten your
pullups. It has a section like this. Look under Resistor.


+---------------------------------------------------------------------------
---------------------------------------------+
| IOB Name                           | Type    | Direction | IO Standard |
Drive    | Slew | Reg (s)  | Resistor | IOB   |
|                                    |         |           |             |
Strength | Rate |          |          | Delay |
+---------------------------------------------------------------------------
---------------------------------------------+
| diff_clk_out                       | DIFFM   | OUTPUT    | LVPECL_33   |
|      | OUTDDR   |          |       |
| diffclk_in                         | DIFFM   | INPUT     | LVDS_33     |
|      |          |          |       |
| clk_in                             | IOB     | INPUT     | LVTTL       |
|      |          |          |       |
| led<0>                             | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
| led<1>                             | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
| led_b<0>                           | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
| led_b<1>                           | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
| push1                              | IOB     | INPUT     | LVTTL       |
|      |          | PULLUP   |       |
| reset_n                            | IOB     | INPUT     | LVTTL       |
|      |          |          |       |
| uled                               | IOB     | OUTPUT    | LVTTL       |
12       | SLOW |          |          |       |
+---------------------------------------------------------------------------
--------------------------------------------
"Max" <cialdi@firenze.net> wrote in message
news:8e077568.0309252330.21aae0c5@posting.google.com...
> I use xilinx ise webpack 6.1 sp1.
> In may project I tried to add contrains like:
>
> NET "probes<0><0>"  LOC = "D11" | PULLUP ;
> NET "probes<0><1>"  LOC = "D12" | PULLUP ;
> NET "probes<0><2>"  LOC = "C12" | PULLUP ;
>
> This signals are all input.
>
> In translate report is reported:
>
> Attached a PULLUP primitive to pad net probes<0><2>
> Attached a PULLUP primitive to pad net probes<0><1>
> Attached a PULLUP primitive to pad net probes<0><0>
>
>
> But in place&route report there is no reference to pullups:
> Resolved that IOB <probes<0><0>> must be placed at site D11.
> Resolved that IOB <probes<0><1>> must be placed at site D12.
> Resolved that IOB <probes<0><2>> must be placed at site C12.
>
> Even in pad report is not mentioned pullup resistor for that signals.
>
> How can I be sure about the presence of pullup resistors on that ports?
>
> thanks



Article: 62546
Subject: Re: Picoblaze development tool
From: "Pete Dudley" <pete.dudley@comcast.net>
Date: Fri, 31 Oct 2003 19:40:56 -0700
Links: << >>  << T >>  << A >>
Henk

Thanks for the notice. Is there any chance you will have a C compiler
available for picoblaze?


"Henk van Kampen" <henk@mediatronix.com> wrote in message
news:23ecd97d.0310240736.7b08c8dd@posting.google.com...
> Recently I have updated my Picoblaze (tm Xilinx) development tool
> pBlazIDE and added some documentation. Additionally I have published
> some example code and demonstration files. Please feel free to check
> this out. Its all freeware. Check under 'Tools'.
>
> Regards,
> Henk van Kampen
> www.mediatronix.com



Article: 62547
Subject: Re: Wishbone interface, FPGA newbie and advice
From: Christopher Fairbairn <ckf13@student.canterbury.ac.nz>
Date: Sat, 01 Nov 2003 15:46:21 +1300
Links: << >>  << T >>  << A >>
Hi,

Andras Tantos wrote:
> - There's no wait-state generation. You don't detect any wait-state
> requests from the WB side and don't generate wait-states for your async
> master (HC11). That can cause problems if you communicate with slow
> devices (for example with a FIFO which, when full, generated waits)

At the moment the three initial wishbone slaves I'm intending to interface 
to are all pretty primitive and have their ACK_O simply tied to their STB_I 
input as allowed by the wishbone spec if they don't require any waitstates.

As such I shouldn't need wait states, but it is something I've been concious 
about and keeping in the back of my mind... knowing full well that 
murphie's law will present a nice wishbone slave that I desire to use at 
some stage in the future which will require waitstates... I'm just not 
excatly sure how to deal with it, considering I can't stall the HC11 bus.

> I'll paste my circuit here for reference. Note, that it does not use the
> CPUs clock to sync up the WB part, so it can run on much higher clock
> speeds (in my case 70MHz). That can help meet the timing (with proper
> wait-state handling of course) but can cause all kinds of meta-stability
> issues, I'm not sure I've addressed properly either. Please note that I'm
> not a professional either, I'm not claiming my design to be nice or
> flowless. It at least worked in a real HW... Any comment are welcome.

As part of my research and investigations today I discovered an asynchronous 
wishbone master on www.opencores.org which appears to be developed by 
yourself (http://www.opencores.org/cores/wb_tk/wb_async_master.shtml).

Is this correct? It appears that the version on the opencores website is a 
lot simplier than the version you presented in your posting. Reading 
through the source for the one on opencores.org has cleared a lot of things 
up for me and "turned a couple of lightbulbs on" in my mind..  What's the 
main differences between the two? I'm having difficulty following the one 
in the newsgroup posting while I can pretty much follow the one on 
www.opencores.org.

The testbench support code in the http://www.opencores.org/cores/wb_tk 
project has also helped me out. The use of a VHDL function to wrap up the 
inner workings of a bus cycle should stop me from duplicating all those 
lines of code in my testbench for every read/write I perform on the bus...

Thanks,
Christopher Fairbairn.

Article: 62548
Subject: Convert verilog to VHDL??
From: <sc01@hotmail.com>
Date: Sat, 01 Nov 2003 03:10:57 GMT
Links: << >>  << T >>  << A >>
Hi,
Does anyone know how I can convert my verilog code to VHDL?

Stanley



Article: 62549
Subject: WinCE driver for Wildcard from Annapolis Micro System?
From: <sc01@hotmail.com>
Date: Sat, 01 Nov 2003 03:13:27 GMT
Links: << >>  << T >>  << A >>
Hi,
Has anyone used or written any WinCE driver for this card?
(Wildcard from Annapolis Micro System www.annapmicro.com)
Where can I possibly find one?

Any information would be greatly appretiated.

Stanley





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