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 14350

Article: 14350
Subject: Re: FPGA architecture
From: wjmoore2167@my-dejanews.com
Date: Wed, 27 Jan 1999 01:12:47 GMT
Links: << >>  << T >>  << A >>
In article <78khl4$oju$1@nnrp1.dejanews.com>,
  pandey@my-dejanews.com wrote:
> Hello, I am studying the architectures of different FPGAs. I want to make a
> comparison between Xilinx, QuickLogic and Altera FPGAs. I have some
> information about Xilinx but almost no information about Altera and
> QuickLogic. I mean I need to know what kind of Cell blocks the FPGA has, what
> are the routing resources and the technology on which it works(like SRAM,
> anti-fuse via etc) How do I go about finding literature. Any inputs will be
> appreciated. Thanx in advance. Best Regards Pandey
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>

Hi,

For a start you could try this web site - it has lots of info and some good
links.
http://www.optimagic.com/

I am currently working on a comparison between the various technologies - but
only just starting. I would be interested in what you come up with - or if
any body has a functionality vs price comparison already done for FPGA
technologies.

Cheers
James Moore
jamesm@open.co,nz

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14351
Subject: Re: Xilinx - Questions on clock & Async delays.
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 26 Jan 1999 17:56:39 -0800
Links: << >>  << T >>  << A >>
Paul Attilla Richards wrote:

> I'm interested in generating small-stepped delays with
> FPGA/CPLDs for
> a phased array transmitter,  and initially thinking of
> Xilinx 4000E &
> 9500 series +M1.5 Foundation, though would happily
> consider others.
>
> I've done a bit of design with all synchronous components
> at 30MHz but
> now need some small time shifts which are probably too
> small to be
> done by clocking.  I'd welcome any comments or pointers.

Interesting problem. Should get many answers. Ray Andraka
might have some good ideas.

I would suggest to use the fastest parts available. From
Xilinx that would be XC4000XLA and Virtex. In a tight
design, you can run the clock at 200 MHz = 5 ns period or
2.5 ns half-period.
If you have to change your delays in real time, you cannot
use the clock polarity configuration option, but for very
small incremental delays of a few hundred picoseconds, you
might enlist the carry delays.
Virtex has four delay-locked loops, each with a timing
granularity of ~35 picoseconds.

So there are interesting possibilities for you to think
about.

Peter Alfke, Xilinx Applications

Article: 14352
Subject: Re: FPGA express warning
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Wed, 27 Jan 1999 02:06:11 +0000
Links: << >>  << T >>  << A >>
Hi Bruce,

 The box your mentionned is checked. The problem is that there are some ports
which are connected
to IPAD and others not (I have already looked at the XNF file ). The description
of the warning message says :
"The pad mapping optimization step assumes that if a port in the top design does
not have a net attached to it that no pad cells ". These are inputs and
connected to input pins of  lower components in the hierarchy, that's why they
are not attached to any net in the top level. There are no errors or warnings
before the optimization phase ( bug?).


Khaled.



Article: 14353
Subject: FPGA/Lead job opportunity at Cisco
From: Margie Way <margiew@ix.netcom.com>
Date: Tue, 26 Jan 1999 18:55:28 -0800
Links: << >>  << T >>  << A >>
Pipelinks (http://www.pipelinks.com) is a startup in the process of
being acquired by Cisco.  This should  close by mid-February.  Get into
Cisco the easy way - get acquired!!

Here's the opening:
Board/FPGA Designer – Project Lead
Skills Required:  BSEE plus 5-8 years board level design experience.
Experience designing add-drop multiplexers, expecially OC-3, T3, E3,
SONET.  Must have experience as a project lead or senior designer.
Skills Desired:  FPGA design in a telecom system - DS1, DS3, T1.  Router
experience a plus.

Please contact:
Margie Way, recruiter
Pipelinks
490 Race St.
San Jose, CA  95126
408-808-4103
408-808-4199 fax
831-427-0838 home office
margiew@pipelinks.com


Article: 14354
Subject: Re: Hysteresis on PLD Clock Inputs
From: jim granville <Jim.Granville@DesignTools.co.nz>
Date: Wed, 27 Jan 1999 17:49:31 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
<snip> 
> 
> Needless to say, all Xilinx FPGAs have some hysteresis on
> all their inputs :-)

Does this mean ALL inputs, or just the Clock inputs ?
( or maybe the smiley means none at all ? :-)

How many mV of hysteresis ?

Does this mean slow edges are legal ?

- jg

Article: 14355
Subject: SWAP Home RF 4-FSK Demodulator
From: Your Name <UserID@pacbell.net>
Date: Tue, 26 Jan 1999 21:42:22 -0800
Links: << >>  << T >>  << A >>

--------------C37268972F66108D133BCA3C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Has anyone in this group done any work related to 4-FSK demodulation
using an FPGA?  The standard I'm interested is the Home-RF SWAP
standard.

 weeniper@pacbell.net

--------------C37268972F66108D133BCA3C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Has anyone in this group done any work related to 4-FSK demodulation using
an FPGA?&nbsp; The standard I'm interested is the Home-RF SWAP standard.

<P>&nbsp;<A HREF="Mailto:weeniper@pacbell.net">weeniper@pacbell.net</A></HTML>

--------------C37268972F66108D133BCA3C--

Article: 14356
Subject: Re: The development of a free FPGA synthesis tool
From: seebs@plethora.net (Peter Seebach)
Date: Wed, 27 Jan 1999 05:50:28 GMT
Links: << >>  << T >>  << A >>
In article <m31zkismqa.fsf@tade.bendor.com.au>,
Zoltan Kocsi  <root@127.0.0.1> wrote:
>The ANSI C standard states that there is C for environments which 
>contain an operating system. In that case main returns an int which
>the OS should interpret as an exit code.

Yup.

>However, if you have the so-called free-standing environment, (which is
>the case with most embedded systems) the main() function:

>- does not have to exist at all, but
>- if it exists, it can have any prototype you like, and
>- does not have to return at all

