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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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 53225

Article: 53225
Subject: JTAG
From: isro@ureach.com (Prakash)
Date: 6 Mar 2003 22:46:27 -0800
Links: << >>  << T >>  << A >>
Hi
Anybody is using JTAG/BIST in 
boards.I'm new to this and want to
know how to use it.Any material/example
other than Mic.Smith(ASIC).

Article: 53226
Subject: Re: Annapolis Microsystems Wildcard
From: johnjakson@yahoo.com (john jakson)
Date: 6 Mar 2003 23:07:20 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3E67A40F.CC97176B@andraka.com>...
> My biggest gripe about the Annapolis stuff is the closed architecture ala microsoft.
> Where they don't exactly have a microsoft sized customer base, you would think they would
> be a bit more accommodating, especially seeing you already dropped a sizable sum for the
> board in the first place.  Oh well, I can't vouch for their business model (nor do I
> understand it, if this is how they are doing it).  Didn't the board also come with NT
> drivers?  Perhaps those may work out a bit better
> 
> ABloke wrote:
> 
> > Hi Ray,
> >
> > Thanks for the reply - I forget to check back on this thread.
> >
> > You would think that they would give them to me. I bought the card a
> > couple of years ago, but it only came with Windows 98 drivers, which
> > are useless to me. It has been lying around for ages, so I thought I'd
> > put it to some use. Unfortunately, Annapolis want to charge nearly
> > $700 for the privelege of using it again, so it will just sit around
> > here doing nothing because the price is ludicrous.
> >


Consider where they come from and who their best customers are and for
that price you can buy a mil grade hammer!

I wonder how many other FPGA boards end up sitting around for lack of
suitable open tools that can be used across different vendors. More
than a few I bet. We are still at the S100/Cromenco days of FPGA,
wonder who the next RC Apple will be?

Article: 53227
Subject: Current Consumption/Limitation Upon Output
From: "Henrik Douglas Green" <Henrik.Green@martin.dk>
Date: Fri, 7 Mar 2003 08:25:29 +0100
Links: << >>  << T >>  << A >>
Hi

I would like to know there are any FPGA's where it is possible to controll
the current consumption upon the output lines. E.g. to limit the current in
some "pins"?


--
Best Regards

Henrik Douglas Green
B.Sc.E.E.

R&D, Stage, Studio and Event Lighting

Martin Professional A/S
Olof Palmes AllÚ 18
DK-8200 Aarhus N

E-mail: Henrik.Green@martin.dk
Phone:  + 45 87 40 00 00
Direct: + 45 72 15 02 06
Fax.:   + 45 87 40 00 10
URL.:   http://www.martin.dk/



Article: 53228
Subject: Re: PCMCIA to IDE interface
From: Jo Kenens <(no_spam)Jo(no_spam).ken(no_spam)ens@acunia.com>
Date: 07 Mar 2003 08:06:41 GMT
Links: << >>  << T >>  << A >>
"Brazil" <a.solinasNOSPAM@tiscali.it> wrote in
news:b44hqc$1s0tkk$1@ID-132949.news.dfncis.de: 

> Dear all,
> I would connect an hard-drive to the PCMCIA interface of my board.
> Is there anybody that can suggest how to do with a simple fpga?
> I know that a Fpga is too much but we would use to do other interfaces
> for the board.
> Thanks in Advance
> Regards Brazil
> 
> 
> 

take a look at the compact flash specification: Compact flash support a 
'true ide' interface. The main difference between the pcmcia modes and the 
ide mode is in the data-bus. Ide expects 16 bit data on address 0x0, 8 bits 
data on the lowest byte lane for address 0x1-0x7. In Pcmcia the two Cs 
signals are used as byte-enable signals. for the odd addresses, data is 
usually placed at the upper byte-lane.

Regards,
Jo

Article: 53229
Subject: Re: Implementation of latch in FPGA
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 07 Mar 2003 08:17:33 -0000
Links: << >>  << T >>  << A >>
>A latch is transparent during one half cycle of the clock. Now you must
>pay attention to signals that might be racing through the latch.
>On the other hand, latches can make your system faster, since you can
>avoid the worst-case delay in every pipeline stage.

There was a style of building hardware that was popular 10-15 years
ago.  It used latches rather than edge triggered FFs.
I never worked with any of that gear so I can't explain it.

I think it made sense with the available technology.  Probably
went faster but took more effort/skill to get right.

The magic phrase was two-phase non-overlapping clocks.


Are today's tools reasonably good with latches?  A while ago
I would have said to avoid them because the tools don't really
support them.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 53230
Subject: Re: Current Consumption/Limitation Upon Output
From: "Hňkon Lisleb°" <hakon.lislebo@ericsson.no>
Date: Fri, 7 Mar 2003 09:22:31 +0100
Links: << >>  << T >>  << A >>
Henrik,
Xilinx FPGA's has a DRIVE_STRENGTH attribute on most IO standards. This
control the drive on e.g. LVTTL from 2mA to 24mA.

