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 19875

Article: 19875
Subject: Re: Xilinx Spartan2
From: dmac <dmac@cutme.matter200.demon.co.uk>
Date: Sat, 15 Jan 2000 02:55:43 +0000
Links: << >>  << T >>  << A >>

Hi all,

I support Peter's position that junction temperature is the real
measurement point. It's the silicon that howls and dies when it gets too
hot, not the air just above the case, so for me I want to know params at
junction temps not air temps. BTW, which ambient are we talking about
here, the one 1mm, 10mm or 50mm from the chip body, the fan exhaust
temperature or etc, etc.

Working from the case temp is, i think, the most accurate way of
assessing thermal & tech params and Xilinx support that by publishing
appropriate thermal figures. The current data book has figures for both
theta-jc and theta-ja on all packages so junction temps are easy to
calculate. Alternatively, by placing a low mass probe on the case you
can find out what the junction is doing and measure the cooling
effectiveness of airflow or increased heatsinking.

I feel that ambient temp reporting is just so much finger in the air,
it's valid for the precise conditions used in the test and no <real>
other.

Dave McLeod

-- 
dmac
Article: 19876
Subject: Re: HW resources increased
From: andy_ash@my-deja.com
Date: Sat, 15 Jan 2000 03:48:41 GMT
Links: << >>  << T >>  << A >>
It's bad enough now.
Hell, if everyone starts writing decent code I don't stand a chance of
looking like a genius anymore!

;-)

Andy.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19877
Subject: Re: Design security
From: murray@pa.dec.com (Hal Murray)
Date: 15 Jan 2000 05:19:50 GMT
Links: << >>  << T >>  << A >>

> 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.

If you are interested in that sort of attackdevice security, be sure
to read this paper.  It helps to be a hardware geek, but software
people (and even managers) should be able to understand this.

It's fun and well done.  So good that I save this from a Usenet posting.

-------


Research Announcement