Not any prototype *you* like.

Any prototype the vendor decided to use.

And they probably have fairly strict standards.

Anyway, if you refer to standard library functions, you're assuming a hosted
environment.

-s
-- 
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Send me money - get cool programs and hardware!  No commuting, please.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!


Article 75 of comp.compilers.lcc:
Article: 14357
Subject: Re: Worst service in India by Xilinx
From: satish_me@hotmail.com
Date: Wed, 27 Jan 1999 05:51:40 GMT
Links: << >>  << T >>  << A >>
In article <78bt35$eql$1@nnrp1.dejanews.com>,
  satish_me@hotmail.com wrote:
> Hello  I am a customer from India to Xilinx. I purchased the Xilinx Express
> foundation series long almost 1 month ago. Till now either for installation
> or to tell how to start was not guided by any of the Indian representative.
> Hence it shows the poor service of the Xilinx company in INDIA. Hence I
> appeal to people of India not to go for purchsing the Xilinx products, which
> suffer from lack of service in Indian region.
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>
I am sorry to put the blame on such an well established company. After my
request the local rep. has turned to me. Any how I apologise for putting this
in the net.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14358
Subject: testing
From: satish_me@hotmail.com
Date: Wed, 27 Jan 1999 06:10:42 GMT
Links: << >>  << T >>  << A >>
Hello I am in the research field of FPGA. Why the PLL's should be used for
FPGA reprogramming.Please intimate to my hotmail account

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14359
Subject: Re: Hysteresis on ALL PLD Inputs
From: jim granville <Jim.Granville@DesignTools.co.nz>
Date: Wed, 27 Jan 1999 21:29:53 +1300
Links: << >>  << T >>  << A >>
Ron Cline wrote:
> 
> In a recent thread, there was a discussion regarding the desire for
> hysteresis on clock inputs for programmable logic.  Although this
> would certainly help those applications where noisy or slow clock edges
> are present, there would be repercussions that might make a product with
> this feature only useful in special cases. 

This is already being done, by Vantis, and ICT - they have PLDs with
hysteresis
on ALL pins.

It is a mistake to put hysteresis on just the clock pins - see the input
transistion oscillation notes below.

> (In other words, to be
> frank, the small sales would make the product not worth the investment
> from the vendor's (i.e. - my) point of view.)  With this in mind,
> reactions and comments on the following points are welcome.
> 
> 1.  Assume any hysteresis on the clock edges that is sufficient to be
> useful (perhaps 0.4 to 0.5 volts) will also cause the clock-to-output
> delay to increase by 0.5 nsec.  (I think this is a reasonable
> estimate.) 

This depends on your Hysteresis design. We have an IP Schematic,
available
for license, for an Input cell design that has Hysteresis, and no
additional 
Buffer delay.

> Why would you buy this product if you were not interested in
> the hysteresis and another PLD was available with a faster Tco?

The Tco cost is maybe 6-9 months of process improvement delay, 
whilst the reliability gains are timeless...
 With Hyst you KNOW your chip is as digital as it can be, without it
and you have a whole lot more to contend with.

Use Hyst for applications that do NOT heed fast Tco, but DO need noise
immunity,
cannot naturally provide 5nS rise/fall signals, or need EMC measures

Raw Speed, and Hyst are almost opposite in nature.

 A growing real world problem is that circuits with 'slow' natured
signals, 
are just waiting to fail, as the headlong rush for SPEED makes faster
and 
faster CPLDs.

ICT are one of the few PLD suppliers I have seen, where a SLOWER spec
PLD is NOT
just a relabeled fast part, but is genuinely quieter, has lower F/Icc,
and has
better noise immunity.

How about a CPLD that IGNORES inputs under 10nS in width ?
 
> Note: Some may suggest making the hysteresis programmable with an EE or
> SRAM bit.  For the purpose of this discussion, assume that such
> programmability would itself add circuit complexity that would increase
> the Tco even without hysteresis.  (At the very least, we would have to
> add a development and time-to-market cost variable into the discussion,
> which would muddy the picture a bit too much.)
> 
> 2.  Half of the 0.5 nsec delta in Tco is simply due to the translated
> threshold point compared to the timing spec.  For example, if we have
> 0.5 nsec of hysteresis centered around a spec'd 1.5 volt input
> threshold, then the input buffer won't switch until the pin signal
> reaches 1.75 volts.  For a 2.5 nsec clock input rise time (a reasonable
> value on IC testers), 10-90% of a 3.3 volt input signal, this implies an
> added built-in delay of .25 nsec.  In a system with long clock edges
> (remember, this is one of the applications this structure is for) the
> adder will be even greater.  For a 10 nsec clock input (10-90), I
> calculate the additional Tco from this effect to be around 1 nsec.  So,
> the question:   With centered hysteresis, the Tco will be fairly
> strongly dependent on clock rise time.  Comments? 

Tco is fundamentally dependant on Rise time, whether you have hysteresis
or not.
Ground bounce of 0.25V can do the same thing to Ip -> Op delays

Also, This also only affects external feedback Speeds - internal Clock
speeds 
stay high

My PCB design package quotes 150pS / inch of PCB trace, to put your
250pS
into perspective.

<snip> 
> 3) Finally, more and more PLDs have output slew-rate control.  This also
> adds to the Tco, but the choice can be made on a pin-by-pin basis.  Does
> this feature obviate the need for hysteresis at the input pins?

How can Output Slew Rate, obviate the need for Hysteresis ?

If you are allowing down the edges to meet EMC, you are _more_ likely to
NEED Hyst, surely ?

> This subject is often debated in my company, and it occurred to me that
> this newsgroup would be a good place to discuss the technical issues
> involved.  I look forward to your comments with interest.
> 
> Ron Cline
> Product Development Mgr
> Philips Programmable Logic Products

 Rather than analyse why it belongs in the 'too hard' box, try some real
world
designs, and see what hysteresis can do for these.
 There are quite a few 4000 / HC type GATE designs that no NOT port well