Hakon




"Henrik Douglas Green" <Henrik.Green@martin.dk> wrote in message
news:rRX9a.13$mN2.12@news.get2net.dk...
> Hi
>
> I would like to know there are any FPGA's where it is possible to controll
> the current consumption upon the output lines. E.g. to limit the current
in
> some "pins"?
>
>
> --
> Best Regards
>
> Henrik Douglas Green
> B.Sc.E.E.
>
> R&D, Stage, Studio and Event Lighting
>
> Martin Professional A/S
> Olof Palmes AllÚ 18
> DK-8200 Aarhus N
>
> E-mail: Henrik.Green@martin.dk
> Phone:  + 45 87 40 00 00
> Direct: + 45 72 15 02 06
> Fax.:   + 45 87 40 00 10
> URL.:   http://www.martin.dk/
>
>



Article: 53231
Subject: Re: JTAG
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: Fri, 07 Mar 2003 13:59:09 GMT
Links: << >>  << T >>  << A >>
If you want to program FPGAs via JTAG, you would need download cable and
software from FPGA vendors.

If you want to do PCB interconnection test via JTAG, you would probably have
to get test SW and HW from JTAG test equipment vendors.

Jim Wu
jimwu88NOOOOOSPAM@yahoo.com (remove capital letters)

"Prakash" <isro@ureach.com> wrote in message
news:790976aa.0303062246.4092c707@posting.google.com...
> Hi
> Anybody is using JTAG/BIST in
> boards.I'm new to this and want to
> know how to use it.Any material/example
> other than Mic.Smith(ASIC).



Article: 53232
Subject: CFP: 2003 NASA/DoD Conference on Evolvable Hardware
From: eh2003conference@yahoo.com (Evolvable Hardware Conference)
Date: 7 Mar 2003 07:18:05 -0800
Links: << >>  << T >>  << A >>
.
                    C A L L   F O R   P A P E R S

            2003 NASA/DoD Conference on Evolvable Hardware
                          July 9 - 11, 2003
               The Westin Michigan Avenue, Chicago, IL
                    http://ic.arc.nasa.gov/~eh2003

              *** Note: deadline extended to March 17 ***

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

Supported By:
Information Sciences and Technology Directorate, NASA Ames Research
Center
Computing, Information and Communications Technology Program, NASA
Ames Research Center
Life Detection Science and Technology Program, Jet Propulsion
Laboratory
Space Exploration Technology Program, Jet Propulsion Laboratory
Navy Center for Applied Research in Artificial Intelligence, Naval
Research Laboratory


The 2003 NASA/DoD Conference on Evolvable Hardware (EH-2003) will
be held in Chicago, Illinois. The Conference builds upon the
tradition of the successful series of NASA/DoD Workshops on
Evolvable Hardware (the first Workshop hosted by JPL in Pasadena,
1999; the second Workshop hosted by NASA Ames in Palo Alto, 2000;
the third hosted by JPL in Long Beach in 2001; and the fourth
hosted by NASA Goddard in Washington DC). 

Evolvable Hardware is an emerging field that applies evolutionary and
related algorithms to automate design and adaptation of physical,
reconfigurable, and morphable structures such as electronic systems,
antennas, MEMS and robots.  The purpose of this conference is to bring
together leading researchers from the evolvable hardware community,
representatives of the automated design and
programmable/reconfigurable hardware communities, technology
developers and end-users from the aerospace, military and commercial
sectors.

Evolvable hardware techniques enable self-reconfigurability,
adaptability and learning by programmable devices and thus have the
potential to significantly increase the functionality of deployable
hardware systems.  Evolvable Hardware is expected to have major
impact on deployable systems for space systems and defense
applications that need to survive and perform at optimal
functionality during long duration in unknown, harsh and/or
changing environments. It is also expected to greatly enhance the
capability of systems that need modification, upgrade and learning
without interrupting their operation.

The focus of this year's conference will be evolvable hardware for
reliability.  Reliability issues range from fault-recovery and
survivable NASA/DoD systems operating in extreme environments to
intelligent adaptive and learning systems for protection of areas
and security of communications.

Topics to be covered include, but are not limited to:
Evolutionary hardware design
Co-evolution of hybrid systems, such as wetware, chemical, mechanical,
and electronic components, etc.
Intrinsic/on-line and extrinsic/off-line evolution
Hardware/software co-evolution
Self-repairing, reconfiguring, and fault tolerant hardware
Embryonic hardware
Novel devices, testbeds and tools supporting evolvable hardware
Adaptive computing and adaptive hardware
Real-world applications of evolvable hardware, such as: 
   -Security and watermarking of digital data
   -Radiation hardening
   -Biometrics
   -Detection and identification of biological agents and