We recently published the following paper, which should be of
interest to those concerned about smartcard hardware security:

  Oliver K<F6>mmerling, Markus G. Kuhn: Design Principles for
  Tamper-Resistant Smartcard Processors. Proceedings of the
  USENIX Workshop on Smartcard Technology (Smartcard '99),
  Chicago, Illinois, USA, May 10-11, 1999, USENIX Association,
  pp. 9-20, ISBN 1-880446-34-0.


(This work received the "USENIX Association Best Student Paper Award".)

Various non-invasive cryptanalysis techniques against smartcards, which
have been publicised as "Differential Fault Analysis", "Differential
Power Analysis", etc., have received considerable attention recently.
However, these are not the attack techniques that have been used by
pirates to break practically all types of smartcard processors that are
fielded in millions of conditional-access systems. We show in our paper
how invasive microprobing techniques are a far more powerful and
universally applicable threat to smartcard security, which processor
architecture elements simplify attacks significantly, and what designers
could quite easily do to make it more difficult.

Unlike fault and current analysis techniques, microprobing attacks do
not depend on any prior knowledge or guessing of the implemented
cryptographic algorithms. Microprobing gives the attacker not only
access to cryptographic keys, but also leads to full disassembler
listings of the extracted security software. Availability of the full
smartcard software then often allows the design of fast and simple
non-invasive glitch and current analysis attacks, which -- unlike
DPA-style attacks -- do not require many hundred seconds of protocol
interactions. Such very fast non-invasive attacks can then be performed
inconspicuously in a Trojan card terminal together with a normal
transaction and without giving the card holder a chance to notice them.
They form a serious additional threat over microprobing even for
applications such as digital signature and banking cards, which do not
rely on global keys stored in the card. Microprobing attacks can be
carried out by skilled technicians starting with an investment of little
more than ten thousand euros and they can then be repeated at rather low
cost.

Our paper not only describes the range of attack techniques that have
been used in the past to break numerous commercially fielded security
systems. We also suggest a number of lowest-cost countermeasures that
will help to make many of these attacks considerably more challenging to
perform. Some of these we believe to be new, while others have already
been implemented in products but are either not widely used or the
implementations we found had design flaws that allowed us to circumvent
them more easily than would have been necessary.

Online version of the paper:

 http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf

Presentation slides with more photos:


 http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf

[Important note to avoid misunderstandings: Our paper does *not* provide
any comparative evaluation of the security mechanisms of specific
products and it should not be quoted to that effect. We present a few
interesting vulnerabilities in the security mechanisms of one commercial
smartcard processor that we named. This processor is of particular
interest primarily, because it features comparatively advanced security
features not found in most other products. The reader should understand
that in spite of the vulnerabilities that we outline, unmentioned
competing products are not necessarily more secure. Indeed, many of them
do not have these advanced security mechanisms implemented and are
easier to break. Much easier.]

Markus Kuhn

--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-- 
These are my opinions, not necessarily my employers.
Article: 19878
Subject: Re: XACT & XC4000E - Need help
From: Ray Andraka <randraka@ids.net>
Date: Sat, 15 Jan 2000 06:35:12 GMT
Links: << >>  << T >>  << A >>
XACT is/was the old place and route software.  You can't buy it from Xilinx
anymore.  The 4000E series is supported with the current Foundation and
Alliance tools however.  Depending on the size of the 4000E series part, you
may be able to use the student edition of the software.

rmeenaks@olf.com wrote:

> 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.

--
-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: 19879
Subject: Re: Lattice
From: "Kresten Nørgaard" <nospam_kresten_noergaard@ddf.dk>
Date: Sat, 15 Jan 2000 15:32:51 +0100
Links: << >>  << T >>  << A >>
Latch-up could be caused by feeding in higher than 5.6v on any pin.
>
>--
Sounds likely to me. Or it might be negative spikes (below 0.6 V). Try to
invoke serial resistors of 2-10 ohms at suspected outputs. It might be
necessary to at protection circuit  (like 2 diodes conducting negative
spikes to ground, postive spikes to Vcc) as well.

Both positve and negative spikes could be caused by bad layout of the
printed circuit board. Beware that FPGA's can hold a lot of flip-flops, that
might change state synchronously. Thus the peak current can be huge, causing
voltage drops to arise along the paths. Try improving your ground layout by
soldering copper wires to and fro.

The high peak current can also "cheat" serial regulators in a way, that
makes the Vcc unstable. Use a good oscilloscope and see, if there are any
ringings. Be careful to measure directly on the power pins of the FPGA - not
from a ground reference somewhere else on the board.

Kresten


Article: 19880
Subject: FPGA + ethernet
From: David Barcelo <dbb24@pantheon.yale.edu>
Date: Sat, 15 Jan 2000 17:42:40 -0500
Links: << >>  << T >>  << A >>

Does anyone know of an FPGA board with one (or even better, two) ethernet
ports?  If not, how about a programmable router?

Please email if you know of any.
Thanks,
-Dave

Article: 19881
Subject: Re: FPGA + ethernet
From: Dave Vanden Bout <devb@xess.com>
Date: Sat, 15 Jan 2000 18:48:24 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------BC2C392A65E8D9DF89D8476A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Barcelo wrote:

> Does anyone know of an FPGA board with one (or even better, two) ethernet
> ports?  If not, how about a programmable router?
>
> Please email if you know of any.
> Thanks,
> -Dave

Our XSV series of boards has a single Ethernet port.  The PHY chip is an LXT970A
and then a Virtex FPGA supplies all the higher-level MAC functions.



--------------BC2C392A65E8D9DF89D8476A
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;David
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;28560
fn:Dave Vanden Bout
end:vcard

--------------BC2C392A65E8D9DF89D8476A--

Article: 19882
Subject: Re: FPGA + ethernet
From: Dave Vanden Bout <devb@xess.com>
Date: Sat, 15 Jan 2000 18:48:24 -0500
Links: << >>  << T >>  << A >>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BF5FB7.454E9036
Content-Type: text/plain

David Barcelo wrote:

> Does anyone know of an FPGA board with one (or even better, two)
ethernet
> ports?  If not, how about a programmable router?
>
> Please email if you know of any.
> Thanks,
> -Dave

Our XSV series of boards has a single Ethernet port.  The PHY chip is an
LXT970A
and then a Virtex FPGA supplies all the higher-level MAC functions.




------ =_NextPart_000_01BF5FB7.454E9036
Content-Type: text/x-vcard;
	name="devb.vcf"
Content-Disposition: attachment;
	filename="devb.vcf"
Content-Description: Card for Dave Vanden Bout

begin:vcard 
n:Vanden Bout;David
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;28560
fn:Dave Vanden Bout
end:vcard

------ =_NextPart_000_01BF5FB7.454E9036--

Article: 19883
Subject: Partly reprogrammable FPGAs
From: arsh@x-stream.se
Date: Sat, 15 Jan 2000 23:50:00 GMT
Links: << >>  << T >>  << A >>
Dear All!

I wonder if anyone know which FPGAs can be partly reprogrammable, so
that one may reconfigure a part of the device while the rest of the
device is still functioning. Has anyone of you any experience from this.

Also I wonder if anyone knows what kind of research is being done in
this area. Has anyone considered the concept of self-modifying blocks
in FPGAs.

Any information is greatly appreciated!

Regards,

Arvind Shah


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19884
Subject: Re: Partly reprogrammable FPGAs
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 16 Jan 2000 00:42:25 GMT
Links: << >>  << T >>  << A >>
In article <85r134$era$1@nnrp1.deja.com>,  <arsh@x-stream.se> wrote:
>Dear All!
>
>I wonder if anyone know which FPGAs can be partly reprogrammable, so
>that one may reconfigure a part of the device while the rest of the
>device is still functioning. Has anyone of you any experience from this.

	The Xilinx 6200 had really nice partial reconfiguration
abilities, but the part is no longer being made and was only really
interesting as a research tool.

	The Virtex has a column oriented partial reconfiguration,
where you can reconfigure columns on the chip.  Look on the Xilinx
application notes for more detail.

>Also I wonder if anyone knows what kind of research is being done in
>this area. Has anyone considered the concept of self-modifying blocks
>in FPGAs.

	Look through back proceedings of FCCM, a lot of work has been
done on partial reconfiguration.  Nobody that I know of really wants
to do self modifying blocks, even though some proposed FPGAs were
capable of it.


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 19885
Subject: Re: XACT & XC4000E - Need help
From: rmeenaks@olf.com
Date: Sun, 16 Jan 2000 04:17:45 GMT
Links: << >>  << T >>  << A >>
In article <38801333.206751B1@ids.net>,
  Ray Andraka <randraka@ids.net> wrote:
> XACT is/was the old place and route software.  You can't buy it from
Xilinx
> anymore.  The 4000E series is supported with the current Foundation
and
> Alliance tools however.  Depending on the size of the 4000E series
part, you
> may be able to use the student edition of the software.
>

I currently have the student edition and it supports my Xilinx
XC4003E.  What is the difference between the Alliance & the
Foundation.


Ram


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19886
Subject: Re: HW resources increased
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 16 Jan 2000 05:27:19 GMT
Links: << >>  << T >>  << A >>
In article <387CEE55.949A3FB7@pobox.com>, Marinos J. Yannikos 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? They must consume an awful lot of power... I'm all for
>retro-computing and putting old hardware to good use, but I draw
>the border where the cost of operating the old systems is so high
>that replacing several of them with a single new system makes sense.

A lot of times it's just a machine that was setup way back when and hasn't
been touched since since it kept on working.  Linux users often like to
think they're the only people doing this, but I've seen all sorts of random
ancient systems that nobody's bothered with in years because it would take
more energy to replace them with their newfangled potentially crashy
counterparts than it takes to just let them sit and do hteir routing or
print serving or floppy copying or whatever it is they're doing.  I left
behind a 386 modem server/firewall with my folks when I moved out and they
haven't complained yet except that the power supply fan stopped working 6
months go (making an awful noise when it does spin, so they've taken to
stopping it when it starts spinning every now and then).
	If it ain't broke, don't fix it.
Article: 19887
Subject: Re: HW resources increased
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 16 Jan 2000 05:35:01 GMT
Links: << >>  << T >>  << A >>
In article <387b72f2_1@newsread3.dircon.co.uk>, Ian Kemmish wrote:
>In article <387AD481.58C40A0C@ieee.org>, Khatib@ieee.org says...
>
>>SW programmers now also have high speed processors, large memories
>>advanced compilers and visual tools. although all these resources are
>>available for programmers, but -as I see- they do not improve their sw
>>_in_the_same_ratio_as_the improvements_of_the_resources. For example all
>>new sw versions need larger memories and faster processors without the
>>increase of the functionality of the new version. This is because they
>
>This is simply not true.  The latest version of Jaws was smaller than the last 
>previous version, and incpororated PostScript LanguageLevel 3 functionality.  
>Some people (and especially marketing departments and managers) feel small code 
>size is not important, but smaller programs do get fewer cache misses and TLB 
>misses, and depending on what you're running, this can make a perceptible 
>difference to performance.

I don't even think that is the best argument.  I mean, improved
performance is nice, but the important thing is stability where I come
from.  So many times I've looked over old programs and realized that I
could tear out half the code if I rearranged one datastructure or thought
about something differently, and the result was both smaller and a lot
easier to debug.  Less code means less bugs. Ideally, computers wouldn't
run any code at all. :)