to
CPLDs, due to the lack of hysteresis.

 PLD prices have come down steeply, but often other considerations make
them 
miss a design opportunity 


- Example A:
 LatestTechCo CPLD is driven from a 40nS rise time FAST optocoupler
signal.
This PLD has a 1nS  In -> First Current Change Spec, and 3nS -> Output.
At the time the Icc starts to change, the clock has moved just 10mV past
the threshold.
( These first currents, from Ip buffers, are fortunately low) 
Current disturbances will increase, until outputs arrive at 5nS, at
which stage the 
Clock has moved 300mV past the threshold.
 This gives a measure of the SELF SYNCRONOUS sensisitvity.
A bounce of over 300mV will recross the clock threshold.

Now, consider ANY ASYNC signals, elsewhere in the PLD.
Now you have an aperture problem, where Double/Miss clocking will be
caused. 
If we take 1nS as a 'visible clock', just 10mV (!) of ASYNC ground
bounce is
needed.  This may fail only rarely, as the effect has a time curve.

If your PLD is one of the 'WakeUp' Zero Power models, they have inbuilt
hi spike
Icc generators, as the internals cycle the power.


- Example B :
The PCB fails EMC tests, and ferrite beads are used to reduce the clock
trace radiation.
EMC now passes, but the CPLD at the trace end fails just sometimes.

- Example C :
 Slow inputs from a Rotary Encoder are used to drive 2 PLD pins - these
are NOT clock
lines, so the designer thought they were ok.
 Sometimes, depending on the operator, Input transistion oscillation
occurs, causing
'ground furr', and a non associated portion of the PLD locks up.

- Example D :
 CPLD is used as a i2c Slave. This needs BIDIRECTIONAL Data/Clock
operation. It is not
possible to square up a 2 way data line, with an external buffer, and
the Open Drain
nature of i2c will never get to the sub 20nS some new PLDs need on
Rise/Fall times.
 It needs a BiDir buffer, with Hysteresis.

- Example E :
 Designer has a uC, running at 11MHz, and clocks the PLD from the sine
wave OSC signal.
There is no budget, or room for a Schmitt buffer ( even a PicoGate )
Product works fine, until new batch of shrink PLDs arrive...

- Example F :
Designer wants to build a 4046 type VCO, using cross coupled FF. PLD
Architecture supports
this well, except for the Input slew rate problems at lower OSC freq ...
A Schmitt design will have lower Icc.

There are many circuits that need an inaccurate local osc, if that could
be
integrated into the PLD ( a la 4093 ), many new applications will open
up.


Just as most uC these days have Schmitt Pin buffers, some day most PLDs
will too.


- jg

-- 
======= Manufacturers of Serious Design Tools for uC and PLD  =====
= CPLD design libraries - uC Slave IO, 82C55, SPI, i2c, SPL, etc
= CPLD_Lib@DesignTools.co.nz

Article: 14360
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Wed, 27 Jan 1999 10:39:56 +0000
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
> 
> [Me speaking from a Handel-C-centric viewpoint]
> Handel-C actually started as Handel which was based on Occam.  We put a
> C "front end" on it to make it more attractive to folks that know C
> already.  The result is actually a big improvement over the original
> Handel, in terms of readability and compact code.
> The fine-grained parallelism and communication primitives from Occam are
> still present and very usable, so it's a nice combination.

Indeed so; and I have done my best to tout the potential benefits
of CSP-based hardware description in this NG and elsewhere.  I'm sure
it's a winner.  But, if I may quote from something I recently posted
to comp.lang.vhdl:
| And don't get me started on how the parallel programming language occam
| anticipated so many developments in multi-threading and active objects;
| nor on how occam could have been the hardware description language of 
| choice;  but occam died because it met Bromley's Criteria for abject
| failure of any engineering development:
| 1) it was technically competent
| 2) it was at least a decade ahead of its time
| 3) it originated in Britain :-)

> <Jamie quoting my earlier post>
> > - you need
> > far more explicit control over parallelism, Handel-C comes close
> > but is not sufficiently configurable - but the possibilities are
> > obviously there.
> 
> Do you have anything more specific in mind?

Mainly, the way in which the present release of Handel-C is something
of a Xilinx bigot, and uses all sorts of weird constructs/pragmas
that are outside the language proper to control exploitation of
device features.  Not a criticism of the language itself, of course.
If I were being cynical I could suggest that it reflects 
commercialisation of the language at rather too early a stage....

My most serious concern about the *language* is the irrevocable 
one-to-one relationship between assignments and clock cycles.  I know
why this was done, and I know it is often convenient, but there are 
occasions when a "non-clocking assignment" would make for much clearer
expression of certain problems.  VHDL deals with this issue by
distinguishing between signals and variables.

There is also a practical problem about the semantics of channels
in a clocked (as opposed to asynchronous) environment.  One
Handel-C guru (names withheld to protect the guilty :-) ) has told me
that he tends to use shared variables in preference to channels
to avoid the extra clock cycle overheads.  If he had a grave, I
suspect Tony Hoare would be turning in it...

