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 25625

Article: 25625
Subject: Re: FPGA Express Strikes Again!
From: Ray Andraka <ray@andraka.com>
Date: Fri, 15 Sep 2000 17:35:50 GMT
Links: << >>  << T >>  << A >>
Oh, synplicity certainly does find the sync reset/set.  The hard part is trying
to keep it form inferring it if that is not what you want

eml@riverside-machines.com.NOSPAM wrote:
> 
> On Thu, 14 Sep 2000 20:47:34 GMT, "S. Ramirez"
> <sramirez@deleet.cfl.rr.com> wrote:
> 
> >Andy,
> >     The ultimate and most elegant fix is to switch to Synplicity.
> >-Simon Ramirez, Consultant
> >-Synchronous Design, Inc.
> 
> Except that, last time I looked, Synplify didn't know that Virtex had
> a sync reset. This can really mess up your CLB calculations. Don't
> know if this has been fixed. Anyone feel brave enough to run up a web
> page comparing different synthesisers?

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25626
Subject: Re: FPGA Express Strikes Again!
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 15 Sep 2000 10:35:59 -0700
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote:
> 
> On Thu, 14 Sep 2000 20:47:34 GMT, "S. Ramirez"
> <sramirez@deleet.cfl.rr.com> wrote:
> 
> >Andy,
> >     The ultimate and most elegant fix is to switch to Synplicity.
> >-Simon Ramirez, Consultant
> >-Synchronous Design, Inc.
> 
> Except that, last time I looked, Synplify didn't know that Virtex had
> a sync reset. This can really mess up your CLB calculations. Don't
> know if this has been fixed. Anyone feel brave enough to run up a web
> page comparing different synthesisers?

Anyone rich enough to own copies of all of the synthesizers?

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25627
Subject: Re: Guide to useing Atmel FPGA (at40k)
From: Ray Andraka <ray@andraka.com>
Date: Fri, 15 Sep 2000 17:40:34 GMT
Links: << >>  << T >>  << A >>
4 bit adders in Atmel aren't bad.  As you are probably aware by now, the AT40K
doesn't have a fast carry chain, so if you are looking to do fast adds of more
than a few bits you wind up learning about fast adder structures and the area
consequences for using them.  If you are not speed critical, a ripple carry
adder works fine in AT40K.  When you start pushing the performance, unlike FPGAs
with fast carry chains, you need to start looking at fast carry schemes.

Paul Maddox wrote:
> 
> Ben,
> 
> >
> > One thing I found useful is to print out a copy of
> > data sheet of the family of FPGA's you are using and any data
> > libraries and data macro function descriptions.
> 
> sadly the Atmel website is a bit lacking in .PDF files for these chips..
> Im hopeingtheres stuff onthe CD with the IDS software I have.
> 
> > Also if your software is time limited it might be wise to
> > wait until you got back and you install the software on a virgin
> > PC.
> >
> 
> Its not time limited, and Ive not installed it yet.. I panic everytime I
> install new software
> incase it screws up my PC.
> 
> >
> > Many FPGA's are similar in design so general design ideas apply
> > to many devices. FPGA's in general don't map well to wide simple
> > gates like a 12 input NAND gate but map better to functions of 3
> > or 4 variables like a 2 input multiplexer or ripple carry adder
> > cell.Registers are often free with every logic cell as well.
> > Small ram like 16xN may have to synthesized taking up a large
> > number of logic blocks.
> 
> the Atmel has distributed RAM so Im hopeing I can use that...
> 
> > The other thing is to understand the design you are creating
> > well in advance.Some logic layouts don't work well and others do
> > often with re thinking of the layout. KISS allways works best.
> > (Keep It Simple Stupid ). Good luck on your project.
> >
> 
> Ive done the design I want using discrete logic, but its 26 odd logic chips
> mostly 4 bit adders and latchs (with a bit of SRAM)..
> I like to keep stuff simple, it helps when it comes to debugging!
> 
> Thanks for the advice
> 
> Paul
> 
> > Ben.
> > --
> > "We do not inherit our time on this planet from our parents...
> >  We borrow it from our children."
> > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25628
Subject: Re: hardware compatibility and patent infringement
From: mojaveg@iwvisp.com (Everett M. Greene)
Date: Fri, 15 Sep 2000 10:40:22 PST
Links: << >>  << T >>  << A >>
david lindauer <dlindauer@notifier-is.net> writes:
> David Kessner wrote:
> > They patented what the instruction did.  One could argue that they didn't
> > patent an algorithm-- only a way of doing an algorithm.  These instructions
> > are basically do a load-shift-and-or.  We could do these instructions using
> > those standard 4 instructions, but the patent covers doing them in a single
> > instruction.
> 
> um... doesn't motorola have such an instruction in the 680x0 series?