>Of course, economics being what it is, one only gets the opportunity for a 
>major code squeeze once or twice a decade.  But it is fun to revisit old code 
>once in a while:-)

Yeah, it is quite a pity when old code that was just a hack at the time is
left behind because you don't have the time to go back and fix it up.  Too
bad many managers don't seem to understand that rewriting the old code at
the heart of a program will often make the new extensions a thousand times
simpler and smaller.

>>Do you think like me? Do you know how can we prevent this?
>>I think this can be prevented by following the Open Source and open
>>Hardware design concepts in the design. You can read more about this
>>idea in OpenIPCore Project at http://www.openip.org/oc
>
>Open Source is a large part of the problem, not part of the solution.
>
>Compact, fast and robust code is produced by Real Programmers, who either work 
>alone, or, as described in The Mythical Man Month, with a co-pilot.  Ideally, 
>the Real Programmer develops on the slowest machine in the building and the 
>co-pilot tracks down bugs on the fastest machine in the building:-)
>
>Activities like Open Source, on the other hand, have a cast of thousands, and a 
>strong economic incentive to ship many flakey new versions and fix them on a 
>time and materials basis later on.  If you want to see what results when you 
>apply a cast of thousands to an otherwise simple problem, look at the ICL 2900 
>(my own choice for computer of the century, if only because we should never 
>forget the Great Disasters Of Computing).