extraterrestrial
    lifeforms (astrobiology)
   -Ultra-safe systems


SUBMISSION OF PAPERS 

Prospective authors are invited to submit their work by email in
PDF, PS, or MSWord formats to eh2003@email.arc.nasa.gov.  Papers
are limited to 10 pages and should be submitted in
single-spaced, 10 point type on a 8.5" X 11" or equivalent paper
with 1" margins on all sides.  Each submission should contain the
following items: (1) title of paper, (2) author name(s), (3) first
author physical address, (4) first author e-mail address, (5) first
author phone number, (6) a maximum 200 words abstract.  Accepted
papers will be published in the Conference proceedings.

The conference will maintain its single-track forma and will include
posters sessions and panel discussions.   Research groups are invited
to
prepare a poster describing their research.  A one-page abstract of
the poster should be submitted following the same procedures as the
paper.


For further information please contact:
Jason Lohn 
EH-2003 Conference Chair
NASA Ames Research Center, MS 269-1
Mountain View, CA 94035, USA
eh2003@email.arc.nasa.gov
Tel: +1 (650) 604-5138
Fax: +1 (650) 604-3594

IMPORTANT DATES
Submission deadline: March 17, 2003
Author notification: April 18, 2003
Camera ready manuscript deadline: May 7, 2003
Conference: July 9-11, 2003

Conference Venue:
The Westin Michigan Avenue, http://www.westinmichiganave.com/


Organizing Committee

Jason Lohn         NASA Ames Research Center (Chair)
Ricardo Zebulum    Jet Propulsion Laboratory (Co-Chair)
James Steincamp    Marshall Space Flight Center (Co-Chair)

Program Chair: 
Didier Keymeulen   Jet Propulsion Laboratory (Co-Chair)
Adrian Stoica      Jet Propulsion Laboratory (Co-Chair)

Local Chair:
Michael I Ferguson Jet Propulsion Laboratory (Chair)

Program Committee:
Tughrul Arslan, University of Edinburgh (UK)
Peter Athanas, Virginia Polytechnic Institute and State University
(USA)
Forrest H. Bennett III, Pharmix Corporation (USA)
Neil Bergmann, Queensland University of Technology (Australia)
Silvano P. Colombano, NASA Ames Research Center (USA)
Rolf Drechsler, Univeristy of Bremen (Germany)
Tim Edwards, Johns Hopkins University (USA)
Hugo de Garis, Utah State University (USA)
Stuart J. Flockton, Royal Holloway, University of London (UK)
Dario Floreano, Swiss Federal Institute of Technology (Switzerland)
Terry Fogarty, South Bank University (UK)
David B. Fogel, Natural Selection, Inc. (USA)
Manfred Glesner, Darmstadt University of Technology (Germany)
Al Globus, NASA Ames Research Center (USA)
Takashi Gomi, Applied AI Systems Inc (Canada)
Garrison Greenwood, Portland State University (USA)
Steven Guccione, Xilinx Corporation (USA)
Pauline Haddow, Norwegian University of Science and Technology
(Norway)
Inman Harvey, University of Sussex (UK)
Tetsuya Higuchi, Electrotechnical Laboratory (Japan)
Gregory Hornby, NASA Ames Research Center (USA)
Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
John Koza, Stanford University (USA)
Gregory Larchev, NASA Ames Research Center (USA)
Derek Linden, Linden Innovation Research (USA)
Daniel Mange, Swiss Federal Institute of Technology (Switzerland)
Pierre Marchal, Centre Suisse d'Electronique et de Microtechnique SA 
(Switzerland)
Trent McConaghy, Analog Design Automation (Canada)
Bob McKay, University of New South Wales @ ADFA (Australia)
Karlheinz Meier, University of Heidelberg (Germany)
Julian Miller, University of Birmingham (UK)
J. M. Moreno, Technical University of Catalunya (Spain)
Masahiro Murakawa, Electrotechnical Laboratory (Japan)
Viktor Prasanna, University of Southern California (USA)
Justinian Rosca, Siemens Corporate Research (USA)
Rob Rutenbar, Carnegie Mellon University (USA)
Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland)
John Schewel, Virtual Computer Corporation (USA)
Hajime Shibata, Tokyo Institute of Technology (Japan)
Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
Stephen Smith, Quicksilver Technology (USA),
Andre Stauffer, Swiss Federal Institute of Technology (Switzerland)
Christof Teuscher, Swiss Federal Institute of Technology (Switzerland)
Stephen Trimberger, Xilinx (USA)
Adrian Thompson, University of Sussex (UK)
Benny Toomarian, Jet Propulsion Laboratory (USA)
Jim Torresen, University of Oslo (Norway)
Andy Tyrrell, University of York (UK)
Xin Yao, The University of Birmingham (UK)
Tina Yu, Chevron Information Technology Company (USA)