As a secondary point, I could raise the limitations of Handel-C when
addressing asynchronous design (for which Occam offers great potential 
benefits, as you are aware I'm sure!) and/or multiple clock domains
on the same device.  And I haven't yet understood how it deals with
design/library maintenance issues in the way that VHDL does, although
this may be because I haven't got to grips with the details yet.

> I find Handel-C's limitations very frustrating, but with experience
> I've found ways of doing things that turn out nicely in the end.

I defer to your experience.  I haven't yet used Handel-C on a "live"
project.  Certainly I've been very impressed with some of the stuff
that your hardware-compilation group has done with it.

Nice to see Handel-C protagonists putting their heads above the parapet
here (by "here" I mean comp.arch.fpga despite the crossposts!) - is the
time ripe for a hardware compilation newsgroup?

Jonathan Bromley
Article: 14361
Subject: Proposals for applications engineers
From: Romanovsky Sergey <thesys@carrier.kiev.ua>
Date: Wed, 27 Jan 1999 12:49:14 +0200
Links: << >>  << T >>  << A >>
JV "THESYS-Mikropribor" in Kiev, Ukraine specializes in microelectronic
design and
service, namely:

- design of digital ICs for 0.6u/0.8u standard CMOS from idea to
experimental chip;
- design of 0.8u CMOS IC with embedded EEPROM blocks;
- standard digital cell design (Hspice models are needed);
- IC's layout service : design, synthesis, edit, DRC, LVS and layout
support in 
  accordance with customer task. Our layouts look very beautiful!!!
- any projects on ACTEL's FPGAs.

We look for a design work in ASIC&FPGA sphere. 
Long-term cooperation is more preferrable for us. We'd like to be a
constant 
partner for any customer.

We use next tools
  for WS : CADENCE's tools
  		     Verilog-XL 
		     Leapfrog   
	           Synergy    
	           Virtuoso  
	           Composer  
		     SpectreS   
		     Dracula 4.51
  for PC : 	     Actel Designer R1-1998
		     Tanner Tools 6.50
	 	     Hspice
		     WorkViewOffice 7.31

Engineers  from our JV are all microelectronics specialists and
have worked in Kiev's Research Institute of Microelectronics
during 10-15years, have taken part in many projects and have designed
(from schematic to foundry) follow chips :
1) 80ó51 /re-engeneering/
2) Altera's EP600, EP1800 /re-engeneering/
3) Xilinx's X2064, XC1736 /re-engeneering/
4) multi-protocol remote control chip with key programming
5) music chip with 1/3-melodies
6) various versions of 64K EPROM chip
7) 4Kbit I2C serial EEPROM

Besides ASIC we deals with ACTEL FPGA's. In this sphere we fulfilled
above 
10 serious projects and a lot of simple from idea to working chip.
The most interest are:
1) phase-digital frequency synthesizer 
2) RZ-code transiever 
3) controller for high-voltage switch
4) universal controller for CCD 

If you have any proposals or ideas, please, mail.

Thank you for your time.

Regards,
-- 
Romanovsky Sergey    phone : 38044 241 7115
Design Manager       fax   : 38044 241 7031
                     email : thesys@carrier.kiev.ua

WWW entry : http://www.ln.com.ua/~thesys
Address   : JV "THESYS-Mikropribor"
            Polytekhnicheskaya Str.33
            252056 Kiev,Ukraine
