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 21100

Article: 21100
Subject: Re: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 01:44:01 GMT
Links: << >>  << T >>  << A >>
On Fri, 3 Mar 2000 20:33:48, "John Janusson" 
<jjanusson@nospami-o.com> wrote:

> In my experience with this design, the three things that caused long P&R
> times were lack of horsepower and/or memory on the PC (256MB, PII 450MHz,
> NT4.0 performed great),

My "KeithKit" is a PII-333 w/160MB (also NT).  I also threw it at
a PIII-600 (128MB) that we had sitting in a closet.  Tomorrow 
I'll gather more memory from the other "servers" the widget is 
supposed to go into and see what happens.  I'm not convinced I'm 
memory bound though.  There is little or no paging going on.
 
> inefficient use of FPGA global resources (ie. use
> only global clocks and resets, enable flipflops at the right frequency),

I've moved clocks and write/read enables to global nets.  What a 
pain!  Synplify understood the clocks were global until I added 
other globals.  It took some time to figure out why they dropped 
the clocks.  I ended up instantiating all globals. BTW, how do 
you do an inverting BUFG?.  I don't like the way the HDLanalyzer 
looks.  

> and
> having many constraints on the Xilinx tools (timespecs, routing placement,
> etc).   In fact, I found overall P&R performance usually was usually better
> if I didn't use constraints (other than pinout constraints).  But again,
> this design didn't push any sort of speed limit...

No speed limit here, but how to guarantee any timing without 
constraints?  Again, I only told Synplify about the clock 
periods.
>
> So assuming you have enough memory in your PC and your design effectively
> uses global routing resources,  I would guess the problem is that Symplicity
> is annotating constraints to the synthesized netlist (EDIF file read by
> Xilinx tools).  There should be an option to turn this off in Symplicity...
> If you really have to use constraints for performance reasons, enter them
> directly (and sparingly) into the Xilinx tool using the constraint editor.

I'm figuring this one out.  Synplify isn't all that great passing
constraints to Alliance.  I've ended up putting some pin locks in
each place because it doesn't like them otherwise.  OTOH, 
Synplify does use timing for synthesis, so it's a two-edged 
sword.

> 
> Good Luck,

Thanks I'll need it, though haven't had any so far (once upon a 
time this was a DynaChip design).  I got to board fab when that 
plank was suddenly drawn in.  ...blub.

----
  Keith
Article: 21101
Subject: Re: Design security
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Mon, 06 Mar 2000 17:52:42 -0800
Links: << >>  << T >>  << A >>
Ian,

A suggestion: Protection shouldn't prevent a copy from working; that's
too obvious. Protection should make a copy unreliable.

John

Article: 21102
Subject: Re: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Mar 2000 01:57:35 GMT
Links: << >>  << T >>  << A >>
On Fri, 3 Mar 2000 22:00:35, Ray Andraka <randraka@ids.net> 
wrote:

> The XCS40 is equivalent to an XC4020E.  The routing in the 4020E and
> 4025E is relatively sparse.  The 4KXL and 4KXLA have additional routing
> resources to combat this problem.  Additionally, the automatic placement
> does not do a very good job.  You can probably get much better results
> as well as a much quicker place and route if you floorplan the design.
> Historically, lots of people had trouble with the routing in the larger
> 4KE devices simply because the routing resources are not sufficient for
> a reasonably congested randomly placed design.  I haven't seen a
> spartan40/4020/4025 design yet that wouldn't route with some
> floorplanning and perhaps a little tailoring.  As a first step, you
> might look at the placed design in the floorplanner.  Turn on the
> routing congestion and see where it is badly congested, then try moving
> stuff around to reduce the congestion.

Thanks Ray.  I've been lurking in this group for a year (give or 
take) and have appreciated your wisdom (though sometimes scared 
by the impending doom ;-).  I've looked in the floorplanner, but 
this tool is not intuitive.  I see where the problems are, but am
not sure what to do about them.  I am just baffled why a 20-25% 
full device is causing me so much lost sleep. I believe I've 
narrowed it down to the constraints that Synplify is adding in, 
but they seem perfectly reasonable (one clock setup up on driven 
nets and zero hold on received nets - at least as I understand 
the constraints).  

I *have* learned that I'll have to take time out for a class on 
this tool before the next step.  That Virtex is going to be a 
mother for timing, though the logic I would call simple.  It's 
mostly data paths.  The only "arithmetic" is a few address 
comparitors.

> For the speed of the PAR, the speed and size of your memory is probably
> more important than the processor speed.  For example, My office machine
> is a dual pentium pro200 with 256MB of fast EDO.  My laptop is a
> PIII-366 Tecra with 64MB.  Place and route takes about 8-10 times longer
> on the laptop than it does on the slower desktop (and place and route
> does not take advantage of multiple processors).