I agree 100% with what you have to say about open source there.  Open
Source is the embodiment of the "okay, it's just a hack, but it works and
that's good enough for me, and nobody else has written it, so let's submit
this for mass distribution" design methodology.  It works, and there's
nothing stopping a random third party from going back and cleaning it up,
but it certainly doesn't guarantee any better code than popular commercial
design methodologies.
Article: 19888
Subject: Re: Partly reprogrammable FPGAs
From: Ray Andraka <randraka@ids.net>
Date: Sun, 16 Jan 2000 05:46:37 GMT
Links: << >>  << T >>  << A >>
Here are the parts that come to mind with partial reconfiguration:

Atmel 6K series
Atmel 40K series
Xilinx 6200
Xilinx Virtex

I think one of the Lucent families may also be partially reconfigurable, but I
am not very familiar with their parts.  Of those listed above, I think the
Atmel parts have the best partial reconfiguration support in terms of tools
(that's not saying they are very good,  though).  Partial reconfiguration
carries with it a fairly large set of problems, many which have not been
adequately solved for general use.  Some of these problems include the need to
know where not only the logic is placed for each block that is configured at
different times, but also where the routing is so that you can connect to
existing logic and avoid obliterating operating logic.  The current tools make
this quite painful to do the necessary partitioning, floorplanning and
detailed route necessary.  This is not to say it can't be done (it has many
times...see my paper discussing a dynamic hardware video processor which takes
advantage of partial reconfiguration, or any one of a number of papers on the
BYU website).