Article: 14362
Subject: Call for Papers - Workshop on Parallel Execution on Reconfigurable Hardware (PERH'99)
From: fsibai@sc.fg (Fadi Sibai)
Date: 27 Jan 1999 10:53:50 GMT
Links: << >>  << T >>  << A >>

                           CALL FOR PAPERS


               International Workshop on Parallel Execution on
                           Reconfigurable Hardware

           
         http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html

                              Aizu, JAPAN

                         September 21-24, 1999

                     in  conjunction with ICPP99

          28th INTERNATIONAL  CONFERENCE ON PARALLEL PROCESSING

          US site:  http://www.cis.ohio-state.edu/~icpp99/
          JP site:  http://www.takilab.k.dendai.ac.jp/conf/icpp99/


Workshop proceedings to be published by IEEE Computer Society Press.


THEME

Continuous progress in density, speed and design tools for 
reconfigurable hardware devices regularly creates new design 
opportunities and directions.

Meanwhile, the increasing diversity of computer workloads are 
making  the design of a universal and resource-efficient solution 
for all computing applications more elusive. Several issues in this 
context deserve further investigation.

The main objective of this workshop is to bring together researchers 
and practitioners with the aim of stimulating the exchange of ideas and
experiences on the potential and limits of reconfigurable hardware, and
opening new avenues of research.
Topics of interest include but are not limited to:

   * Dynamically Customizable Processor Microarchitectures
   * Parallel Reconfigurable Architectures
   * Performance Evaluation Techniques for Reconfigurable Systems
   * General Reconfigurable Computing Models
   * Programmable Logic Devices and Systems
   * Merging FPGA and Logic/DRAM
   * Design Process Flows and Tools
   * Hardware/Software Co-design
   * Evolvable Hardware
   * Performance/Cost Comparative Studies with Standard Designs
   * Applications (in search of the "killer" applications)
   * Use of Reconfigurable Hardware in Emulation, Prototyping, and 
     System Validation.

IMPORTANT DATES


   * Submission deadline:               1   March        1999
   * Notification of acceptance:        8   May          1999
   * Camera-ready copies:               15  June         1999

Demos are strongly encouraged. If you plan to make a demo of software 
or hardware platform please inform one of the co-chair by the same  
deadline.We can provide you with various equipments (WSs, PCs, CAD 
Softwares, some FPGA boards,  Instruments (digital analyzers, 
oscilloscopes, power supplies,etc)).


WORKSHOP Co-CHAIRS

   *    Fadi Sibai, Intel
   *    Omar Hammami, University of Aizu

PROGRAM COMMITTEE

   *    Hideru Amano, Keio University (JP)
   *    Sameh Asaad, IBM T.J.Watson, (USA)
   *    Peter Athanas, Virginia Tech., (USA)
   *    Nader  Bagherzadeh,UCI, (USA)
   *    Pak Chan, UCSC, (USA)
   *    Abdelaziz Chihoub, SIEMENS (USA)
   *    Apostolos Dollas, Technical University of Crete, (GR)
   *    Michel Dubois, USC (USA)
   *    Carl  Ebeling, University of Washington (USA)
   *    Hossam Elgindy, University of Newcastle, (Au)
   *    John Granacki, ISI-USC(USA)
   *    Omar   Hammami, University of Aizu (JP)
   *    Hitoshi Hemmi, NTT (JP)
   *    Brad Hutchings, BYU (USA)
   *    Tom Kean, Algotronix, (USA)
   *    Hassan Kobeissi, AMD   (USA)
   *    Kenichi Kuroda, University of Aizu, (JP)
   *    Miriam Leeser, Northeastern U., (USA)
   *    Toshiaki Miyazaki, NTT (JP)
   *    Masato  Motomura, NEC (JP)
   *    Scott Robinson, Los Alamos National Laboratory, (USA)
   *    Jonathan Rose, U.Toronto, (CA)
   *    Stephen Smith, Altera Corp., (USA)
   *    Yuichiro Shibata, Keio University (JP)
   *    Fadi   Sibai, Intel  (USA)
   *    Steve Trimberger, Xilinx, (USA)

PUBLICITY CHAIRS

   * Abdullah Abonamah, University of Akron (USA)
   * Imad Mahgoub, Florida Atlantic University , (USA)

TUTORIAL CHAIR

   * Abdelaziz Chihoub, SIEMENS, (USA)

LOCAL ARRANGEMENTS

   * Omar Hammami, University of Aizu (JP)
   * Kenichi Kuroda, University of Aizu (JP)


SUBMISSION DETAILS

Authors are invited to submit research contributions representing 
original,previously unpublished work. Submitted papers will be 
carefully evaluated based on originality, significance, technical 
soundness, and clarity of exposition. All papers will be refereed by 
at least two members of the program committee. Accepted papers will 
be published by IEEE Computer Society Press as proceedings of the 
ICPP'99 workshops. All submitted papers MUST be formatted according 
to the author guidelines provided by  IEEE Computer Society Press 
(two-column format) and MUST NOT be longer than 6 pages.


Electronic Submission

Please submit your paper electronically to our FTP site. Please 
prepare your paper as plain ASCII PostScript only, with NO encoding, 
condensing, or encapsulation. Please use TrueType 1 fonts wherever 
possible. Do not use bitmapped fonts such as Computer Modern if you 
can avoid it.
Guidelines for Generating and Submitting Postscript Files.

File Name

Please save your file using your name, i.e. John Smith's file would be
smith.ps. If you are submitting two or more files, please number them:
smith1.ps, smith2.ps, etc.

Transferring to FTP Site
When transferring files to our FTP site, if you have a choice between
ASCII and binary modes, use binary. Although ASCII mode works well
most of the time, binary mode incurs fewer problems.

     Our FTP site:                   ehw1.u-aizu.ac.jp
     Logon as:                       anonymous
     Place files in subdirectory:    /pub  
                                    (available from Dec 1st, 1998)

Submission Notification

When you have transferred your file(s) to our FTP site, please send an
e-mail with subject line ICPP99-PERH to:

                      perh99tpc@ehw1.u-aizu.ac.jp

with the following information: (1) author's name,  (2) postal 
address, (3) phone number, (4) fax number,  (5) e-mail address,  
(6) title of your paper,(7)  5 keywords,  (8) abstract, and the 
filename(s) you used. (Do NOT send a copy of your postscript file via 
email.)

Hard Copy Paper

If, for some reason, you cannot place an electronic copy of your 
paper on our FTP site, ONLY THEN you may submit it as four hard 
copies to the following address:

Asia-Pacific/Europe/Africa            America

 Dr.Omar Hammami                   Dr.Fadi Sibai
 University of Aizu                Intel Corporation, M/S:SC12-202
 Fukushima 965-8580                2200 Mission College Boulevard
 JAPAN                             Santa Clara, CA 95052, USA

Please send also an electronic copy of your abstract, in ASCII format 
and including author's name, postal address, phone number, fax number,
e-mail address, title of your paper, keywords,abstract, to both emails:

hammami@u-aizu.ac.jp                   fsibai@mipos2.intel.com

with in the subject field: ICPP99-PERH.



For any further questions or inquiries please contact one of the 
program co-chair :


 Dr.Omar Hammami                     Dr.Fadi Sibai
 University of Aizu                  Intel Corporation, M/S: SC12-202
 Fukushima 965-8580                  2200 Mission College Boulevard
 JAPAN                               Santa Clara, CA 95052, USA
 Voice : +81-242-37-2558             Voice:(408) 765-5581
 Fax   : +81-242-37-2595             Fax  :(408) 765-5263
 e-mail: hammami@u-aizu.ac.jp        email:fsibai@mipos2.intel.com


updates will be available at:

http://www.u-aizu.ac.jp/labs/sw-pe/PERH99/welcome.html



Article: 14363
Subject: Re: Hysteresis on PLD Clock Inputs
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 27 Jan 1999 12:40:05 GMT
Links: << >>  << T >>  << A >>
My vote is 'forget it'. It's not your problem if someone is driving
your chip with a bad clock. My personal experience, with other
people's boards, is that if they have a marginal clock somewhere, then
they probably have all sorts of other unrelated problems as well, and
a fix at a single device probably won't help anyway. And take a look
at this from the point of view of an engineering manager at one of
your customers:

Engineer:  weeellll, the board works *most* of the time but, hey, it
works all the time if I use a Philips PALxxx..... Should I just
specify the Philips PAL?
Manager: In your dreams. Fix the problem or you're fired.

If you have to spend your development money, then a differential clock
input is something I would pay for. The other important area that
needs attention is the output driver structure, to make fast devices
more usable. BTW, I have a friend with a patent for an adaptive driver
which carries out on-the-fly impedance matching, and I'm sure he'd be
interested in talking to you - mail me if you're interested.

Evan

Article: 14364
Subject: Re: The development of a free FPGA synthesis tool
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 27 Jan 1999 12:42:37 GMT
Links: << >>  << T >>  << A >>
On Wed, 27 Jan 1999 05:50:28 GMT, seebs@plethora.net (Peter Seebach)
wrote:

>In article <m31zkismqa.fsf@tade.bendor.com.au>,
>Zoltan Kocsi  <root@127.0.0.1> wrote:
>>The ANSI C standard states that there is C for environments which 
>>contain an operating system. In that case main returns an int which
>>the OS should interpret as an exit code.
>
>Yup.

Well, I've never seen the ANSI standard, but it shouldn't say this -
the OS can do whatever it wants. The standard has no business
enforcing an interpretation on the OS.

>>However, if you have the so-called free-standing environment, (which is
>>the case with most embedded systems) the main() function:
>
>>- does not have to exist at all, but
>>- if it exists, it can have any prototype you like, and
>>- does not have to return at all
>
>Not any prototype *you* like.
>Any prototype the vendor decided to use.
>And they probably have fairly strict standards.

I wrote a kernel some years ago, so that makes either (i) myself, or
(ii) the compiler vendor, 'the vendor' in this case.

(i) The compiler has no business enforcing a prototype for main, and
it didn't. The wrapper put a return value in Rx if there was one, and
put zero in Rx if there wasn't one.

(ii) That leaves me. I supplied a set of calling params, which were of
no interest to the compiler, but were agreed between myself and the
application writer. I was also at liberty to do whatever I wanted with
Rx on return. In other words, neither of the vendors enforced a
prototype.

>Anyway, if you refer to standard library functions, you're assuming a hosted
>environment.

What is 'a hosted environment'? It's not that simple. I supplied some
Unix-look-a-like entry points, and the compiler used them to provide
'standard library functions'. The real host was another computer at
the end of a comms link, which had no ability to act on a return code.
As it happened, I did return main's return value, if there was one,
but it wouldn't have made any difference if I hadn't.

I also recall using a 'real' OS at some point in the past which
ignored the return value (riscos??).

Evan



Article 76 of comp.compilers.lcc:
Article: 14365
Subject: Re: FPGA express warning
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 27 Jan 1999 12:43:34 GMT
Links: << >>  << T >>  << A >>
On Wed, 27 Jan 1999 02:06:11 +0000, Khaled benkrid
<k.benkrid@qub.ac.uk> wrote:

>Hi Bruce,
>
> The box your mentionned is checked. The problem is that there are some ports
>which are connected
>to IPAD and others not (I have already looked at the XNF file ). The description
>of the warning message says :
>"The pad mapping optimization step assumes that if a port in the top design does
>not have a net attached to it that no pad cells ". These are inputs and
>connected to input pins of  lower components in the hierarchy, that's why they
>are not attached to any net in the top level. There are no errors or warnings
>before the optimization phase ( bug?).

I'm not sure I understand what you're saying here. Are you saying:

(1) The pin you want is a port at the top level of the design, and
it's also a port at the next level down, and you're joining the 2
ports together by name without using an intervening signal?

or:

(2) You have a port at the next level down, and you want it to be a
pin, but you haven't connected it either a top-level port or a
top-level signal?

(1) sounds like an FPGA Express problem; if (2), check Andy's replies
again.

Evan

Article: 14366
Subject: Re: Ratings for Synplicity Synplify
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 27 Jan 1999 12:58:20 GMT
Links: << >>  << T >>  << A >>
On Fri, 22 Jan 1999 16:52:40 -0500, Rickman <spamgoeshere4@yahoo.com>
wrote:

>When Synopsys's FPGA Compiler is mentioned, which is this? Is this the
>FPGA Express package from Synopsys (ver 2.1.3), supplied via Xilinx in
>the Foundation Express package? Or is this a version direct from
>Synopsys?

Here's my understanding of the Synopsys line-up, in the absense of a
more definitive answer. All disclaimers apply. There's a low-end
product (FPGA Express), a mid-range product (FPGA Compiler, which I
haven't used), and a high-end product (lots of software here, but the
front end is Design Analyser, and the compiler is DC).

Synopsys appears to want to distance itself from FPGA Express, and you
can't buy it directly from Synopsys. It has to come from a
distributor. It appears to share the same synthesis core as FPGA
Compiler and DC, but I'm not sure about this. However, the analyser
itself is certainly different, since it now supports some '93
features, whereas DC doesn't. It has none of the scripting features of
DC or FPGA Compiler, and you're stuck with the GUI. Price here in the
UK is about 10K (16.5K USD), including all technologies. Xilinx sells
a Xilinx-only version, without the constraints manager, for much less.
The constraints manager is, in principle, a Very Good Thing to have,
since applying constraints to the synthesiser makes much more sense
than applying them only to the PAR tool. However, I have heard it said
(not from Synopsys) that the constraints are used simply to select
between one of three (?) optimisation strategies; if this is true,
then the constraints manager is of limited, or no, use.

FPGA Compiler is an older product, and comes in two flavours. I
believe that it was originally a cut-down version of DC, with a
script-only interface. However, there is also now, additionally,
something which looks like (or is?) FPGA Express. The two products
will be integrated at some point. If the command language is similar
to DC's then it should be a very useful product, but I haven't tried
it. Pricing in the UK is, I think, about 25K (about 42K USD). It
presumably has a schematic viewer.

DC is a completely different ballgame, and is an ASIC tool (it can
also target FPGAs, but I think this is uncommon). There's a lot of
extra software here, and pricing starts at, I guess, about 100K UKP
here. As an aside, DC is apparently scheduled to get a Tcl/Tk front
end next year, which would also be a nice addition to the cheaper
tools (Spectrum/Synplify/Modelsim already have it).

I get the impression that Synopsys has a real problem positioning
itself in the FPGA market, and coming up with a coherent range of FPGA
tools - just compare it with Spectrum, for example.

Evan
Article: 14367
Subject: Re: Ratings for Synplicity Synplify
From: Geir Harris Hedemark <geirhe@hridil.ifi.uio.no>
Date: 27 Jan 1999 14:46:23 +0100
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM writes:
> distributor. It appears to share the same synthesis core as FPGA
> Compiler and DC, but I'm not sure about this. However, the analyser
> itself is certainly different, since it now supports some '93
> features, whereas DC doesn't. It has none of the scripting features of

Two errors:

The core is not the same as far as I know - the FPGA tools have some
FPGA-specific algorithms.
DC now also supports some '93 things (since 1998.08)

I haven't gotten my hands on the 1999.02 release yet, but I guess it
would be natural that it supports an even bigger subset of VHDL'93?

Geir

Article: 14368
Subject: Cheap P&R tool for Xilinx 3K series?
From: Marc Peter <mrp@42.is.the.answer>
Date: Wed, 27 Jan 1999 14:51:02 +0100
Links: << >>  << T >>  << A >>
I have left 2 3042A parts and now I want to make use of them.
Unfortunately I havn't got the right P&R tool for 3K devices. (My job at
the University has ended, and "Xilinx Student Edition" has only 4K
support).

