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 19900

Article: 19900
Subject: Further to board
From: #YEO WEE KWONG# <P7102672H@ntu.edu.sg>
Date: Mon, 17 Jan 2000 10:08:45 +0800
Links: << >>  << T >>  << A >>
Hi,

Thanks for the info. Can  you give the location to find more info. on
your board that you are talking about.


-----Original Message-----
From: Dave Vanden Bout [mailto:devb@xess.com]
Posted At: 16 January 2000 07:48
Posted To: comp.arch.fpga
Conversation: FPGA + ethernet
Subject: Re: FPGA + ethernet


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.



Article: 19901
Subject: Re: Further to board
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 16 Jan 2000 23:25:57 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------EF4780E717CCCAA6E3B6C663
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

#YEO WEE KWONG# wrote:

> Hi,
>
> Thanks for the info. Can  you give the location to find more info. on
> your board that you are talking about.

Just go to www.xess.com and look in the catalog for the XSV Board.  Click on the catalog link to see a preliminary picture of the board.  There is also a link to the preliminary manual.

You should also check the list of boards at www.optimagic.com to see if there are other boards with Ethernet links on them.

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




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

--------------EF4780E717CCCAA6E3B6C663--

Article: 19902
Subject: Re: Further to board
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 16 Jan 2000 23:25:57 -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_01BF60A7.EED8D67A
Content-Type: text/plain

#YEO WEE KWONG# wrote:

> Hi,
>
> Thanks for the info. Can  you give the location to find more info. on
> your board that you are talking about.

Just go to www.xess.com and look in the catalog for the XSV Board.
Click on the catalog link to see a preliminary picture of the board.
There is also a link to the preliminary manual.

You should also check the list of boards at www.optimagic.com to see if
there are other boards with Ethernet links on them.

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

Article: 19903
Subject: Re: Random Number Generator
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Mon, 17 Jan 2000 08:09:31 +0100
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 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). 
> > 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.) 
Another proposal: 
Use a "radio" Nearly everywhere you will have a strong MF radio station
thus you get a strong signal. Use a triggering input and sample only now
and then (below speach frequency).
Article: 19904
Subject: Design flow needed
From: Jamil Khaib <Khatib@ieee.org>
Date: Mon, 17 Jan 2000 11:31:06 +0200
Links: << >>  << T >>  << A >>
Hi,
We need to define a design flow and projects definitions for open
hardware designs something like what companies are doing.

For example at the beginning they study the market and check what is
missing then starts defining the project and the spec then the reset of
design flow something like top down or down top flow and many kind of
documentation should be considered scheduled and followed in particular
order and how the project is divided into smaller parts and so on.

What do you suggest for these kind of projects?

For more information and discussions pls. join us at OpenIPCore mailing
list

Thanks
Jamil Khatib
OpenIP Organization  http://www.openip.org
OpenIPCore Project  http://www.openip.org/oc
OpenCores   Project  http://www.opencores.org

Article: 19905
Subject: Viterbi decoder in FPGA
From: mehmeto@my-deja.com
Date: Mon, 17 Jan 2000 10:49:35 GMT
Links: << >>  << T >>  << A >>
  I have searched the net for a viterbi decoder implementation ( vhdl
source for FPGAs). I could not found any resources for free. VHDL codes
for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much
expensive. So, why is this staff so expensive? I mean viterbi decoders
are widely used and someone can easily find a cheap decoder IC. Can
somebody explain the reason?
  Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the
incoming data rate (kbits/s or Mbit/s)the main factor.
 I have found many C codes for viterbi decoders. How can I use them to
translate to VHDL or Verilog for FPGAs?

Thanks a lot


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19906
Subject: Re: Partly reprogrammable FPGAs
From: Jamil Khaib <Khatib@ieee.org>
Date: Mon, 17 Jan 2000 12:51:40 +0200
Links: << >>  << T >>  << A >>


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

You can visit my page to check about self-modiying logic at
http://www.geocities.com/SiliconValley/Pines/6639/fpga

