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 775

Article: 775
Subject: Questions of implementing asynchronous circuits using FPGAs.
From: cheng@news.cs.columbia.edu (Fu-Chiung Cheng)
Date: 27 Feb 1995 22:21:50 -0500
Links: << >>  << T >>  << A >>

We are considering implementing asynchronous circuits using FPGAs.
We need to choose FPGAs such that hazard-free logic can be realized
and the FPGAs can be reprogrammable in circuits.

The following are in-circuit reprogrammable FPGAs we know right now:

Company    Family 	WWW
========== ============ ==========================================
Xilinx     LCA	 	
Plessey    ERA		
AMD        		
Atmel 	   CLi		
AT&T	   Orca
Altera	   Flex,UTFPGA1 http:\\www.altera.com
Toshiba	   
Algotronix CAL,Triptych  
========== ============	==========================================


Question 1. Which of them are (seem to be) suitful for asynchronous circuits?

Question 2. Do you know any other products may be suitful for asynchronous 
	    circuits?

Question 3. Any experience or suggestion in implementing asynchronous circuits
	    with FPGAs are welcomed.

Question 4. Any Email-address, WWW, or tel. no. related to the above products 
	    are welcomed.
	    

	Thanks a lot in advance.

						-John
 					        Email: cheng@cs.columbia.edu


