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 9475

Article: 9475
Subject: FPGA: Upcoming Seminars and Events
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Mon, 16 Mar 1998 11:45:08 -0800
Links: << >>  << T >>  << A >>
Topic:  Upcoming Seminars and Events for FPGA Users

April, 1998
===========

IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM'98)
15-17 April, 1998, Napa Valley, California, USA.

Cypress Semiconductor's VHDL Primer, 9 April, 1998. Web-based seminar
requires pre-registration and download.

Find out more on The Programmable Logic Jump Station at
http://www.optimagic.com/conferences.html#Apr98.



Article: 9476
Subject: Re: FPGA/VHDL design tools review < $10K
From: Richard Schwarz <aps@associatedpro.com>
Date: Mon, 16 Mar 1998 15:39:34 -0500
Links: << >>  << T >>  << A >>
You can evaluate our tools for free at:

http://www.associatedpro.com/aps



Stephen King wrote:

> Can anyone out there point me to an independent review of low cost (less
> than 10K dollars - preferably a lot less) FPGA vendor independent VHDL
> tools.
>
> Thanks
>
> Stephen King
> CRL
> sking@crl.co.uk



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

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

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


Article: 9477
Subject: Re: Ideas for an FPGA Project?
From: Richard Schwarz <aps@associatedpro.com>
Date: Mon, 16 Mar 1998 15:43:30 -0500
Links: << >>  << T >>  << A >>
A fairly simple project might be connectiong some AtoD converters to the
FPGA and filtering the inputs in the FPGA. You could then send them back
through D to As and into speakers or an oscilloscope or spectrum
analyzer.

For low cost tools and examples in order to complete your project you
might check our website at:

http://www.associatedpro.com/aps

Antonio Rosa wrote:

>    Hi, i would like to develop an one semester project with an FPGA.
> This project should make something with advantages when compared to
> microcontrollers/microprocessors such as working with multiple
> sensors.... does anybody has an idea?
>
>    Thanks!
>    Antonio Rosa
>
>
>    p.s: please email the idea
>
>
>
>   mail: arosa@mail.telepac.pt



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

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

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


Article: 9478
Subject: Free Printed Circuit Board Symposium
From: erik.kimball@mailexcite.com
Date: Mon, 16 Mar 1998 17:22:35 -0600
Links: << >>  << T >>  << A >>
Here's an upcoming event you may be interested in:

Praegitzer Technical Symposium
May 12, 1998, 7:30 a.m. - 3:00 p.m.
Sheraton Tara Hotel , Nashua, NH
An all-day event featuring discussions on important issues and trends in the
PCB industry.  Admission is free but space is limited to the first 400
respondents.

Email symposium@pii.cOm to reserve your seat today.

For more information, please contact Sonya Seyle via phone at 503.221.7421 or
email at sonya_seyle@kvo.c*m

Be sure to visit Praegitzer's Web site at http:www.pii.c*m

(Please replace "*" with an "o")

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
Article: 9479
Subject: Re: Xilinx could gaurd its secrets better (Re: Strange Xilinx question?)
From: "Mark Markham" <markm@cdepot.net>
Date: Mon, 16 Mar 1998 17:00:01 -0800
Links: << >>  << T >>  << A >>
Its hard to call companies like Xilinx "Meanies" for keeping its bitmaps
secret. It really ends up more a matter of protecting the customer. With a
bit of time and  test cases one can use the Xilinx software to decode the
memory map. I'm aware of several people who have (at least one
disasterously).
But the real issue is wheither an FPGA user can take advantage of it. One
not only needs to know what the bits does, but how the device is programming
those bits. There are a number of "illegal" programming combinations (things
that cause Vdd shorts!) for all FPGAs and knowing the memory bitmap doesn't
help you here.  Knowing the bitmap and the programming personality is what
the software is for.
Besides...how many people still pro
gram their computers in octal.



Article: 9480
Subject: Re: Strange Xilinx question?
From: gah@u.washington.edu (G. Herrmannsfeldt)
Date: 17 Mar 1998 01:00:12 GMT
Links: << >>  << T >>  << A >>
I was once working on such an application.  It was almost like the post
that needed to change a ROM.  The one I was working on was an array processor
where each processor element needed to have a look-up table programmed into
it.  But as mentioned, it isn't hard to find ROM tables and stuff the 
bits into the bitstream.  However, the design also needed a 16 bit binary
adder to add a constant.  To do this required finding the bits in the carry
logic, and modifying them to change the constant.  The extra logic to
store these constants (16 16 bit constants per XC4013) was not available.