>
> Any information is greatly appreciated!
>
> Regards,
>
> Arvind Shah
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 19907
Subject: Re: Random Number Generator
From: Etienne Racine <etienne@cae.ca>
Date: Mon, 17 Jan 2000 08:39:49 -0500
Links: << >>  << T >>  << A >>
Hello Ray,

Ray Andraka wrote:

> 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 few things on the subject can be noted:

Many LFSRs use only XOR gates to generate the pseudorandom sequences and in
this case, the all-0 state becomes the illegal state (thus resulting in the
2^n - 1 states); if all 2^n states are desired, then either the number of
bits used in the LFSR may be increased by one (then of course, states will
occur twice in a complete cycle) or a NOR may be done with every bit but the
MSB, then XOR'ed with the feedback (which is usually taken on the MSB).

Xilinx app note 052 shows a LFSR structure known as "type 1", where the XOR
(and other logic) gates introducing the pseudorandomness are not part of the
shift register itself; there is another structure called "type 2" which
respects the same polynomial expression but the XOR gates are placed
*within* the shifting path.

Type 2 LFSR will produce the same states but in a different order that will
eliminate the "time-delayed copy of the first bit" effect. Visually, they
look much more "random" than type 1 LFSRs since the variations occur on
multiple bits. Additionally, the combinatory delay introduced by type 2
LFSRs is usually much lower; the only delay introduced is the delay through
only one XOR.

Regards,

Etienne.
--
      ______ ______
*****/ ____// _  \_\*************************************************
*   / /_/_ / /_/ / /       Etienne Racine, Hardware Designer        *
*  / ____// __  /_/           Visual Systems Engineering            *
* / /_/_ / / /\ \ \              CAE Electronics Ltd.               *
*/_____//_/_/**\_\_\*************************************************


Article: 19908
Subject: Re: Viterbi decoder in FPGA
From: Ray Andraka <randraka@ids.net>
Date: Mon, 17 Jan 2000 14:02:17 GMT
Links: << >>  << T >>  << A >>
Engineering time to develop, verify and support a core is not
insignificant.  Consider what the cost would be for you to roll you own and
use that as a measure of the core's real cost.  I think with that in mind,
even at the prices you cite, the cores are a bargain.  That is assuming
they are fully verified on the target architecture, and that they come with
some semblance of support.  The FPGA cores business is a tough business to
make money in, for some reason people expect the cores to cost next to
nothing, and yet perform better than anythng they could develop in house.
What you are buying with a core is time to market, and possibly design
expertise you don't have in house.  Bottom line is you gets what you pays
for.

mehmeto@my-deja.com wrote:

>   I have searched the net for a viterbi decoder implementation ( vhdl
> source for FPGAs). I could not found any resources for free. VHDL codes
> for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much
> expensive. So, why is this staff so expensive? I mean viterbi decoders
> are widely used and someone can easily find a cheap decoder IC. Can
> somebody explain the reason?
>   Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the
> incoming data rate (kbits/s or Mbit/s)the main factor.
>  I have found many C codes for viterbi decoders. How can I use them to
> translate to VHDL or Verilog for FPGAs?
>
> Thanks a lot
>
> 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: 19909
Subject: Re: Random Number Generator
From: Ray Andraka <randraka@ids.net>
Date: Mon, 17 Jan 2000 14:11:07 GMT
Links: << >>  << T >>  << A >>
Quite true.  In Xilinx FPGAs, and other places where you might use a small
memory as a circular queue, the type 1 is more advantageous since there are
fewer places you need access to the shift register.  In many FPGAs, a two input
logic function has the same delay as a four input function, so the speed
difference is non-existant.  The sequence produced by the type 2 is the same as
the sequence generated by type 1 if you were to invert some of the outputs from
the type 1 LFSR, so while the output of a type 2 may appear more random,
adjacent bits still have a hig degree of correlation.

Etienne Racine wrote:

> Hello Ray,
>
> Ray Andraka wrote:
>
> > 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 few things on the subject can be noted:
>
> Many LFSRs use only XOR gates to generate the pseudorandom sequences and in
> this case, the all-0 state becomes the illegal state (thus resulting in the
> 2^n - 1 states); if all 2^n states are desired, then either the number of
> bits used in the LFSR may be increased by one (then of course, states will
> occur twice in a complete cycle) or a NOR may be done with every bit but the
> MSB, then XOR'ed with the feedback (which is usually taken on the MSB).
>
> Xilinx app note 052 shows a LFSR structure known as "type 1", where the XOR
> (and other logic) gates introducing the pseudorandomness are not part of the
> shift register itself; there is another structure called "type 2" which
> respects the same polynomial expression but the XOR gates are placed
> *within* the shifting path.
>
> Type 2 LFSR will produce the same states but in a different order that will
> eliminate the "time-delayed copy of the first bit" effect. Visually, they
> look much more "random" than type 1 LFSRs since the variations occur on
> multiple bits. Additionally, the combinatory delay introduced by type 2
> LFSRs is usually much lower; the only delay introduced is the delay through
> only one XOR.
>
> Regards,
>
> Etienne.
> --
>       ______ ______
> *****/ ____// _  \_\*************************************************
> *   / /_/_ / /_/ / /       Etienne Racine, Hardware Designer        *
> *  / ____// __  /_/           Visual Systems Engineering            *
> * / /_/_ / / /\ \ \              CAE Electronics Ltd.               *
> */_____//_/_/**\_\_\*************************************************

--
-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: 19910
Subject: Re: Xilinx Spartan2
From: Greg Neff <gregneff@my-deja.com>
Date: Mon, 17 Jan 2000 16:13:43 GMT
Links: << >>  << T >>  << A >>
In article <tUL80GAvG+f4EwE7@matter200.demon.co.uk>,
  dmac <dmac@cutme.matter200.demon.co.uk> wrote:
>
> 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
>

Again, I agree that the junction temperature is the correct way to rate
an FPGA.  I am not trying to argue that Xilinx should specify parts
using ambient temperature, because it is obvious that the power
dissipation is unknown by Xilinx.

The point that I was trying to make is that the 15 degree margin
assumed by the timing specifications (relative to normal rated ambient
operating temperature ranges) can easily be exceeded by an FPGA with a
fast clock.  As a result, the engineer is responsible to know what the
junction temperature is.  The real question is how to do this with a
high level of confidence.  How many FPGA's do you have to measure, and
from how many lots, before you can say that you have adequately
characterized power consumption and thermal performance for any given
design?  What is the correct measurement point on each package for the
theta JC?  Does device orientation affect the specifications or
readings? What effect does PCB construction have? How much margin needs
to be applied to account for tolerance in theta JC and theta JA
specifications? Can we take reliable temperature measurements using
input ESD protection diodes?

I'm sure that Xilinx has a complex and proprietary methodology for
establishing timing specifications based on characterizing devices
under carefully controlled conditions.  The problem is that this
methodology does not extend into the field, where the application
junction temperature has to be known and characterized.

I'm not saying that this is the responsibility of Xilinx, but it sure
would be nice if Xilinx would provide a guideline or methodology,
including measurement points and recommended apparatus, in order to
help engineers close the loop.

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


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19911
Subject: Verilog FAQ
From: rajesh52@hotmail.com
Date: Mon, 17 Jan 2000 19:09:35 GMT
Links: << >>  << T >>  << A >>
Greetings
 This is semimonthly announcement of Verilog FAQ.

 Verilog FAQ is located at
 http://www.angelfire.com/in/verilogfaq/

 Alternate Verilog FAQ is an attempt to gather the answers
 to most Frequently Asked Questions about Verilog HDL in
 one place. It also  contains list of publications, services,
 and products.

 Alternate Verilog FAQ is divided into three logical parts.

 Part 1 : Introduction and misc. questions
 Part 2 : Technical Topics
 Part 3 : Tools and Services

 What's New section outlines the changes in different versions
 and announcements. Links connects you to related
 informative
 links in internet.

 Your suggestions to make this FAQ more informative are
 welcome.

 Rajesh Bawankule
 (Also Visit Verilog Center :
 http://www.angelfire.com/in/rajesh52/verilog.html )



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19912
Subject: Wanted: Xilinx XCV400-6FG676C for prototype
From: "Dan Kuechle" <dan_kuechle@i-tech.com>
Date: Mon, 17 Jan 2000 19:33:06 GMT
Links: << >>  << T >>  << A >>
My Xilinx distributor screwed up and I'm in desperate need of a Xilinx
Virtex FPGA for a prototype so I can procede with de-bug.  Earliest
Xilinx says they can get me one is Feburary something.  Full part number
is XCV400-6FG676C although faster speeds (-5 or -4) or indistrial would 
be ok.  Need one or two IC's.  They must be new, never mounted, and in
vaccume packing.  Please respond via email:  dan_kuechle@i-tech.com
Thanks
   Dan

Article: 19913
Subject: Re: Viterbi decoder in FPGA
From: muzo <muzok@nospam.pacbell.net>
Date: 17 Jan 2000 17:06:31 EST
Links: << >>  << T >>  << A >>
Mehmet(?),
This stuff is expensive because staff is expensive :-). Design,
implementation and verification of such a core takes time and on top
of that such cores are valuable to the buyers so the price. You can
take the C code and write verilog yourself too or hire me to do it ;-)