Ok.  If the system doesn't page, is there any benefit in more 
memory?  These systems aren't paging, at least not much.  The 
only disk access I see is when the log files are written.  I'll 
steal some more memory tomorrow and see, but I'd like to know why
more memory would help (limiting paging is obvious).

> Bottom line: design to the architecture and do some floorplanning paying
> attention to the routing congestion.

Sure, but I didn't expect these problems for this trivial design.

----
  Keith
Article: 21103
Subject: Newbie asks: prototype done, now what?
From: nospam@bitbucket.com (MarvL)
Date: Tue, 07 Mar 2000 02:21:48 GMT
Links: << >>  << T >>  << A >>
Having just used a PCI prototype board to design and test our
fpga co-processor for a PC, the next question is: what is the 
breakeven number for just distributing our design to
various departments with more expensive prototype boards
versus getting some custom boards made in an attempt to make the
project cheaper? A few facts: the PCI interface logic is implemented
by the FPGA on board. We use almost none of the "extras" on
the board ( such as I/O connectors, LEDs, etc ).We will not
be sure of even approximate numbers until this thing is
demo'ed to the departments, but they will surely ask about
ballpark numbers. So what kinds of numbers are we talking
about to get a PCI PC board with little more than the fpga
device & its supporting circutry on it? 10? 25? 100? 1000?
Or is something like this already available off-the shelf?
TIA.
Article: 21104
Subject: Xilinx software
From: wannarat <ksuwanna@kmitl.ac.th>
Date: Tue, 07 Mar 2000 09:45:23 +0700
Links: << >>  << T >>  << A >>
Dear All
    Please tell me :
1. How different between Hardware debugger and JTAG programmer
in Xilinx Software when I want to download the design into FPGA?
2. How different between the usage of  (DONE, DIN, PROGRAM ...) pins and

(TSK,TCK...)pins for programming  cable?

Best Regard
mail to me at:  ksuwanna@kmitl.ac.th
--
Wannarat Suntiamorntut
Computer System Design Laboratory (CSDL)
Computer Engineering Department
Prince of Songkla University, Hatyai, Songkla 90112 Thailand
Tel. 66-074-212895  ext.311  Fax. 66-074-212895
 

Article: 21105
Subject: Re: SpartanXL route and place
From: Phil Hays <Spampostmaster@sprynet.com>
Date: Mon, 06 Mar 2000 21:18:14 -0800
Links: << >>  << T >>  << A >>
"Keith R. Williams" wrote:

> Possibly, but a UNIX make isn't going to help much.  This is NT,
> sorry to say.

There are make utilities for NT as well.  


-- 
Phil Hays
"Are you willing to vote for funding the completion 
of the third report of the IPCC"?  Ask the question!
Article: 21106
Subject: REMINDER: CFP: The Second NASA/DoD Workshop on Evolvable Hardware
From: jlohn@kronos.arc.nasa.gov (Jason Lohn)
Date: 7 Mar 2000 05:38:10 GMT
Links: << >>  << T >>  << A >>
			  **** REMINDER ****

                           Call for Papers

          The Second NASA/DoD Workshop on Evolvable Hardware

                          July 13 - 15, 2000
                   Silicon Valley, California, USA

                   http://ic.arc.nasa.gov/ic/eh2000

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

Hosted by:
   NASA Ames Information Sciences and Technology Directorate 
   JPL Center for Integrated Space Microsystems (CISM)

Evolvable hardware is an emerging field that applies simulated
evolution to the design and adaptation of physical structures,
particularly electronic systems.  The Second NASA/DoD Workshop on
Evolvable Hardware (EH-2000) will bring together leading researchers
and technologists from academia, government, and industry to discuss
advances and the state-of-the-art in this field.

Evolvable hardware techniques enable self-reconfigurability and
adaptability of programmable devices and thus have the potential to
significantly increase the functionality of deployed hardware systems.
Moreover, these techniques have the potential to reduce costs by
automating numerous design and optimization tasks encountered in
engineering design.

A focus of this year's workshop is on real-world applications of
evolvable hardware.  Current application areas include adaptive and
reconfigurable computing, circuit and antenna design, and evolutionary
robotics.  Evolvable hardware methods could also be effective in
dealing with increased complexity and reliability requirements in
areas such as sensors, MEMS, biomolecular design, quantum computing,
and nanoelectronics.

Topics to be covered include, but are not limited to:

      - Evolutionary hardware design (including mechanical and robotic
          systems, electronic circuit synthesis)
      - Real-world applications of evolvable hardware
      - Co-evolutionary methods
      - Online and offline evolution methods
      - Hardware/software co-evolution 
      - Testbeds and evolutionary design automation tools
      - Self-repairing hardware 
      - Self-reconfiguring hardware
      - Embryonic hardware 
      - Morphogenesis 
      - Novel devices and hardware platforms suitable for evolution 
      - Adaptive hardware, adaptive computing 
      - Adaptive flight hardware 