"Nicholas C. Weaver" wrote:

> In article <85r134$era$1@nnrp1.deja.com>,  <arsh@x-stream.se> wrote:
> >Dear All!
> >
> >I wonder if anyone know which FPGAs can be partly reprogrammable, so
> >that one may reconfigure a part of the device while the rest of the
> >device is still functioning. Has anyone of you any experience from this.
>
>         The Xilinx 6200 had really nice partial reconfiguration
> abilities, but the part is no longer being made and was only really
> interesting as a research tool.
>
>         The Virtex has a column oriented partial reconfiguration,
> where you can reconfigure columns on the chip.  Look on the Xilinx
> application notes for more detail.
>
> >Also I wonder if anyone knows what kind of research is being done in
> >this area. Has anyone considered the concept of self-modifying blocks
> >in FPGAs.
>
>         Look through back proceedings of FCCM, a lot of work has been
> done on partial reconfiguration.  Nobody that I know of really wants
> to do self modifying blocks, even though some proposed FPGAs were
> capable of it.
>
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

--
-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: 19889
Subject: Re: XACT & XC4000E - Need help
From: Ray Andraka <randraka@ids.net>
Date: Sun, 16 Jan 2000 05:48:29 GMT
Links: << >>  << T >>  << A >>
Foundation has design capture tools in the product.  Alliance has
libraries and the links to use third party tools, which are generally more
sophisticated than the tools in the foundation product.



rmeenaks@olf.com wrote:

> In article <38801333.206751B1@ids.net>,
>   Ray Andraka <randraka@ids.net> wrote:
> > XACT is/was the old place and route software.  You can't buy it from
> Xilinx
> > anymore.  The 4000E series is supported with the current Foundation
> and
> > Alliance tools however.  Depending on the size of the 4000E series
> part, you
> > may be able to use the student edition of the software.
> >
>
> I currently have the student edition and it supports my Xilinx
> XC4003E.  What is the difference between the Alliance & the
> Foundation.
>
> Ram
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-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: 19890
Subject: Random Number Generator
From: "Domagoj Babic" <domagoj.babic@fer.hr>
Date: Sun, 16 Jan 2000 13:00:44 +0100
Links: << >>  << T >>  << A >>
Hi!

Does anyone have a clue how to implement random number generator

in XC4k family ?

Thanks.

Domagoj Babic
domagoj.babic@fer.hr


Article: 19891
Subject: Re: HW resources increased
From: Chris Morgan <cm@mihalis.net>
Date: 16 Jan 2000 10:08:59 -0500
Links: << >>  << T >>  << A >>
galexand@sietch.bloomington.in.us (Greg Alexander) writes:

> I agree 100% with what you have to say about open source there.  Open
> Source is the embodiment of the "okay, it's just a hack, but it works and
> that's good enough for me, and nobody else has written it, so let's submit
> this for mass distribution" design methodology.  It works, and there's
> nothing stopping a random third party from going back and cleaning it up,
> but it certainly doesn't guarantee any better code than popular commercial
> design methodologies.

That's true but irrelevant. The interesting thing is that popular
commercial design methodologies certainly don't guarantee any better
code than Open Source, despite many peoples expectations to the
contrary, and some people's continued denials.

-- 
Chris Morgan <cm at mihalis.net>                  http://mihalis.net
Reply-To: "Kang Liat Chuan" <kanglc@cyberway.com.sg>
Article: 19892
Subject: Re: timing diagrams
From: "Kang Liat Chuan" <kanglc@cyberway.com.sg>
Date: Mon, 17 Jan 2000 00:22:51 +0800
Links: << >>  << T >>  << A >>
Try this site:
http://support.xilinx.com/support/techsup/journals/timing/presentation/timin
gcsts2_1i/index.htm