The 68030 (and some others) do an automatic alignment via
hardware.  It's a "simple" rearrange the bytes operation.

----------------------------------------------------------------------
Everett M. Greene  (The Mojave Greene, crotalus scutulatus scutulatus)
Ridgecrest, Ca. 93555           Path: mojaveg@IWVISP.com
Article: 25629
Subject: Re: hardware compatibility and patent infringement
From: Darin Johnson <darin@usa.net>
Date: Fri, 15 Sep 2000 19:15:07 GMT
Links: << >>  << T >>  << A >>
bjolin@lin.foa.se (Björn Lindgren) writes:

> Intel also managed to get a patent on something published by another company
> several years earlier and thereby could be considered as common knowledge.

Lots of patents are this way.  It depends upon how you phrase the
patent (obfuscation, adding novel twists, etc).

At an old company I was at, there was a push to get software to submit
more patents (hardware was already good at this, as should be the
case).  One of the ideas they suggest was to take an _existing_idea_, and
apply it to our company's line of work.  Ie, to use broad strokes,
take an idea of "mirrored backups of data to removeable media",
and turn into "mirrored backups of data in a medical ultrasound
machine".  It seemed absurd, but that's exactly what our competitors
were doing, and it was in a way self-defense.

While I agree that hardware people do seem more attuned to noticing
when things are patentable, on the other hand I don't believe most
software and algorithms should be patentable.  (ie, the set-uid bit
fits my notion of something patentable, the XOR for moving a GUI's
cursor is borderline, and having a Start menu is plainly not
justifiably patentable)
Article: 25630
Subject: Re: hardware compatibility and patent infringement
From: Darin Johnson <darin@usa.net>
Date: Fri, 15 Sep 2000 19:17:07 GMT
Links: << >>  << T >>  << A >>
Paul Hovnanian ® <hovnania@bcstec.ca.boeing.com> writes:

> I don't think that any system that depends on a small group of
> patent examiners, no matter how smart or well paid they are, can
> keep up with developments in all areas of industry. Alot of 'prior
> art' exists but is not known well enough outside of a specific
> industry where an examiner might be aware of it. In some cases,
> someone may have incorporated some technique or idea into a product
> for years without considering it to be patentable.

What about a form of peer-review?  The drawback being you've got to
show your idea to competitors, but maybe that snag can be ironed out.
Article: 25631
Subject: Re: MAX PLUS 2
From: bob elkind <eteam@aracnet.com>
Date: Fri, 15 Sep 2000 12:45:47 -0700
Links: << >>  << T >>  << A >>
You could contact the local Altera sales rep and/or distributor.

They have evaluation dongles for short-term (30/60 day) licensing, which
they might well loan you out of compassion for your plight.

By the way (oops, BTW), I agree with another respondent, you should do the
multi-device partitioning yourself (pencil and paper).  You understand the
logical grouping of functions and interconnect (and critical timing paths)
*much* better than any SW tool might.  Consider this an extension of the
"floorplanning" step in your design.

Good luck,

Bob Elkind

gk7eong wrote:
> 
> Hi,
> 
> I'm a final year electrical electronics engineering student. I'm using
> Max Plus 2 Baseline 9.6 to do my final year project. Is there anyone out
> there with full licences? Can you send me a copy of your license.dat or
> can anybody tell me how to get the partitioner features from it. Thanks
> in advance.
Article: 25632
Subject: Re: hardware compatibility and patent infringement
From: Paul Hovnanian ® <hovnania@bcstec.ca.boeing.com>
Date: Fri, 15 Sep 2000 19:54:56 GMT
Links: << >>  << T >>  << A >>
Darin Johnson wrote:
> 
> Paul Hovnanian ® <hovnania@bcstec.ca.boeing.com> writes:
> 
> > I don't think that any system that depends on a small group of
> > patent examiners, no matter how smart or well paid they are, can
> > keep up with developments in all areas of industry. Alot of 'prior
> > art' exists but is not known well enough outside of a specific
> > industry where an examiner might be aware of it. In some cases,
> > someone may have incorporated some technique or idea into a product
> > for years without considering it to be patentable.
> 
> What about a form of peer-review?  The drawback being you've got to
> show your idea to competitors, but maybe that snag can be ironed out.

That's my understanding of how its done in other countries. Following
an initial application (which establishes who was first in line)
members of industry (maybe any interested person) can submit a review
of the patent. Generally, these reviews have to be backed by careful
analysis and data (not just an opinion for or against) and they are
used by the patent examiners to asist in thei research. I'm not sure if
there is a 'pull' or 'push' system to get these reviews. It might be
possible to put your name on a mailing list for certain subject
areas.  
 