NASA/DoD Advisory Committee:
David Alfano, NASA Ames Research Center
Leon Alkalai, Jet Propulsion Laboratory
Scott Hubbard, NASA Ames Research Center
Alan Hunsberger, National Security Agency
Jose Munoz, Department of Energy
Alan C. Schultz, Naval Research Laboratory
Rich Terrile, Jet Propulsion Laboratory
Anil Thakoor, Jet Propulsion Laboratory
Steven Zornetzer, NASA Ames Research

Article: 53233
Subject: Re: Issues in Outsourcing?
From: Paul Hovnanian <paul.hovnanian@boeing.com>
Date: Fri, 7 Mar 2003 15:47:06 GMT
Links: << >>  << T >>  << A >>
TI wrote:
> 
> Hello
> we are an ASIC/FPGA company currently understaffed but with a very
> limited budget; so I wonder under what circumstances and what type of
> projects(non crucial?) we could consider outsourcing to some(which?)
> developing country team?
> Thanks
> MA

Look at your development process from this point of view: which parts
of your product development can you bundle up and have someone
accomplish
with limited communications with your staff? Are those functions
something that you would consider to be a part of your businesses
core competence? In order to perform those functions, how much
strategic knowledge would be needed to perform them? In other words,
would you have to divulge any trade secrets or knowledge not generally
shared in your industry with your subcontractor.

Keep one thing in mind when considering your proprietary knowledge:
some countries only pay lip service to intellectual property laws.
Hand them too much information and pretty soon they'll be knocking
off your designs and there won't be much that our legal system can do
about it. Of course, this isn't solely a characteristic of foreign
suppliers. I've seen U.S. companies do the same thing. Your only
advantage is that you can take them to court. Unless they have enough
cash to drag that process out until you go bankrupt, that is.
 
-- 
Paul Hovnanian P.E.    | (here)  mailto:hovnania@bcstec.ca.boeing.com
Software Conflagration | (there) mailto:Paul@Hovnanian.com 
Control                | (spam)  mailto:postmaster@mouse-potato.com
-----------------------+---------------------------------------------
         Fingerprint: 52:98:95:EA:E3:4F:D9:14:42:E8:E3:E4:EC:E1:A6:22
Expired (10/24/2002): D7:8B:E3:BF:61:AF:37:B1:4B:47:19:CE:90:09:CC:A3
---------------------------------------------------------------------
Life is like an analogy.

Article: 53234
Subject: Re: Mac Os X for FPGA design
From: tmlo@networks.nera.no (Tomas)
Date: 7 Mar 2003 07:57:57 -0800
Links: << >>  << T >>  << A >>
Hello
>  
> For any serious work your best choice is Linux. The Mac has never been
> supported by EDA vendors and it's unlikely that they will start now. Most
> of the major EDA tools are available on Linux. Altera's tools are available
> as native Linux tools, Xilinx's tools still have to be run under wine but
> the important ones work fine and Xilinx is planning to have native Linux
> support in their next major release. The only real use for Mac is as an X
> server and for documentation.

Right now, I would say that any serious job requires Solaris (and this
is the platform we are using). We do have an experimental linux box
but using wine is not as straightforward as one would like (Wine over
NFS is simply awful).

Mac has never been supported by EDA vendors simply because Mac OS 9
was an ancient operating system. But I am talking now of Mac OS X,
i.e. BSD Unix.

Linux is by definition an unstable platform. Look at all the
distributions: Red Hat, SuSE, Mandrake... EDA vendors support
basically Red Hat. There has been a new release of Red Hat every 5-6
months. Compare to Solaris.

Mac OS X is here to stay for a while. It's supported. Its interface is
solid. The machines are not more expensive than Intel boxes. They have
blade servers. I really think that Apple is going to be one of the big
players in the unix world in the future. In this case, why should not
we have EDA tools for this platform as well??

Just my friday thoughts.
Regards,
Tomas

Article: 53235
Subject: Re: JTAG
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Fri, 7 Mar 2003 15:58:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 07 Mar 2003 13:59:09 GMT, Jim Wu <jimwu88NOOOSPAM@yahoo.com> wrote:
>If you want to program FPGAs via JTAG, you would need download cable and
>software from FPGA vendors.

False.  There are plenty of vendor-free ways to program FPGAs by JTAG.
People who are in the habit of using decent paid-for, supported, time-saving,
flexible and relevant commercial software/hardware are, of course, free
to continue doing so.  Everyone also needs to understand that this approach
is not the only path, and in many cases it doesn't exist.  Actual knowledge
of how to solve the problem is sometimes essesntial, and such knowledge is
not the exclusive province of large companies.

         - Larry