However, the project never got built, so I didn't need to find out
where those bits were.  I do believe, though, that this is close to 
the "uncommon" application mentioned.  The required bits would be generated
by a program, based on an input file, so documentation would not be a
problem.

-- glen


Ed McCauley <edmccauley@bltinc.com> writes:

>This is a multi-part message in MIME format.
>--------------733CC5D50035A2854133574D
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit

>For all the "uncommon" applications so far presented, a modification of the
>original source followed by an M1 or PPR run with the guide option would have
>addressed the situations.  Standard, readable source, no long run times,
>consistent placement and timing results.

Article: 9481
Subject: Re: Strange Xilinx question?
From: Ed McCauley <edmccauley@bltinc.com>
Date: Mon, 16 Mar 1998 21:39:43 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------8B3ED71EEFE7B10CC7B9466E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



G. Herrmannsfeldt wrote:

> logic, and modifying them to change the constant.  The extra logic to
> store these constants (16 16 bit constants per XC4013) was not available.

Another solution could have been to create 1 16 bit rom (8 CLBS, 4013 has 576) and
simply apply the appropriate 4-bit address to select the needed constant.

Another could have been a 16-bit register that the uP could write to.

Another could have been a 16-bit RAM (8 or 16 CLBs depending on single or
dual-port) that the micro could write thus loading 16 constants at uP speeds and
then allowing the micro OR the Hardware to select which of the 16 constants to
use.

...... just throwing out food for thought for those currently in process ........

--
Ed McCauley
Bottom Line Technologies Inc.
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817


--------------8B3ED71EEFE7B10CC7B9466E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ed McCauley
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Ed McCauley
n:              McCauley;Ed
org:            Bottom Line Technologies Inc.
email;internet: edmccauley@bltinc.com
title:          President
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------8B3ED71EEFE7B10CC7B9466E--

Article: 9482
Subject: Re: Strange Xilinx question?
From: husby@fnal.gov (Don Husby)
Date: Tue, 17 Mar 1998 14:14:09 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> wrote:
> The designer who created the FPGA-based design obviously knows what's
> going on in the design, and the GUI can show it in excruciating detail.
> Giving him/her the meaning of gezillion configuration bits adds no new
> information. Only the rip-off artist would profit...

This is not true.  Several people have posted applications where it would
be very helpful to have access to the bit-stream mechanics.  I, for one, face
a problem where I will have 1024 front-end FPGA chips that will gather data
and encode it.  Each of these chips is nearly identical with the exception of
of a few ID bits and translation tables.  

Now, one could imagine a bunch of ways of maintaining this, but none of them
would be as simple and elegant as having software-level access to the 
bitstream generation.  If Xilinx wants to do more than pay lipservice to the 
concept of reconfigurable computing, it will eventually have to provide such
a facility.

Note that this doesn't mean that I want to disassemble existing bits streams.



--
Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
Fermi National Accelerator Lab                      Fax: 630-840-5406
Batavia, IL 60510
Article: 9483
Subject: Re: Xilinx could gaurd its secrets better (Re: Strange Xilinx question?)
From: galibert@pobox.com (Olivier Galibert)
Date: 17 Mar 1998 15:47:45 GMT
Links: << >>  << T >>  << A >>
In article <6ekihr$5j4@pumpkin.cdepot.net>, Mark Markham wrote:
>Besides...how many people still program their computers in octal.

To use your analogy, there is still a lot of people who :
- debug programs are asm level
- try to make compilers/assemblers better

  OG.
Article: 9484
Subject: Re: Strange Xilinx question?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 17 Mar 1998 08:09:45 -0800
Links: << >>  << T >>  << A >>
Don Husby wrote:

>  .......Several people have posted applications where it would
> be very helpful to have access to the bit-stream mechanics.  I, for
> one, face
> a problem where I will have 1024 front-end FPGA chips that will gather
> data
> and encode it.  Each of these chips is nearly identical with the
> exception of
> of a few ID bits and translation tables.

 The location of the look-up table bits has always been available from
Xilinx
( under non-disclosure, but I am working on simplifying that ) . There
are not many requests, perhaps it is not widely known. The remaining 90%
of the configuration bits control the interconnect structure ( remember:
"We sell interconnect, the logic is free") are not divulged.
So I think we can satisfy every reasonable requirement.

Peter Alfke, Xilinx Applications.