-- 
Paul Hovnanian         | (here)  mailto:hovnania@bcstec.ca.boeing.com
Software Conflagration | (there) mailto:Paul@Hovnanian.com 
Control                | (spam)  mailto:postmaster@mouse-potato.com
-----------------------+---------------------------------------------
I lost my emotional baggage on my last flight of fancy.
Article: 25633
Subject: Re: Physical Interpretation
From: bob elkind <eteam@aracnet.com>
Date: Fri, 15 Sep 2000 13:08:54 -0700
Links: << >>  << T >>  << A >>
The maximum clock period is derived from the maximum path delay (including
setup time) between edge-triggered storage elements in single-clock
synchronous systems.

This assumes the simplest design methodology.  Period.  If you want to
keep life simple, this is what time and experience has proven works
well.

If you want to complicate your life, there are lots of ways to do it:

1.  consider minimum as well as maximum path delays, plus maximum clock
distribution skews, and use these to derive maximum clock frequency.
You will probably need to derive a *minimum* clock frequency as well,
since depending on minimum path delays implies this requirement.

2.  you could try multiple clock phases, possibly combined with latch
based storage elements (rather than edge-sensitive "flip-flops"), and
you still need to consider maximum and minimum path delays and maximum
clock skews (between all clock phase distribution networks).  This
generally removes the need for minimum clock frequency, but does have
a cost in terms of design maintainability, design time, design verification,
designer life expectancy, designer marriage life expectancy
(e.g. "Darling, put the scope probe down and COME HOME!!"), etc.

In any case, don't take anyone's word that single-clock synchronous
design is safe and simple.  Do the investigation yourself.  Every digital
system designer needs to do this once in their lives (it's like building
your own light sabre, if you want to become a jedi).  In the process
you gain necessary insight into clock distribution, clock theory, etc.;
*AND* you gain an understanding of the potential risks and benefits
of straying from the simple path (which is sometimes-but-rarely a
genuinely good idea).

The other half of the "build your own light sabre" exercise is
figuring out if synchronizers to avoid meta-stable conditions are
*really* necessary... but that's another discussion thread!

Good luck!

-- Bob Elkind

erika_uk@my-deja.com wrote:
> 
> Hey,
> 
> Could someone of you explain me PHYSICALLY why the path delay between
> two synchronous components is considered as the maximum clock period.
> 
> The logic levels are1 and 0.
> so if i send a pulse 1 and later 0 in less than the path delay, from
> where comes the problem
> dV=-E.dx, and the electrons have the same speed, so why the conflict
> occurs?
> 
> --Erika
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Article: 25634
Subject: Re: Simulation problem
From: Mujtaba Hamid <mujtaba.hamid@xilinx.com>
Date: Fri, 15 Sep 2000 15:17:55 -0600
Links: << >>  << T >>  << A >>
Your design is going into an infinite loop at that point. You can go to
Options > Simulation Options in MTI and increase the iteration limit. But
even if hte default iteration limit is reached (5000), it probably means that
there is an infinite loop at that time in simulation.

What you might wanna do is to run simulation for maybe 1 ns less than at the
time when this error happens. Then step through the simulator and see which
line in the source code MTI hangs at.

Mujtaba

Tomasz Brychcy wrote:

> Hello,
>
> Simulation of model before synthesis is correct. When i simulate the same
> model but after synthesis during simulation in MTI 5.2c occur the problem:
>
> iteration limit reached. Possilbe zero delay oscillation.
>
> I do not know what do?
>
> Please about help
>
> I attach files:
>
> file before synthesis: controllogic(synth).v
> file after synthesis: controllogic.v
> testbench: tb_controllogic.v
>
> P.S I know that the problem occur exactly when signal ReadCn goes to high
> state.
>
> Tomek
>
> --
> Department of Electrical Metrology
> Technical University of Zielona Gora
>
> T.Brychcy@ime.pz.zgora.pl



Article: 25635
Subject: Re: Simon , decoupling caps
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Fri, 15 Sep 2000 22:02:51 GMT
Links: << >>  << T >>  << A >>
Dan/Ben,
     In general, as Ben said, both caps are a very good and much better
decoupling method than just 0.1uF.
     I have seen both used and both work.  The 0.01uF/0.1uF combination is a
more conservative and relaible design for high frequency designs.  I have
never seen quantitative results, though, to determine just how much better
it really is.  I have seen analytical results that say it is better.
     I think Ben meant "power distribution system" rather than "power