So my question is: What options do I have? Are there any old XACT
packages
for sale (<$100)? I don't have internet access at home, so online
services
are not applicable.

Yours
Marc

-------------------------------------
-- return address field is invalid --
--                                 --
-- email:  mrp@rz.uni-jena.de      --
-------------------------------------
Article: 14369
Subject: Re: SWAP Home RF 4-FSK Demodulator
From: Ray Andraka <randraka@ids.net>
Date: Wed, 27 Jan 1999 09:05:23 -0500
Links: << >>  << T >>  << A >>

--------------695775E356BAC32D5CCD14D4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Your Name wrote:

>  Has anyone in this group done any work related to 4-FSK demodulation
> using an FPGA?  The standard I'm interested is the Home-RF SWAP
> standard.
>
>  weeniper@pacbell.net

Close, but no banana.  I am giving a half day seminar on modulation and
demodulation next week at DesignCon 99 (1 PM on feb 1) in Santa Clara.
While I don't specifically address 4 FSK, the techniques I do address do
apply.

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


--------------695775E356BAC32D5CCD14D4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
&nbsp;

<P>Your Name wrote:
<BLOCKQUOTE TYPE=CITE>&nbsp;Has anyone in this group done any work related
to 4-FSK demodulation using an FPGA?&nbsp; The standard I'm interested
is the Home-RF SWAP standard.