mehmeto@my-deja.com wrote:

>  I have searched the net for a viterbi decoder implementation ( vhdl
>source for FPGAs). I could not found any resources for free. VHDL codes
>for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much
>expensive. So, why is this staff so expensive? I mean viterbi decoders
>are widely used and someone can easily find a cheap decoder IC. Can
>somebody explain the reason?
>  Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the
>incoming data rate (kbits/s or Mbit/s)the main factor.
> I have found many C codes for viterbi decoders. How can I use them to
>translate to VHDL or Verilog for FPGAs?
>
>Thanks a lot
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.

muzo

Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)
Article: 19914
Subject: Re: Xilinx Spartan2
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Mon, 17 Jan 2000 14:25:30 -0800
Links: << >>  << T >>  << A >>

Greg Neff wrote:
> 
<snipped from his *excellent* post which was a bit too long to quote>
>
> Can we take reliable temperature measurements using
> input ESD protection diodes?
> 

I've done some experiments along these lines and have to say that
it's pretty tricky to get believable measurements. Some notes:

1) The small changes in diode voltage drop due to temperature
are hard to measure accurately in a high-noise environment. Using
an input diode, either the power or ground rail are part of the
measurement circuit, and they have their own noisy voltage drops due
to bond wire resistance etc. The 2-wire connection used on
Virtex, Pentium, etc. is  MUCH better. Better yet would be
an on-chip temperature-to-digital (pulse width or frequency)
converter like the Maxim 6576/77 parts.

2) At least for the (non-Xilinx) chip I was playing with, the resistance
in series with the protection diode had a fairly large temperature coefficient,
opposite in sign from the diode, thus reducing the voltage swing over
temperature even further.

3) Relating the diode measurement to the actual junction
temperature requires calibrating the part - I used a water bath,
gradually raising it to boiling while taking measurements. This
is awkward.

4) Another experiment involved painting thermochromic liquid
crystals (they change color with temperature) onto the die of a
de-lidded device. It was easy to see large temperature gradients
across the chip, and quite easy to see hot spots, making me a bit
pessimistic about the usefulness of a single point measurement, especially
when taken at the edge of the die (usually the coolest part).

My worry about hot spots is that usual high-speed FPGA design practice
requires that the highest speed stuff be packed together in a small
area, with lower-speed logic spread out over the remainder
of the chip. If the heat spreading is poor, some areas could get
very hot indeed. What we need is a temperature sensor per CLB which
can be read while the part is operating, and of course some way to
feed the results back into the place and route software to spread
things out without violating timing constraints :)

5) I'll skip my regular (yearly?) rant about the lack of accurate power
estimation tools (like for example PowerMill, etc.) for FPGAs. And
then if they did exist, I'd be moaning about the cost. Better leave it
alone ...

Oh, here's a PowerMill description:
http://www.synopsys.com/products/etg/powermill_ds.html