supplies."  The power distribution system includes but isn't limited to the
connector power and ground pins, the power and ground plane design, and the
decoupling caps.
     The way I see it is that 0.01uF caps are cheap.  If you have the real
estate and a few bucks to spare, why not use them?
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


> > Is such a recomendation useful ?
> >
> > Dan
>
> That is true, it is better than a cap of .11 uf?
> For the high frequencies the .01 cap has less
> inductance and is able to respond power supply fluctuations quickly until
> the .1 cap can catch up. With transistors switching in ps range you need
> very good high freq response on the power supplies.
>
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
>


Article: 25636
Subject: Virtex clock fanout
From: Lawrence Peregrim <lperegrim@nospam.ksa1.com>
Date: Fri, 15 Sep 2000 23:07:03 GMT
Links: << >>  << T >>  << A >>
We have a design that, in its present configuration, uses a
Virtex internal DLL to phase lock some external chips to the
(input) Xilinx PCI core clock.  I send a clock feed out one
of the Virtex pins and present it to a clock buffer which
does the fanout.  I feed back one of the clock copies to the
Virtex and present it to the feedback input of the DLL.
The clock buffer we are using has a maximum skew of 1 ns
between outputs.

We are considering moving the fanout functionality inside the
Virtex, to save on external parts count.  The issue I have a
question about is the following.  When one sets up the constraints
for the P&R tool (Alliance in this case), is there a way of doing
this so that one can specify the **maximum skew** between any 2
clock outputs?  In other words, is it possible to fan out a clock
inside the Virtex for external use and simultaneously approximate
(dare I say guarantee?) the low skew among all clock outputs that
is characteristic of an external buffer?

Thanks for any response.

Lawrence
lperegrim@ksa1.com
Article: 25637
Subject: Re: hardware compatibility and patent infringement
From: Znospam+noZs_0009@hpb13799Z.Zboi.hpZ.com.invalid (Sylvan Butler)
Date: 15 Sep 2000 17:32:04 -0600
Links: << >>  << T >>  << A >>
On Thu, 14 Sep 2000 07:06:16 +0000, Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote:
>Well most programers program at the  C level... some even make it
>to C++ :)

You mean 'D' ?

sdb

-- 
 | Sylvan Butler | Not speaking for Hewlett-Packard | sbutler-boi.hp.com |
 | Watch out for my e-mail address. Thank UCE.   #### change ^ to @ #### |
    They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety. --Benjamin Franklin, 1759
 "Don't Tread On Me!"
Article: 25638
Subject: Re: hardware compatibility and patent infringement
From: "John L. Smith" <jsmith@visicom.com>
Date: Fri, 15 Sep 2000 16:34:58 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------FBEC8FD144DD41A19592D688
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

"Paul Hovnanian ®" wrote:
> all areas of industry. Alot of 'prior art' exists but is not known well enough
> outside of a specific industry where an examiner might be aware of it. In some
> cases, someone may have incorporated some technique or idea into a product
> for years without considering it to be patentable. Now, unaware of this (or worse
> yet, with full knowledge) a competitor 'discovers' this idea and applies for a
> patent. If the prior use of this isn't obvious to an outsider (you might have
> to reverse engineer a product or examine a manufacturing process), the first
> person has no defense in our patent system unless he(she) is lucky enough
> to intervene in the application prior to its final decision.

Surely there must be some appeal process available after this 'final'
decision. Are you saying that if I've been building widgets for
twenty years, and someone comes along, reverse engineers and patents
a doohickey that is part of the widget, that person now has the right
to ask me for royalties? If I can prove that I designed the doohickey
twenty years ago, it _must_ be possible to overturn the patent
examiner's
decision to grant that patent!?!? Just because the patent office doesn't
know about my use of it, and I don't know the application is in process,
makes it legal to steal it!?!?
--------------FBEC8FD144DD41A19592D688
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard

--------------FBEC8FD144DD41A19592D688--

Article: 25639
Subject: Re: hardware compatibility and patent infringement
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Sat, 16 Sep 2000 02:48:44 +0200
Links: << >>  << T >>  << A >>


"Darin Johnson" <darin@usa.net> wrote in message
news:uaed9o4fn.fsf@nokia.com...
> bjolin@lin.foa.se (Björn Lindgren) writes:
>
> > Intel also managed to get a patent on something published by another
company
> > several years earlier and thereby could be considered as common
knowledge.
>
> Lots of patents are this way.  It depends upon how you phrase the
> patent (obfuscation, adding novel twists, etc).
>
ARM Ltd has some key patents that probably would not hold up in court.
One of the key requirements of any interrupt processing in a CPU
is that it must be able to execute the interrupt and return without
destroying
the current context.
In ARM , there is no specific interrupt handling except that the CPU
executes intstructions.
The it follows logically that the context must be protected from
another interrupt until the CPU has saved the current context.
Yet they patent it. Ridiculous.....