<elynum@my-deja.com> wrote in message news:84u5lg$sa8$1@nnrp1.deja.com...
> Does anyone know where I can get a good book or article on timing
> diagrams?  I haven't had a lot of experience when it comes to stuff like
> timing violations as far as I need something that will explain how to
> understand clock to output times, setup and hold times and their
> importance in simulation.
>
> Thanks
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 19893
Subject: Re: HW resources increased
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 16 Jan 2000 17:56:09 GMT
Links: << >>  << T >>  << A >>
In article <87ln5qvyt0.fsf@think.mihalis.net>, Chris Morgan wrote:
>galexand@sietch.bloomington.in.us (Greg Alexander) writes:
>
>> I agree 100% with what you have to say about open source there.  Open
>> Source is the embodiment of the "okay, it's just a hack, but it works and
>> that's good enough for me, and nobody else has written it, so let's submit
>> this for mass distribution" design methodology.  It works, and there's
>> nothing stopping a random third party from going back and cleaning it up,
>> but it certainly doesn't guarantee any better code than popular commercial
>> design methodologies.
>
>That's true but irrelevant. The interesting thing is that popular
>commercial design methodologies certainly don't guarantee any better
>code than Open Source, despite many peoples expectations to the
>contrary, and some people's continued denials.

So?  That just means that neither of them alone are a solution to the
problem individually.  Open Source is good in that it allows any random
Joe to use whatever methodology he wants to make someone else's code not
bloated, but it does nothing at all to prevent the creation, distribution,
and bloated code in the first place.  Open Source is good, when combined
with other methodologies, at addressing the bloat problem, but alone, it
is not related to the bloat problem.
Article: 19894
Subject: Re: Random Number Generator
From: Ray Andraka <randraka@ids.net>
Date: Sun, 16 Jan 2000 18:01:53 GMT
Links: << >>  << T >>  << A >>
Linear feedback shift register counters will give you a pseudo random
sequence of bits.  The sequence repeats after 2^(n-1) counts for a
maximal length sequence.  See xilinx application note xapp052 for more
details on implementation and description of the counters.  The
distribution of the output is uniform, with a slight bias due to the all
'1's state being an illegal state of the LFSR counter.

Note, that these really only produce one random bit per clock, as the
remaining bits are time delayed copies of the first bit.  A fairly
common approximation is to use more than one bit, but be careful since
this colors the spectrum.  If you do choose to use more than one bit,
the new bit should be the most significant of the output bits, so that
the next output is y= b*2^n + 1/2*y(n-1) where b is the new random bit.
If you bring the new bit in the lsb position, your output is y=2*y(n-1)
+ b, which is a noisy ramp function (which becomes a sawtooth because of
modular arithmetic).  A better generator uses separate LFSR counters for
each bit, which care taken to make sure the seed values of the separate
LFSRs are not near each other in the sequence.

If you need other distributions, the uniform distribution can be used
with other logic to generate the desired distribution either
algorithmically (ie box-mueller algorithm for gaussian noise), using the
uniform value to map to the desired distribution through a cumulative
density function table, or by using the central limit theorem for
gaussian distributions.

Domagoj Babic wrote:

> Hi!
>
> Does anyone have a clue how to implement random number generator
>
> in XC4k family ?
>
> Thanks.
>
> Domagoj Babic
> domagoj.babic@fer.hr

--
-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: 19895
Subject: Re: timing diagrams
From: Ray Andraka <randraka@ids.net>
Date: Sun, 16 Jan 2000 18:18:32 GMT
Links: << >>  << T >>  << A >>
many data sheets have diagrams showing the timing parameters relative to
waveforms.

