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 21725

Article: 21725
Subject: Re: FPGA openness
From: krw@attglobal.net (Keith R. Williams)
Date: 30 Mar 2000 03:09:03 GMT
Links: << >>  << T >>  << A >>
On Wed, 29 Mar 2000 22:34:52, galexand@sietch.bloomington.in.us 
(Greg Alexander) wrote:

> In article <38E21159.490EB7CD@ids.net>, Ray Andraka wrote:
> >No,  I'm just presenting the technical side of what I suspect is the vendor's reluctance to
> >release it.  There are times I've needed to get into the bitstream to modify it slightly, and
> >there an open format would have been helpful.  On the otherhand, I can plainly see why the
> >Vendors would not want to put this out for general consumption.
> 
> I was replying to Keith, not you. :)

Ok, and your point?  He answered most of the points I was 
addressing, likely better than I could.

..or do you just like my keyboarding?  ;-)

----
  Keith


Article: 21726
Subject: Re: FPGA & single point failure
From: krw@attglobal.net (Keith R. Williams)
Date: 30 Mar 2000 03:18:44 GMT
Links: << >>  << T >>  << A >>


Understood. However, the fact is that the astronauts have told 
the OBS people that they would never pull the lever in flight.  
By the time time things got so bad that they'd try 
un-FLIGHT-tested software they'd be dead, or so hopelessy lost 
that it wouldn't matter.  Note that they won't test the backup 
software on a nominal flight.  

It's one thing to screw up in the simulator because you're "dead"
and another kettle-o-fish to be in space and pull the plug on 
something you've always trusted.  With the dynamics there isn't 
time to react and any reaction is *going* to go with what you 
know - right or wrong.

On Wed, 29 Mar 2000 03:21:33, rk <stellare@nospam.erols.com> 
wrote:

> Keith R. Williams wrote:
> 
> > > The one example of a system with diversity that I am aware of is the Space
> > > Shuttle's main computer system.  It consists of 5 computers, with identical
> > > hardware.  The software, however, is identical on the 4 computers that
> > > actually do the work.  A fifth computer, running but not controlling the
> > > vehicle unless commanded to, runs software developed by a completely
> > > independent team.
> >
> > This is correct.  Note the astronauts have also said that they
> > would never pull the switch to go to the redundant software (it
> > is a manual override).  They trust the Shuttle OBS and have never
> > tried the other.
> > >
> > > Anyone else know of any other examples?
> >
> > Other than multiple parallel, but identical, TMR circuits in a
> > crypto processor I don't know of any.  It's incredibly expensive
> > to duplicate everything, especially the intellectual part.  Then,
> > when you get an error after years of fault-free operation, do you
> > want to trust a newbie?  When do you make that determination?
> > ..likely when things have gone so wrong it's too late.  I
> > believe it's better to throw that money and tallent at making
> > sure the original problem is solved.  I believe the Shuttle OBS
> > is evidence of this, both ways.
> 
> Here's an excerpt from:
> 
>    The Space Shuttle Primary Computer System
>    A. Spector and D. Gifford
>    Communications of the ACM, September, 1984, p. 874
> 
> which is "interesting" ...
> 
> 
>      AS. Could you describe a training scenario on the SMS that caused a problem
>      for you?
> 
>      Clemons.  Yes - it was a "bad-news - good-news" situation.  In 1981, just
>      before STS-2 was scheduled to take off, some fuel spilled on the vehicle and
>      a number of tiles fell off.  The mission was therefore delayed for a month
>      or so.  there wasn't much to do at the Cape, so the crew came back to
>      Houston to put in more time on the SMS.
> 
>      One of the abort simulations they chose to test is called a "TransAtlantic
>      abort," which supposes that the crew can neither return to the launch site
>      nor go into orbit.  The objective is to land in Spain after dumping some
>      fuel.  The crew was about to go into this dump sequence when all four of our
>      flight computer machines locked up and went "catatonic."  Had this been the
>      real thing, the Shuttle would probably have had difficulty landing.  This
>      kind of scenario could only occur under a very specific and unlikely
>      combination of physical and aerodynamic conditions; but there it was: Our
>      machines stopped.  Our greatest fear had materialized - a generic software
>      problem.
>        We went off to look at the problem.  The crew was rather upset, and they
>      went off to lunch.
> 
>      AS. And contemplated their future on the next mission?
> 
>      Clemons.  We contemplated our future too.  We analyzed the dump and
>      determined what had happened.  Some software in all four machines had
>      simultaneously branched off into a place where there wasn't any code to
>      branch off into.  This resulted in a short loop in the operating system that
>      was trying to field and to service repeated interrupts.  No applications
>      were being run.  All the displays got a big X across them indicating that
>      there were not being serviced.
> 
> rk
> 


Article: 21727
Subject: Re: FPGA & single point failure
From: Jonathan Feifarek <feifarek@estreet_n_o_s_p_a_m.com>
Date: Wed, 29 Mar 2000 22:12:51 -0700
Links: << >>  << T >>  << A >>
EDM,
Here is a link that I hope will be helpful:
http://rk.gsfc.nasa.gov/richcontent/eeelinks/eee_links/9703_eee.htm
It is a paper by the title of "Programmable Logic Application Notes"
which addresses Single Point Failure, Single Event Upset, and radiation
Total Dose issues for multiple PLD technologies.
It lists useful items for anyone doing designs for space or high
radiation environments.
Regards,
Jonathan Feifarek
Beyond the Horizon Ent.
Article: 21728
Subject: Foundation 2.1 Macro HIZ outputs
From: Chuck Carlson <sanna@wco.com>
Date: Thu, 30 Mar 2000 06:00:15 GMT
Links: << >>  << T >>  << A >>
Hello all,

I'm trying to make a macro with an HIZ output but can
only get plain OUT outputs even though the underlying
part has an HIZ output.

The macro editor lets me change the pin type to HIZ
and save it but when I reload it, the pin type is set
back to OUT.

I can create a BIDIR pin which might work but what I
really want is HIZ.

Thanks for any ideas,

Chuck
Article: 21729
Subject: Re: FPGA openness
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Thu, 30 Mar 2000 09:07:10 +0200
Links: << >>  << T >>  << A >>
Greg Alexander wrote:
> 
> >
> >I think, you (Greg) should start with that and roll your own tools
> >down to XDL. If you are there, you can still start looking around
> >for the bitgen option.
> >I guess that final step is than not hard anymore.
> 
>  There'll always be a nagging
> suspicion that perhaps it's buggy or similar.  If you work with
> proprietary software on a daily basis you are completely used to the
> suspicion, you don't even let t enter your concious mind, but I've known
> another way and it's really hard to go back.
> 

I am aware that most software contain bugs. In particular my own. 
Its one of the most basic facts of life that human beeings make
mistakes.
I do a lot of scripting to make cross checks of the results at every
point 
in design flow. 
Some examples: 
I count the number of lines in the pcf (physical constraints file), 
check the reports on TBUFs and IOB FFs used in the reports and so on. 
Most mistakes are discover are mine. 
Our front end tool (Sy..s), perl and the xilinx tools are among the best
software 
I used so far. 
Andreas


-----------------------------------------------------------------
                        Andreas C. Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik
                        Ratzeburger Allee 160
                        D-23538 Luebeck Germany

		        Tel.: +49 451 500-3741, Fax: -3687
		        Email: doering@iti.mu-luebeck.de
                        Home: http://www.iti.mu-luebeck.de/~doering 
                             quiz, papers, VHDL, music

"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 21730
Subject: Re: FPGA & single point failure
From: rk <stellare@nospam.erols.com>
Date: Thu, 30 Mar 2000 02:51:04 -0500
Links: << >>  << T >>  << A >>
Hi Keith,

This is an interesting example of a computer system designed for high-reliability in a
very critical application.  That fly-by-wire system is required to operate during
flight.  It also did have a systematic flaw that was uncovered despite very extensive
analysis and test that forced things to lock up which made the astronauts slightly less
then happy.

From the same reference:

     DG. How do you make the system reliable?

     ...

     As I mentioned, there is a fifth computer that runs the Backup Flight System
     (BFS).  Early on, NASA was concerned about the possibility of a generic software
     problem in the PASS.  what if there were a "bug" in the PASS that brought the
     entire primary system down?  The way they alleviated their fears was by developing
     independent ascent and entry software from a subset of the requirements they had
     given us.  This independent software was witten by Rockwell International and
     resides in the fifth computer.

     ...

     The decision to engage the VGS is totally a crew function.  Their procedures
     indentify certain situations for which the switch should be made: for instance,
     loss of control, multiple consecutive failures of PASS coputers, or the infamous
     two-on-two split where the computers split up into two pairs (we've never seen
     this occur).  To date the crew has never had to use the BFS during a mission..