Another patent is that they figured out that people are interested in
good code density.
The "thumb" patent is having two possibly totally unrelated instruction sets
execute on the same pipeline using a mode bit.
The only thing the instruction sets should have in common is that the data
path
of both instruction sets are of the same size.
Like noone knew that 32 bit RISC instructions had poor density.
The classical book on RISC (KAtevenis) states that
"Garrison and VanDyke havbe studied how much RISC code size would be
reduced by encoding the same instruction set vith variable length fields
and instructions [GaVD81]".
In the light of the ARM threats to the  "www.open-cores.com"  activity it
would be interesting to see how easy  the ARM patents would fall down in
court...."

> While I agree that hardware people do seem more attuned to noticing
> when things are patentable, on the other hand I don't believe most
> software and algorithms should be patentable.  (ie, the set-uid bit
> fits my notion of something patentable, the XOR for moving a GUI's
> cursor is borderline, and having a Start menu is plainly not
> justifiably patentable)

--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden


Article: 25640
Subject: Re: Guide to useing Atmel FPGA (at40k)
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Sat, 16 Sep 2000 02:58:12 +0200
Links: << >>  << T >>  << A >>
The trick to good designing with the AT40K is to use the RAM blocks.
Have been working on a few design.
48 12 bit PWM timers running at 10 kHz  PWM output frequency
implemented in a 5 k FPGA is not too bad.


8  x 8 bit PWM timers with a PWM output frequency of 120 kHz in the
also in a 5k gate FPGA.

Both designs use the SRAM extensivly instead of logic and
the same design would be much larger using a "normal" FPGA architecture.

Time domain multiplexing is also used.
I.E: Run the SRAM much faster than the actual logic and conext switch
between the different instances.
This way you only need to implement logic once for each type of peripheral
instead of once for every instance.

If you want to implement multiple UARTs, you could do the same.
I think a 5k AT40K FPGA easily could do 8 UARTs at a VERY low cost
and have plenty of room to spare.

--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden

"Ray Andraka" <ray@andraka.com> wrote in message
news:39C25EAB.6F90DA0@andraka.com...
> 4 bit adders in Atmel aren't bad.  As you are probably aware by now, the
AT40K
> doesn't have a fast carry chain, so if you are looking to do fast adds of
more
> than a few bits you wind up learning about fast adder structures and the
area
> consequences for using them.  If you are not speed critical, a ripple
carry
> adder works fine in AT40K.  When you start pushing the performance, unlike
FPGAs
> with fast carry chains, you need to start looking at fast carry schemes.
>
> Paul Maddox wrote:
> >
> > Ben,
> >
> > >
> > > One thing I found useful is to print out a copy of
> > > data sheet of the family of FPGA's you are using and any data
> > > libraries and data macro function descriptions.
> >
> > sadly the Atmel website is a bit lacking in .PDF files for these chips..
> > Im hopeingtheres stuff onthe CD with the IDS software I have.
> >
> > > Also if your software is time limited it might be wise to
> > > wait until you got back and you install the software on a virgin
> > > PC.
> > >
> >
> > Its not time limited, and Ive not installed it yet.. I panic everytime I
> > install new software
> > incase it screws up my PC.
> >
> > >
> > > Many FPGA's are similar in design so general design ideas apply
> > > to many devices. FPGA's in general don't map well to wide simple
> > > gates like a 12 input NAND gate but map better to functions of 3
> > > or 4 variables like a 2 input multiplexer or ripple carry adder
> > > cell.Registers are often free with every logic cell as well.
> > > Small ram like 16xN may have to synthesized taking up a large
> > > number of logic blocks.
> >
> > the Atmel has distributed RAM so Im hopeing I can use that...
> >
> > > The other thing is to understand the design you are creating
> > > well in advance.Some logic layouts don't work well and others do
> > > often with re thinking of the layout. KISS allways works best.
> > > (Keep It Simple Stupid ). Good luck on your project.
> > >
> >
> > Ive done the design I want using discrete logic, but its 26 odd logic
chips
> > mostly 4 bit adders and latchs (with a bit of SRAM)..
> > I like to keep stuff simple, it helps when it comes to debugging!
> >
> > Thanks for the advice
> >
> > Paul
> >
> > > Ben.
> > > --
> > > "We do not inherit our time on this planet from our parents...
> > >  We borrow it from our children."
> > > "Luna family of Octal Computers"
http://www.jetnet.ab.ca/users/bfranchuk
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com