Article: 53236
Subject: Multipliers Architectures use on FPGA COREGEN
From: dementepr@hotmail.com (JDS)
Date: 7 Mar 2003 10:08:03 -0800
Links: << >>  << T >>  << A >>
Hi all,

I'd like to know which multiplication schemes (among Wallace, Booth,
shift-add, etc) are used on Xilinx CoreGen modules, taking in account
the speed vs area tradeoff. Or if those generated modules use more
technology specific features like fast-carry chains, RPM, LUT, etc.

Thank you in advance,
JDS

Article: 53237
Subject: Cyclone power up problem
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Fri, 07 Mar 2003 18:48:19 GMT
Links: << >>  << T >>  << A >>
I've built a board with the Cyclone from Altera. First board was ok, but on
some of the following there was a problem with startup of the Cyclon.

For the core voltage (1.5V) I use a drop-down regulator from Linear
Technology (LTC3405) as described in the app. note (AN257). But the core
voltage did not reach the 1.5V. The regulator stopped at 0.5 - 0.8 V. I
examined the problem by building an extern regulator.

Starting the regulator without load and than attaching the VCCINT pins from
the FPGA leads to a successfull start. The output capacitor (4u7) supplies
enough initial current.

Measuring the current during startup yields to following results:
First few us the Cyclone needs about 0.7A! Falling down to 200 mA and
staying there for about 15 us (I think for internal startup). After that it
dropps to a few mA.
The LCT3405 is a 300 mA regulator with a peak current of about 650 mA. It
can not deliver this peak current during it's own start.

Just wanted to tell this story (of hidden problems of a new family) for
others who want to work with this new (still exciting) FPGAs to not run into
the same troubles.

Martin Schoeberl



Article: 53238
Subject: Re: Cyclone power up problem
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 7 Mar 2003 18:57:44 +0000 (UTC)
Links: << >>  << T >>  << A >>
Martin Schoeberl <martin.schoeberl@chello.at> wrote:
: I've built a board with the Cyclone from Altera. First board was ok, but on
: some of the following there was a problem with startup of the Cyclon.

: For the core voltage (1.5V) I use a drop-down regulator from Linear
: Technology (LTC3405) as described in the app. note (AN257). But the core
: voltage did not reach the 1.5V. The regulator stopped at 0.5 - 0.8 V. I
: examined the problem by building an extern regulator.

: Starting the regulator without load and than attaching the VCCINT pins from
: the FPGA leads to a successfull start. The output capacitor (4u7) supplies
: enough initial current.

: Measuring the current during startup yields to following results:
: First few us the Cyclone needs about 0.7A! Falling down to 200 mA and
: staying there for about 15 us (I think for internal startup). After that it
: dropps to a few mA.
: The LCT3405 is a 300 mA regulator with a peak current of about 650 mA. It
: can not deliver this peak current during it's own start.

: Just wanted to tell this story (of hidden problems of a new family) for
: others who want to work with this new (still exciting) FPGAs to not run into
: the same troubles.

Is your Cyclone and Engineering sample or from a normal production run?

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 53239
Subject: Re: Cyclone power up problem
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Fri, 07 Mar 2003 19:03:39 GMT
Links: << >>  << T >>  << A >>
> : Just wanted to tell this story (of hidden problems of a new family) for
> : others who want to work with this new (still exciting) FPGAs to not run
into
> : the same troubles.
>
> Is your Cyclone and Engineering sample or from a normal production run?
>
Its a EP1C6Q240C8 from the production run. First shipped Cyclones (in
Austria) where marked as production.

Martin



Article: 53240
Subject: Re: Implementation of latch in FPGA
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 07 Mar 2003 14:57:53 -0500
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> Registers really isolate the input side from the output side. If you
> have tight clock distribution and pay attention to set-up times, you can
> analyze each part of the circuitry in its own clock period, and you
> never get any strange race-condition effects, Something like the
> revolving door at the hotel entrance, there is never any blast of wind
> through it.
>
> A latch is transparent during one half cycle of the clock. Now you must
> pay attention to signals that might be racing through the latch.
> On the other hand, latches can make your system faster, since you can
> avoid the worst-case delay in every pipeline stage.
>
> Peter Alfke
> =========

Peter,
    That was what I thought, but now I know for sure.
Thanks,
Theron