regards,
Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3
Email:        tom.burgess@hia.nrc.ca
Article: 19915
Subject: Re: HW resources increased
From: seebs@plethora.net (Peter Seebach)
Date: Tue, 18 Jan 2000 00:01:47 GMT
Links: << >>  << T >>  << A >>
In article <85rla5$722$3@jetsam.uits.indiana.edu>,
Greg Alexander <galexand@sietch.bloomington.in.us> wrote:
>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.

It does, however, provide a limiting function; if the code is bad, it will
be much more likely to get fixed, much sooner.  Also, as a prospective user,
you can, if you really want, hire a good programmer to spend a day skimming
the code and give you a pretty good feel for the quality of the code; you
don't just have to look at a rigged demo and wonder.

-s
-- 
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Consulting & Computers: http://www.plethora.net/
Get paid to surf!  No spam.  http://www.alladvantage.com/go.asp?refid=GZX636
Article: 19916
Subject: Please help : Translogic's .ini files
From: dave_admin@my-deja.com
Date: Tue, 18 Jan 2000 00:10:00 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: 19917
Subject: Re: Random Number Generator
From: mushh@slip.net (Dave Decker)
Date: Tue, 18 Jan 2000 02:51:59 GMT
Links: << >>  << T >>  << A >>
Don't forget the built in OSC that has a very poor tempco. You could
possibly substitute the internal OSC for the RC discussed below.

Dave Decker
(I have only one h in my emal adr)

>snip


>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: 19918
Subject: Which VHDL synthesizer/compiler?
From: "MK Yap" <mkyap@REMOVE.ieee.org>
Date: Tue, 18 Jan 2000 11:30:33 +0800
Links: << >>  << T >>  << A >>
Hi all,

My current FPGA design is based on Altera Flex 10k. I'm designing using VHDL
& schematics.  However it seems that Max+plus2's VHDL compiler is not strong
enough. It can't do things like triggering up and down on the same signal on
2 separate different processes.

I tried xilinx foundation series's vhdl compiler (synopsis??) & synplify and
it works.  Why is it that max+plus2 is so much expensive than foundation
series by xilinx but the vhdl compiler is so weak?

I saw that there are quite a number of VHDL tools (compiler & simulator &
analysis tools) ard... synplicity, viewlogic, exampler, leonardo, modelsim,
synopsis, cadence....
Among all, i have used synplicity and found that it is cheap and fast.. for
those who have tried the rest before, can you pls give a short review of it
in terms of  ...the COST, speed, compatibity, powerful... ?Anyone has any
preference, pls feel free to share...

Thank you!!


MK




Article: 19919
Subject: CFP: The Second NASA/DoD Workshop on Evolvable Hardware
From: jlohn@kronos.arc.nasa.gov (Jason Lohn)
Date: 18 Jan 2000 09:06:02 GMT
Links: << >>  << T >>  << A >>

                           Call for Papers

          The Second NASA/DoD Workshop on Evolvable Hardware

                          July 13 - 15, 2000
                   Silicon Valley, California, USA

                   http://ic.arc.nasa.gov/ic/eh2000

Sponsored by:
   National Aeronautics and Space Administration (NASA)
   Defense Advanced Research Projects Agency (DARPA)

Hosted by:
   NASA Ames Information Sciences and Technology Directorate 
   JPL Center for Integrated Space Microsystems (CISM)

Evolvable hardware is an emerging field that applies simulated
evolution to the design and adaptation of physical structures,
particularly electronic systems.  The Second NASA/DoD Workshop on
Evolvable Hardware (EH-2000) will bring together leading researchers
and technologists from academia, government, and industry to discuss
advances and the state-of-the-art in this field.

Evolvable hardware techniques enable self-reconfigurability and
adaptability of programmable devices and thus have the potential to
significantly increase the functionality of deployed hardware systems.
Moreover, these techniques have the potential to reduce costs by
automating numerous design and optimization tasks encountered in
engineering design.

A focus of this year's workshop is on real-world applications of
evolvable hardware.  Current application areas include adaptive and
reconfigurable computing, circuit and antenna design, and evolutionary
robotics.  Evolvable hardware methods could also be effective in
dealing with increased complexity and reliability requirements in
areas such as sensors, MEMS, biomolecular design, quantum computing,
and nanoelectronics.