Article: 25641
Subject: Re: Physical Interpretation
From: Muzaffer Kal <muzaffer@kal.st>
Date: 16 Sep 2000 01:07:30 GMT
Links: << >>  << T >>  << A >>
erika_uk@my-deja.com wrote:

>Hey,
>
>Could someone of you explain me PHYSICALLY why the path delay between
>two synchronous components is considered as the maximum clock period.
>
>The logic levels are1 and 0.
>so if i send a pulse 1 and later 0 in less than the path delay, from
>where comes the problem
>dV=-E.dx, and the electrons have the same speed, so why the conflict
>occurs?
>
>--Erika

Yes you can use multiple wave fronts in a single path and this is a
(albeit more recently invented) way to do logic design. But this is
not what we usually do. The EDA tools we use are not designed for that
methodology. Assume you can have only one wavefront in a path and you
can see why the min period is the clk->q + path delay + setup.

Muzaffer

Sender: eric@ruckus.brouhaha.com
Article: 25642
Subject: Re: hardware compatibility and patent infringement
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 15 Sep 2000 18:41:00 -0700
Links: << >>  << T >>  << A >>
"John L. Smith" <jsmith@visicom.com> writes:
> Surely there must be some appeal process available after this 'final'
> decision. Are you saying that if I've been building widgets for
> twenty years, and someone comes along, reverse engineers and patents
> a doohickey that is part of the widget, that person now has the right
> to ask me for royalties? If I can prove that I designed the doohickey
> twenty years ago, it _must_ be possible to overturn the patent
> examiner's
> decision to grant that patent!?!?

Yes.  Shipping a product that embodies an invention is considered
to be prior art for patent purposes.

If you invented it, kept it secret, built four units, kept three on a
shelf, and gave one to your brother-in-law, that probably would NOT
count as prior art.
Article: 25643
Subject: Re: hardware compatibility and patent infringement
From: Darin Johnson <darin@usa.net>
Date: Sat, 16 Sep 2000 01:54:52 GMT
Links: << >>  << T >>  << A >>
"John L. Smith" <jsmith@visicom.com> writes:

> If I can prove that I designed the doohickey
> twenty years ago, it _must_ be possible to overturn the patent
> examiner's
> decision to grant that patent!?!?

But if you're a small time doohickey manufacturer, can you afford
the legal fees to overturn the patent?

Large corporations often just give each other blanket cross-licenses
for patents, so it's just the small guys who end up worrying about
such things.
Article: 25644
Subject: FPGA'2001 CFP: 2 weeks to deadline
From: tessier@spock.ecs.umass.edu (Russell Tessier)
Date: 16 Sep 2000 03:45:51 GMT
Links: << >>  << T >>  << A >>
                   FPGA 2001: Call for Papers
Ninth ACM* International Symposium on Field-Programmable Gate Arrays

                     Monterey, California
                     February 11-13 2001

Submissions due: September 29, 2000
web site: http://www.ecs.umass.edu/ece/fpga2001


The annual ACM/SIGDA International Symposium on Field-Programmable 
Gate Arrays is the premier conference for presentation of advances 
in all areas related to FPGA technology. For FPGA 2001, we are 
soliciting submissions describing novel research and developments 
in the following (and related) areas of interest:

* FPGA Architecture: Logic block & routing architectures, I/O 
  structures and circuits, new commercial architectures, 
  Field-Programmable Interconnect Chips and Devices (FPIC/FPID), 
  Field-Programmable Analog Arrays (FPAA).
* CAD for FPGAs: Placement, routing, logic optimization, 
  technology mapping, system-level partitioning, logic generators, 
  testing and verification, CAD for FPGA-based accelerators.
* Applications: Innovative use of FPGAs, exploitation of FPGA 
  features, novel circuits, high-performance and 
  low-power/mission-critical applications, DSP techniques, 
  uses of reconfiguration, FPGA-based cores.
* FPGA-based computing engines: Compiled accelerators, reconfigurable 
  computing, adaptive computing devices, systems and software.
* Rapid-prototyping: Fast prototyping for system-level design, 
  Multi-Chip Modules (MCMs), logic emulation.

Authors are invited to submit PDF of their paper (12 pages maximum) by 
September 29, 2000 via E-mail to fpga2001@cse.ucsc.edu.  Notification of 
acceptance will be sent by November 22, 2000.  The authors of the accepted 
papers will be required to submit the final camera-ready copy by 
December 6, 2000.  A proceedings of the accepted papers will be published 
by ACM, and included in the Annual ACM/SIGDA CD-ROM Compendium publication.*