Clock to Q is the time from the active clock edge to a valid output (generally
we are interested in the max time here).  Set-up time is the minimum amount of
time required after input data is guaranteed valid and the active edge of the
clock  to guarantee the register will get the correct data.  Hold time specifies
the minimum period after the active edge of the clock for which the input data
cannot be changed to guarantee the correct data is clocked into the register.
In your timing analysis (for synchronous designs), your design will not fail due
to timing problems if the correct data is present and stable at all clocked
registers during the window defined by the set-up and hold times around the
active clock edge.  The data will be stable within that window if the sum of the
propagation delays from one register to the next is less than the clock period.
That sum of delays is the time from clock to output of the first register, the
combinatorial and routing delay of any logic and wiring between that output and
the next input, and the set-up time of the destination register.   A hold time
violation occurs if the new data arrives at the next register too soon.  If the
hold times are zero or negative (and clock has no skew), the hold time becomes a
non-issue.  There are instances where there are positive hold times, in which
case one has to make sure the **minimum** delay on the data path is greater than
the hold time.  Since minimum delays are difficult to specify, we don't like to
see positive hold times.  Inside FPGAs, the manufacturer tries to keep the
register hold times such that no hold time violations can occur in a synchronous
design.

Kang Liat Chuan wrote:

> Try this site:
> http://support.xilinx.com/support/techsup/journals/timing/presentation/timin
> gcsts2_1i/index.htm
>
> <elynum@my-deja.com> wrote in message news:84u5lg$sa8$1@nnrp1.deja.com...
> > Does anyone know where I can get a good book or article on timing
> > diagrams?  I haven't had a lot of experience when it comes to stuff like
> > timing violations as far as I need something that will explain how to
> > understand clock to output times, setup and hold times and their
> > importance in simulation.
> >
> > Thanks
> >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

--
-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: 19896
Subject: Re: Benchmarks
From: "Number Cruncher" <michel.heuts@pandora.be>
Date: Sun, 16 Jan 2000 19:29:58 GMT
Links: << >>  << T >>  << A >>
Michael,

                there was an article in EDN - May 27, 1999 - called Lies,
damn lies and Benchmarks pag. 54
author: Brian Dipert     http://www.ednmag.com