Article: 9485
Subject: JOB > AZ Digital FPGA Modem Design
From: "Hi Tech Jobs" <clientserver@msn.com>
Date: Tue, 17 Mar 1998 10:12:38 -0800
Links: << >>  << T >>  << A >>
Princeton Information < www.princetoninformation.com > is seeking
Ten (10) Senior Digital Design Engineers............

Digital FPGA Hardware Engineer -High Speed Digital Modem Technology

Job Description:

You will participate in the design and development of a flexible
communications system breadboard utilizing FPGA's (ASIC) for
Motorola's Celestri (tm) Modem Technology development program.
These are specialized high-speed modems (Mbps) installed in satellites.

Celestri is a multi-year, $13 billion project that will provide
high-bandwidth packet switching -
connections (e.g., internet) in outer SPACE!!!

Celestial Data Communications for the 21st Century!!!

BS/MS in Electrical Engineering +4 to 6 years of experience required.
Familiarity with FPGA based design limitations and mitigation methods.
Willingness to accept responsibility & technical challenge
Ability to work independently and on a team
Focus on customer satisfaction

Location:  Phoenix/ Chandler,  AZ
Duration:  Full Time Salary and Temp to Permanent or out right contract
consulting
Pay Rate: Open

See our Website: < www.princetoninformation.com >

Email your resume TODAY!!! => < clientserver@msn.com >

Princeton Information
1201 South Alma School #1125
Mesa, Arizona  85210
(602) 655-7600
FAX => (602) 655-7052




























Article: 9486
Subject: POSITION IN RECONFIGURABLE COMPUTING
From: mbaxter <mbaxter@rsv.ricoh.com>
Date: Tue, 17 Mar 1998 11:45:23 -0800
Links: << >>  << T >>  << A >>
		SENIOR SOFTWARE ENGINEER POSITION

Ricoh Silicon Valley is engaged in an innovative image computing project
involving FPGAs. We have need for a Senior Software Engineer to join a
small team of hardware and algorithm specialists in research in novel
FPGA-based reconfigurable computing. 

The complete job description of duties and responsibilities can be viewed
at our Web site at:
http://www.crc.ricoh.com/jobs/ssejob.html

To apply, please fax resumes to 650-854-8740, Attn: HR dept., or send
e-mail to jobs@crc.ricoh.com.

We will attend FCCM'98 in Napa Valley, CA April 15-17, and would be happy
to meet applicants at that time.

The California Research Center of Ricoh Silicon Valley, Inc. is a small
lab focusing on information technologies for future office automation
environments, such as image compression, uses of the world wide web and
document technologies. The lab is very close to Stanford University and in
easy driving distance to San Francisco, San Jose, and Santa Cruz, and many
Bay Area natural and cultural attractions.

Ricoh Silicon Valley is an equal opportunity employer and encourages
qualified women and minorities to apply. Applications must already be
qualified to work in the USA. Further information is available at:
http://www.crc.ricoh.com.

Specific questions can be addressed to mbaxter@rsv.ricoh.com


Article: 9487
Subject: Re: Strange Xilinx question?
From: Rick Collins <spamgoeshere1@yahoo.com>
Date: Tue, 17 Mar 1998 20:32:51 -0500
Links: << >>  << T >>  << A >>
Don Husby wrote:

> Peter Alfke <peter.alfke@xilinx.com> wrote:
> This is not true.  Several people have posted applications where it would
> be very helpful to have access to the bit-stream mechanics.  I, for one, face
> a problem where I will have 1024 front-end FPGA chips that will gather data
> and encode it.  Each of these chips is nearly identical with the exception of
> of a few ID bits and translation tables.
>
> Now, one could imagine a bunch of ways of maintaining this, but none of them
> would be as simple and elegant as having software-level access to the
> bitstream generation.  If Xilinx wants to do more than pay lipservice to the
> concept of reconfigurable computing, it will eventually have to provide such
> a facility.
>
> Note that this doesn't mean that I want to disassemble existing bits streams.

I guess I am missing something. Why can't you diddle the bits for the ID and
translation tables using the XACT design editor? This tool allows you to edit by
hand the LUT contents, the CLB configuration and all of the interconnect. Why is
this not sufficient for your needs? Certainly you can generate a unique bitstream
from the XNF file (or what ever it is at this point in the design process). The
only limitation would be going backwards from the bitstream to the XACT design
editor. I doubt if Xilinx supports that.

Rick Collins

redsp@yahoo.com