>
> Nimrod Mesika wrote:
> >
> > Peter Alfke <peter@xilinx.com> wrote in message news:<3E654FF4.B03BCACE@xilinx.com>...
> > > Here is what I say in seminars:
> > > Latches are only used by very inexperienced designers, and by very
> > > experienced designers.
> > > The inexperienced ones don't realize the pitfalls ( and get themselves
> > > into bad trouble), the really experienced ones appreciated the
> > > advantages ( and know how to stay out of trouble).
> > > The average designer is much better off with only flip-flops.
> >
> > Can you elaborate a little about the advantages of using latches (or
> > point us at some paper)?
> >
> > The only advantage I know of is that latches may sometimes give better
> > performance if your pipeline isn't well balanced (i.e., you may get a
> > higher maximum clock).
> >
> > From what I recall disadvantages are difficult testability and
> > sensitivity to clock duty cycle. Both of these shouldn't be an issue
> > for FPGA design, I assume.
> >
> > Just an interesting discussion.
> >
> > Nimrod.


Article: 53241
Subject: Re: Implementation of latch in FPGA
From: johnjakson@yahoo.com (john jakson)
Date: 7 Mar 2003 12:01:56 -0800
Links: << >>  << T >>  << A >>
"Theron Hicks (Terry)" <hicksthe@egr.msu.edu> wrote in message news:<3E67F34A.16F64A6E@egr.msu.edu>...
> Peter Alfke wrote:
> 
> > Here is what I say in seminars:
> > Latches are only used by very inexperienced designers, and by very
> > experienced designers.
> > The inexperienced ones don't realize the pitfalls ( and get themselves
> > into bad trouble), the really experienced ones appreciated the
> > advantages ( and know how to stay out of trouble).
> > The average designer is much better off with only flip-flops.
> >
> > Peter Alfke
> > ==================
> 

Nicely summed up warning!


> Peter,
>     I don't seem to have been bitten by this problem yet, but I would rather
> not be bitten either so could I get a few clarifications please....
> 
> 1.    How do you define a flipflop vs a latch?
>         Is a latch a register with a level sensitive strobe?
>         What is a flip-flop then?  To me a Flip-flop is, for example, a pair of
> cross-coupled nand or nor gates (R-S flip-flop), or else a J-K, toggle, or
> D-type (edge sensitive.)  Is the definition here different?
> 
> 2.    Why are latches bad?  Is it due to timing of clock distribution?
> 
> 3.    Can you point me at some examples of pitfalls and advantages?  (Really I
> would like to just find them here, but I am not that lazy.)
> 
> 4.    How does one stay out of trouble with latches?
> 
> 5.    Are you saying, "Stick with edge sensitive devices, not level sensitive
> devices"?  If I understand correctly, you really want us to stick with one
> clock domain and thus one clock frequency throughout the device, if at all
> possible, right?
> 
> Thanks,
> Theron
> 
> 
> >


this is for the newbies, or people with way too much time on their
hands like me

The word flip flop is perhaps one of the most abused words in the EE
dictionary.

Somewhere along the road the terms flipflop, & even register became
ambiguous.


A flipflop can be level sensitive or edge sensitive.

A level sensitive flop is usually to be avoided in most situations,
but see below. Also known as bistables, latches, slaves, SRAM memory
cell or even register or pipeline. I refer to them usually as latches
even if they are used as SW registers or RTL pipelines. The design is
usually a crosscoupled circuit, a bistable. Even a single node design
is possible with varacters or devices with hysteresis (MRAM, even DRAM
with refresh). How & when it is written is what usually separates the
newbie from the experienced circuit designer.

An edge sensitive flop is to be desired in most situations, but see
below.
These can be called DFlop, a master slave [register], an edge
triggered|sensitive latch|flop or just register or pipeline. I refer
to these as DFlops or registers/pipelines in the RTL sense. How & when
it is written is what usually separates the newbie from the
experienced logic designer. When written by a clock edge, it is almost
always safe given enough cycle time, but written by a user created
signal, almost as bad as a latch unless such signal is made glitch
free.

So many names to confuse the novice, even the same name is often used
for both, but the design context usually resolves which type is meant.

Verilog doesn't help by having register as a reserved word to mean
something else. Personally I never use Verilog always @ to infer
clocking of latches or Dflops. I always instance DFFs directly hiding
the always @ inside a few lib files.


Level context
In some situations, like in ECL of ancient days, or even in the
fastest CMOS cpus, most registers/flops are just latches written with
a short pulse, either an asymetric clock pulse or derived from a clock
edge locally. If all the logic paths in an x ns design are longer than
the set up & hold of a latch, then only latches are needed for the
pipelines. If a pipe stage has no path delay then enough delay is
added. Without the extra delay, a clock could propagate a signal
through >1 pipe since they are momentarily all transparent. This use
of latches along with extraordinary short logic paths gives fastest
clock frequency and less circuit power. This style of design is rarely
used except by cpu and memory designers and can only be used safely
when the layout is precisely controlled and included in the design
calculations. This means that in FPGA it is almost impossible to use
since very few can manually place every LUT, flop, and wire. Since
FPGA pathas tend to be 1 or 2 orders of magnitude longer than in cpus,
the savings from use of latch over DFlop are zere.