Important Dates:
  Submission deadline:                  March 17, 2000
  Author notification:                  April 17, 2000
  Camera ready manuscript deadline:     May 15, 2000
  Workshop:                             July 13-15, 2000


Submission of Papers:
  Please see the workshop web page at http://ic.arc.nasa.gov/ic/eh2000


Chair:	Jason Lohn, NASA Ames Research Center

Co-Chair:  Adrian Stoica, Jet Propulsion Laboratory

Program Co-Chairs:
  Silvano Colombano, NASA Ames Research Center
  Didier Keymeulen, Jet Propulsion Laboratory

Program Committee:
  Leon Alkalai, Jet Propulsion Laboratory (USA)
  Forrest H Bennett III, FX Palo Alto Laboratory (USA) 
  Neil Bergmann, Queensland University of Technology (Australia)
  Hugo de Garis, Starlab (Belgium)  
  Stuart J. Flockton, University of London (UK)
  Terry Fogarty, South Bank University (UK)
  David B. Fogel, Natural Selection, Inc. (USA) 
  James A. Foster, University of Idaho (USA)
  Pauline Haddow, Norwegian University of Science and Technology (Norway)
  Inman Harvey, University of Sussex (UK) 
  Hitoshi Hemmi, NTT Communication Science Labs (Japan) 
  Tetsuya Higuchi, Electrotechnical Laboratory (Japan) 
  Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
  Alan Hunsberger, National Security Agency (USA)
  Rich Katz, NASA Goddard Space Flight Center (USA) 
  John Koza, Stanford University (USA)
  Daniel Mange, Swiss Federal Institute of Technology (Switzerland) 
  Pierre Marchal, Swiss Center for Electronics & Microtechnology (Switzerland)
  Meyya Meyyappan, NASA Ames Research Center (USA)
  Julian Miller, University of Birmingham (UK)
  Jose Munoz, Department of Energy (USA)
  Masahiro Murakawa, Electrotechnical Laboratory (Japan) 
  Jordan Pollack, Brandeis University (USA)
  Edward Rietman, Lucent Technologies (USA)
  Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland) 
  Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
  Adrian Thompson, University of Sussex (UK) 
  Anil Thakoor, Jet Propulsion Laboratory (USA)
  Benny Toomarian, Jet Propulsion Laboratory (USA)
  Annie Wu, University of Central Florida (USA)
  Ricardo Zebulum, Jet Propulsion Laboratory (USA)
  Steven Zornetzer, NASA Ames Research Center (USA)


In Cooperation With:
  Numerical Aerospace Simulation (NAS) Systems Division, NASA Ames
  Computational Sciences Division, NASA Ames 
  Integrated Product Team, NASA Ames 
  Research Institute for Advanced Computer Studies (RIACS)
  GECCO-2000: Genetic and Evolutionary Computation Conference


For further information please check the workshop web site or contact:
	
  Jason Lohn
  NASA Ames Research Center
  MS 269-1
  Mountain View, CA 94035, USA
  jlohn@ptolemy.arc.nasa.gov
  Tel: +1 (650) 604-5138
  Fax: +1 (650) 604-3594
Article: 21107
Subject: Re: Design security
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Mon, 6 Mar 2000 22:55:10 -0800
Links: << >>  << T >>  << A >>
Seriosuly getting off topic, but:

> Ther "real" risk isn't from the sophisticated engineering team capable
> of reverse engineering your design, but rather from the fellow who
> finds an application with only an IC or two, i.e. an FPGA and a config
> prom...  His boards don't work, of course, but he knows your tech
> support and warranty policy are good.

Are they?  I don't know what the policy of the company I work at is, but I
would imagine most companies, as soon as they discover counterfeit parts
being made, would send out a notice to their customers and not support the
conterfeit parts.  I suppose some people unsuspectingly purchase counterfeit
equipment and get screwed with this approach, but I think most people who
have been around the block a few times know when a deal is "too good to be
true" and suspect the obvious.

Interesting link from Asus (the motherboard guys) on counterfeit
motherboards: http://www.asus.com/company/right.html

I was in Singapore a couple of years ago, and one of the friendly merchants
on Orchard Row took me up to his counterfeit Rolex room.  They actually had
a side by side comparison of their counterfeit Rolex "guts" (the mechanism
inside the watch) next to some (Chinese, I think it said) conterfeit guts,
and were pointing out on a sign why _their_ counterfeits were so much better
than those of the Chinese...!  :-)

I didn't buy any coutnerfeit Rolexes, but I did buy some counterfeit Nike
apparel to give to a friend who owns a chunk of Nike stock.

---Joel Kolstad