The article should still be on their website! If you cannot locate it, I
will post it on request by e-mail.
(look at: http://www.ednmag.com/ednmag/verticalmarkets/PLD.asp )


regards,

Michel HEUTS
WMU Belgium



"Michael Eisenring" <eisenring@tik.ee.ethz.ch> wrote in message
news:387C9D45.D0EAC273@tik.ee.ethz.ch...
> Hi to everybody
>
> Does somebody know a library of FPGA benchmarks used for
> research?
>
> I would be pleased if I got to know where to look for it.
>
> Thanks.
> Michael


Article: 19897
Subject: Re: Random Number Generator
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Sun, 16 Jan 2000 12:21:53 -0800
Links: << >>  << T >>  << A >>
On Sun, 16 Jan 2000 18:01:53 GMT, Ray Andraka <randraka@ids.net>
wrote:

|Linear feedback shift register counters will give you a pseudo random
|sequence of bits.  The sequence repeats after 2^(n-1) counts for a
|maximal length sequence.  See xilinx application note xapp052 for more
|details on implementation and description of the counters.  The
|distribution of the output is uniform, with a slight bias due to the all
|'1's state being an illegal state of the LFSR counter.
|
|Note, that these really only produce one random bit per clock, as the
|remaining bits are time delayed copies of the first bit.  A fairly
|common approximation is to use more than one bit, but be careful since
|this colors the spectrum.  If you do choose to use more than one bit,
|the new bit should be the most significant of the output bits, so that
|the next output is y= b*2^n + 1/2*y(n-1) where b is the new random bit.
|If you bring the new bit in the lsb position, your output is y=2*y(n-1)
|+ b, which is a noisy ramp function (which becomes a sawtooth because of
|modular arithmetic).  A better generator uses separate LFSR counters for
|each bit, which care taken to make sure the seed values of the separate
|LFSRs are not near each other in the sequence.
|
|If you need other distributions, the uniform distribution can be used
|with other logic to generate the desired distribution either
|algorithmically (ie box-mueller algorithm for gaussian noise), using the
|uniform value to map to the desired distribution through a cumulative
|density function table, or by using the central limit theorem for
|gaussian distributions.
|
|Domagoj Babic wrote:
|
|> Hi!
|>
|> Does anyone have a clue how to implement random number generator
|>
|> in XC4k family ?
|>
|> Thanks.
|>
|> Domagoj Babic
|> domagoj.babic@fer.hr


Ray,

in a similar discussion in comp.arch.embedded, somebody wanted a truly
random (non-predictable) number at powerup time. One suggestion that
evolved was as follows:

Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a
counter or  linear shift register until the pin goes high sometime
after powerup (or after being pulled low tristate-wise.) Use an X7R
cap, which has a terrible TC. If the RC time constant is long, the
result (PRN reg contents, or some counter LSBs) is fairly random.

Refinement: depending on some number of LSBs of the prievious timeout,
reset the cap using a reset time scale that results in only partial
discharge, then repeat the charge time thing. Serious chaos theory
results, and something like real randomness can be had for just the
price of one RC.

John

==

A little nonsense now and then,
is cherished by the wisest men.

- Willy Wonka
Article: 19898
Subject: Re: HW resources increased
From: Chris Morgan <cm@mihalis.net>
Date: 16 Jan 2000 16:42:07 -0500
Links: << >>  << T >>  << A >>
galexand@sietch.bloomington.in.us (Greg Alexander) writes:

> >The interesting thing is that popular
> >commercial design methodologies certainly don't guarantee any better
> >code than Open Source, despite many peoples expectations to the
> >contrary, and some people's continued denials.
> 
> So?  That just means that neither of them alone are a solution to the
> problem individually.  Open Source is good in that it allows any random
> Joe to use whatever methodology he wants to make someone else's code not
> bloated, but it does nothing at all to prevent the creation, distribution,
> and bloated code in the first place.

Right, this is correct, when a project is launched the code is often
just something thrown together to get the ball rolling. The key thing
is projects that flourish often have people who care enough to weed
out the bad bits and improve the structure, without those people being
beholden to any budget or deadline.

>  Open Source is good, when combined with other methodologies, at
> addressing the bloat problem, but alone, it is not related to the
> bloat problem.

Well, I wouldn't go that far, as Open Source guarantees you the right
to replace some bloaty piece of junk with your beautifully spare and
elegant replacement ;^)

Chris

-- 
Chris Morgan <cm at mihalis.net>                  http://mihalis.net
Article: 19899
Subject: Re: Random Number Generator
From: Ray Andraka <randraka@ids.net>
Date: Mon, 17 Jan 2000 00:08:47 GMT
Links: << >>  << T >>  << A >>


While the LSBs may be random, I think for one particular cap under the same
conditions, you will get similar results.  I suspect the distribution would
be gaussian with a fairly small variance for a given set of conditions.  Many
many years ago I tried using a blinking incadescent lamp (you know, the kind
with the bimetallic strip in it) to generate a random gate for a counter to
get random numbers (this was in the mid '70's).  While it did get random
numbers, the distribution was fairly tight for a given bulb once the bulb had
cycled a few times.  I would expect the capacitor probably has a tighter
distribution.   If you can put a real-time clock somewhere in the system, you
can use it to seed an LFSR with quite good results.


John Larkin wrote:


> in a similar discussion in comp.arch.embedded, somebody wanted a truly
> random (non-predictable) number at powerup time. One suggestion that
> evolved was as follows:
>
> Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a
> counter or  linear shift register until the pin goes high sometime
> after powerup (or after being pulled low tristate-wise.) Use an X7R
> cap, which has a terrible TC. If the RC time constant is long, the
> result (PRN reg contents, or some counter LSBs) is fairly random.
>
> Refinement: depending on some number of LSBs of the prievious timeout,
> reset the cap using a reset time scale that results in only partial
> discharge, then repeat the charge time thing. Serious chaos theory
> results, and something like real randomness can be had for just the
> price of one RC.
>
> John
>
> ==
>
> A little nonsense now and then,
> is cherished by the wisest men.
>
> - Willy Wonka

--
-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




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