Of course, I assume that the crew would follow their procedures.  I would suggest
follow-up on current Shuttle procedures be directed to sci.space.shuttle where one can
find people currently employed in the Shuttle program and some of the original
designers of that computer system (not me) as that would be too off-topic for this
group.

How much time would they have in this particular system to switch to a backup?  That's
a good question.  Again, I'll just take a quick snip from the reference:


     DB. How quickly would the astronauts have to switchover from the PASS to the BFS?

     Spotz.  In the worst case, there would be a 400-millisecond window where, if the
     whole primary went down and had previously commanded hard overs on the thrust
     vector controllers, we would lose the vehicle if they couldn't switchover in
     time.  This would be at maximum dynamic pressure, shortly after lift-off.
        The general rule, based onobservations from the crew trainer, is that if they
     can't switchover within about 10 seconds, they needn't bother.  There are physical
     reasons for this: One is that the integrating accelerometer registers overflow in
     about 10 seconds at three gravities.  After 10 seconds, they would have lost 1000
     feet per second in velocity.
        As long as the BFS is able to listen to all of the data the primary is getting,
     there's no real constraint unless the primary issues a hard over command
     improperly.  If the primary stops issuing I/O commands, the crew has about 10
     seconds from that point.

Some more information on this is available from _Computers in Spaceflight - The NASA
Experience_, James E. Tomayko,Wichita State University:

     At first the backup flight system computer was not considered to be a permanent
     fixture. When safety level requirements were lowered, some IBM and NASA people
     expected the fifth computer to be removed after the Approach and Landing Test
     phase of the Shuttle program and certainly after the flight test phase (STS-1
     through 4). However, the utility of the backup system as insurance against a
     generic software error in the primary system outweighed considerations of the
     savings in weight, power, and complexity to be made by [104] eliminating it.

     The reference for this last sentence: A.D. Aldrich, "A Sixth GPC On-Orbit,"
     Memorandum, Johnson Space Center, Houston, TX, October 13, 1978, JSC History
     Office.

Clearly, this system was designed with diversity.  Again, any one know of any others?
One other is, Gemini, although I don't recall that the intent was to provide a
"diverse" system by use of a different computer for a backup.  In that case, their
launch vehicle [Titan] was essentially a missle; for backup, the astronauts could use
the Gemini computer if necessary, with switchover done either or automatically or by
manual control.  This was part of man rating that particular system.  The Saturn V,
designed for manned operations from the start, was internally redundant such that it
could operate, non-stop, through a fault.   I have seen some attitude control systems
designed with diversity where an analog backup was used along with a primary digital
system.

"18 Years of Flight Experience with the UoSAT Microsatellites," Craig I. Underwood,
discusses their use of diverse design.  This was presented at ESCCON, 2000.  I'll quote
some of the general verbiage; he follows up with specifics of how other components
provide functional backup.

In the "Design Philosophy" section:

     Recognising the risk inherent in the use of components which are not formally
     “space qualified”, we use redundancy at
     many levels to reduce the risk of total mission failure. When adopting new
     technologies, we employ them alongside
     flight-proven technologies in order to reduce risk. Thus we build a “layered
     architecture”, in which each successive layer relies on different systems
     comprising increasingly well-proven technologies. The top-layer systems use
     state-of-the-art high-performance device types - often without flight-heritage -
     but which give a high degree of functionality. Whereas the lower-layer systems use
     device-types which have been flown and tested in previous spacecraft, and which
     are able to carry out most of the same functions, albeit with a possible loss of
     performance. In this way, problems caused by an inherent system design fault, or
     by the failure of a particular device-type, are not duplicated in the different
     layers.

Going through various notes and references laying around, I can only quickly find one
more reference to diverse systems in _Reducing Space Mission Cost_, Wertz and Larson.
Here's a quick quote (p. 299):

     In diverse design redundancy two or more components of different design furnish
     the same service.  This has two advantages: it offers high protection against
     failures due to design deficiencies, and it can offer lower cost if the back-up
     unit is a "life-boat," with lower accuracy and functionality, but still adequate
     for the minimum mission needs.  The installation of diverse units usually adds to
     logistic cost because of additional test specifications, fixtures, and spare
     parts.  This form of redundancy is, therefore, economical primarily where the
     back-up unit comes from a previous satellite design, or where there is experience
     with it from another source.  Where there is concern about the design integrity of
     a primary component, diverse design redundancy may have to be employed regardless
     of cost.  [Unfortunately they don't give, in their case studies, specific examples
     of this, or at least none that I could find at this hour].

I have some other references that might include more material on this but they are not
available right now.

Clearly, common design errors in redundant systems is a strong concern for designers of
these systems [or at least they should be].  Other then the Space Shuttle, I can't
think off-hand of any other operating systems that do offer diverse design for
reliability purposes.  The other application of "diversity" is usually employed in
verification efforts, either through independent design verification or an independent
test team.  This, of course, is quite common, as there is a strong desire not to repeat
the same mistake, particularly an assumption, during the verification effort.

Have a good evening/morning or whatever, as appropriate for your time zone,

An interesting discussion,

Regards,

rk

============================================

Keith R. Williams wrote:

> Understood. However, the fact is that the astronauts have told
> the OBS people that they would never pull the lever in flight.
> By the time time things got so bad that they'd try
> un-FLIGHT-tested software they'd be dead, or so hopelessy lost
> that it wouldn't matter.  Note that they won't test the backup
> software on a nominal flight.
>
> It's one thing to screw up in the simulator because you're "dead"
> and another kettle-o-fish to be in space and pull the plug on
> something you've always trusted.  With the dynamics there isn't
> time to react and any reaction is *going* to go with what you
> know - right or wrong.
>
> On Wed, 29 Mar 2000 03:21:33, rk <stellare@nospam.erols.com>
> wrote:
>
> > Keith R. Williams wrote:
> >
> > > > The one example of a system with diversity that I am aware of is the Space
> > > > Shuttle's main computer system.  It consists of 5 computers, with identical
> > > > hardware.  The software, however, is identical on the 4 computers that
> > > > actually do the work.  A fifth computer, running but not controlling the
> > > > vehicle unless commanded to, runs software developed by a completely
> > > > independent team.
> > >
> > > This is correct.  Note the astronauts have also said that they
> > > would never pull the switch to go to the redundant software (it
> > > is a manual override).  They trust the Shuttle OBS and have never
> > > tried the other.
> > > >
> > > > Anyone else know of any other examples?
> > >
> > > Other than multiple parallel, but identical, TMR circuits in a
> > > crypto processor I don't know of any.  It's incredibly expensive
> > > to duplicate everything, especially the intellectual part.  Then,
> > > when you get an error after years of fault-free operation, do you
> > > want to trust a newbie?  When do you make that determination?
> > > ..likely when things have gone so wrong it's too late.  I
> > > believe it's better to throw that money and tallent at making
> > > sure the original problem is solved.  I believe the Shuttle OBS
> > > is evidence of this, both ways.
> >
> > Here's an excerpt from:
> >
> >    The Space Shuttle Primary Computer System
> >    A. Spector and D. Gifford
> >    Communications of the ACM, September, 1984, p. 874
> >
> > which is "interesting" ...
> >
> >
> >      AS. Could you describe a training scenario on the SMS that caused a problem
> >      for you?
> >
> >      Clemons.  Yes - it was a "bad-news - good-news" situation.  In 1981, just
> >      before STS-2 was scheduled to take off, some fuel spilled on the vehicle and
> >      a number of tiles fell off.  The mission was therefore delayed for a month
> >      or so.  there wasn't much to do at the Cape, so the crew came back to
> >      Houston to put in more time on the SMS.
> >
> >      One of the abort simulations they chose to test is called a "TransAtlantic
> >      abort," which supposes that the crew can neither return to the launch site
> >      nor go into orbit.  The objective is to land in Spain after dumping some
> >      fuel.  The crew was about to go into this dump sequence when all four of our
> >      flight computer machines locked up and went "catatonic."  Had this been the
> >      real thing, the Shuttle would probably have had difficulty landing.  This
> >      kind of scenario could only occur under a very specific and unlikely
> >      combination of physical and aerodynamic conditions; but there it was: Our
> >      machines stopped.  Our greatest fear had materialized - a generic software
> >      problem.
> >        We went off to look at the problem.  The crew was rather upset, and they
> >      went off to lunch.
> >
> >      AS. And contemplated their future on the next mission?
> >
> >      Clemons.  We contemplated our future too.  We analyzed the dump and
> >      determined what had happened.  Some software in all four machines had
> >      simultaneously branched off into a place where there wasn't any code to
> >      branch off into.  This resulted in a short loop in the operating system that
> >      was trying to field and to service repeated interrupts.  No applications
> >      were being run.  All the displays got a big X across them indicating that
> >      there were not being serviced.
> >
> > rk
> >