Article: 21108
Subject: Microprocessor architecture (6800, 4004? PA-RISC, PPC, MIPS, x86, ...?)
From: Tobin Fricke <tobin@cory.eecs.berkeley.edu>
Date: Tue, 07 Mar 2000 06:57:25 GMT
Links: << >>  << T >>  << A >>
I've recently become interested in microprocessor architecture and have
adopted as a personal project to implement a simple processor of some
sort in an Altera FPGA.  I'd like to learn about the architectures and
implementations of various processors in use today and from the past. 
I'm familiar with the general "big ideas" such as load-store
architectures, accumulator-architectures, etc, but I'd like to see some
real world designs.  I'd like to find some information on the early
Intel and Motorola processors; where can I find data on the Intel 4004
and 8080?  How about the Motorola 6800?  Is there some book or website
that offers a comparison of various designs?   I'm also interested in
seeing a comparison of modern designs, such as x86, Alpha, MIPS, ARM,
PA-RISC, PowerPC, etc. 

Thanks,
Tobin
Article: 21109
Subject: Re: SpartanXL route and place
From: Ray Andraka <randraka@ids.net>
Date: Tue, 07 Mar 2000 07:10:36 GMT
Links: << >>  << T >>  << A >>


"Keith R. Williams" wrote:

>
> > Virtex and Virtex-E devices have very rich routing resources.
> > Some engineer told here that he achieved more than 90%
> > routing resource usage of Virtex. I know another engineer
> > personally who showed me that their team have successfully
> > used 94% routing resources of Virtex XCV1000.
>
> Ok, but 22-24% on a Spartan??

Look at the routing resources in the data sheet.  There's not a whole lot
there for the spartan/4KE parts.  If you have a high fan-in, you will
need enough routing to get the signals in there.  You should probably
take another look at how those high fan-in nodes are designed and perhaps
find alternative designs that distribute the connections a little better.
Floorplanning can reduce the congestion by a ton.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21110
Subject: Re: SpartanXL route and place
From: Ray Andraka <randraka@ids.net>
Date: Tue, 07 Mar 2000 07:32:18 GMT
Links: << >>  << T >>  << A >>
I don't know what your design is, but I kinda suspect you are not registering
at the IOBs.  I push registers into the IOBs whenever I can because it makes
the external timing independent of the internal implementation.  It also takes
those offset thingies and makes them all affect just the pin to IOB (which is
fixed), so you can s**tcan them.  You can turn off the generation of the
xilinx constraints file in synplicity while still using hte synplicity
constraints while in synplicity (it is under the options menu I think).

The things that add to delay are levels of logic (as a rule of thumb, allot
half the clock period to CLB logic delay, the other half leave for routing),
high fan-outs, and routes to geographically distant places.  Being a first
timer, you've probably got all these.  You can try relaxing the time
constraints some, then looking in the timing analyzer to see which are the
mean spirited signals which are giving you the most grief.  With that
knowledge, and perhaps some knowledge gleaned from looking at the ratsnest in
the floorplanner you should get an idea on how to fix up the design.  Typical
tricks are pipelining, duplicating high fan-out signals, strategic placement
and others.

Spartan is nowhere near as fast as VIrtex, nor is it anywhere near as rich in
routing.  Where you are really struggling with the spartan, you will likely
have very little problem with the virtex (Xilinx, for a long time wouldn't
even put out a floorplanner for Virtex...they told everyone it wasn't
necessary).  33 MHz, while not blazingly fast, can be aggressive for a first
timer in a Spartan device, especially if it is one of the slower 5v devices.

Please don't get scared off by my rants.  Most of the stuff I am doing really
is pushing the envelope of the device either in density, speed or both.  I
tend to find the problems with the devices and tools that no one else notices
because they never go in those corners.

"Keith R. Williams" wrote:

> On Fri, 3 Mar 2000 22:00:35, Ray Andraka <randraka@ids.net>
> wrote:
>
> > The XCS40 is equivalent to an XC4020E.  The routing in the 4020E and
> > 4025E is relatively sparse.  The 4KXL and 4KXLA have additional routing
> > resources to combat this problem.  Additionally, the automatic placement
> > does not do a very good job.  You can probably get much better results
> > as well as a much quicker place and route if you floorplan the design.
> > Historically, lots of people had trouble with the routing in the larger
> > 4KE devices simply because the routing resources are not sufficient for
> > a reasonably congested randomly placed design.  I haven't seen a
> > spartan40/4020/4025 design yet that wouldn't route with some
> > floorplanning and perhaps a little tailoring.  As a first step, you
> > might look at the placed design in the floorplanner.  Turn on the
> > routing congestion and see where it is badly congested, then try moving
> > stuff around to reduce the congestion.
>
> Thanks Ray.  I've been lurking in this group for a year (give or
> take) and have appreciated your wisdom (though sometimes scared
> by the impending doom ;-).  I've looked in the floorplanner, but
> this tool is not intuitive.  I see where the problems are, but am
> not sure what to do about them.  I am just baffled why a 20-25%
> full device is causing me so much lost sleep. I believe I've
> narrowed it down to the constraints that Synplify is adding in,
> but they seem perfectly reasonable (one clock setup up on driven
> nets and zero hold on received nets - at least as I understand
> the constraints).
>
> I *have* learned that I'll have to take time out for a class on
> this tool before the next step.  That Virtex is going to be a
> mother for timing, though the logic I would call simple.  It's
> mostly data paths.  The only "arithmetic" is a few address
> comparitors.
>
> > For the speed of the PAR, the speed and size of your memory is probably
> > more important than the processor speed.  For example, My office machine
> > is a dual pentium pro200 with 256MB of fast EDO.  My laptop is a
> > PIII-366 Tecra with 64MB.  Place and route takes about 8-10 times longer
> > on the laptop than it does on the slower desktop (and place and route
> > does not take advantage of multiple processors).
>
> Ok.  If the system doesn't page, is there any benefit in more
> memory?  These systems aren't paging, at least not much.  The
> only disk access I see is when the log files are written.  I'll
> steal some more memory tomorrow and see, but I'd like to know why
> more memory would help (limiting paging is obvious).
>
> > Bottom line: design to the architecture and do some floorplanning paying
> > attention to the routing congestion.
>
> Sure, but I didn't expect these problems for this trivial design.
>
> ----
>   Keith

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21111
Subject: Re: New name: DLLs, PLLs and videotape...
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 07 Mar 2000 07:37:44 GMT
Links: << >>  << T >>  << A >>
We seem to be going round in circles.
I claim that a digital DLL can do its job with a certain granularity = error
of say 50 ps. The error is more or less fixed, definitely not cumulative.

But a VCO output frequency must be perfect ( in the long run ). That means,
any error must be corrected immediately, since it is cumulative.
The DLL eror i not cumulative.
That's why DLL can be implemented with purely digital circuitry.

Maybe I have said all this before.

Peter Alfke
=======================
Don Husby wrote:

> Maybe, but I think the noise sensitivity for this kind of
> limited-adjustable-threshold buffer is about the same as for
> the pure digital buffer used in a digital delay line whose
> threshold may be fixed, but is still subject to noise on Vcc
> and ground.  This is especially true when you consider that
> the "analog" buffer can (must) have a leisurely rail-to-rail
> rise time of >1.0ns, while the digital delay must switch
> in < 0.1ns.
>
>   The analog control signal (and its amplifier) has a fairly
> large low-pass filter, so is also tolerant of noise.
>
> --
> Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab                          Phone: 630-840-3668
> Batavia, IL 60510                                         Fax: 630-840-5406

Article: 21112
Subject: Re: SpartanXL route and place
From: murray@pa.dec.com (Hal Murray)
Date: 7 Mar 2000 07:56:11 GMT
Links: << >>  << T >>  << A >>

> Spartan is nowhere near as fast as VIrtex, nor is it anywhere near as rich in
> routing.  Where you are really struggling with the spartan, you will likely
> have very little problem with the virtex (Xilinx, for a long time wouldn't
> even put out a floorplanner for Virtex...they told everyone it wasn't
> necessary).

"wasn't necessary"???  Wow.  How could they be that far out of touch?

What fraction of the posts to this newsgroup say (roughly) "Have you
tried floorplanning yet?"

I wonder if there is a good story behind that decision.


> Please don't get scared off by my rants.  Most of the stuff I am doing really
> is pushing the envelope of the device either in density, speed or both.  I
> tend to find the problems with the devices and tools that no one else notices
> because they never go in those corners.

Funny.  All the people I know tend to do that.  I suppose it's possible
to use an FPGA for an easy project.  I've never seen one though.

-- 
These are my opinions, not necessarily my employers.
Article: 21113
Subject: Re: SpartanXL route and place
From: Ray Andraka <randraka@ids.net>
Date: Tue, 07 Mar 2000 08:15:34 GMT
Links: << >>  << T >>  << A >>


Hal Murray wrote:

>
> > Please don't get scared off by my rants.  Most of the stuff I am doing really
> > is pushing the envelope of the device either in density, speed or both.  I
> > tend to find the problems with the devices and tools that no one else notices
> > because they never go in those corners.
>
> Funny.  All the people I know tend to do that.  I suppose it's possible
> to use an FPGA for an easy project.  I've never seen one though.

Whether it is easy or not depends on the designer now, doesn't it.


--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21114
Subject: antifuse fpga's replacing xilinx
From: Hans Holm <ff@sigcom.de>
Date: Tue, 07 Mar 2000 10:45:57 +0100
Links: << >>  << T >>  << A >>
Hi folks;

some days ago i tried to start a discussion about experiences with
antifuse fpgas.
May be it's been the wrong subject ...

I know two vendors actel and quicklogic. As far as I know, both of them
are much lower in power consumtion than sram- based fpga's and this is
exactly what I need.
We want to replace our digital board with Virtex and SpartanXL with
antifuse fpga's
to solve our temperature problem.