<P>&nbsp;<A HREF="Mailto:weeniper@pacbell.net">weeniper@pacbell.net</A></BLOCKQUOTE>
Close, but no banana.&nbsp; I am giving a half day seminar on modulation
and demodulation next week at DesignCon 99 (1 PM on feb 1) in Santa Clara.&nbsp;
While I don't specifically address 4 FSK, the techniques I do address do
apply.

<P>--
<BR>-Ray Andraka, P.E.
<BR>President, the Andraka Consulting Group, Inc.
<BR>401/884-7930&nbsp;&nbsp;&nbsp;&nbsp; Fax 401/884-7950
<BR>email randraka@ids.net
<BR><A HREF="http://users.ids.net/~randraka">http://users.ids.net/~randraka</A>
<BR>&nbsp;</HTML>

--------------695775E356BAC32D5CCD14D4--

Article: 14370
Subject: Re: Ratings for Synplicity Synplify
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 27 Jan 1999 15:52:30 GMT
Links: << >>  << T >>  << A >>
On 27 Jan 1999 14:46:23 +0100, Geir Harris Hedemark
<geirhe@hridil.ifi.uio.no> wrote:

>ems@riverside-machines.com.NOSPAM writes:
>> distributor. It appears to share the same synthesis core as FPGA
>> Compiler and DC, but I'm not sure about this. However, the analyser
>> itself is certainly different, since it now supports some '93
>> features, whereas DC doesn't. It has none of the scripting features of
>
>Two errors:
>
>The core is not the same as far as I know - the FPGA tools have some
>FPGA-specific algorithms.
>DC now also supports some '93 things (since 1998.08)
>
>I haven't gotten my hands on the 1999.02 release yet, but I guess it
>would be natural that it supports an even bigger subset of VHDL'93?

Interesting - are you sure about the '93 bits? I put a test case
through 1998.08 about a month ago, the last time I used DC, and it
failed. IIRC, the test was simply 'entity E...end entity E', which is
now supported by FPGA Express, but wouldn't compile on DC - maybe I
missed a compilation switch? There was nothing in the help about any
93-related switches.

Evan

Article: 14371
Subject: Re: Ratings for Synplicity Synplify
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Wed, 27 Jan 1999 09:26:38 -0700
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote in message
<36af0a1c.10994993@news.dial.pipex.com>...
>On Fri, 22 Jan 1999 16:52:40 -0500, Rickman <spamgoeshere4@yahoo.com>
>wrote:

> Xilinx sells
>a Xilinx-only version, without the constraints manager, for much less.
>The constraints manager is, in principle, a Very Good Thing to have,
>since applying constraints to the synthesiser makes much more sense
>than applying them only to the PAR tool. However, I have heard it said
>(not from Synopsys) that the constraints are used simply to select
>between one of three (?) optimisation strategies; if this is true,
>then the constraints manager is of limited, or no, use.


I think you're right; it doesn't seem to be a very aggressive optimizer
(optimiser?).  I've come across instances where something didn't meet a
timing spec and it didn't seem to make any effort at all.  I couldn't figure
out how to force it to "try harder."

One exciting thing FPGA Express does is to embed timing constraints in the
xnf.  The reason that this is exciting because it creates about sixty (!)
different timing constraints, most of which are irrelevant and silly. Of
course, when you get bogged down when you're doing PAR because of all the
extra constraints.  There IS a check-box to turn all of that off, but it
seems sort of a waste.  Yeah yeah yeah we can go edit xnfs and edifs but we
shouldn't HAVE to do that.

Also, it *doesn't* create useful contraints like timing ignores (you have to
go into the .ucf for that; the Xilinx Constraints Editor actually makes that
job easy).

-- andy
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters@noao.edu

"In the beginning, there was darkness.  And it was without form, and void.
And there was also me!"
-- Bomb #20, John Carpenter's "Dark Star"