Article: 9488
Subject: Re: The case for Linux and EDA
From: "rk" <stellare@erols.com.NOSPAM>
Date: 18 Mar 1998 01:40:46 GMT
Links: << >>  << T >>  << A >>
rk:
: >it goes on to say that the "pc-based quicktools plus 7.0 offers
schematic
: >engry, p&r, timing analysis, and 3rd party tool interfaces." - available
: >for $495.  the quickworks package for windows available for $2,995.
: >
: >not recommending anything but it is in line with this discussion about
eda
: >tools, platforms, and markets and a data point.
: >
: >and note that the synplicity program is available for quite a bit less $
: >with a lot of other eda capability too, for this environment. 
interesting.
 
stu:
: But, does this have something to do with the long standing
: relationship between Synplicity and Quicklogic. I wouldn't be
: surprised if Quicklogic had some involvement at the start-up and so
: lever appropriate access to the product at low (or possibly zero?)
: cost.
: 
: I presume it'll only support QL devices, and won't be upgradeable to
: other vendors, will it?

rk:
hi stu,

still can't quite fully answer your question as i don't know if synplicity
bundles with any other vendors, but i do have more information about
pricing for this product, giving us a nice sample.  here are the relative
price levels for the same product, with over an order of magnitude
difference from top to bottom (iirc, top two lines are tied in $):

	unix
	pc/win - floating
	pc/win - node locked   (1/2 the line above)
	pc/win - single vendor <---- new point, ~ 40% of line above 
	                                        (no discount on hdl analyst
though)
	pc/win - bundled w/ q-logic s/w + tools ( $3k for the whole bundle)

anyways,

just some data.

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------	
Article: 9489
Subject: Test
From: Azeddien Sllame <Sllame@dcse.fee.vutbr.cz>
Date: Wed, 18 Mar 1998 10:30:51 +0100
Links: << >>  << T >>  << A >>
Hi,
   I am looking to use Ram capability in XC4000 family, How can I access
and use it. e.g. for arithmatic operations.
Thanks
Article: 9490
Subject: Synthesizable SDRAM-Controller wanted!
From: Martin Vorbach <Martin.Vorbach@SCRAP.de>
Date: Wed, 18 Mar 1998 12:40:12 +0100
Links: << >>  << T >>  << A >>
I=B4m looking for a SYNOPSIS synthesizable SDRAM-controller=20

- for up to 143 MHz clock frequency (an integrated PLL for programmable
   clock-rates would be great)=20
- and SDR support (DDR support would be great to)

The macro will be implemented in 0.25um ASIC technology.


Can somebody give me a contact address or company name?

Thank you!
Martin Vorbach

martin.vorbach@scrap.de
Fon +49 721 97243 35
Fax +49 721 97243 28



Article: 9491
Subject: Re: Strange Xilinx question?
From: husby@fnal.gov (Don Husby)
Date: Wed, 18 Mar 1998 13:52:39 GMT
Links: << >>  << T >>  << A >>
 spamgoeshere1@yahoo.com wrote:
> I guess I am missing something. Why can't you diddle the bits for the ID and
> translation tables using the XACT design editor? This tool allows you to edit  by
> hand the LUT contents, the CLB configuration and all of the interconnect. Why
> is this not sufficient for your needs? Certainly you can generate a unique
> bitstream from the XNF file (or what ever it is at this point in the design process).
>  The only limitation would be going backwards from the bitstream to the XACT design
> editor. I doubt if Xilinx supports that.

As I said, there are many proposed solutions to this problem.  The idea of 
editing 1024 versions of the chip with the Xact editor each time I make even a 
minor design change is probably the least desirable of any that I could think 
of.



--
Don Husby <husby@fnal.gov>                        Phone: 630-840-3668
Fermi National Accelerator Lab                      Fax: 630-840-5406
Batavia, IL 60510
Article: 9492
Subject: Re: Xilinx XACT 6.01 crack
From: "Rambutwa Gooberundi" <rambog@camelnet.com.in>
Date: 18 Mar 1998 16:32:51 GMT
Links: << >>  << T >>  << A >>
Oh, Thank you!

Do you happen to have one for Viewlogic ;-)  That is an even much more
annoying key!  I hear it can not be cracked...

Article: 9493
Subject: Open IP
From: Martin Vorbach <Martin.Vorbach@SCRAP.de>
Date: Wed, 18 Mar 1998 17:40:01 +0100
Links: << >>  << T >>  << A >>
we have found an organization called OpenIP to trade and exchange
IP without any fee or only less fee.