We are still in discussion whats better to use
quicklogic or aldec antifuse FPGAs to replace the xilinx heater.


May be someone can give me an any good arguments?

I am interested in following questions:

1.How are your experiences with unsing sysnopsys and aldec or
quicklogic?

2.Did someone ever ported a vhdl- source made for xilinx spartan to any
of this antifuse devices? Any problems (might have an other timing for
sure)

2.5 We want to use synopsis fc2... is it really a good idea? Or should
we use other eda tools?

3.How about the eda tool provides by quicklogic and aldec

4.How many FPGAs has to go until you will hav one workin'

5.Did someone made experiences with programming services for higer
values of these devices?

I hope there is someone to find who knows some answers, even if my
questions are in a rusty english ....

ff




Article: 21115
Subject: Re: SpartanXL route and place
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 07 Mar 2000 10:18:01 +0000
Links: << >>  << T >>  << A >>


"Keith R. Williams" wrote:

>
>
> I *have* learned that I'll have to take time out for a class on
> this tool before the next step.  That Virtex is going to be a
> mother for timing, though the logic I would call simple.  It's
> mostly data paths.  The only "arithmetic" is a few address
> comparitors.
>
> > FoSure, but I didn't expect these problems for this trivial design.
>
> ----
>   Keith

I wouldn't worry about Virtex - I suspect you will have an order of magnitude
less trouble. As an example we did an ASIC prototype last year in an XCV300-4.
It used 90% LUTs, 57% CLB registers, 14/16 BlockRams and got to 66MHz fairly
easily unfloorplanned [because back in May last year there wasn't one!! Also
the 300-4 was the only part we could get]. Each P&R pass was taking about 1.25
hrs on a PII-450+512MBytes. Relaxing the constraints to 50MHz took the time
down to less than 45 min.

A couple of possibilities not yet mentioned:

o Have you tried setting the Synplify ``max fanout'' parameter to something
lower than the Xilinx default of 100 ? My normal setting is 32 and in some
circumstances I take it down as far as 8.

o Have you checked the parameters that Foundation passes to MAP/PAR ? Some of
these are really for non-HDL designs & should be switched off.

o You have tripped over some subtle and brand new bug in the Xilinx tools. If
so join the club.

In order to really find out what's going on I think you'll have to make your
move out of the GUI playground sooner than you expected.


Article: 21116
Subject: setup and hold times for data during configuration (Xilinx Virtex 4000E select-map)
From: usenet201@hotmail.com
Date: Tue, 07 Mar 2000 10:37:45 GMT
Links: << >>  << T >>  << A >>
I am developing an interface to configure a 4000E Xilinx Virtex FPGA
through the Select-Map paralell configuration method.
Can anyone direct me to a Xilinx document that
illustrates the necessary setup and hold times for Data with respect to
CCLK? I coulnd't find anything in their online documentation
(configuration documents and electrical specifications), nor could I
find anything in their tech. support answer database. I would appreciate
any info. Thanks.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21117
Subject: Re: Microprocessor architecture (6800, 4004? PA-RISC, PPC, MIPS, x86, ...?)
From: Trent Worthington <none@all.net>
Date: Tue, 07 Mar 2000 05:52:16 -0500
Links: << >>  << T >>  << A >>
On Tue, 07 Mar 2000 06:57:25 GMT, Tobin Fricke
<tobin@cory.eecs.berkeley.edu> wrote:

>I've recently become interested in microprocessor architecture and have
>adopted as a personal project to implement a simple processor of some
>sort in an Altera FPGA.  I'd like to learn about the architectures and
>implementations of various processors in use today and from the past. 
>I'm familiar with the general "big ideas" such as load-store
>architectures, accumulator-architectures, etc, but I'd like to see some
>real world designs.  I'd like to find some information on the early
>Intel and Motorola processors; where can I find data on the Intel 4004
>and 8080?  How about the Motorola 6800?  Is there some book or website
>that offers a comparison of various designs?   I'm also interested in
>seeing a comparison of modern designs, such as x86, Alpha, MIPS, ARM,
>PA-RISC, PowerPC, etc. 
>
>Thanks,
>Tobin

Datasheets for the 8080 can ge had here:
ftp://www.jameco.com/jameco_gifs/gallery2/000646/


Article: 21118
Subject: Re: Stupid Foundation question
From: "Holger Kleinert" <Kleinert@ibpmt.com>
Date: Tue, 7 Mar 2000 11:58:38 +0100
Links: << >>  << T >>  << A >>

Jim Stewart <jstewart@jkmicro.com> schrieb in im Newsbeitrag:
7371799D6336F608.6C99816437643EFF.3312317873E61B1F@lp.airnews.net...
> I've been working my way through learning the Xilinx Foundation software
> and I can't find out where the physical pins get assigned to the pin
> labels.
Schematic :
Just add a property like LOC=P7 to the IPAD, OPAD or IOPAD