Article: 21731
Subject: Re: New Place and Route Software for Non-Commercial Research (Academic VPR 4.30 Available)
From: gnippiks@my-deja.com
Date: Thu, 30 Mar 2000 08:18:34 GMT
Links: << >>  << T >>  << A >>
In article <lauE4.42019$pA.130208@typhoon.mbnet.mb.ca>,
"Steve" <reply.through.newsgroup@paranoid.com> wrote:
>
> Tom Burgess <tom.burgess@hia.nrc.ca> wrote in message
> news:38E245D1.B020618E@hia.nrc.ca...
> > Is the software usable with any real FPGAs or it is just an academic
> exercise?
>
> Isn't this the stuff Altera is picking up?
>
> Steve
>
>

Well the technology in VPR has been commercialized by Right Track CAD
(see http://www.rtrack.com/ and http://www.rtrack.com/technology.html )
and incorporated in version 9.5 of MAX+PLUS II.

See this press release: http://www.altera.com/html/new/pressrel/pr-mp9.5.html
VPR's timing-driven packing, placement, and routing algorithms have been
incorporated in MAX+PLUS II.

The "academic non-commercial research" version just released also
incorporates timing-driven algorithms, but they are probably more
generic (i.e. not tuned to Altera's architecture).

The academic VPR allows to define your own FPGA architectural parameters
so you could target it to Xilinx- or Altera-like architectures, but
you won't be able to generate a bitstream from it and I don't think you can
even pass a placed and routed netlist to the Xilinx or Altera tools.

The academic VPR is mainly a tool for research into FPGA architectures
and CAD algorithms.  (The founders of Right Track CAD have written
a book on these topics: http://www.wkap.nl/book.htm/0-7923-8460-1 )


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21732
Subject: Re: Anyone using Philips (now Xilinx) Coolrunner PLDs?
From: z80@ds2.com (Peter)
Date: Thu, 30 Mar 2000 08:28:21 +0000
Links: << >>  << T >>  << A >>

AMD make a "zero power" one too, but in fact it is no more than a
standard 100mA 22V10 with input transition detection, powering down
the device if nothing is happening. So if you are clocking at say 1MHz
all the time (as some people do :)) it draws maybe 10-20mA - far too
much for me.

>>I do think someone else makes a "zero power" 22V10, though.
>TI makes them, however the price is out of all proportion to the amount
>of logic you can get in them.


Peter.
--
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 21733
Subject: Re: 10 gbit/s input
From: Tom Burgess <tom.burgess@home.com>
Date: Thu, 30 Mar 2000 08:53:35 GMT
Links: << >>  << T >>  << A >>
For the present, you need a separate demultiplexer in front of the FPGA to bring the data
rate down to something it can handle. For example, the Vitesse 8172 1-16 demux
http://www.vitesse.com/pdfs/vsc8172.pdf produces 16 parallel LVDS streams at a mere
600 MHz or so, which I think? should work with Xilinx's Virtex-E series. For FPGAs,
you want parts that are fast (duh), and that interface well with available demuxes, meaning
lots of LVDS or PECL differential inputs and clocks, and demuxes on the inputs to bring
the data rate down some more - you DON'T want to run the whole FPGA at 600 MHz. 

regards, tom


Anoop Nannra wrote:
> 
> Hi all,
> 
> Anyone out there know of any references, texts or otherwise, that may give
> me an idea on how to take in a 10gbit/s serial data stream into an fpga or
> an array of fpga's ?  Also, any ideas on what I should be looking for in and
> fpga to be able to accept that kind of input ?
> 
> TIA
> Anoop
Article: 21734
Subject: Re: FPGA openness
From: rob_dickinson@my-deja.com
Date: Thu, 30 Mar 2000 08:58:11 GMT
Links: << >>  << T >>  << A >>
In article <8btl68$kjh$1@jetsam.uits.indiana.edu>,
galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
> In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com
wrote:
> >Having read most of this thread I have the following global comments.
> >
> >1)If you just want to play then surely you can understand that
company
> >A or X have better things to do than to be bothered with even a few
> >hundred people going "your" route.
>
> Total disagreement. As I've said before, most people competent in the
> field learned most of what they knew going in just playing around. The
> more hobbyists playing with it today the more companies buying hte
things
> tomorrow. I think Linux's commercial success proves that -- I don't
think
> managers picked it because htey liked it, I think managers picked it
> because their employees said "I know and like Linux, it'll do the job
and
> if it doesn't we'll make it."


Greg
I'm about to disapoint you.
FPGA's are inevitably designed by many people in such a manner that
they can be maintained by other people over many years and probably
ported easily to newer devices.  The ability to "hack" at or near the
bitstream level will not impress many people and I can assure you that
decisions to invest 10,000 (say) man hours because "Greg played with
bitstreams at home" will not cut it at all.  If it was "Greg is bloody
good at VHDL simulation using VITAL and does the job in half the time"
then you probably will still not influence the decision making but you
will get paid more than the next guy.
Yes one guy can probably write good code for FPGA's on his own, doing
it some strange weird way because X let him do it at the bitstream
level,  but you might go under a bus and you will almost definitely
change companies during the lifetime of the #CODE#.  You are therefore
only usefull to a company if you are competent with the tools which the
next guy can use.
The more hobyists using VHDL (which is free from the right places) the
better, the more people coming through degrees who still know what a
counter or state machine is at the gate level, even better.  A thorough
knowledge of the routing architecture at any level is almost useless,
Vertex will be almost completely superceeded in a frighteningly short
time and no-one will give diddly squat that you know it litterally
inside out.

Rob



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21735
Subject: Re: MaxPlus9.5 License and Fitter problems
From: rob_dickinson@my-deja.com
Date: Thu, 30 Mar 2000 09:03:14 GMT
Links: << >>  << T >>  << A >>
In article <01bf99ea$b3e094a0$2a3b2bd1@speedy>,
"M R Wheeler" <intell-a-sys@iquest.net> wrote:
> I am evaluating MaxPlus 9.5 and am finding that often the software
can not
> seem to locate the dongle during the build process on larger designs.
The
> software give me a license error message. Also, when selecting the
Quartus
> fitter, I am getting internal errors (contact Altera, who never has a
> clue). Both problems occur on two different computers. Just wonder if
> anyone else is using this version yet.
>
>
We are compiling for 10K30 just fine but can reliably crash the Quartus
fitter with certain designs.  "Our" Altera FAE is fully aware that this
is so.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21736
Subject: Re: VGA interface and VHDL
From: Leon Heller <leon_heller@hotmail.com>
Date: Thu, 30 Mar 2000 12:10:19 GMT
Links: << >>  << T >>  << A >>
In article <8bta6v$qkc@catapult.gatech.edu>,
Anshuman Sharma <gte600f@prism.gatech.edu> wrote:
> I am designing a processor that runs the calculator game "worm". I
have
> designed it in VHDL and I am going to use a Flex10k part to synthesize
> it. I want help with the VGA display. Basically if anyone can help me
find
> something on how I can build a VGA module that will interact with my
> datapath and the game as a whole.

The XSOC FPGA CPU has a VGA display. You'll find details here:
www.fpgacpu.org/xsoc

Leon



--
Leon Heller, G1HSM
Tel: (Mobile) 079 9098 1221 (Work) +44 1327 357824
Email: leon_heller@hotmail.com
Web: http://www.geocities.com/SiliconValley/Code/1835


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21737
Subject: Re: tristate /driving a bidirectional port
From: Jonas Rangell <jonas.rangell@emw.ericsson.se>
Date: Thu, 30 Mar 2000 15:21:16 +0200
Links: << >>  << T >>  << A >>
MK Yap wrote:
>
>

[snip]
 
> I have been struggling with this for quite some time. Is there a good way
> for coding bidirection signals so that there is no logic contention? When to
> drive the signal & when to tristate it?

  
>   ELSIF (MClk'event AND MClk='0') THEN
>        RdDone <= '0';
>        WrtHold <= '0';
>        RAM_Data <= (OTHERS=>'Z');                --- (1)


You have Z-assignments inside a clocked process.
That is not good. These should be placed in an
asyncronus process.

Create a clocked process, containing the data to RAM
and one asyncronus process which will do the data output,
and handling the tristate.



Something like this....


Process(cp)  -- Clocked Output to port
Begin
 if rising_edge(cp) then
   data_int <= data_to_RAM; 
 end if;
End Process;

Process(data_int, direction_to_RAM) -- Tristate control
Begin
  If direction_to_RAM = '1' Then
    data_iob <= data_int;
  Else
    data_iob <= 'Z';
  End If;
End Process;

Process(data_iob) -- Read data from port
Begin
  data_in <= data_iob;
End Process;

process(cp) -- return zero during write, else RAM data
begin
 if rising_edge(cp) then
  if direction_to_RAM='1' then
   data_from_RAM<='0'; 
  else
   data_from_RAM<=data_in;
  end if;
 end if;
end process;




Well, I have not really checked the code but it looks OK.
Hope it helps


/Jonas
Article: 21738
Subject: Memory cores
From: Jamil Khatib <khatib@ieee.org>
Date: Thu, 30 Mar 2000 16:34:36 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------E48B7AAADCC3B79468E7BEDC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
why do the FPGA tools does not recognize the array model of a ram as a
memory bits and so synthesize it to memory cores when a reset operation
is assumed?

For example, I've two dual port memory models " That can be found on the
opencores CVS" one that sets all memory bits to zero upon reset and the
other does not care about memory initialization.

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



--------------E48B7AAADCC3B79468E7BEDC
Content-Type: application/x-unknown-content-type-vhd_auto_file;
 name="dpmem.vhd"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="dpmem.vhd"

LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gDQotLSBDb3B5cmlnaHQgSmFtaWwgS2hh
dGliIDE5OTkNCi0tIA0KLS0NCi0tIFRoaXMgVkhETCBkZXNpZ24gZmlsZSBpcyBhbiBvcGVu
IGRlc2lnbjsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yDQotLSBtb2RpZnkgaXQg
YW5kL29yIGltcGxlbWVudCBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE9wZW5pcCBHZW5l
cmFsIFB1YmxpYw0KLS0gTGljZW5zZSBhcyBpdCBpcyBnb2luZyB0byBiZSBwdWJsaXNoZWQg
YnkgdGhlIE9wZW5JUCBPcmdhbml6YXRpb24gYW5kIGFueQ0KLS0gY29taW5nIHZlcnNpb25z
IG9mIHRoaXMgbGljZW5zZS4NCi0tIFlvdSBjYW4gY2hlY2sgdGhlIGRyYWZ0IGxpY2Vuc2Ug
YXQNCi0tIGh0dHA6Ly93d3cub3BlbmlwLm9yZy9vYy9saWNlbnNlLmh0bWwNCi0tDQotLQ0K
LS0gQ3JlYXRvciA6IEphbWlsIEtoYXRpYg0KLS0gRGF0ZSAxNC81Lzk5DQotLQ0KLS0gdmVy
c2lvbiAwLjE5OTkxMjI0DQotLQ0KLS0gVGhpcyBmaWxlIHdhcyB0ZXN0ZWQgb24gdGhlIE1v
ZGVsU2ltIDUuMkVFDQotLSBUaGUgdGVzdCB2ZWNvcnMgZm9yIG1vZGVsIHNpbSBpcyBpbmNs
dWRlZCBpbiB2ZWN0b3JzLmRvIGZpbGUNCi0tIFRoaXMgVkhETCBkZXNpZ24gZmlsZSBpcyBw
cm92ZWQgdGhyb3VnaCBzaW11bGF0aW9uIGJ1dCBub3QgdmVyaWZpZWQgb24gU2lsaWNvbg0K
LS0gDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTElCUkFSWSBpZWVlOw0KVVNF
IGllZWUuc3RkX2xvZ2ljXzExNjQuQUxMOw0KDQpVU0UgaWVlZS5zdGRfbG9naWNfc2lnbmVk
LkFMTDsNCg0KDQoNCi0tIER1YWwgcG9ydCBNZW1vcnkgY29yZQ0KDQoNCg0KRU5USVRZIGRw
bWVtIElTDQpnZW5lcmljICggQUREX1dJRFRIOiBpbnRlZ2VyIDo9IDggOw0KCQkgV0lEVEgg
OiBpbnRlZ2VyIDo9IDgpOw0KICBQT1JUICgNCiAgICBjbGsgICAgICA6IElOICBzdGRfbG9n
aWM7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSB3cml0ZSBjbG9jaw0KICAg
IHJlc2V0ICAgIDogSU4gIHN0ZF9sb2dpYzsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIC0tIFN5c3RlbSBSZXNldA0KICAgIFdfYWRkICAgIDogSU4gIHN0ZF9sb2dpY192ZWN0
b3IoYWRkX3dpZHRoIC0xIGRvd250byAwKTsgIC0tIFdyaXRlIEFkZHJlc3MNCiAgICBSX2Fk
ZCAgICA6IElOICBzdGRfbG9naWNfdmVjdG9yKGFkZF93aWR0aCAtMSBkb3dudG8gMCk7ICAt
LSBSZWFkIEFkZHJlc3MNCiAgICBEYXRhX0luICA6IElOICBzdGRfbG9naWNfdmVjdG9yKFdJ
RFRIIC0gMSAgRE9XTlRPIDApOyAgICAtLSBpbnB1dCBkYXRhDQogICAgRGF0YV9PdXQgOiBP
VVQgc3RkX2xvZ2ljX3ZlY3RvcihXSURUSCAtMSAgIERPV05UTyAwKTsgICAgLS0gb3V0cHV0
IERhdGENCiAgICBXUiAgICAgICA6IElOICBzdGRfbG9naWM7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAtLSBXcml0ZSBFbmFibGUNCiAgICBSRSAgICAgICA6IElOICBzdGRf
bG9naWMpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBSZWFkIEVuYWJsZQ0K
RU5EIGRwbWVtOw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQVJDSElURUNU
VVJFIGRwbWVtX3YxIE9GIGRwbWVtIElTDQoNCg0KDQogIFRZUEUgZGF0YV9hcnJheSBJUyBB
UlJBWSAoaW50ZWdlciByYW5nZSA8PikgT0Ygc3RkX2xvZ2ljX3ZlY3RvcihXSURUSCAtMSAg
RE9XTlRPIDApOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t
IE1lbW9yeSBUeXBlDQogIFNJR05BTCBkYXRhIDogZGF0YV9hcnJheSgwIHRvICgyKiogYWRk
X3dpZHRoKSApOyAgLS0gTG9jYWwgZGF0YQ0KDQoNCg0KICBwcm9jZWR1cmUgaW5pdF9tZW0o
c2lnbmFsIG1lbW9yeV9jZWxsIDogaW5vdXQgZGF0YV9hcnJheSApIGlzDQogIGJlZ2luDQoN
CiAgICBmb3IgaSBpbiAwIHRvICgyKiogYWRkX3dpZHRoKSBsb29wDQogICAgICBtZW1vcnlf
Y2VsbChpKSA8PSAob3RoZXJzID0+ICcwJyk7DQogICAgZW5kIGxvb3A7DQoNCiAgZW5kIGlu
aXRfbWVtOw0KDQoNCkJFR0lOICAtLSBkcG1lbV92MQ0KDQogIFBST0NFU1MgKGNsaywgcmVz
ZXQpDQoNCiAgQkVHSU4gIC0tIFBST0NFU1MNCg0KDQogICAgLS0gYWN0aXZpdGllcyB0cmln
Z2VyZWQgYnkgYXN5bmNocm9ub3VzIHJlc2V0IChhY3RpdmUgbG93KQ0KICAgIElGIHJlc2V0
ID0gJzAnIFRIRU4NCiAgICAgIGRhdGFfb3V0IDw9IChPVEhFUlMgPT4gJ1onKTsNCiAgICAg
IGluaXRfbWVtICggZGF0YSk7DQoNCiAgICAgIC0tIGFjdGl2aXRpZXMgdHJpZ2dlcmVkIGJ5
IHJpc2luZyBlZGdlIG9mIGNsb2NrDQogICAgRUxTSUYgY2xrJ2V2ZW50IEFORCBjbGsgPSAn
MScgVEhFTg0KICAgICAgSUYgUkUgPSAnMScgVEhFTg0KICAgICAgICBkYXRhX291dCA8PSBk
YXRhKGNvbnZfaW50ZWdlcihSX2FkZCkpOw0KICAgICAgZWxzZQ0KICAgICAgICBkYXRhX291
dCA8PSAoT1RIRVJTID0+ICdaJyk7ICAgIC0tIERlZnVhbHQgdmFsdWUNCiAgICAgIEVORCBJ
RjsNCg0KICAgICAgSUYgV1IgPSAnMScgVEhFTg0KICAgICAgICBkYXRhKGNvbnZfaW50ZWdl
UihXX2FkZCkpIDw9IERhdGFfSW47DQogICAgICBFTkQgSUY7DQogICAgRU5EIElGOw0KDQoN
Cg0KICBFTkQgUFJPQ0VTUzsNCg0KDQpFTkQgZHBtZW1fdjE7DQoNCg0KDQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCi0tIFRoaXMgQXJjaGl0ZWN0dXJlIHdhcyB0ZXN0ZWQgb24g
dGhlIE1vZGVsU2ltIDUuMkVFDQotLSBUaGUgdGVzdCB2ZWN0b3JzIGZvciBtb2RlbCBzaW0g
aXMgaW5jbHVkZWQgaW4gdmVjdG9ycy5kbyBmaWxlDQotLSBJdCBpcyBTeW50aGVzaXplZCB1
c2luZyBYaWxpbnggV2ViZml0dGVyDQotLQ0KLS0gDQotLSBUaGUgdmFyaWFibGUgcmVzdWx0
X2RhdGEgaXMgdXNlZCBhcyBhbiBpbnRlcm1lZGlhdGUgdmFyaWFibGUgaW4gdGhlIHByb2Nl
c3MNCi0tIA0KDQpBUkNISVRFQ1RVUkUgZHBtZW1fdjIgT0YgZHBtZW0gSVMNCg0KDQoNCiAg
VFlQRSBkYXRhX2FycmF5IElTIEFSUkFZIChpbnRlZ2VyIHJhbmdlIDw+KSBPRiBzdGRfbG9n
aWNfdmVjdG9yKFdJRFRIIC0xIERPV05UTyAwKTsNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAtLSBNZW1vcnkgVHlwZQ0KICBTSUdOQUwgZGF0YSA6IGRhdGFf
YXJyYXkoMCB0byAoMioqIGFkZF93aWR0aCkgKTsgIC0tIExvY2FsIGRhdGENCg0KDQotLSBJ
bml0aWFsaXplIHRoZSBtZW1vcnkgdG8gemVyb3MgDQogIHByb2NlZHVyZSBpbml0X21lbShz
aWduYWwgbWVtb3J5X2NlbGwgOiBpbm91dCBkYXRhX2FycmF5ICkgaXMNCiAgYmVnaW4NCg0K
ICAgIGZvciBpIGluIDAgdG8gKDIqKiBhZGRfd2lkdGgpIGxvb3ANCiAgICAgIG1lbW9yeV9j
ZWxsKGkpIDw9IChvdGhlcnMgPT4gJzAnKTsNCiAgICBlbmQgbG9vcDsNCg0KICBlbmQgaW5p
dF9tZW07DQoNCiANCkJFR0lOICAtLSBkcG1lbV92Mg0KDQogIFBST0NFU1MgKGNsaywgcmVz
ZXQpDQoNCiAgICB2YXJpYWJsZSByZXN1bHRfZGF0YSA6IHN0ZF9sb2dpY192ZWN0b3IoV0lE
VEggLTEgIGRvd250byAwKTsNCg0KICBCRUdJTiAgLS0gUFJPQ0VTUw0KDQotLSBpbml0IGRh
dGFfb3V0DQoNCg0KICAgIC0tIGFjdGl2aXRpZXMgdHJpZ2dlcmVkIGJ5IGFzeW5jaHJvbm91
cyByZXNldCAoYWN0aXZlIGxvdykNCiAgICBJRiByZXNldCA9ICcwJyBUSEVODQogICAgICBy
ZXN1bHRfZGF0YSA6PSAoT1RIRVJTID0+ICdaJyk7DQogICAgICBpbml0X21lbSAoIGRhdGEp
Ow0KDQogICAgICAtLSBhY3Rpdml0aWVzIHRyaWdnZXJlZCBieSByaXNpbmcgZWRnZSBvZiBj
bG9jaw0KICAgIEVMU0lGIGNsaydldmVudCBBTkQgY2xrID0gJzEnIFRIRU4NCiAgICAgIElG
IFJFID0gJzEnIFRIRU4NCiAgICAgICAgcmVzdWx0X2RhdGEgOj0gZGF0YShjb252X2ludGVn
ZXIoUl9hZGQpKTsNCiAgICAgIGVsc2UNCiAgICAgICAgcmVzdWx0X2RhdGEgOj0gKE9USEVS
UyA9PiAnWicpOyAgICAtLSBEZWZ1YWx0IHZhbHVlDQogICAgICBFTkQgSUY7DQoNCiAgICAg
IElGIFdSID0gJzEnIFRIRU4NCiAgICAgICAgZGF0YShjb252X2ludGVnZVIoV19hZGQpKSA8
PSBEYXRhX0luOw0KICAgICAgRU5EIElGOw0KICAgIEVORCBJRjsNCg0KZGF0YV9vdXQgPD0g
cmVzdWx0X2RhdGE7DQoNCg0KRU5EIFBST0NFU1M7DQoNCg0KRU5EIGRwbWVtX3YyOw0KDQoN
Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0gVGhpcyBBcmNoaXRlY3R1cmUgd2Fz
IHRlc3RlZCBvbiB0aGUgTW9kZWxTaW0gNS4yRUUNCi0tIFRoZSB0ZXN0IHZlY3RvcnMgZm9y
IG1vZGVsIHNpbSBpcyBpbmNsdWRlZCBpbiB2ZWN0b3JzLmRvIGZpbGUNCi0tIEl0IGlzIFN5
bnRoZXNpemVkIHVzaW5nIFhpbGlueCBXZWJwYWNrDQotLQ0KLS0gVGhpcyBpcyB0aGUgc2Ft
ZSBhcyBkcG1lbV92MSBidXQgd2l0aG91dCB0aGUgWiBzdGF0ZQ0KLS0gaW5zdGVhZCB0aGUg
b3V0cHV0IGdvZXMgdG8gYWxsIDEncyBkdXJpbmcgcmVzZXQgYW5kIA0KLS0gd2hlbiBSRSA9
IDANCg0KQVJDSElURUNUVVJFIGRwbWVtX3YzIE9GIGRwbWVtIElTDQoNCg0KDQogIFRZUEUg
ZGF0YV9hcnJheSBJUyBBUlJBWSAoaW50ZWdlciByYW5nZSA8PikgT0Ygc3RkX2xvZ2ljX3Zl
Y3RvcihXSURUSCAtMSBET1dOVE8gMCk7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLS0gTWVtb3J5IFR5cGUNCiAgU0lHTkFMIGRhdGEgOiBkYXRhX2FycmF5
KDAgdG8gKDIqKiBhZGRfd2lkdGgpICk7ICAtLSBMb2NhbCBkYXRhDQoNCg0KDQogIHByb2Nl
ZHVyZSBpbml0X21lbShzaWduYWwgbWVtb3J5X2NlbGwgOiBpbm91dCBkYXRhX2FycmF5ICkg
aXMNCiAgYmVnaW4NCg0KICAgIGZvciBpIGluIDAgdG8gKDIqKiBhZGRfd2lkdGgpIGxvb3AN
CiAgICAgIG1lbW9yeV9jZWxsKGkpIDw9IChvdGhlcnMgPT4gJzAnKTsNCiAgICBlbmQgbG9v
cDsNCg0KICBlbmQgaW5pdF9tZW07DQoNCg0KQkVHSU4gIC0tIGRwbWVtX3YzDQoNCiAgUFJP
Q0VTUyAoY2xrLCByZXNldCkNCg0KICBCRUdJTiAgLS0gUFJPQ0VTUw0KDQoNCiAgICAtLSBh
Y3Rpdml0aWVzIHRyaWdnZXJlZCBieSBhc3luY2hyb25vdXMgcmVzZXQgKGFjdGl2ZSBsb3cp
DQogICAgSUYgcmVzZXQgPSAnMCcgVEhFTg0KICAgICAgZGF0YV9vdXQgPD0gKE9USEVSUyA9
PiAnMScpOw0KICAgICAgaW5pdF9tZW0gKCBkYXRhKTsNCg0KICAgICAgLS0gYWN0aXZpdGll
cyB0cmlnZ2VyZWQgYnkgcmlzaW5nIGVkZ2Ugb2YgY2xvY2sNCiAgICBFTFNJRiBjbGsnZXZl
bnQgQU5EIGNsayA9ICcxJyBUSEVODQogICAgICBJRiBSRSA9ICcxJyBUSEVODQogICAgICAg
IGRhdGFfb3V0IDw9IGRhdGEoY29udl9pbnRlZ2VyKFJfYWRkKSk7DQogICAgICBlbHNlDQog
ICAgICAgIGRhdGFfb3V0IDw9IChPVEhFUlMgPT4gJzEnKTsgICAgLS0gRGVmdWFsdCB2YWx1
ZQ0KICAgICAgRU5EIElGOw0KDQogICAgICBJRiBXUiA9ICcxJyBUSEVODQogICAgICAgIGRh
dGEoY29udl9pbnRlZ2VSKFdfYWRkKSkgPD0gRGF0YV9JbjsNCiAgICAgIEVORCBJRjsNCiAg
ICBFTkQgSUY7DQoNCg0KDQogIEVORCBQUk9DRVNTOw0KDQoNCkVORCBkcG1lbV92MzsNCg0K
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==
--------------E48B7AAADCC3B79468E7BEDC
Content-Type: application/x-unknown-content-type-vhd_auto_file;
 name="dpmem2clk.vhd"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="dpmem2clk.vhd"

LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotLSBUaXRsZSAgICAgIDogR2VuZXJlaWMgc3lu
Y2hyb25vdXMgRHVhbCBwb3J0IG1lbW9yeQotLSBQcm9qZWN0ICAgIDogTWVtb3J5IENvcmVz
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLS0gRmlsZSAgICAgICAgOiBEUE1FTTJDTEsu
VkhECi0tIEF1dGhvciAgICAgIDogSmFtaWwgS2hhdGliICA8a2hhdGliQGllZWUub3JnPgot
LSBPcmdhbml6YXRpb246IE9wZW5JUENvcmUgUHJvamVjdAotLSBDcmVhdGVkICAgICA6IDIw
MDAvMDMvMjkKLS0gTGFzdCB1cGRhdGUgOiAyMDAwLzAzLzI5Ci0tIFBsYXRmb3JtICAgIDog
DQotLSBTaW11bGF0b3JzICA6IE1vZGVsc2ltIDUuMkVFIC8gV2luZG93czk4ICYgWGlsaW54
IG1vZGVsc2ltIDUuM2EgWEUNCi0tIFN5bnRoZXNpemVyczogTGVvbmFyZG8gLyBXaW5kb3dz
TlQgJiBYaWxpbnggd2ViZml0dGVyDQotLSBUYXJnZXQgICAgICA6IEZsZXgxMEtFDQotLSBE
ZXBlbmRlbmN5ICA6IAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0tIERlc2NyaXB0aW9u
OiBHZW5lcmVpYyBzeW5jaHJvbm91cyBEdWFsIHBvcnQgbWVtb3J5DQotLSAgICAgICAgICAg
ICAgICAgICAgICAgIDogU2VwZXJhdGUgcmVhZCBhbmQgd3JpdGUgY2xvY2tzCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0KLS0gQ29weXJpZ2h0IChjKSAyMDAwIEphbWlsIEtoYXRpYgot
LSANCi0tIFRoaXMgVkhETCBkZXNpZ24gZmlsZSBpcyBhbiBvcGVuIGRlc2lnbjsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yDQotLSBtb2RpZnkgaXQgYW5kL29yIGltcGxlbWVu
dCBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIE9wZW5pcCBHZW5lcmFsIFB1YmxpYw0KLS0g
TGljZW5zZSBhcyBpdCBpcyBnb2luZyB0byBiZSBwdWJsaXNoZWQgYnkgdGhlIE9wZW5JUENv
cmUgT3JnYW5pemF0aW9uIGFuZA0KLS0gYW55IGNvbWluZyB2ZXJzaW9ucyBvZiB0aGlzIGxp
Y2Vuc2UuDQotLSBZb3UgY2FuIGNoZWNrIHRoZSBkcmFmdCBsaWNlbnNlIGF0DQotLSBodHRw
Oi8vd3d3Lm9wZW5pcC5vcmcvb2MvbGljZW5zZS5odG1sDQoNCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0KLS0gUmV2aXNpb25zICA6Ci0tIFJldmlzaW9uIE51bWJlciA6IDENCi0tIFZl
cnNpb24gICAgICAgICAgICAgIDogICAxLjANCi0tIERhdGUgICAgICAgICAgICAgOiAgIDI5
dGggTWFyIDIwMDANCi0tIE1vZGlmaWVyICAgICA6ICAgSmFtaWwgS2hhdGliIChraGF0aWJA
aWVlZS5vcmcpDQotLSBEZXNjY3JpcHRpb24gOiAgICAgICBDcmVhdGVkDQotLQ0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCmxpYnJhcnkgaWVlZTsgDQp1c2UgaWVlZS5zdGRf
bG9naWNfMTE2NC5hbGw7IA0KdXNlIGllZWUuc3RkX2xvZ2ljX3Vuc2lnbmVkLmFsbDsgDQoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tIFN5bmNocm9ub3VzIER1YWwgUG9ydCBN
ZW1vcnkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmVudGl0eSBEcG1lbTJjbGsgaXMN
CiAgDQogIGdlbmVyaWMgKA0KICAgIEFERF9XSURUSCAgICAgICAgIDogICAgIGludGVnZXIg
ICA6PSA0OyAgLS0gQWRkcmVzcyB3aWR0aA0KICAgIFdJRFRIICAgICAgICAgICAgIDogICAg
IGludGVnZXIgICA6PSA4OyAgLS0gV29yZCBXaWR0aA0KICAgIGNvcmV0eXBlICAgICAgICAg
IDogICAgIGludGVnZXIgICA6PSAwKTsgIC0tIG1lbW9yeSBidWxkaW5nIGJsb2NrIHR5cGUN
CiAgDQogIHBvcnQgKA0KICAgIFdjbGsgICAgICAgICAgICAgIDogaW4gIHN0ZF9sb2dpYzsg
IC0tIHdyaXRlIGNsb2NrDQogICAgV2VuICAgICAgICAgICAgICAgOiBpbiAgc3RkX2xvZ2lj
OyAgLS0gV3JpdGUgRW5hYmxlDQogICAgV2FkZCAgICAgICAgICAgICAgOiBpbiAgc3RkX2xv
Z2ljX3ZlY3RvcihBRERfV0lEVEggLTEgZG93bnRvIDApOyAgLS0gV3JpdGUgQWRkcmVzcw0K
ICAgIERhdGFpbiAgICAgICAgICAgIDogaW4gIHN0ZF9sb2dpY192ZWN0b3IoV0lEVEggLTEg
ZG93bnRvIDApOyAgLS0gSW5wdXQgRGF0YQ0KICAgIFJjbGsgICAgICAgICAgICAgIDogaW4g
IHN0ZF9sb2dpYzsgIC0tIFJlYWQgY2xvY2sNCiAgICBSZW4gICAgICAgICAgICAgICA6IGlu
ICBzdGRfbG9naWM7ICAtLSBSZWFkIEVuYWJsZQ0KICAgIFJhZGQgICAgICAgICAgICAgIDog
aW4gIHN0ZF9sb2dpY192ZWN0b3IoQUREX1dJRFRIIC0xIGRvd250byAwKTsgIC0tIFJlYWQg
QWRkcmVzcw0KICAgIERhdGFvdXQgICAgICAgICAgIDogb3V0IHN0ZF9sb2dpY192ZWN0b3Io
V0lEVEggLTEgZG93bnRvIDApKTsgIC0tIE91dHB1dCBkYXRhDQogIA0KZW5kIERwbWVtMmNs
azsgDQoNCmFyY2hpdGVjdHVyZSBkcG1lbV9hcmNoIG9mIERwbWVtMmNsayBpcw0KICANCiAg
dHlwZSBEQVRBX0FSUkFZIGlzIGFycmF5IChpbnRlZ2VyIHJhbmdlIDw+KSBvZiBzdGRfbG9n
aWNfdmVjdG9yKFdJRFRIIC0xIGRvd250byAwKTsgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgLS0gTWVtb3J5IFR5cGUNCiAgc2lnbmFsICAgZGF0YSAgICAg
ICA6ICAgICBEQVRBX0FSUkFZKDAgdG8gKDIqKkFERF9XSURUSCkgLTEpOyAgLS0gTG9jYWwg
ZGF0YQ0KICBjb25zdGFudCBJREVMT1VUUFVUIDogICAgIHN0ZF9sb2dpYyA6PSAnWic7ICAt
LSBJREVMIHN0YXRlIG91dHB1dA0KICANCmJlZ2luICAtLSBkcG1lbV9hcmNoDQogIA0KICAt
LSBwdXJwb3NlOiBSZWFkIHByb2Nlc3MNCiAgLS0gdHlwZSAgIDogc2VxdWVudGlhbA0KICAt
LSBpbnB1dHMgOiBSY2xrDQogIC0tIG91dHB1dHM6IA0KICBSZVByb2MgICAgICAgICAgICAg
IDogICAgIHByb2Nlc3MgKFJjbGspDQogIGJlZ2luICAtLSBwcm9jZXNzIFJlUHJvYw0KICAg
IA0KICAgIGlmIFJjbGsnZXZlbnQgYW5kIFJjbGsgPSAnMScgdGhlbiAgIC0tIHJpc2luZyBj
bG9jayBlZGdlDQogICAgICBpZiBSZW4gPSAnMScgdGhlbg0KICAgICAgICBEYXRhb3V0ICAg
ICAgICAgICAgICAgICAgICAgICA8PSBkYXRhKGNvbnZfaW50ZWdlcihSYWRkKSk7IA0KICAg
ICAgZWxzZQ0KICAgICAgICBEYXRhb3V0ICAgICAgICAgICAgICAgICAgICAgICA8PSAob3Ro
ZXJzID0+IElERUxPVVRQVVQpOyANCiAgICAgIGVuZCBpZjsgDQogICAgICANCiAgICBlbmQg
aWY7IA0KICBlbmQgcHJvY2VzcyBSZVByb2M7IA0KICANCiAgLS0gcHVycG9zZTogV3JpdGUg
cHJvY2Vzcw0KICAtLSB0eXBlICAgOiBzZXF1ZW50aWFsDQogIC0tIGlucHV0cyA6IFdjbGsN
CiAgLS0gb3V0cHV0czogDQogIFdyUHJvYyAgICAgICAgICAgICAgOiAgICAgcHJvY2VzcyAo
V2NsaykNCiAgYmVnaW4gIC0tIHByb2Nlc3MgV3JQcm9jDQogICAgDQogICAgaWYgV2Nsaydl
dmVudCBhbmQgV2NsayA9ICcxJyB0aGVuICAgLS0gcmlzaW5nIGNsb2NrIGVkZ2UNCiAgICAg
IGlmIFdlbiA9ICcxJyB0aGVuDQogICAgICAgIA0KICAgICAgICBkYXRhKGNvbnZfaW50ZWdl
cihXYWRkKSkgICAgICA8PSBEYXRhaW47IA0KICAgICAgZW5kIGlmOyANCiAgICAgIA0KICAg
IGVuZCBpZjsgDQogIGVuZCBwcm9jZXNzIFdyUHJvYzsgDQogIA0KZW5kIGRwbWVtX2FyY2g7
IA0KDQoNCgoKCgoK
--------------E48B7AAADCC3B79468E7BEDC--

Article: 21739
Subject: Re: Global clock nets. Can I use it for signal other than clock.
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Thu, 30 Mar 2000 09:35:56 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------9D26ACEF6E5B27AA3E63F9C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the responses.  We are using Virtex in this case.  So, we will not
get a DRC error in the backend flow, but our RESET signal is not really using
a global net.  Our timing did get alot better, but I guess it was because of
other changes we made.  Thanks for clearing this up.

Regards,
Tom

Peter Alfke wrote:

> It depends on the Xilinx family:
>
> In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you can
> use the global nets for anything you might want.
>
> In Virtex and its derivatives ( incl. Spartan-II) you can use the global
> clock nets *ONLY* as clocks.
> If you were to use them for other purposes, the routing would actually use
> the normal routing channels. So this would be self-defeating.
>
> Peter Alfke, Xilinx Applications
> =========================================
> Tom McLaughlin wrote:
>
> > All,
> > If I interpret the datasheet, it says that the 4 global clock nets in a
> > Xilinx Virtex device can only be used for clocks.  Before we read this,
> > we implemented a reset signal using one of the global clock buffers and
> > global clock nets.  We did not get any errors in synthesis or place and
> > route.  We have done gate level simulations on the netlist and it
> > simulates fine.  However, the Xilinx doc clearly states that, "Four
> > global buffers drive the four primary global nets that in turn drive any
> > clock pin."
> >
> > So, the question remains:
> >
> > Can we use the global nets for global signals other than clocks???
> >
> > Tom

--------------9D26ACEF6E5B27AA3E63F9C4
Content-Type: text/x-vcard; charset=us-ascii;
 name="tomm.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom McLaughlin
Content-Disposition: attachment;
 filename="tomm.vcf"

begin:vcard 
n:McLaughlin;Tom
tel;fax:314-935-7302
tel;work:314-935-7198
x-mozilla-html:FALSE
url:http://www.arl.wustl.edu/~tomm
org:Washington University;Applied Research Lab
version:2.1
email;internet:tomm@arl.wustl.edu
title:Research Associate
adr;quoted-printable:;;One Brookings Drive=0D=0ACampus Box 1045-ARL;St. Louis;MO;63130;USA
x-mozilla-cpt:;0
fn:Tom McLaughlin
end:vcard

--------------9D26ACEF6E5B27AA3E63F9C4--

Article: 21740
Subject: Pipelined ALTERA LPMs - where are the registers introduced?
From: nestor@stansync.com (Nestor Caouras)
Date: Thu, 30 Mar 2000 16:23:10 GMT
Links: << >>  << T >>  << A >>
Hi everyone.

I have a very simple question regarding the ALTERA LPMs.  I am
currently using the ALTERA FLEX10K100 series for a project at work and
I would like to use some of ALTERA's LPMs in pipelined form in order
to speed up my design.

My question: 
Assuming I want only one PIPELINE stage, where is it introduced in the
macro? At the output stage, so that the macro is composed of a
combinational circuit followed by a register?  Is this general for all
of ALTERA's macros?

Your help is greatly appreciated.

Thanks in advance.
 
Nestor Caouras
Tel.: (514) 356-0634     Fax.: (514) 356-0165     
email: nestor@stansync.com

Article: 21741
Subject: Re: Memory cores
From: Eric Friedrichs <Eric.Friedrichs@usa.alcatel.com>
Date: Thu, 30 Mar 2000 08:38:27 -0800
Links: << >>  << T >>  << A >>


Jamil Khatib wrote:

> Hi,
> why do the FPGA tools does not recognize the array model of a ram as a
> memory bits and so synthesize it to memory cores when a reset operation
> is assumed?

I am not aware of any FPGA memory resources (block, distributed) that include reset
capability.  To implement this, the synthesis tool is forced to use discreet Flip
Flops.

Try removing the reset function...

Regards
Eric Friedrichs

Article: 21742
Subject: Re: Virtex bitstreams wanted for compression study
From: Tim Tyler <tt@cryogen.com>
Date: Thu, 30 Mar 2000 16:49:46 GMT
Links: << >>  << T >>  << A >>
Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> wrote:

: And don't worry, due to the secret nature of the Xilinx bitstreams, I
: have no practical way of working out what your design does.

Uploading it to a Virtex chip - and then treating its pins as the outputs
from a black box - could give you a practical method of determining the
function ;-)
-- 
__________
 |im |yler  The Mandala Centre  http://mandala.co.uk/  tt@cryogen.com

When I gave her the ring, she gave me the finger.
Article: 21743
Subject: Re: Memory cores
From: David Kessner <davidk@free-ip.com>
Date: Thu, 30 Mar 2000 10:16:21 -0700
Links: << >>  << T >>  << A >>
Jamil Khatib wrote:
> why do the FPGA tools does not recognize the array model of a ram as a
> memory bits and so synthesize it to memory cores when a reset operation
> is assumed?

Ummm...   If I understand your question correctly, there are two 
issues here:

	1.  Why do FPGA tools not correctly synthesize the array
	    model of RAM?
	2.  Why can I not initialize the contents of RAM using a global
	    reset signal.

To answer #1:  Basically, synthesis tools are still not mature enough
to "transparently" take advantage of special FPGA/ASIC features like
RAM (but also DLL/PLL's, CAM, etc.).  There are several synthesis 
tools that will accept an array and synthesize it into RAM (Synplify
comes to mind), but many more do not (Quartus, FPGA Express, etc.).  

Further, the tools that do synthesize an array have limitations when
it comes to actual use.  These limitations come mostly from the 
different RAM architectures found in many FPGA's (and sometimes in
the same FPGA, a.la. Virtex & Spartan 2).  While they still synthesize
an array into RAM, it isn't always as transparent as we would like.

Take a look at the Free-RAM core at The Free-IP Project 
(http://www.free-ip.com).  This is basically a dual port ram core
that is portable across FPGA Express (Xilinx), Quartus (Altera),
and Model SIM.  To do this, the Free-RAM core takes the lowest 
common denominator of features across all architectures and 
puts them under a single VHDL entity (actually, a series of them
that are interchangeable).  This sounds like a relatively easy
thing to do, but as you can see from the VHDL code, it's not
as trivial as one would think!


To answer #2:  You cannot initialize the contents of RAM using a
reset signal because they just aren't wired that way.  Neither Xilinx
or Altera have a mechanism to reset the contents of RAM (any type 
of RAM) using any reset signal (global reset or otherwise).  This
is just like using a standard off the shelf RAM chip-- there isn't
a reset signal for those either.

What Altera and Xilinx have done, however, is provide a way to 
initialize the contents of RAM to any arbitrary value during the
normal FPGA programming process.  In other words, the initial 
contents of all RAM is included in the programming bitstream.
This allows the RAM to be initialized to a specific value and 
used as a ROM (or something else).

Unfortunately, I have no experience initializing RAM like that--
other than I know that it can be done and have seen it done.  I'll
have to learn how to soon, however, since it's recently come up
on a new core design...


Hope that helps!


David Kessner
davidk@free-ip.com		http://www.free-ip.com/
Article: 21744
Subject: Re: Global clock nets. Can I use it for signal other than clock.
From: "Tim" <tim@tile.demon.co.uk.notreally>
Date: Thu, 30 Mar 2000 10:24:42 -0700
Links: << >>  << T >>  << A >>
As I recall the sequence was

   XC2000 - (I have forgotten)
   XC3000 - only drive clocks
   XC4000 - drive anything
   Virtex - only drive clocks

Is there a paper on the research behind this?

> Peter Alfke wrote:
>
> > It depends on the Xilinx family:
> >
> > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you
can
> > use the global nets for anything you might want.
> >
> > In Virtex and its derivatives ( incl. Spartan-II) you can use the
global
> > clock nets *ONLY* as clocks.



Article: 21745
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 30 Mar 2000 17:51:11 GMT
Links: << >>  << T >>  << A >>
In article <8bv4us$7st$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote:
>In article <8btl68$kjh$1@jetsam.uits.indiana.edu>,
>galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
>> In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com
>wrote:
>> >Having read most of this thread I have the following global comments.
>> >
>> >1)If you just want to play then surely you can understand that
>company
>> >A or X have better things to do than to be bothered with even a few
>> >hundred people going "your" route.
>>
>> Total disagreement. As I've said before, most people competent in the
>> field learned most of what they knew going in just playing around. The
>> more hobbyists playing with it today the more companies buying hte
>things
>> tomorrow. I think Linux's commercial success proves that -- I don't
>think
>> managers picked it because htey liked it, I think managers picked it
>> because their employees said "I know and like Linux, it'll do the job
>and
>> if it doesn't we'll make it."
>
>
>Greg
>I'm about to disapoint you.
>FPGA's are inevitably designed by many people in such a manner that
>they can be maintained by other people over many years and probably
>ported easily to newer devices.  The ability to "hack" at or near the
>bitstream level will not impress many people and I can assure you that
>decisions to invest 10,000 (say) man hours because "Greg played with
>bitstreams at home" will not cut it at all.  If it was "Greg is bloody
>good at VHDL simulation using VITAL and does the job in half the time"
>then you probably will still not influence the decision making but you
>will get paid more than the next guy.
>Yes one guy can probably write good code for FPGA's on his own, doing
>it some strange weird way because X let him do it at the bitstream
>level,  but you might go under a bus and you will almost definitely
>change companies during the lifetime of the #CODE#.  You are therefore
>only usefull to a company if you are competent with the tools which the
>next guy can use.
>The more hobyists using VHDL (which is free from the right places) the
>better, the more people coming through degrees who still know what a
>counter or state machine is at the gate level, even better.  A thorough
>knowledge of the routing architecture at any level is almost useless,
>Vertex will be almost completely superceeded in a frighteningly short
>time and no-one will give diddly squat that you know it litterally
>inside out.

As easily as you dismiss my approach to learning, people who have been
through my approach to learning completely dismiss anything learned your
way as being inadequate and cloudy.  *shrug*  Bias can go both ways and it
doesn't make either side right -- but if there are two sides you shouldn't
be so sure yours is the only way.  I maintain that you don't know anything
if you don't know how it works -- you can't learn how FPGAs in general
work if you don't look in depth at at least one example and looking in
edpth at the Vertex chip won't make you any stupider when you see the
foobar chip -- if anything, it'll make you smarter because you'll see the
historical basis for decisions and you'll see neat innovations rather than
just an entirely new system.  If you'll never learn ANY of the chips then
I continue to maintain that you know plenty to get most jobs done, but not
enough for extreme excellence, which is sometimes demanded.
Article: 21746
Subject: What's so good about antifuse???
From: fulvs@my-deja.com
Date: Thu, 30 Mar 2000 18:28:03 GMT
Links: << >>  << T >>  << A >>
I'm trying to understand the difference between
antifuse, SRAM and flash based FPGAs. I have 3
questions and any comments on any of these would
be much appreciated.

1) Antifuse is purportedly cheaper, lower power,
higher performance. Why is this? If this is true
- how much cheaper, lower power etc?