Edge context
In most synchronous designs, registers/flops are edge triggered.
A register usually implies 2 latches back to back on opposing clocks,
ie a DFlop, a master slave, an edge triggered/sensitive latch/flop, a
2 phase register etc. It is also possible to design edge triggered
Dflops with only one storage circuit with more complex circuit design
that schemes or races a short pulse event from an edge, often used by
TTL DFlops and SRAM sense amplifiers.

In a typical datapath pipeline, if the master slave latches were
instead written with skinny pulses at the clock edges, the design
would essentially do the same. Further, many of the master latches
could then be safely removed from those longer paths, leaving out the
master latch delay. Then you have the latch based pipeline scheme
above. The remaining masters left in the short paths are the blocks
that prevent clock tunneling, same effect as just adding enough delay.
This sort of optimization is hardly justified (except for cpus) as the
savings in removal of master flops is minimal.


Memory context
In the memory context, all memory cells are the simplest smallest
erea, lowest power, least leakage bistable latches. The memory may
appear to be edge clocked, but the early side of the clock masters the
data into a front latch, and the other side transfers it to the
selected memory slave latch. 1 master, many slaves. In asychronous
SRAM design, the master latch is missing, so the selected memory
latch/cell can be exposed to outside world if WE is asserted long
enough. These asynchronous memories are harder to use since they
require detailed attention to timing, ie address must be stable long
before & during WE.

In ASIC design, even a logic designer can safely build small memories
from std cell latches to save area, but requires careful logic design
& hand placement.


Delay context
Latches can be used to extend a signal out by remaining mostly open
and closing to freeze a signal. These can be safe when used with
clocks or safe glitch free LE. Usually better to design reason out and
use Dflop & mux.


Synthesis context
Any reader of synthesis texts will learn that synthesis algorithms
have a hard time with latches esp when used poorely or unconstrained.
Synthesis SW is so much easier to write for Dflops, even ordinary
users can write basic synthesis tools that are safe by construction,
since these are often mathematical transform tools. As soon as general
latches are allowed, they become something else. When HDL is used to
create what synthesis can only assume is a latch, it is usually a
mistake on the coders part. In a schematic flow, use of latches is
usually more deliberate since the Dflop & latch have quite different
symbols. Personally I would ban all use of latches unless deliberately
instanced, & never inferred.


Layout context
In FPGAs and all high performance VLSIs/ASICs the clock signal nets
get extraordinary attention to detail to assure that the clock signals
are uniformly available over whole chip with minimal skew, and plenty
of drive strength. No such attention can be guaranteed for any other
signal when used as a clock, esp FPGAs. Using signals to write latches
undermines the work done to make chip design as easy as possible. Use
of latches forces one to know chip internals that are not usually
available.


Asynchonous logic context
Some are of the opinion that synchronous logic design has had its day
in the sun, and that asynchronous design could produce faster lower
power design as all clocks become locally produced. They are probably
right, but FPGAs make that scheme mostly irrelevant. Here latches
become the circuit of choice as global clocks are discarded, but thats
another story, and it applies only to custom ASIC design with carefull
layout.


Multiple clock domain context
Use of latches is even worse in multiple clock domain. Multiple clock
domains that involve multiple blocks of logic at different frequencies
invites problems. Best if the clocks are locked together so that edge
events in one domain occur in fixed points in time in another domain
where two domains communicate. When the domains are locked, then the
system is equivalent to a system with much faster clock, each sub
domain simply choosing to use a fraction of the available edges. In an
unlocked system, then the communication between domains invites
asynchronous behaviour requiring resynchronizing logic which can be a
back door to metastability.

Unfortunately multi clock domains are with us because different
domains are locked to systems that cannot always be unified. One
example is hard disk controller, where analog front end even varies
its domain depending on track position.


I could go on

Article: 53242
Subject: Xilinx ISP Header
From: TigerMole <none@nowhere.de>
Date: Fri, 07 Mar 2003 22:06:02 +0100
Links: << >>  << T >>  << A >>

Is there a standard ISP Header for
Xilinx CPLDs. I want to use a 10 pin
header, but i am not sure which 
signals should be at which pins ...
Is there a standard pinout ?

Is there a standard isp header
i should put on my board ? (maybe
not 10 pin ...)

TigerMole

Article: 53243
Subject: Re: Xilinx ISP Header
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Fri, 7 Mar 2003 21:18:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
TigerMole <none@nowhere.de> wrote:

: Is there a standard ISP Header for
: Xilinx CPLDs. I want to use a 10 pin
: header, but i am not sure which 
: signals should be at which pins ...
: Is there a standard pinout ?

: Is there a standard isp header
: i should put on my board ? (maybe
: not 10 pin ...)