Address questions to:

Martine Schlag, Program Chair, FPGA 2001
Dept. of Computer Engineering,
University of California, Santa Cruz
Santa Cruz, CA  95064
phone: (831) 459-3243
fax: (831) 459-4829
Email: martine@cse.ucsc.edu


General Chair: Scott Hauck, U. of Washington
Program Chair: Martine Schlag, UCSC
Publicity Chair: Russ Tessier, U. Mass.-Amherst
Finance Chair: Steve Trimberger, Xilinx

Program Committee

Ray Andraka, Andraka Consulting         Arun Kundu, Actel 
Mike Bershteyn, Quickturn               Miriam Leeser, Northeastern U.
Richard Cliff, Altera                   Wayne Luk, Imperial College 
Jason Cong, UCLA                        Margaret Marek-Sadowska, UCSB 
Andre DeHon, Caltech                    Jonathan Rose, U. Toronto 
Eugene Ding, Lucent                     Martine Schlag, UCSC 
Carl Ebeling, U. Washington             Herman Schmit, CMU 
Scott Hauck, U. Washington              Charles Stroud, UNC-Charlotte 
TingTing Hwang, Natl. Tsing Hua U.      Russ Tessier, U. Mass.-Amherst 
Sinan Kaptanoglu, Adaptive Silicon      Steve Trimberger, Xilinx 
Tom Kean, Algotronix                    Steve Wilton, U. British Columbia

Sponsored by ACM SIGDA, with support from industry.*

Please visit the web site <http://www.ecs.umass.edu/ece/fpga2001> for 
more information.

*Pending approval
Article: 25645
Subject: Re: Xilinx Student Edition 2.1 where?
From: "default@user.com" <default@user.com>
Date: Fri, 15 Sep 2000 20:59:31 -0700
Links: << >>  << T >>  << A >>
http://www.xess.com claims to have it in stock.

>         is the Xilinx Student Edition 2.1 actually available from anywhere
> or is it still on the way?
> Last I heard was on 24/7/00:
Article: 25646
Subject: Good FPGA prototyping boards?
From: "default@user.com" <default@user.com>
Date: Fri, 15 Sep 2000 21:06:28 -0700
Links: << >>  << T >>  << A >>
Hello, a few months back I purchased an XS40-010XL+ from XESS
corporation (http://www.xess.com.)  The board is populated with an
8051uC and Xilinx XC4010XL ("10k system gates") FPGA, with a 128k X 8
async SRAM chip.  The board has its own VGA connector (you are
responsible for implementing the display controller circuit), a PS/2
keyboard connector, and standard connector headers giving access to all
84 I/O pins of the FPGA.  

Initially, the board was great, but I've since discovered 10k gates
isn't a whole lot at all!  So now I'm looking to move up to a larger
FPGA board.

XESS's next higher board is a Virtex (XCV-50) product, but it costs
$699.  Considering the XS40-010XL+ was only $239, this seems like a huge
price jump.  XESS's Virtex boards come with much more memory and
circuitry (RAMDAC, stereo audio codec, video capture, etc.) but I don't
need a lot of it.  Does anyone know of a similar FPGA board which costs
less?
Article: 25647
Subject: Re: FPGA Express Strikes Again!
From: wq998@yahoo.com
Date: Sat, 16 Sep 2000 04:16:03 GMT
Links: << >>  << T >>  << A >>
I am not rich, but do have FPGA Express v3.4 (with Foundation v3.1) and
Synplicity Pro v6.0.  Overall, I like to use Synplicity much more. Its
schematic view and critical path analysis are very helpful. The
performance of systhersized results are almost always better than
Synopsys.

Only one design forced me to switch back to Synopsys.  It has 12
125MHz/16bit Serdes inputs (12 Rx clocks routing locally) across to a
global 133MHz clock domain.  Synplicity failed.

wq998


In article <8ptmo6$1pvu$2@noao.edu>,
  Andy Peters <"apeters <"@> n o a o [.] e d u> wrote:
> eml@riverside-machines.com.NOSPAM wrote:
> >
> > On Thu, 14 Sep 2000 20:47:34 GMT, "S. Ramirez"
> > <sramirez@deleet.cfl.rr.com> wrote:
> >
> > >Andy,
> > >     The ultimate and most elegant fix is to switch to Synplicity.
> > >-Simon Ramirez, Consultant
> > >-Synchronous Design, Inc.
> >
> > Except that, last time I looked, Synplify didn't know that Virtex
had
> > a sync reset. This can really mess up your CLB calculations. Don't
> > know if this has been fixed. Anyone feel brave enough to run up a
web
> > page comparing different synthesisers?
>
> Anyone rich enough to own copies of all of the synthesizers?
>
> -- a
> ----------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatory
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) n o a o [dot] e d u
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25648
Subject: Re: FPGA Express Strikes Again!
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sat, 16 Sep 2000 07:06:54 GMT
Links: << >>  << T >>  << A >>
<eml@riverside-machines.com.NOSPAM> wrote in message
news:39c205c4.14815385@news.dial.pipex.com...
> Except that, last time I looked, Synplify didn't know that Virtex had
> a sync reset.