2) Other than military/aerospace, what
applications are antifuse FPGAs used for? Aren't
SRAM FPGAs much better because they're many times
reprogrammable?

3) Who is the best antifuse vendor?

Thanks in advance for your help.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21747
Subject: Re: What's so good about antifuse???
From: "HH" <javier_cardona@no.com>
Date: Thu, 30 Mar 2000 11:21:54 -0800
Links: << >>  << T >>  << A >>
Hi,

I recommend you to visit http://www.optimagic.com/ .  It has a lot of
device-independent information...
I'm not an expert, but I'll try to answer you...

> 1) Antifuse is purportedly cheaper, lower power,
> higher performance. Why is this? If this is true
> - how much cheaper, lower power etc?

The resistance of a "shorted" gate is much lower that when a S-RAM cell is
used, thus less power.  Also the you use less die area for an anti-fuse that
for a SRAM control cell.

> 2) Other than military/aerospace, what
> applications are antifuse FPGAs used for? Aren't
> SRAM FPGAs much better because they're many times
> reprogrammable?

SRAM needs to be "booted".  In some applications it is a big disadvantage.

> 3) Who is the best antifuse vendor?

I only know Actel  (... but that does not make it the best ;-)

> Thanks in advance for your help.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 21748
Subject: Re: Global clock nets. Can I use it for signal other than clock.
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 30 Mar 2000 11:33:35 -0800
Links: << >>  << T >>  << A >>
No, there is no published research paper.
The decisions depend on the priorities seen at the time of family
inception:

Generality is obviously nice, but burdens the clock tree with a lot of
extra capacitance, whether the destinations are activated or not.

Single-mindedness reduces capacitive loading, and thus clock delay and
clock skew, which are important parameters at clock rates > 200 MHz. Also,
the improved quality of the additional interconnect allows us to restrict
the global clock lines to their original purpose.

Clock distribution quality has a higher importance today than it had years
ago, especially since the DLL can effectively eliminate the clock delay.
Clock skew thus takes on a new significance, and clock skew is drastically
improved by using the global nets as clocks only.

Hope this is convincing.

Peter Alfke, Xilinx Applications



Tim wrote:

> As I recall the sequence was
>
>    XC2000 - (I have forgotten)
>    XC3000 - only drive clocks
>    XC4000 - drive anything
>    Virtex - only drive clocks
>
> Is there a paper on the research behind this?
>
> > Peter Alfke wrote:
> >
> > > It depends on the Xilinx family:
> > >
> > > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you
> can
> > > use the global nets for anything you might want.
> > >
> > > In Virtex and its derivatives ( incl. Spartan-II) you can use the
> global
> > > clock nets *ONLY* as clocks.

Article: 21749
Subject: Re: FPGA & single point failure
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Thu, 30 Mar 2000 11:43:18 -0800
Links: << >>  << T >>  << A >>
Noticed new Xilinx app note on "SEU mitigation design
techniques for XQR4000XL" which might be of interest:

http://www.xilinx.com/xapp/xapp181.pdf

-- 
Tom Burgess
Digital Engineer
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3
Email:        tom.burgess@hia.nrc.ca


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