VHDL :
Search all *.UCF Files inside the project directory and
add the line

NET   "MYNETNAME"   LOC "P7";

Thats all !


Holger



Article: 21119
Subject: Re: antifuse fpga's replacing xilinx
From: rk <stellare@nospam.erols.com>
Date: Tue, 07 Mar 2000 08:16:10 -0500
Links: << >>  << T >>  << A >>
Hans Holm wrote:

> Hi folks;
>
> some days ago i tried to start a discussion about experiences with
> antifuse fpgas.
> May be it's been the wrong subject ...

In this group, probably, not that many posts with respect to antifuse.  I
can add a few comments.  Please see below.

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

> I know two vendors actel and quicklogic. As far as I know, both of them
> are much lower in power consumtion than sram- based fpga's and this is
> exactly what I need. We want to replace our digital board with Virtex and
> SpartanXL with antifuse fpga's to solve our temperature problem.

One thing that you may find is that the available antifuse parts do not
have the same density as Virtex parts.  One can start a gate counting
"discussion," which I will not, but there is about an order of magnitude
difference in gates per device (and neglecting boot PROMs).

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

> 2.Did someone ever ported a vhdl- source made for xilinx spartan to any
> of this antifuse devices? Any problems (might have an other timing for
> sure)

I find that "VHDL-source" is a meaningless term.  While having code in VHDL
makes it sound like it's portable (just like writing in C [discussion of
that language's portability goes to another group]), if there is any
instantiated macros you have your work cut out.  This is equivalent to
having in-line assembly code inside of your C program.

An additional issue is whether the architectural features match up.  For
example, if you need a DLL or more than three low-skew clocks or ... it
just might not be a good match.  Lastly, as I'm sure R.A. will remind us,
to get a good result, the design should be well matched to the
architecture.  There have also been studies that show that coding style of
an HDL can have a very large impact on performance.

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

> 4.How many FPGAs has to go until you will hav one workin'

One.

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

> 5.Did someone made experiences with programming services for higer
> values of these devices?

Perhaps a language thing, I did not quite understand this question.

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

> I hope there is someone to find who knows some answers, even if my
> questions are in a rusty english ....

Except for question 5, your English is fine, and, of course, my English is
a bit less then stellar, too.

----------------------------------------------------------------------
rk                               History will remember the twentieth
stellar engineering, ltd.        century for two technological
stellare@erols.com.NOSPAM        developments: atomic energy and
Hi-Rel Digital Systems Design    space flight. -- Neil Armstrong, 1994


Article: 21120
Subject: Re: New name: DLLs, PLLs and videotape...
From: husby@fnal.gov (Don Husby)
Date: Tue, 07 Mar 2000 15:11:24 GMT
Links: << >>  << T >>  << A >>
palfke@earthlink.net wrote:
> We seem to be going round in circles.

I guess we are.  You seem to be debating the merits of DLL vs PLL
while I'm off debating the merits of having some analog control
over the delay elements of a delay line which may be used to
implement either a DLL or PLL.

> ...
> But a VCO output frequency must be perfect ( in the long run ). That means,
> any error must be corrected immediately, since it is cumulative.
> The DLL eror i not cumulative.
> That's why DLL can be implemented with purely digital circuitry.

I fully agree.  A DLL is better for most applications, whether the
delay is fully digital or has some analog control.  The Lucent clock
circuit supports a DLL mode as well as a PLL mode which allows you to
do things such as clock multiplication and extracting a clock from
a serially encoded bit stream.

It is my conjecture that a partially-analog implementation has better
performance, is cheaper, more flexible, and has similar noise
immunity compared to the fully digital implementation.



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Reply-To: "Ron" <skalarv@hotmail.com>
Article: 21121
Subject: Quartus for APEX
From: "Ron" <skalarv@hotmail.com>
Date: Tue, 7 Mar 2000 17:23:34 +0200
Links: << >>  << T >>  << A >>
Hello all, I'm going to create a large design when one of the options is
using Altera - APEX working with Quartus.
I'm looking for the "cons and pros" of Quartus especialy pit falls that u
faced during the work.

Regards
Ron
skalarv@hotmail.com



Article: 21122
Subject: Re: antifuse fpga's replacing xilinx
From: "Kate Atkins" <kate.atkins@siraeo.nospam.co.uk>
Date: Tue, 7 Mar 2000 15:58:17 -0000
Links: << >>  << T >>  << A >>
The first FPGAs I used were Actel's due to the equipment final destination
being a satellite. I've since used Xilinx for prototypes and test equipment.

The insides of Actel chips are quite different from Xilinx chips. When I did
a Xilinx based prototype that later became Actel based flight equipment I
was very careful to check that the synthesis tool (Synplify) didn't do
anything special in the Xilinx that couldnt be reproduced in the Actel chip.
I knew when I started that the design would finish up in an Actel.