As someone who's just fixed a bunch of code to deal with this supposed
"problem," I can tell you that actually, Synplify DOES know about
synchronous resets.  HOWEVER... it DOES NOT know about GSR.  As you're
aware, the 'flops in a Virtex CLB can have an asynchronous or synchronous
set/reset -- but not both.  So guess what happens with this code --

process(Clk,Reset)
begin
    if Reset='1' then
        q<=(others=>'0');
    elsif rising_edge(Clk) then
        if r='1' then -- This is supposed to be synchronous reset
            q<=(others=>'0');
        else
            q<=d;
        end if;
    end if;
end process;

?????

That's right... Synplify happily decides to route RESET to the CLB's "reset"
input (and configures the 'flop for asynchronous resets), and muxes what was
supposed to be your synchronous reset in with the data path.  Blecch.

But, before you thing this is that awful, consider:

1) Synplicity is following Xilinx's recommendation to use general routing
resources instead of GSR for reset.  I don't like the fact that you have no
choice in the matter, but I can't blame them too much for toeing the Xilinx
party line.

2) You often don't really need an asynchronous reset anyway.  Change the
code above to:

process(Clk)
begin
    if rising_edge(Clk) then
        if r='1' then -- This is supposed to be synchronous reset
            q<=(others=>'0');
        else
            q<=d;
        end if;
    end if;
end process;

...and you WILL get a synchronous reset.  Woo hoo!  Yes, in the words of Ray
Andraka, not having a global async. reset will "make an ASIC designer's
blood curdle," but just don't mention what you've done at your next design
review, and you'll be fine.

In fact, if I recall correctly, the Xilinx power-on resetwill (in this case)
reset the 'flop anyway.

(BTW, this is all in Synplify 6.0.0, which -- despite some bugs -- is a nice
improvement over 5.3.1.)

> This can really mess up your CLB calculations.

We have an XCV400 that went from 61% CLB usage to 58% just by spending 15
minutes running around ditching unneeded async resets.

> Don't
> know if this has been fixed. Anyone feel brave enough to run up a web
> page comparing different synthesisers?

We've got Synplify and FPGA Express (but both are the Xilinx-only licensed
versions) at work... anybody have Spectra?

---Joel Kolstad



Article: 25649
Subject: Re: FPGA Express Strikes Again!
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sat, 16 Sep 2000 07:13:32 GMT
Links: << >>  << T >>  << A >>
<wq998@yahoo.com> wrote in message news:8pus5o$km1$1@nnrp1.deja.com...
> I am not rich, but do have FPGA Express v3.4 (with Foundation v3.1) and
> Synplicity Pro v6.0.  Overall, I like to use Synplicity much more. Its
> schematic view and critical path analysis are very helpful.

If you can believe it... in my experience it's timing estimates are pretty
far off.  It tends to overestimate logic delay and underestimate route
delay.  Our current design has a 53MHz clock running around, and meets PAR
timing just fine, even though Synplify claims the timing margin is -5.6ns.
Yeah, right.

> The
> performance of systhersized results are almost always better than
> Synopsys.

FPGA Express is pretty dismal.  People who bitch about how buggy Microsoft's
operating systems are should try FPGA Express for awhile...

> Only one design forced me to switch back to Synopsys.  It has 12
> 125MHz/16bit Serdes inputs (12 Rx clocks routing locally) across to a
> global 133MHz clock domain.  Synplicity failed.

[Cough]

We've got an HP, I mean Agilent, HDMP-1536 running at fiber channel speeds.
The '1536 needs byte-wide data feed to it at 106.25MHz, and spits out 2
bytes of data with two clocks 180 degrees out of phase.  We had to build the
ROM32x1's ourselves to make timing.  Synplify would have met the timing, but
the ROM it inferes exposes a bug in Xilinx PAR that causes PAR to error out.
Specifically, the 6B->5B decoder needs a 64 entry ROM, and the mux Synplify
builds to route the outputs of two ROM32x1's together causes the problem.

---Joel Kolstad






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