Main goal is the development of cores and IP by multiple parties, which
exchange the source and development using a web page. For managing the
development we use a configuration-management software sponsored by
Perforce Inc. (http://www.perforce.com).

Our starting project is the further development of the Amulet-software,
which
was developed until some months by Brad Myers et. al. from Carnegie
Mellon=20
University (http://www.cs.cmu.edu/~amulet).

Everybody, who is interested in participating on the development of =
free
cores
and IP should contact me. Also developers or companies, which are able
to=20
share developments for free or less fee should contact me.
Also I=B4m interested in response by people which are looking for free
cores,
so that we can find out, which parts are required for developing.

The development of the cores should be done using VERILOG or VHDL.


BUT: WE DO NOT WANT TO TRADE OR EXCHANGE ILLEGAL OR
HACKED SOFTWARE OR CORES. SUCH REQUESTS WILL BE REJECTED
AND WE WILL CONTACT THE MANUFACTURER OF THIS PARTS!


The organization is up to now sponsored by three parties
1. Realax Software AG, a virtual reality software company
(http://realax.com)
2. Perforce Inc., which develops configuration-management software
(http://www.cs.cmu.edu/~amulet)
3. SCRAP GmbH, which develops computer hard- and software.
We are still looking for more sponsors.


We are still using the SCRAP-homepage to start the project. Later on we
will use a
server by the address http://www.OpenIP.org, but this is still under
development.


Best regards
Martin Vorbach

martin.vorbach@scrap.de
Fon +49 721 97243 35
Fax +49 721 97243 28




Article: 9494
Subject: Re: Strange Xilinx question?
From: jhallen@world.std.com (Joseph H Allen)
Date: Wed, 18 Mar 1998 17:34:54 GMT
Links: << >>  << T >>  << A >>
In article <350F2442.485B9D00@yahoo.com>,
Rick Collins  <spamgoeshere1@yahoo.com> wrote:
>Don Husby wrote:
>
>> Peter Alfke <peter.alfke@xilinx.com> wrote:
>> This is not true.  Several people have posted applications where it would
>> be very helpful to have access to the bit-stream mechanics.  I, for one, face
>> a problem where I will have 1024 front-end FPGA chips that will gather data
>> and encode it.  Each of these chips is nearly identical with the exception of
>> of a few ID bits and translation tables.
>>
>> Now, one could imagine a bunch of ways of maintaining this, but none of them
>> would be as simple and elegant as having software-level access to the
>> bitstream generation.  If Xilinx wants to do more than pay lipservice to the
>> concept of reconfigurable computing, it will eventually have to provide such
>> a facility.
>>
>> Note that this doesn't mean that I want to disassemble existing bits streams.
>
>I guess I am missing something. Why can't you diddle the bits for the ID and
>translation tables using the XACT design editor? This tool allows you to edit by
>hand the LUT contents, the CLB configuration and all of the interconnect. Why is
>this not sufficient for your needs? Certainly you can generate a unique bitstream
>from the XNF file (or what ever it is at this point in the design process). The
>only limitation would be going backwards from the bitstream to the XACT design
>editor. I doubt if Xilinx supports that.

I think what he wants is to take all of the possible bitstreams for his
application (each generated with XDE), XOR them together and store the
differences from a "master" one.  It would be a kind of compression...

Someone should write a program to automate this process...  I.E., it would
generate a test design, run makebits and store the xor difference between
the result and a blank design.  This would probably get you pretty close to
a reverse engineered bit-stream format.  Then you just need to adapt a few
of those berkeley tools, and voila, a freeware xilinx design system :-)

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 9495
Subject: Re: Suggestions on synthesis/simulation packages under $10K
From: Joel Kolstad <Joel.Kolstad@Techne-Sys.Com>
Date: Wed, 18 Mar 1998 10:24:02 -0800
Links: << >>  << T >>  << A >>
> Which version of NT were you trying to run PeakVHDL on?

Same as you... NT 4.0 with SP 3.

> I have been using
> PeakVHDL (4.21a) on NT4 + service pack3 for some time now and it is more stable
> than some of Microsoft's own products. As described in the service pack 3
> readme file you have to reinstall the service pack each time you install a new
> application.

You only have to reinstall SP 3 each time you install a new application that
overwrites something that SP 3 upgraded!  Anyway, David Pullerin from Accolade can
reproduce it and is busily investigating its cause.  He's been working at it for
awhile now, and if it were as simple as reinstalling service pack 3, I think he
would already have it licked.

---Joel Kolstad


Article: 9496
Subject: Linux and Xchecker
From: akeiser@ews.uiuc.edu (keiser anthony lynn)
Date: 18 Mar 1998 21:04:42 GMT
Links: << >>  << T >>  << A >>
  Greetings,

  I am trying to make an xchecker download program to run on Linux.
I have found the schematics on Xilinx's web page, but can find no
information on any of the "commands" that are obviously being stored
in the XC3042 and/or SRAM.  Any help you can provide would be 
appreciated.

  Thanks in advance.

--
Tony L. Keiser
The Department of Electrical and Computer Engineering
The University of Illinois in Urbana-Champaign
<a href="http://www.students.uiuc.edu/~akeiser">Lame Page</a>
Article: 9497
Subject: Cypress ISR
From: "Rob Semenoff" <robert_semenoff@phoenix.com>
Date: 18 Mar 1998 21:47:33 GMT
Links: << >>  << T >>  << A >>
Hi,
I would like to know if anyone else has been using the cypress ISR
(in-circuit reprogrammable) CPLDs and would have any comments on their
download cable 
device programmer and programming the devices in general. 
One thing I have found is that the error messages from the programming
software are 
innaccurate, but I won't be able to try programming a device until I can
get a 
prototype board built - and I don't want to commit to the cypress part in
my design
if it turns out their system is flaky.

Any comments appreciated,

-Rob
Article: 9498
Subject: Re: Cypress ISR
From: janovetz@ews.uiuc.edu (Jacob W Janovetz)
Date: 19 Mar 1998 03:08:40 GMT
Links: << >>  << T >>  << A >>
"Rob Semenoff" <robert_semenoff@phoenix.com> writes:

>Hi,
>I would like to know if anyone else has been using the cypress ISR
>(in-circuit reprogrammable) CPLDs and would have any comments on their
>download cable 
>device programmer and programming the devices in general. 
>One thing I have found is that the error messages from the programming
>software are 
>innaccurate, but I won't be able to try programming a device until I can
>get a 
>prototype board built - and I don't want to commit to the cypress part in
>my design
>if it turns out their system is flaky.

>Any comments appreciated,

>-Rob

I've used them and they seem fine.  Make SURE you put a decoupling
capacitor (0.1uF or so) on the programming voltage pin on your side
(near your part).

   Cheers,
   Jake

--
   janovetz@uiuc.edu    | Once you have flown, you will walk the earth with
 University of Illinois | your eyes turned skyward, for there you have been,
                        | there you long to return.     -- da Vinci
        PP-ASEL         | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9499
Subject: Re: Ideas for an FPGA Project?
From: Guitar Man <abuse@erols.com>
Date: Wed, 18 Mar 1998 23:32:01 -0500
Links: << >>  << T >>  << A >>
Antonio Rosa wrote:

>    Hi, i would like to develop an one semester project with an FPGA.
> This project should make something with advantages when compared to
> microcontrollers/microprocessors such as working with multiple
> sensors.... does anybody has an idea?
>
>    Thanks!
>    Antonio Rosa
>
>
>    p.s: please email the idea
>
>
>
>   mail: arosa@mail.telepac.pt

Something I have wanted to do for a long time is to make a pulse width
modulated analog output from a digital signal. For this you will need a
very high speed clock. 100 MHz is not too high. The samples that you
want to D to A are loaded into a counter and counted down. A second
counter counts through the maximum period. The first counter outputs a 1
until it reaches a count of 0 when it outputs a 0. This output remains
at 0 until the second counter reaches a count of 0. Then the next sample
is loaded and the process repeats.

This will produce a pulse with an average DC level proportional to the
sample loaded into the counter. With an appropriate low pass filter on
the output, this should produce reasonable sound without analog
amplifiers.

The limitation of this design is that you need an extremely high speed
clock to reach the upper limit of human hearing with reasonable dynamic
range. For example, 16 bits require 65536 clock pulses per sample X
40,000 sample per second = 2,560,000,000 Hz or 2.5 GHz clock speed. But
at telephone quality, 12 bits, 4,096 x 8,000 = 32,000,000 Hz or 32 MHz.
This is within the range of an FPGA.

It would allow the production of audio without ADC, analog amps, ect. A
simple LC filter should be enough to smooth the output. This can be
improved by using a pulse train that interleaves the 1's and the 0's of
each clock cycle to produce a higher speed pulse train than the audio
sample rate. This could be a very good class project.

Rick Collins

redsp@yahoo.com






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