Topics to be covered include, but are not limited to:

      - Evolutionary hardware design (including mechanical and robotic
          systems, electronic circuit synthesis)
      - Real-world applications of evolvable hardware
      - Co-evolutionary methods
      - Online and offline evolution methods
      - Hardware/software co-evolution 
      - Testbeds and evolutionary design automation tools
      - Self-repairing hardware 
      - Self-reconfiguring hardware
      - Embryonic hardware 
      - Morphogenesis 
      - Novel devices and hardware platforms suitable for evolution 
      - Adaptive hardware, adaptive computing 
      - Adaptive flight hardware 



Important Dates:
  Submission deadline:                  March 17, 2000
  Author notification:                  April 17, 2000
  Camera ready manuscript deadline:     May 15, 2000
  Workshop:                             July 13-15, 2000


Submission of Papers:
  Please see the workshop web page at http://ic.arc.nasa.gov/ic/eh2000


Chair:	Jason Lohn, NASA Ames Research Center

Co-Chair:  Adrian Stoica, Jet Propulsion Laboratory

Program Co-Chairs:
  Silvano Colombano, NASA Ames Research Center
  Didier Keymeulen, Jet Propulsion Laboratory

Program Committee:
  Leon Alkalai, Jet Propulsion Laboratory (USA)
  Forrest H Bennett III, FX Palo Alto Laboratory (USA) 
  Neil Bergmann, Queensland University of Technology (Australia)
  Hugo de Garis, Starlab (Belgium)  
  Stuart J. Flockton, University of London (UK)
  Terry Fogarty, South Bank University (UK)
  David B. Fogel, Natural Selection, Inc. (USA) 
  James A. Foster, University of Idaho (USA)
  Pauline Haddow, Norwegian University of Science and Technology (Norway)
  Inman Harvey, University of Sussex (UK) 
  Hitoshi Hemmi, NTT Communication Science Labs (Japan) 
  Tetsuya Higuchi, Electrotechnical Laboratory (Japan) 
  Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
  Alan Hunsberger, National Security Agency (USA)
  Rich Katz, NASA Goddard Space Flight Center (USA) 
  John Koza, Stanford University (USA)
  Daniel Mange, Swiss Federal Institute of Technology (Switzerland) 
  Pierre Marchal, Swiss Center for Electronics & Microtechnology (Switzerland)
  Meyya Meyyappan, NASA Ames Research Center (USA)
  Julian Miller, University of Birmingham (UK)
  Masahiro Murakawa, Electrotechnical Laboratory (Japan) 
  Jordan Pollack, Brandeis University (USA)
  Edward Rietman, Lucent Technologies (USA)
  Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland) 
  Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
  Adrian Thompson, University of Sussex (UK) 
  Anil Thakoor, Jet Propulsion Laboratory (USA)
  Benny Toomarian, Jet Propulsion Laboratory (USA)
  Annie Wu, University of Central Florida (USA)
  Ricardo Zebulum, Jet Propulsion Laboratory (USA)
  Steven Zornetzer, NASA Ames Research Center (USA)


In Cooperation With:
  Numerical Aerospace Simulation (NAS) Systems Division, NASA Ames
  Computational Sciences Division, NASA Ames 
  Integrated Product Team, NASA Ames 
  Research Institute for Advanced Computer Studies (RIACS)


For further information please check the workshop web site or contact:
	
  Jason Lohn
  NASA Ames Research Center
  MS 269-1
  Mountain View, CA 94035, USA
  jlohn@ptolemy.arc.nasa.gov
  Tel: +1 (650) 604-5138
  Fax: +1 (650) 604-3594
Article: 19920
Subject: Cores interfaces
From: Jamil Khaib <Khatib@ieee.org>
Date: Tue, 18 Jan 2000 11:28:50 +0200
Links: << >>  << T >>  << A >>
In the new world of SOC and design reuse the IP cores should be able to
interface to each other easily. Some companies are trying to define
their own cores interfaces and sometimes do not publish it.

So we need to have a free open standard for cores interfaces that may be
become more powerfull and usable for all designers

Do you have any comments how to start defining these interfaces?