Article: 776
Subject: Re: Can I implement a digital PLL in an FPGA??
From: randraka@ids.net
Date: Tue, 28 Feb 95 13:45:49 GMT
Links: << >>  << T >>  << A >>
In Article <3ijrn8$c54@src-news.pa.dec.com>
murray@src.dec.com (Hal Murray) writes:
>In article <3ihku7$asj@mark.ucdavis.edu>, jwcollin@chorizo.engr.ucdavis.edu (Jeff Collins) writes:
>
>|> I understand that the combinatorial delays (especially the 6ns ones in 
>|> the slower part that I'm using) will lead to some tradeoffs in accuracy.  
>|> However, I really don't think that maximum clock rate should be a problem, 
>|> even with the -6 grade part.  My operating freqency is only 5MHz.
>|> 
>|> If my understanding is correct, is there a specific VCO chip that anyone
>|> would recommend?  If I'm completely off-base, and you're talking about
>|> some way to implement the entire loop within an FPGA, please let me know. 
>
>Most designers I know are willing to work pretty hard to avoid analog things like
>VCOs.
>
>Have you checked out Digital PLLs?  (Sorry, I don't have a good reference.)
>
>After you get the hang of it they are pretty simple.  The basic idea is to build a
>small/fast state machine to wait a while and then look for the next transition.  When
>it finds the transition, it emits the data bit and a valid signal, and restarts the
>scan.  If your state machine is running at nX the bit rate, you expect to see the
>transition after n clocks.  n-1 and n+1 are also reasonable.  They just mean that
>your clock has drifted a tick relative to the transmitting clock.
>
>5 MHz is 200 ns.  You want to sample at 10X or 16X.  That's 20 or 12.5 ns.
>You can also process 2 samples in parallel: 40 or 25 ns.  If you don't like cramming
>that into a corner of your FPGA, consider using a PAL.  (Think of it as trading the
>VCO for a PAL.)  The details probably depend upon what clocks you have available.
>
>You can probably work out the state machines by spending an evening with graph paper
>and pencil.
>
>Note that just parsing the received data stream is only half of the problem.  You
>also have to do something with it, like collect it into bytes and pass it on to some
>other digital logic.  That requires clocking and/or synchronizers.  You might, for
>example, modify the state machine to generate the clock that drives the next stage of
>the system rather than a valid bit.  That means the downstream logic might see
>shorter than average clock pulses...  But it is all digital so once you understand
>what is going on it is possible to check all the setup/hold times and be pretty sure
>your design will work.

A digital PLL is definitely the way to go.  For the clock rates you are 
looking at, putting the entire thing in a FPGA should be the definition of
simplicity.  It doesn't take up much space either: the counter in the loop is 
the biggest part.  The phase detector state machine is small (can be done with
just a few logic cells of what ever flavor your part is.  I did one a while 
back in a Cypress CY7C392 (Altera) which had a divide ratio of about 5K and 
recovered a quadrature clock and data using about 30% of the chip.  That left 
plenty of room on the chip for data error detection, a BCD to binary converter,
holding  registers for the 18bit result, a huge timer, and control logic.
 
The best part is you get rid of that pesky analog stuff with its associated
tolerance/noise/adjustments/voltages/etc problems in alot less real-estate. 

I can't direct you to any reference material on DPLL's, I can't really recall
seeing much anything on the subject.  As the first reply points out, these are
pretty easy to do.  No magic here.
 
Good Luck with your project.
 
-Ray Andraka
Chairman, the Andraka Consulting Group
401/884-7930    FAX 401/884-7950
email randraka@ids.net

The Andraka Consulting Group is a digital hardware design firm specializing in
obtaining the maximum performance from FPGAs.  Our services include complete
design, development, simulation, and integration of these devices and the
surrounding circuits.  We also evaluate, troubleshoot and improve existing
designs.  Please call or email for a brochure.
   


Article: 777
Subject: Call for Papers (2)
From: john@vcc.com (John Schewel)
Date: Tue, 28 Feb 1995 20:01:23 GMT
Links: << >>  << T >>  << A >>

_____________________________________________________________________________

ANNOUNCEMENT AND CALL FOR PAPERS  (2 of 2 calls) 
_____________________________________________________________________________

CONFERENCE ON

                     "Using Reconfigurable Technology  
                       for Rapid Product Development"
               

This conference is part of SPIE's International Symposium on

                         INTELLIGANT SYSTEMS AND ADVANCED MANUFACTURING 
    
       Symposium Chair: Paul S. Schenker, Jet Propulsion Lab 

To be held as part of Photonics East '95
                      Philadelphia, Pennsylvania USA
                      22-27 October 1995
                      (over 5000+ attendees at Boston, Photonics94)

Conference Chair: John Schewel, Virtual Computer Corp., 
                                jas@vcc.com   tel.(818)-342-8294

Program Committee: Peter Athanas, Virginia Polytechnic Institute
                                   & State Univ., athanas@vt.edu;
                   Brad Fawcett, Xilinx Corp., brad.fawcett@xilinx.com; 
                   Dave Kolmier, Data I/O Corp., davek@data-io.com;
                   John Watson, Viatek Corp., jlwatson@aol.com 


Reconfigurable technologies are new and valuable tools for both
the design and maunfacturing engineer. With the ever-changing needs 
in the marketplace and growing worldwide competition, manufacturers
must continually search for methods which accelerate the time to market. 
Current reconfigurable hardware platforms enable the use of this technology 
for electronic design in rapid product development and implementation.

This conference will present papers that illustrate applications
and techniques for using reconfigurable technology in the product design
and manufacturing cycles. 

Papers are solicited in the following and related areas:

-   reconfigurable digital components, and their use in
the product development cycle

-   reconfigurable analog components, and their use in
the product development cycle

-   applications and platforms utilizing reconfigurable
technology for rapid product development

-   applications and platforms utilizing reconfigurable
technology for testing, quality assurance, and manufacturing control


TO OBTAIN ALL CALLS FOR PAPERS ELECTRONICALLY
The calls for papers for all conferences in the Photonics East
symposium are available on SPIE Web
(http://www.spie.org/web/meetings/calls/), by anonymous FTP
(ftp://spie.org/meetings/calls/pe95*), or by e-mail file
retrieval (Send a message to info-optolink-request@spie.org with
the following in the message body:  send
[meetings.calls]pe95_conf*

For a printed call for papers or other information:
E-mail: spie@spie.org
Fax: 360/647-1445
Phone: 360/676-3290

PHOTONICS EAST DEADLINES
Paper Abstracts Due from Authors: March 27, 1995 (call chair)
Advance Programs due from Chairs: April 24, 1995
Course Descriptions due from Instructors: April 30, 1995
Manuscripts Due from Authors:
     August 1, 1995 (on-site books)
     September 25, 1995 (post-meeting books) 




Article: 778
Subject: Call for Papers
From: john@vcc.com (John Schewel)
Date: Tue, 28 Feb 1995 20:09:18 GMT
Links: << >>  << T >>  << A >>

_____________________________________________________________________________

ANNOUNCEMENT AND CALL FOR PAPERS  (1 of 2 calls) 
_____________________________________________________________________________

CONFERENCE ON

                     "Using Reconfigurable Technology for Solving 
                  the Computational and Signal Processing Bottlenecks"
               

This conference is part of SPIE's International Symposium on

             		INFORMATION, COMMUNICATIONS, COMPUTER &
                         TECHNOLOGIES, APPLICATIONS, & SYSTEMS
    
       Symposium Chair: Arun Netravalli, VP Research, Bell Labs, AT&T

To be held as part of Photonics East '95
                      Philadelphia, Pennsylvania USA
                      22-27 October 1995
                      (over 5000+ attendees at Boston, Photonics94)

Conference Chair: John Schewel, Virtual Computer Corp., 
                                jas@vcc.com   tel.(818)-342-8294

Program Committee: Peter Athanas, Virginia Polytechnic Institute
                                   & State Univ., athanas@vt.edu;
                   Brad Fawcett, Xilinx Corp., brad.fawcett@xilinx.com; 
                   Dave Kolmier, Data I/O Corp., davek@data-io.com;
                   John Watson, Viatek Corp., jlwatson@aol.com 


Reconfigurable technologies are new and valuable tools for the
development and rapid prototyping of future products. With the
ever-changing standards in the marketplace and growing worldwide
competition, one must continually search for methods which
accelerate the time to market. Current reconfigurable hardware
platforms enable the use of this technology for electronic design
in rapid product development and performance acceleration.

This conference will present papers that illustrate applications
and techniques for solving computational and signal processing
bottlenecks using reconfigurable technology in product design
and software acceleration.

Papers are solicited in the following and related areas:

-   reconfigurable digital components, and their use in
communications and image processing

-   reconfigurable analog components, and their use in
communications and image processing

-   applications and platforms utilizing reconfigurable
technology for rapid product development in communications and
image processing

-   applications and platforms utilizing reconfigurable
technology for high-speed computing.


Complete Symposium Programs

COMMUNICATIONS INTERFACING
Emerging High Speed LANs
Workstation & PC Interfacing
Information Protection & Network Security 
Standards & Common Interfaces for Information Systems 
>>>>Using Reconfigurable Technology for Solving the Computational
& Signal Processing Bottlenecks<<<<(conference above)

MULTIMEDIA SYSTEMS 
Creating Content for the Information Highway 
Indexing, Accessing & Processing Real Time Media Integration
Issues in Large Commercial Media Delivery Systems 

FULL SERVICE RESIDENTIAL NETWORKS 
Hybrid Fiber-Coax Systems
Multimedia, Full Service, Broadband Subscriber Networks
New Loop Architectures & Applications for Carriers & Providers
Software Infrastructure for Multi-Service Network Applications
Impact of Interactive Multimedia on Education & the Home 

ENTERPRISE SERVICES
Health Care Information Infrastructure
BB Technology & Services for Business & Institutional Users 
Video Conferencing & Desktop Video Communications

INFORMATION STORAGE AND MANAGEMENT
Devices & Architectures for High Capacity Rapid Access Storage
Coding & Signal Processing for Data Storage & Retrieval
Error Correction & Modulations Techniques for Magnetic Storage 
Digital Image Storage & Archiving Systems 
High Density Recording System Technologies

TELECOMMUNICATIONS EQUIPMENT ENGINEERING
Optical Network Engineering & Integrity
Laser Diode Technology for Fiber Optic Communications 
Photonic Packaging for Light Source-to-Fiber Coupling 
Emerging Components & System Technologies for All-Optical
   Photonic Systems 
All Optical Communications Systems: Architecture, Control, and
   Network Issues
SONET Equipment & Applications in Broadband Networks 
Fast Packet Technologies:  Frame Relay, SMDS, ATM 

WIRELESS GLOBAL COMMUNICATIONS
Cellular Technologies & Services
Enhanced Special Mobile Radio
Wireless Personal Communications Technologies & Services 
Wireless Data Communications

TO OBTAIN ALL CALLS FOR PAPERS ELECTRONICALLY
The calls for papers for all conferences in the Photonics East
symposium are available on SPIE Web
(http://www.spie.org/web/meetings/calls/), by anonymous FTP
(ftp://spie.org/meetings/calls/pe95*), or by e-mail file
retrieval (Send a message to info-optolink-request@spie.org with
the following in the message body:  send
[meetings.calls]pe95_conf*

For a printed call for papers or other information:
E-mail: spie@spie.org
Fax: 360/647-1445
Phone: 360/676-3290

PHOTONICS EAST DEADLINES
Paper Abstracts Due from Authors: March 27, 1995 (call chair)
Advance Programs due from Chairs: April 24, 1995
Course Descriptions due from Instructors: April 30, 1995
Manuscripts Due from Authors:
     August 1, 1995 (on-site books)
     September 25, 1995 (post-meeting books) 




Article: 779
Subject: Re: Can I implement a digital PLL in an FPGA??
From: lharold@mrc.uidaho.edu (Len Harold)
Date: 28 Feb 1995 21:04:28 GMT
Links: << >>  << T >>  << A >>
David Hough (dave@sectel.com) wrote:
: In article <3ihku7$asj@mark.ucdavis.edu>, jwcollin@chorizo.engr.ucdavis.edu (Jeff Collins) writes:

: |: I understand that the combinatorial delays (especially the 6ns ones in 
: |: the slower part that I'm using) will lead to some tradeoffs in accuracy.  
: |: However, I really don't think that maximum clock rate should be a problem, 
: |: even with the -6 grade part.  My operating freqency is only 5MHz.
: |: 
: |: If my understanding is correct, is there a specific VCO chip that anyone
: |: would recommend?  If I'm completely off-base, and you're talking about
: |: some way to implement the entire loop within an FPGA, please let me know. 
:
: Most designers I know are willing to work pretty hard to avoid analog things
: like VCOs.

Most definitely.

: Have you checked out Digital PLLs?  (Sorry, I don't have a good reference.)
:
: After you get the hang of it they are pretty simple.  The basic idea is to
: build a small/fast state machine to wait a while and then look for the next
: transition.  When it finds the transition, it emits the data bit and a valid
: signal, and restarts the scan.  If your state machine is running at nX the
: bit rate, you expect to see the transition after n clocks.  n-1 and n+1 are
: also reasonable.  They just mean that your clock has drifted a tick relative
: to the transmitting clock.

The problem is that serial data doesn't guarantee a data edge (assuming NRZ).
Along with the problems with acquiring, it makes the problem much more
difficult.  For one, during acquire n+/-1 will not be valid, and after a long
string of ones or zeros the same is true.

: 5 MHz is 200 ns.  You want to sample at 10X or 16X.  That's 20 or 12.5 ns.
: You can also process 2 samples in parallel: 40 or 25 ns.  If you don't like
: cramming that into a corner of your FPGA, consider using a PAL.  (Think of
: it as trading the VCO for a PAL.)  The details probably depend upon what
: clocks you have available.

10X is probably the lower limit for stablity (assuming real control of the 
generated clock), I prefer ~100X which is not really practical for most
applications.

: You can probably work out the state machines by spending an evening with 
: graph paper and pencil.

Or write a little VHDL or Verilog to generate the state machines.

: Note that just parsing the received data stream is only half of the problem.
: You also have to do something with it, like collect it into bytes and pass
: it on to some other digital logic.  That requires clocking and/or
: synchronizers.  You might, for example, modify the state machine to generate
: the clock that drives the next stage of the system rather than a valid bit.
: That means the downstream logic might see shorter than average clock pulses.
: But it is all digital so once you understand what is going on it is possible
: to check all the setup/hold times and be pretty sure your design will work.

This brings up another problem with intermittent bad samples.  The data
recovery needs to be smart enough not flip on a single bad sample.  As
well the clock shouldn't make a radical change to due to a bad sample.

We have found that an all digital PLL will take up most of a large FPGA.
I will post more after we have finished and published if there is a desire
to see such a post.

Len
--
 _______________________________________________________________________ 
|      __    ___    ___  _______    _____                               | 
|    /|  |  /\  \  /|  \|\   _   \/\   __\       Len Harold             | 
|   | |  |  \ \   - |   \ \  \_\ /_ \  \_/                              | 
|   | |   \  \ \  \ _|\  \ \   _   \ \  \___     Phone: 208-885-7034    |
|   | |    \  \ \__\/\ \__\ \__\ \__\ \_____\    Fax:   208-885-6840    | 
|   | |*    |  \/__/  \/__/\/__/\/__/\/_____/    Internet:              | 
|   |/\     |/\                                    lharold@uidaho.edu   | 
|    \/        \_/\     University of Idaho                             |
|    /|            |    Microelectronics Research Center                |
|   | |            |    NASA Space Engineering Research                 |
|   | |____________|    Center for VLSI System Design                   |
|   |/____________/     WWW[URL]: http://www.mrc.uidaho.edu/            |
|_______________________________________________________________________|


Article: 780
Subject: Setting up a Rapid Systems Prototyping Lab.
From: kwng@cs.cuhk.hk (Dr. K.W.Ng)
Date: 1 Mar 1995 01:46:18 GMT
Links: << >>  << T >>  << A >>
Hi,

We am setting up a Rapid Systems Prototyping Laboratory for doing research
into software/hardware tools for rapid prototyping of hardware/software
systems (based on FPGAs). We are especially interested in the rapid
prototyping of distributed multimedia applications. We would very much
like to hear your suggestions on the equipments setup (both hardware &
software) for this lab. Thank you in advance for your input.


Article: 781
Subject: FCCM95 conference: Info on US visit requested
From: kugel@mp-sun6.informatik.uni-mannheim.de (Andreas Kugel)
Date: 1 Mar 1995 09:49:07 GMT
Links: << >>  << T >>  << A >>
I' ll be at the FCCM95 conference in April, which will
be my first visit to US. I have some spare days before
to travel around.
If you wish to help with informations, tips or share
some time I'll send you a personal profile on request.

Cheers, Andreas


--------------------------------------------------------
Andreas Kugel                
Chair for Computer Science V      Phone:(49)621-292-5755
University of Mannheim            Fax:(49)621-292-5756
A5
D-68131 Mannheim
Germany
e-mail:kugel@mp-sun1.informatik.uni-mannheim.de
--------------------------------------------------------





Article: 782
Subject: slif2xnf or eqn2xnf
From: cemchp@faces.ula.ve (Charles Paez - CEMISID - ULA)
Date: Wed, 1 Mar 1995 23:42:33 GMT
Links: << >>  << T >>  << A >>

I am looking for a compiler or traslator tool in order to transform
a digital design described into SLIF format or EQN format to a file
in XNF format for digital design based on Xilinx FPGA's.

Any help will be appreciated. 

Charles R. Paez
Cemisid - Universidad de Los Andes
Merida - Venezuela
e-mail : cemchp@faces.ula.ve


Article: 783
Subject: Re: Real-time fractal gen in h/w
From: tomh@bambi.ccs.fau.edu (Tom Holroyd)
Date: 2 Mar 1995 03:10:26 GMT
Links: << >>  << T >>  << A >>
I just had a demo today of an SGI Onyx computer with a Sirius video box.
The Onyx has video in and out already, but the Sirius box gives it additional
mixing capabilities.

The Onyx can display live video on arbitrary 2D surfaces as a texture map!
We hooked up a camera and pointed it at the computer screen, and got some
nice feedback patterns after messing with the controls for a while.  One
difference is that the Onyx screen image showed a full frame (2 interlaced
fields) while the normal camera looped to monitor feedback goes at the 60
Hz field rate.	This slowed things down a bit more than I would like.
Perhaps it is adjustable.  We didn't play with the mixer yet, but I hope to
in the future.	It is certainly possible already with the Onyx to distort
the image via texture mapping onto an arbitrary surface.  We didn't try
this either, yet, but it would obviously add a new dimension.  Too bad the
Onyx costs $200K!

I did use it to digitize some frames from a feedback tape I had with me,
and these will soon appear on my web page.  An unusual feature there is
that it is possible to "derotate" the images produced in each field,
showing the effect of the nonlinear map more clearly.

Tom Holroyd
Program in Complex Systems and the Brain Sciences	   The basis of
Florida Atlantic University, Boca Raton, FL 33431 USA	   stability is
tomh@bambi.ccs.fau.edu					   instability.
The 9th Amendment of the U.S. Constitution:
"The enumeration in the Constitution, of certain rights, shall not be
construed to deny or disparage others retained by the people."



Article: 784
Subject: Re: Real-time fractal gen in h/w
From: spencer@hailwood.asd.sgi.com (Paul Spencer)
Date: 2 Mar 1995 04:23:08 GMT
Links: << >>  << T >>  << A >>
tomh@bambi.ccs.fau.edu says:
> One
> difference is that the Onyx screen image showed a full frame (2 interlaced
> fields) while the normal camera looped to monitor feedback goes at the 60
> Hz field rate.

Sirius can send either 60 fields per second, or 30 interlaced frames per
second, to texture memory (software selectable).

> Too bad the Onyx costs $200K!

Reality Station would be significantly cheaper than that, even with the
Sirius board.

....paul

-- 
Paul Spencer                 Silicon Graphics Advanced Graphics Division
spencer@sgi.com                                Mountain View, California


Article: 785
Subject: Limits on on-chip FPGA virtual computing
From: dong@icsl.ee.washinton.edu (Dong-Lok Kim)
Date: 2 Mar 1995 09:59:02 GMT
Links: << >>  << T >>  << A >>
Hi,

I happened to read a paper
	"Area & Time Limitations of FPGA-based Virtual Hardware",
	Osama T. Albaharna, etc, IEEE International Conference 
	on Computer Design 1994, pp. 184-189.
and found a quite interesting fact from it as follows:

The author says they found the FPGA area to implement certain set of circuits
has overhead of ~100 times compared to the fixed VLSI implementation. Also, the
delay overhead is ~10 times, so using the FPGA on the same die with a RISC core
would not be feasible with the current technology. (Please forgive me if 
I am misinterpreting his conclusion).

Another paper that attempts such an integration of FPGA and a CPU core on the
same chip was 
	"DPGA-Coupled Microprocessors: Commodity ICs for the Early 21st
	Century", Andre DeHon, IEEE Workshop on FPGAs for Custom Computing
	Machines, 1994, pp. 31-39.
Here, the author just seems to assume that the integration of the FPGA area
on the same die is feasible (very well phrased, but without any proof).

I just wonder if any of you want to discuss about the limits of this
idea (i.e., on-chip FPGA + CPU core) and the above papers. I can provide 
further information about the papers if you want. (Do the authors read this 
news group?)  


Thank you in advance.
--
Donglok Kim

ICSL (Image Computing Systems Lab)
Dept. of Electrical Eng., FT-10
University of Washington
Seattle, WA 98195

Phone) 543-1019
FAX)   543-0977


Article: 786
Subject: Re: Can I implement a digital PLL in an FPGA??
From: randraka@ids.net
Date: Thu, 2 Mar 95 13:36:19 GMT
Links: << >>  << T >>  << A >>
In Article <3j034s$rn6@newshound.uidaho.edu>
lharold@mrc.uidaho.edu (Len Harold) writes:
>David Hough (dave@sectel.com) wrote:
>: In article <3ihku7$asj@mark.ucdavis.edu>, jwcollin@chorizo.engr.ucdavis.edu (Jeff Collins) writes: >: |: I understand that the combinatorial delays (especially the 6ns ones in 

>: After you get the hang of it they are pretty simple.  The basic idea is to
>: build a small/fast state machine to wait a while and then look for the next
>: transition.  When it finds the transition, it emits the data bit and a valid
>: signal, and restarts the scan.  If your state machine is running at nX the
>: bit rate, you expect to see the transition after n clocks.  n-1 and n+1 are
>: also reasonable.  They just mean that your clock has drifted a tick relative
>: to the transmitting clock.
>
>The problem is that serial data doesn't guarantee a data edge (assuming NRZ).
>Along with the problems with acquiring, it makes the problem much more
>difficult.  For one, during acquire n+/-1 will not be valid, and after a long
>string of ones or zeros the same is true.
>
That is true, however, I got around the problem as follows.  My phase detect
state machine required 15 consecutive samples at the same logic level before
signalling a transition.  My divider was set to approximately match the
expected buried clock, and would free run in the absence of a detected
transition.  The divider provided a data sample pulse and quadrature clock
outputs so that the data got sampled a few times and 'voted' on well away from
the transition region.  If I remember right, the divider also prevented a data
transition detection except within a window of the divider count.  This
kept the thing from going ape if there was a radical shift in the incoming
phase.  In my case, I had a pretty big ratio between the sample clock and the
data clock so I had the luxury of a lot of samples and plenty of time for
serial processing (my incoming data rate was pretty low)  For higher data rates
you lose some of the oversampling so the design gets more challenging.  Also,
in cases where you need to have a larger capture range, you may need a more
complicated divider whose divide ratio gets bumped up or down as a result of
repeated phase errors in the same direction.  That takes a little more than
twice the logic the fixed divide needed.  The rate of the increment with
respect to the frequency of the phase error will determine the loop stability
and the time required to lock to a new frequency or phase.
Working with phase encoded data such as a manchester code makes it a lot
easier since the clock information is always there (you can only miss one
transition at a time).

>: 5 MHz is 200 ns.  You want to sample at 10X or 16X.  That's 20 or 12.5 ns.
>: You can also process 2 samples in parallel: 40 or 25 ns.  If you don't like
>: cramming that into a corner of your FPGA, consider using a PAL.  (Think of
>: it as trading the VCO for a PAL.)  The details probably depend upon what
>: clocks you have available.
>
>10X is probably the lower limit for stablity (assuming real control of the 
>generated clock), I prefer ~100X which is not really practical for most
>applications.
>
Also true.  If your input signal is clean, I wouldn't go below 16X.  Noisy
inputs (phase noise) will require a higher sample rate to keep it stable.

>: You can probably work out the state machines by spending an evening with 
>: graph paper and pencil.
>
>Or write a little VHDL or Verilog to generate the state machines.

This may be why you are taking most a large FPGA.  My experience shows a
synthesized design tends to be about 1.6X the size of a handcrafted
design.  I think the design I described above used a little over 30% of a
Cypress CY7C392 (Altera).
>
>: Note that just parsing the received data stream is only half of the problem.
>: You also have to do something with it, like collect it into bytes and pass
>: it on to some other digital logic.  That requires clocking and/or
>: synchronizers.  You might, for example, modify the state machine to generate
>: the clock that drives the next stage of the system rather than a valid bit.
>: That means the downstream logic might see shorter than average clock pulses.
>: But it is all digital so once you understand what is going on it is possible
>: to check all the setup/hold times and be pretty sure your design will work.
>
>This brings up another problem with intermittent bad samples.  The data
>recovery needs to be smart enough not flip on a single bad sample.  As
>well the clock shouldn't make a radical change to due to a bad sample.
>
See the comments above for limiting the phase slew and time filtering the data.

>We have found that an all digital PLL will take up most of a large FPGA.
>I will post more after we have finished and published if there is a desire
>to see such a post.
>


-Ray Andraka
Chairman, the Andraka Consulting Group
401/884-7930    FAX 401/884-7950
email randraka@ids.net


Article: 787
Subject: IST Drying Up In North America
From: jcooley@world.std.com (John Cooley)
Date: Thu, 2 Mar 1995 14:08:43 GMT
Links: << >>  << T >>  << A >>
I read in this week's EE Times that Innovative Synthesis Technologies (IST),
a small French company that was trying to take French university developed
FPGA synthesis into the commercial market shut down its Silicon Valley
office after Bruce Bourbon, a ex-Chairman of Open Verilog International (OVI),
turned down the offer of becoming IST's CEO.  (It's rumored that what triggered
the shut down was their venture capital people didn't want to pony up the
$5 million IST requested leaving IST in a lurch.)

As far as I know, Actel was the only company that signed an OEM deal with IST
to resell their software.  If you were a user of this tool either through the
Actel OEM process or through some other independant IST sales channel, I'd
like to hear what you thought of it in a technical sense.  Was this a case of
the financial people killing a possibly good product because they saw its
market as too competitive, was the tool they were offering buggy & ugly or
was this just a bad time to try to commercialize French university developed
FPGA synthesis tools?
                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3196 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."
                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3196 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 788
Subject: Re: Lattice ispLSI starter kit
From: iisakkil@alpha.hut.fi (Mika Iisakkila)
Date: 02 Mar 1995 15:58:30 GMT
Links: << >>  << T >>  << A >>
Luc Deriemaeker <llderiem@vnet3.vub.ac.be> writes:
>Is there anyone out there who played with the kit before and can
>give me an evaluation. Is the soft bugfree etc...

I've had it die a couple of times without any warning during some
operations. Save before verifying. As to real bugs, like false
operation, none encountered so far but I haven't used it that
much yet. Certainly value for the money, but I'd give one arm for a
simulator. 

>not the Gal there is only a loader for JEDEC files. Doe anyone know
> if there exist a simple compiler on the net that can create this
>JEDEC files ?

Check out ftp.intel.com. PLDShell should be still available despite
that the business was bought out by Altera. I haven't tried yet if the
fuse maps generated for iPLD22V10 work with the ispGAL22V10, but I
can't see why not. The software even includes a simulator - I'd use
the Intel/Altera parts, if only I had a programmer...
--
Segmented Memory Helps Structure Software


Article: 789
Subject: Re: Can I implement a digital PLL in an FPGA??
From: edwint@bnr.ca (Edwin Tsang)
Date: 2 Mar 1995 16:13:58 GMT
Links: << >>  << T >>  << A >>
Len Harold (lharold@mrc.uidaho.edu) wrote:


: We have found that an all digital PLL will take up most of a large FPGA.
: I will post more after we have finished and published if there is a desire
: to see such a post.
  Yes please post more on this topic.  Could some body post something on
the different approach/ algorithm on DPLL.

--
Edwin Tsang, Email:edwint@bnr.ca ,Bramalea Lab, Northern Telecom
Opinion is mine only and I reserved the right to change it 


Article: 790
Subject: FPGA Custom Computing Machine
From: linchih@guitar.ece.ucsb.edu (Chih-chang Lin)
Date: 2 Mar 95 22:45:40 GMT
Links: << >>  << T >>  << A >>

Hi,

  I am looking for the information (call for paper, registration)
for "FPGA Custom Computing Machine workshop".

  Help please!

Chih-chang Lin
UC, Santa Barbara


Article: 791
Subject: FPGA Custom Computing Machine
From: linchih@guitar.ece.ucsb.edu (Chih-chang Lin)
Date: 2 Mar 95 22:45:40 GMT
Links: << >>  << T >>  << A >>

Hi,

  I am looking for the information (call for paper, registration)
for "FPGA Custom Computing Machine workshop".

  Help please!

Chih-chang Lin
UC, Santa Barbara


Article: 792
Subject: FPL'95: Final Call for Papers
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Thu, 2 Mar 1995 23:13:15 GMT
Links: << >>  << T >>  << A >>
		  ***FINAL CALL FOR CONTRIBUTIONS***

		     FIFTH INTERNATIONAL WORKSHOP
				  on
		       FIELD PROGRAMMABLE LOGIC
			   and APPLICATIONS


Paper deadline: 10 March, 1995
Notification  : 5 May, 1995
Final version : 1 July, 1995

Workshop: 30 August - 1 September, 1995 
Oxford University, UK


AIM

The aim of this workshop  is to bring together  workers  from throughout
the  world  for  a  wide  ranging  discussion  of  all  forms  of  field
programmable  logic  (but particularly  field programmable  gate arrays)
and their applications.  It is intended to discuss the increasing  range
of device types,  industrial  applications,  advanced  CAD developments,
research  applications,  novel  systems  architectures  and  educational
experiences.  The workshop  will include regular presentations,  posters
and discussion  sessions  and it is expected  that most of the delegates
will  wish  to make  some  contribution  to one  or more  of these.  The
workshop is the fifth in a series of workshops which were held in Oxford
(1991 and 1993), Vienna (1992) and Prague (1994).



SCOPE

Field Programmable  Logic has been available for a number of years,  but
the increasing  power and variety of devices now available  is extending
its role from that of simply being a convenient way of implementing  the
system 'glue logic'  to an increasing  ability  to implement  mainstream
system functions.  The speed with which devices can be programmed  makes
them ideal for prototyping and for education, the reprogrammable devices
are opening up sophisticated  new applications and new hardware/software
trade-offs. CAD is being developed for automatic compilation of advanced
designs and routes to custom circuits are now available.

The  scope  of the  workshop  includes,  but is not be limited  to,  the
following aspects:

 * New and future commercial devices
 * Novel chip architectures
 * New software and hardware development tools
 * Bridges to other CAD and to custom circuits
 * High-level design and compilation research
 * Industrial applications and experiences
 * Trade-offs between devices, architectures and technologies
 * Benchmark comparisons
 * Smart applications
 * Custom computers
 * Novel machine paradigms and system architectures
 * ASIC emulators, hardware modellers and compiled accelerators
 * Fault models, testability methods, reliability
 * Educational experiences and opportunities


CALL FOR CONTRIBUTIONS

Contributions   are  invited   for  regular  presentation,   poster  and
discussion  sessions.  Prospective  authors  are  invited  to submit  an
abstract of at least 500 words or a full paper by 3rd March, 1995 to:

Ms. Laura Duffy
Field Programmable Logic Workshop Secretary,
CPD Unit, Department for Continuing Education,
University of Oxford, Rewley House,
1 Wellington Square,
OXFORD OX1 2JA, England.
Tel.:  +44 865 270360  Fax: +44 865 270708
e-mail: cpdmail@vax.ox.ac.uk

Please preface this by your full correspondence  address including email
and fax, a list of (at most) 5 one-line statements that best encapsulate
the essence of your proposed contribution,  and a note of your preferred
presentation format.  Please mail 10 copies if possible, but submissions
by email or fax will be accepted.

Notification  of acceptance  will  be posted  by 5th May and full papers
(up to 12 pages including  Figures  --  the format instructions  will be
available  at an FTP  site)  must be received  by 1st July to guarantee
distribution  at the workshop.  Selected  contributors  will  be invited
to submit  their papers  to be included  in an edited proceedings  to be
published in book form after the workshop.  (The proceedings of the 1991
and 1993 workshops are available from Abingdon EE&CS Books, 49 Five Mile
Drive, Oxford OX2 8HR, UK.)

Potential exhibitors and tutorial presenters are also invited to contact
the secretariat.


PROGRAMME COMMITTEE

Doug Amos, Altera Corp, USA
Jeffrey Arnold, IDA SRC, USA
Peter Athanas, Virginia Tech, USA
Stan Baker, PEP, USA
Erik Brunvand, U. of Utah, USA
Pak Chan, U. of California (Santa Cruz), USA 
Barry Fagin, Dartmouth College, USA
Patrick Foulk, Heriot-Watt U., UK
John Gray, Xilinx Development Corp., UK
Herbert Guenbacher, Vienna Technical U., Austria
Reiner Hartenstein, U. Kaiserlautern, Germany
Brad Hutchings, Brigham Young U., USA
Sinan Kaptanoglu, Actel Corp., USA
Craig Lytle, Altera Corp, USA
Wayne Luk, Imperial College, UK
Amr Mohsen, Aptix, USA
Will Moore, Oxford U., UK
Peter Noakes, Essex U., UK
John Oldfield, Syracuse U., UK
Ian Page, Oxford U., UK
Franco Pirri, U. of Firenze, Italy
Jonathan Rose, U. of Toronto, Canada
Michal Servit, Czech T. U., Czech Republic
Herve Touati, DEC Paris Research, France
Steve Trimberger, Xilinx, USA


LOCAL DETAILS

The  workshop  will  be  held  at the  University  of Oxford  from  30th
August to 1st September 1995 with meals and accommodation  available  in
16th century  Jesus College  on the nights  of 29th to 31st August.  The
cost of the workshop  is still  to be decided  and will be inclusive  of
proceedings, lunches and banquet.

The  University  and  its  Colleges  are located  in the centre  of this
historic  city which  has fast connections  to London  and its airports.
Oxford  and  the  surrounding  area  has numerous  cultural  and tourist
attractions and has plenty to interest accompanying partners.


FURTHER DETAILS FROM:
Ms. Laura Duffy
Field Programmable Logic Workshop Secretary,
CPD Unit, Department for Continuing Education,
University of Oxford, Rewley House,
1 Wellington Square,
OXFORD OX1 2JA, England.
Tel.:  +44 865 270360  Fax: +44 865 270708
e-mail: cpdmail@vax.ox.ac.uk

or

Dr. Will Moore,
Department of Engineering Science,
University of Oxford,
Parks Road, OXFORD, OX1 3PJ, England.
Tel.: +44 865 273187  Fax: +44 865 273010
e-mail: will.moore@eng.ox.ac.uk  







Article: 793
Subject: C.A.F. WWW page (aperiodic reminder)
From: jma@descartes.super.org (Jeffrey M. Arnold)
Date: Fri, 3 Mar 1995 00:38:01 GMT
Links: << >>  << T >>  << A >>
The IDA Supercomputing Research Center (SRC) maintains a World Wide
Web page for the comp.arch.fpga newsgroup that contains:

1) The group charter;

2) An archive of posted messages with various retrieval mechanisms;

3) A list of upcoming events of interest to the custom computing
community; 

4) Pointers to organizations engaged in FPGA based computing research;

5) Several other interesting links.

This page can be found at:

	http://www.super.org:8000/FPGA/caf.html

Note the new URL: we are finally running htpd.  The old 'ftp' URL
will no longer work.

This page is still very much under construction, so any comments or
additions are welcome.  We would especially like to solicit
contributions to the bibliography and a FAQ list.

-jeff

------
Jeffrey Arnold
IDA Supercomputing Research Center
17100 Science Dr.
Bowie, MD 20715
email: jma@super.org



Article: 794
Subject: area of RAM cells in FPGAs
From: mstan@hades.ecs.umass.edu (Mircea R Stan)
Date: 3 Mar 1995 01:39:29 GMT
Links: << >>  << T >>  << A >>
Can someone please enlighten me as to what is the percentage of
area occupied by SRAM configuration cells in an SRAM based FPGA?
The ones that come to mind are the Xilinx 3/4000, AT&T ORCA,
Atmel 6000, Altera Flex 8000.
Any pointers to the literature will be much appreciated.
Thank you,
	Mircea
-- 
Mircea R. Stan		|	"Without immortality the whole world would 
UMass, ECE Dept.	|	be nonsense, all of creation an absurdity."
Amherst, MA 01003	|					Karl F. Gauss


Article: 795
Subject: Re: IST Drying Up In North America
From: y01@vista.eng.hawaii.edu (wiliki)
Date: Fri, 3 Mar 1995 02:56:18 GMT
Links: << >>  << T >>  << A >>

About french  software, I can think of  Frederic PETROT @ Equipe Alliance, Labo. MASI , they have done some good work...

By the way is there a proposal to moderate the following newsgroups.
comp.arch.fpga  and comp.cad.synthesis . 

I am sick of having to  subscribe to  20 mailing lists, because
thats the only way,  news  gets around now. 





--------------------------------------------------------------------------------


I read in this week's EE Times that Innovative Synthesis Technologies (IST),
a small French company that was trying to take French university developed
FPGA synthesis into the commercial market shut down its Silicon Valley
office after Bruce Bourbon, a ex-Chairman of Open Verilog International (OVI),
turned down the offer of becoming IST's CEO.  (It's rumored that what triggered
the shut down was their venture capital people didn't want to pony up the
$5 million IST requested leaving IST in a lurch.)

As far as I know, Actel was the only company that signed an OEM deal with IST
to resell their software.  If you were a user of this tool either through the
Actel OEM process or through some other independant IST sales channel, I'd
like to hear what you thought of it in a technical sense.  Was this a case of
the financial people killing a possibly good product because they saw its
market as too competitive, was the tool they were offering buggy & ugly or
was this just a bad time to try to commercialize French university developed
FPGA synthesis tools?
                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant



Article: 796
Subject: Re: Lattice ispLSI starter kit
From: roger@coelacanth.com (Roger Williams)
Date: 03 Mar 1995 04:11:48 GMT
Links: << >>  << T >>  << A >>
   Check out ftp.intel.com. PLDShell should be still available despite
   that the business was bought out by Altera. I haven't tried yet if the
   fuse maps generated for iPLD22V10 work with the ispGAL22V10, but I
   can't see why not. The software even includes a simulator - I'd use
   the Intel/Altera parts, if only I had a programmer...

Should be able to pick up a programmer that'll handle these pretty
inexpensively...  I was all set to use the Intel parts until the
business got moved to Altera, but after being kicked in the head
enough times over the last 6 years, Altera has become a *very* dirty
word for me 8-o

-- 
Roger Williams <roger@coelacanth.com>
Coelacanth Engineering  |  Numeric stability is probably not all
Middleborough, Mass     |  that important when you're guessing...


Article: 797
Subject: Re: Lattice ispLSI starter kit
From: Sami Sallinen <sjs@varian.fi>
Date: 3 Mar 1995 08:11:48 GMT
Links: << >>  << T >>  << A >>
iisakkil@alpha.hut.fi (Mika Iisakkila) wrote:
>
> Check out ftp.intel.com. PLDShell should be still available despite
> that the business was bought out by Altera. I haven't tried yet if the
> fuse maps generated for iPLD22V10 work with the ispGAL22V10, but I
> can't see why not. The software even includes a simulator - I'd use
> the Intel/Altera parts, if only I had a programmer...
> --

Use the iFX780 or iFX740, and alas, you only need a special cable 
attached to the parallel port to program them. Schematics available
from me upon request.

-Sami





Article: 798
Subject: Re: Limits on on-chip FPGA virtual computing
From: Sami Sallinen <sjs@varian.fi>
Date: 3 Mar 1995 09:36:04 GMT
Links: << >>  << T >>  << A >>
dong@icsl.ee.washinton.edu (Dong-Lok Kim) wrote:
>
> Hi,
> 
> I happened to read a paper
> 	"Area & Time Limitations of FPGA-based Virtual Hardware",
..


There might be a significant overhead when compared to a fixed VLSI solution
both real-estate- and performance-wise, but when you compare trying to implement
the same features with a software-only solution the odds are reversed.

Consider having a DSP processor without the autoincrementing bit-reverse 
address pointers that speed up the calculation of a FFT so neatly. You could
do that with software in a risc processor, or you could have a fixed VLSI 
solution as in a modern DSP processor. But if you had the configurable
logic gates to implement this besides of a more or less standard processor
you could do the FFT with a speed comparable to a VLSI solution, and by 
reconfiguring you could also do many other things.



Sami Sallinen
sjs@varian.fi
Systems Engineer, Varian-Dosetek Oy
Tel. +358-0-43077212
Fax  +358-0-4554585

#include <disclaimers.h>


Article: 799
Subject: Power gain when moving from FPGA to Gate Array
From: ekatjr@eua.ericsson.se (Robert Tjarnstrom)
Date: 3 Mar 1995 10:20:05 GMT
Links: << >>  << T >>  << A >>
What is the experiences of reduction in power dissipation/consumption when moving an FPGA design to a Gate Array.

Obviously there are two different situations

A) 1 FPGA -> 1 Gate Array. Is a factor 4 power gain reasonable to expect?

B) N FPGA -> 1 Gate Array. Here the power gain should be considerably larger due to reduced io power.


Opinions are welcome

Robert Tjarnstrom





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