Synplify takes about 6 times as long to target the same design to Actel
compared to Xilinx. Reported device usage 85% A14100 (actually pessimistic)
30% XC4028 (optimistic)

One advantage with the Actel place and route tool is the ability to set
operating voltage and temperature range. You can then check "best" as well
as "worst" case timings.
It will also generate an sdf file with min and max timings so you can
simulate your placed and routed design at "best" and "worst" case timings.
This is useful when you have a 256pin surface mount one-time-programmable
chip, you really do want to try your best to get it right first time. I once
had a design that simulated fine interfacing to external circuitry at
maximum timings but didn't work at minimum timings.

(Compiling Actels libraries for back annotated simulation is a lot easier
than the Xilinx libraries.)

When it doesn't work first time Actels Silicon Explorer is a handy gadget.
It allows you to monitor any two signals inside the chip. The software makes
it like a logic analyser.

I didn't notice a significant difference in power consumption between the
A14100A and XC4028EX. Have you done a dynamic power estimate with that big
long formula Actel provide?

My company usually does one offs so investment in an Actel programmer with
the necessary adaptors was considered uneconomic. Apparently our local Actel
distributor is the biggest provider of programming services in Europe. If
you buy your chips from them they will programme at no extra cost. They are
Gothic Crellon Ltd, tel UK +1189 788878.

Kate

Hans Holm <ff@sigcom.de> wrote in message
news:38C4CFD5.F007E949@sigcom.de...
> Hi folks;
>
> some days ago i tried to start a discussion about experiences with
> antifuse fpgas.
> May be it's been the wrong subject ...
>
> I know two vendors actel and quicklogic. As far as I know, both of them
> are much lower in power consumtion than sram- based fpga's and this is
> exactly what I need.
> We want to replace our digital board with Virtex and SpartanXL with
> antifuse fpga's
> to solve our temperature problem.
>
> We are still in discussion whats better to use
> quicklogic or aldec antifuse FPGAs to replace the xilinx heater.
>
>
> May be someone can give me an any good arguments?
>
> I am interested in following questions:
>
> 1.How are your experiences with unsing sysnopsys and aldec or
> quicklogic?
>
> 2.Did someone ever ported a vhdl- source made for xilinx spartan to any
> of this antifuse devices? Any problems (might have an other timing for
> sure)
>
> 2.5 We want to use synopsis fc2... is it really a good idea? Or should
> we use other eda tools?
>
> 3.How about the eda tool provides by quicklogic and aldec
>
> 4.How many FPGAs has to go until you will hav one workin'
>
> 5.Did someone made experiences with programming services for higer
> values of these devices?
>
> I hope there is someone to find who knows some answers, even if my
> questions are in a rusty english ....
>
> ff
>
>
>
>


Article: 21123
Subject: Re: Stupid Foundation question
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Tue, 7 Mar 2000 10:37:10 -0700
Links: << >>  << T >>  << A >>
Jim Stewart wrote in message
<7371799D6336F608.6C99816437643EFF.3312317873E61B1F@lp.airnews.net>...
>I've been working my way through learning the Xilinx Foundation software
>and I can't find out where the physical pins get assigned to the pin
>labels.

If you don't explicity assign pin numbers - either on your schematics, or in
your VHDL code, or in a user-constraint file (.ucf), then the tools will
assign them for you.  If you let the tools assign the pin numbers, then
there is an option somewhere called "pinlocking" that sticks the assignments
in the UCF.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
            -- Justice John Paul Stevens



Article: 21124
Subject: Re: antifuse fpga's replacing xilinx
From: "Keith Jasinski, Jr." <jasinski@mortara.com>
Date: Tue, 7 Mar 2000 11:47:00 -0600
Links: << >>  << T >>  << A >>
My 2 cents...

--
Keith F. Jasinski, Jr.
kfjasins@execpc.com

> 1.How are your experiences with unsing sysnopsys and aldec or
> quicklogic?
We use Symplify-Lite and the Silos III simulator included with Quicklogic's
tool suite.  I have had very good results with very dense designs.  Our
designs typically use >90% of the logic cells.  We use a mixed
schematic/Verilog design environment.
>
> 3.How about the eda tool provides by quicklogic and aldec
Quicklogic's tools set is quite good.  I am not familiar with Actel's tool
set or Aldec simulation.
>
> 4.How many FPGAs has to go until you will hav one workin'
This is a loaded question.  It really depends on the designer.  If you are
thorough, have a clear set of specifications, and simulate it thoroughly,
you can do it in one chip.  Most of my designs take 3-5 revisions due to my
mistakes, lack of clear definition, and the theory that it can take longer
to simulate some things than just to try them out.
>
> 5.Did someone made experiences with programming services for higer
> values of these devices?
We have our distributor program in production, but have our own programming
tools for develpment.
>
> I hope there is someone to find who knows some answers, even if my
> questions are in a rusty english ....
>
> ff
>
>
>
>




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