all what I know that there are two types Bus style or point-to-point
style but I do not know the advantages of each type.

If you are intrested in defining this kind of interfaces please join us
at openipcore project



Thanks
Jamil Khatib
OpenIP Organization  http://www.openip.org
OpenIPCore Project  http://www.openip.org/oc
OpenCores   Project  http://www.opencores.org



Article: 19921
Subject: Virtex to ASIC conversion
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 18 Jan 2000 11:58:25 +0000
Links: << >>  << T >>  << A >>
Does anybody know which ASIC vendors - if any - have dual-port
independently clocked RAM macros that match the Virtex's Block RAMs ?


Article: 19922
Subject: Re: Random Number Generator
From: Ray Andraka <randraka@ids.net>
Date: Tue, 18 Jan 2000 14:33:29 GMT
Links: << >>  << T >>  << A >>
One of the things I considered was looking at the phase of the internal
oscillator compared to an external clock, which would be random even with
the same conditions, and would have a pretty much uniform distribution.  To
do this, you need a fairly slow external clock (or divided clock), and
after the FPGA is configured count the number of cycles of the internal
oscillator until a specific transition of the external clock.  The slower
the external clock with respect to the oscillator, the better the
resolution.  Of course, for a slow clock, you want that independent of the
time you start configuration or the variance will again be small.

In any of these methods, the value obtained should be used as an initial
seed to a digital PN sequence generator so that the distribution of your RN
is controllable, even if the seed is not nicely distributed.

Dave Decker wrote:

> Don't forget the built in OSC that has a very poor tempco. You could
> possibly substitute the internal OSC for the RC discussed below.
>
> Dave Decker
> (I have only one h in my emal adr)
>
> >snip
>
> >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


Article: 19923
Subject: Re: Benchmarks
From: Brian Dipert <bdipert@NOSPAM.pacbell.net>
Date: Tue, 18 Jan 2000 06:56:35 -0800
Links: << >>  << T >>  << A >>
Michel,
Thanks for the pointer to my article. The direct URL is
http://www.ednmag.com/ednmag/reg/1999/052799/11cs.htm. Michael, make
sure you also check out the website-only  addendum to the article
(link in 'at a glance' section), and you might also find my '98
benchmarking of various synthesis tools to be of interest
(http://www.ednmag.com/ednmag/reg/1998/091198/19df2.htm and
http://www.ednmag.com/ednmag/reg/1998/050798/10df_01.htm)

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

Brian Dipert
Technical Editor: Memory, Multimedia and Programmable Logic
EDN Magazine: The Design Magazine Of The Electronics Industry
http://www.ednmag.com
Contributing Editor; CommVerge Magazine
http://www.commvergemag.com
1864 52nd Street
Sacramento, CA   95819
(916) 454-5242 (voice), (916) 454-5101 (fax)
***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY***
mailto:bdipert@NOSPAM.pacbell.net
Visit me at http://members.aol.com/bdipert
Article: 19924
Subject: Re: Partly reprogrammable FPGAs
From: Brian Dipert <bdipert@NOSPAM.pacbell.net>
Date: Tue, 18 Jan 2000 06:58:05 -0800
Links: << >>  << T >>  << A >>
Arvind,
Check out my reconfigurable logic article at
http://www.ednmag.com/ednmag/reg/1999/080599/16df2.htm. Feedback as
always appreciated

>
>
>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.
>>
>> 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.
>
>You can visit my page to check about self-modiying logic at
>http://www.geocities.com/SiliconValley/Pines/6639/fpga
>
>>
>> Any information is greatly appreciated!
>>
>> Regards,
>>
>> Arvind Shah
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.

Brian Dipert
Technical Editor: Memory, Multimedia and Programmable Logic
EDN Magazine: The Design Magazine Of The Electronics Industry
http://www.ednmag.com
Contributing Editor; CommVerge Magazine
http://www.commvergemag.com
1864 52nd Street
Sacramento, CA   95819
(916) 454-5242 (voice), (916) 454-5101 (fax)
***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY***
mailto:bdipert@NOSPAM.pacbell.net
Visit me at http://members.aol.com/bdipert


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