I use now the Altera Bteblaster pinout for the JTAG header, even with the
XILINX parallel cable. At least a little bit of interoperability.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 53244
(removed)


Article: 53245
(removed)


Article: 53246
Subject: Re: Xilinx ISP Header
From: TigerMole <none@nowhere.de>
Date: Fri, 07 Mar 2003 22:46:21 +0100
Links: << >>  << T >>  << A >>

>I use now the Altera Bteblaster pinout for the JTAG header, even with the
>XILINX parallel cable. At least a little bit of interoperability.

I have seen 4 different pinouts for a 10 pin headers now.
So it is true that there is no standard ?

Isn't it strange, that Xilinx does not make a 
suggestion ?

Some are using the Atmel header: 
MISO->TDO
SCK->TCK
/RESET->TMS
MOSI->TDI

how about that ?

TigerMole





Article: 53247
Subject: Re: Implementation of latch in FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 07 Mar 2003 14:43:02 -0800
Links: << >>  << T >>  << A >>
See my comments:

"Theron Hicks (Terry)" wrote:

> 
> Peter,
>     I don't seem to have been bitten by this problem yet, but I would rather
> not be bitten either so could I get a few clarifications please....
> 
> 1.    How do you define a flipflop vs a latch?
>         Is a latch a register with a level sensitive strobe?
>         What is a flip-flop then?  To me a Flip-flop is, for example, a pair of
> cross-coupled nand or nor gates (R-S flip-flop), or else a J-K, toggle, or
> D-type (edge sensitive.)  Is the definition here different?

I beg to differ. 
In my book
A latch is a single-rank device, e.g. two cross-coupled gates, where the
output change   is directly affected by an input change while the latch
is transparent.
A flip-flop changes it output only as a result of the clock edge. Data
input changes never change the output directly, a flip-flop is never
transparent. (This ignores the asynchronous preset and clear inputs).
> 
> 2.    Why are latches bad?  Is it due to timing of clock distribution?

Because they are transparent. You can send a race condition through the
latch, and you should not feed the latch output back to its input. 
"Toggle latch" would be a contradiction in terms.
> 
> 3.    Can you point me at some examples of pitfalls and advantages?  (Really I
> would like to just find them here, but I am not that lazy.)
> 
> 4.    How does one stay out of trouble with latches?
> 
> 5.    Are you saying, "Stick with edge sensitive devices, not level sensitive
> devices"?  If I understand correctly, you really want us to stick with one
> clock domain and thus one clock frequency throughout the device, if at all
> possible, right?

Well, that is the safe way, everything else is more risky.
BTW, all "registers" and "flip-flops" (in my book) are edge sensitive.
Level-sensitive "ones-catching" flip-flops died in the early seventies.

Peter Alfke
> 
>

Article: 53248
Subject: Re: Current Consumption/Limitation Upon Output
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 07 Mar 2003 15:06:11 -0800
Links: << >>  << T >>  << A >>
Look at the DCI option in XilinxVirtex-II outputs. You can define the
output source and sink impedances ( source and sink independently) for
any bank (half-side) of outputs.
Typical values are 50 to 100 Ohm.

Peter Alfke, Xilinx Applications
=========================
Henrik Douglas Green wrote:
> 
> Hi
> 
> I would like to know there are any FPGA's where it is possible to controll
> the current consumption upon the output lines. E.g. to limit the current in
> some "pins"?
> 
> --
> Best Regards
> 
> Henrik Douglas Green
> B.Sc.E.E.
> 
> R&D, Stage, Studio and Event Lighting
> 
> Martin Professional A/S
> Olof Palmes AllÚ 18
> DK-8200 Aarhus N
> 
> E-mail: Henrik.Green@martin.dk
> Phone:  + 45 87 40 00 00
> Direct: + 45 72 15 02 06
> Fax.:   + 45 87 40 00 10
> URL.:   http://www.martin.dk/

Article: 53249
Subject: best way to read/write contents of BRAM to a file during simulation?
From: wrighton@ieee.org (Michael Wrighton)
Date: 7 Mar 2003 15:26:10 -0800
Links: << >>  << T >>  << A >>
Hi,
I'm trying to figure out if there's a bit of IP out there that can
solve my problem before write my own solution:

I'd like to put together a design with a block RAM, initializing it
from a ASCII file. At the end of simulation (or possibly several times
during simulation), I'd like to be able to write out the contents of
the memory to a text file (in the same format that I read them in,
ideally).

I already know I can easily put a COE file into the VHDL that Xilinx
COREGEN produces, but I'm having trouble finding the bit to handle
writing out the file.

My reason for doing this is that I'd like to demonstrate that the
significant part of my design works before I try to interface the
other half of of the DP memory to Ethernet via a Microblaze processor.

I'd appreciate any help.

Thanks,
-michael



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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