Article: 14372
Subject: Re: Free max+plus ll simulator on win95
From: hsanchez@egresados.upb.edu.co
Date: Wed, 27 Jan 1999 16:53:50 GMT
Links: << >>  << T >>  << A >>
I think you can buy "The Practical Xilinx Designer Lab Book", it's a good book
with the Xilinx Foundation Software in CD-ROM.  It's not limited, except by
VHDL, but if you are a student, you can upgrade it to v1.4 complete with VHDL
support for free.

Hernán Sánchez
Professor
Universidad Pontificia Bolivariana

In article <7874b8$c86$4@arachne.labyrinth.net.au>,
  Hamish Moffatt <hamish@rising.com.au> wrote:
> Armin Mueller <ual6@rz.uni-karlsruhe.de> wrote:
> > kim tae-chang wrote:
> >> Is there any site from where I can down load a free max+plus ll(ALTEAR
> >> COMPANY) simulator and runs on Windows 95 environment.
> >> This simulator must handle big projects (up to 10k gates) in timing
> >> simulation.
>
> > There is only one _free_ MAX+plus II software. It's available at
> > http://www.altera.com
>
> > For big projects and with timing, the software is $$$.
>
> So is there ANY way to do free FPGA work yet? Like little projects for home?
>
> There's a collection of things around, but each have drawbacks.
>
> ActiveVHDL is very nice, but the demo (a) is simulation-time limited,
> and (b) expires after 1 month. It also appears to use a LOT of RAM,
> but I don't mind that so much. I gather this is pretty expensive.
>
> Synopsis have an FPGA Express demo, for VHDL. But the design size
> is limited to something quite small, and then there's no way to route
> the output netlist anyway.
>
> Altera have the MAX+PLUS II baseline. It can synthesize and compile AHDL
> or schematics. It can't do VHDL, but I can live with AHDL (although the
> help doesn't really make a very good tutorial). But you can't simulate it,
> and the device range is reasonably limited.
>
> So what other options are there? I want to be able to enter a design,
> either in an HDL or schematics (preferably the former), simulate it,
> and route it for a device I can get reasonably easily. (Xilinx is the easiest
> to get in Melbourne in my experience.)
>
> I've used Mentor, XACT 5.2, XACT M1.4 and Synopsis at uni and at work,
> and it's frustrating not to be able to get this stuff for home.
>
> If the manufacturers concentrated on selling chips and gave the software
> away, they might just sell a few more chips! I imagine that for a startup
> company, the cost of software tools could be quite important. For a home
> user it is obviously crucial.
>
> Hamish
> --
> Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au
>
> Rising Software Australia Pty. Ltd.
> Developers of music education software including Auralia & Musition.
> 31 Elmhurst Road, Blackburn, Victoria Australia, 3130
> Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free: 1-888-667-7839
> Internet: http://www.rising.com.au/
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14373
Subject: Re: The development of a free FPGA synthesis tool
From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela)
Date: 27 Jan 1999 18:02:12 GMT
Links: << >>  << T >>  << A >>
In article <36af092b.10753191@news.dial.pipex.com>,
 <ems@riverside-machines.com.NOSPAM> wrote:
>On Wed, 27 Jan 1999 05:50:28 GMT, seebs@plethora.net (Peter Seebach)
>wrote:
>>>The ANSI C standard states that there is C for environments which 
>>>contain an operating system. In that case main returns an int which
>>>the OS should interpret as an exit code.
>>Yup.
>
>Well, I've never seen the ANSI standard, but it shouldn't say this -
>the OS can do whatever it wants. The standard has no business
>enforcing an interpretation on the OS.

The standard doesn't enforce anything on the OS.  What the OS does with
the return value, if anything is up to the OS.

The truth it that there is usually an unseen layer between the main()
funtion and the OS.  Most operating systems don't look info a file for
a routine called main and call it with an argument count and pointers to
the arguments.  Under most systems, the system calls some startup code
either inside or outside the executable which sets up the environment
for the call to main().  After main() exits, control us returned either
to the startup code, or some cleanup code.  That is the real interface to
the OS.  For example the interface to an OS that expects programs to
return a pointer to an error message could look like....

char *_error_messages[];

char *_startup(char *command_line) {
  int argc;
  char *argv[MAX_ARGV_PARAMS];

  if (!setup_args(command_line,&argc,argv)) {
    return _error_messages[main(argc,argv)]; 
  } else {
    return _error_messages[BAD_COMMAND_LINE];
  }
}

It's usually up to the C implementation to provide this interface code.
If C actually set requirements on what the full interface to the OS looks
like, C implementations would be impossible on many systems.

Eric
-- 
Eric Korpela                        |  An object at rest can never be
korpela@ssl.berkeley.edu            |  stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>


Article: 14374
Subject: Re: Hysteresis on PLD Clock Inputs
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 27 Jan 1999 10:02:51 -0800
Links: << >>  << T >>  << A >>
jim granville wrote:

> Peter Alfke wrote:
> <snip>
> >
> > Needless to say, all Xilinx FPGAs have some hysteresis
> on
> > all their inputs :-)
>
> Does this mean ALL inputs, or just the Clock inputs ?
> ( or maybe the smiley means none at all ? :-)

Inspite of the smiley I was serious and precise:

ALL inputs on ALL Xilinx FPGAs ( the CPLDs are just starting
to get the religion ) have a few hundred millivolts of
hysteresis, and have had this for the last 15 years. Xilinx
is celebrating its 15th birthday this coming weekend :-)

>  
>
> How many mV of hysteresis ?

The data book - page 13-21 - says "All inputs have limited
hysteresis, typically in excess of 200 mV for TTL input
thresholds, and in excess of 100 mV for CMOS thresholds" (
The numbers only seem reversed,  they are correct ). This
description refers to XC3000, but is similar on all other
FPGAs.

>  
>
> Does this mean slow edges are legal ?

There has never been any problem with combinatorial inputs.
If they are slow, it just delays the signal and may add some
power dissipation. The problem is with clocks.In an
environment without any noise and without any ground-bounce,
even the incoming clock edges can be as slow as molasses.
But show me that kind of environment....

Peter Alfke, Xilinx Applications
  
 
 
 
 



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