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 24875

Article: 24875
Subject: Usage of ROC (Foundation 2.1i)
From: "Michael Ljunggren" <info@alienconnections.com>
Date: Mon, 21 Aug 2000 13:19:58 +0200
Links: << >>  << T >>  << A >>
Hi.

We don't have a dedicated external reset pin on our Spartan device,
and it cannot be expected we will have one either.
The idea was insted using ROC (Reset on configuration) which is
generated internally. (We are using Foundation 2.1i.)

...but it doesn't work. All blocks connected to the internal reset is
magically optimized away. The Floorplanner shows a pretty empty
design.

I have been reading the docs, but that doesn't help. Is there something I
can do?
Am I doing some common error?


Thanks all!
/Michael Ljunggren


Article: 24876
Subject: Re: Distributor attitude !!
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Mon, 21 Aug 2000 11:23:01 GMT
Links: << >>  << T >>  << A >>
Dan,
     I think that Xilinx distees are all hungry to sell you something, just
like the other FPGA vendors.  If they can get their FPGA socket on your
board, then they can get the other sockets that they carry, too.  So in
general, distees start out by tripping over themselves to help you.  As the
action pans out, they start making more realistic choices.
     Their activity after the initial visit depends on several factors.
First, they look to see if there is any real potential for long term and big
money sales.  If not, it doesn't necessarily mean that they will cut you
off, because they get paid on "sockets," too.  What they really look at,
though, is how much revenue they will derived vs. the amount of time and
money spent at the account.  If you buy 10 chips a year, they won't spend as
much time or money on your account as the other guy who is buying 100,000
chips a year.  No one should blame them for these actions; after all,
they're in it to make money just like you and the rest of us are.
     If you are a low volume account, I have found that there are some
things that you can do to help them help you.  First, don't act flaky.
There are companies where the engineers and purchasers act very flaky, and
this is a turn off to distees and other salespeople.  It means that they
have to work harder to get either information or orders.  The harder they
have to work, the more time they waste, the less money they make.  Be
forthright in answering their questions.  Don't give away the show, i.e.,
guard proprietary information, but surely answer some or most of the
questions they pose.  Sometimes these questions don't make sense to you, but
they make a lot of sense to them.  They are coming from a different point of
view.  If you are not acting flaky, then maybe purchasing is, and this could
be your problem.
     Second, if you find an FAE that is very helpful, reward him/her and the
company by directing questions and sales to them.  Stroking the FAE is very
important, because most silicon vendors, Xilinx included, base their sales
on "how good" a distee FAE is.  If they get feedback from engineering
customers that a particular FAE is doing a really good job, then they will
side with that particular distee when sales orders arrive.  FAEs tend to
visit accounts more often where they are respected.  They also tend to drag
in their salespeople, silicon vendor reps, etc., because they know that you
will give them good marks in front of the audience.  The more you see the
FAE, the better service you will get.  This better service will include
samples, immediate response, "free lunches," seminars, free software, etc.
Also, the better relationship you have with your FAE, the less time the
salesperson has to dedicate to you and the more time he dedicates to
purchasing.  Essentially, this gets the salesperson off your back asking
silly questions.
     Third, don't give up on the other distees, just because you favor
distee A.  Competition will always keep everyone on their toes.  Other
distees will show up and try to get you to switch to them.  They will hear
that you are a damn good account for distee A, and they will court you more
often.  Even if they don't get anywhere, they will occasionally come just to
give you the opportunity to switch (hmm, more free lunches!).  Treat them
honestly and don't act flaky -- they will covet you that much more!
     Fourth, remember that salespeople get paid on sales volume, and FAEs
get paid on sockets, in general.
     Fifth, remember that if you are using FPGAs, then distees will want to
love you.  Take advantage of this natural attraction to your account.  For
them, it means that they can probably not only sell you FPGAs but possibly
the other components on your board, if they carry it.  The FAE who is
"helping" you with the FPGA(s) will most likely have to know more about your
board in order to know how the FPGA works.  It is this knowledge that makes
him the "board authority" to the people behind the scenes that control who
gets the orders and who doesn't.  The FAE who is helping you with the FPGA
more likely will know more about what you are doing than the FAE who is
helping you with the SSI/MSI components or even the microprocessor!
     The one thing that distees and silicon vendors don't like is to walk
into an account and see boards with other vendors' or distees' parts on
them.  I designed a board once with 13 FPGAs, 9 Altera and 4 Xilinx.  Every
time either the Altera or Xilinx FAE/salesperson walked in and saw that
board, they salivated because they didn't have the whole board.  I could see
it in their face and actions.  Their actions were to come by more often and
check on me just to see how I was doing.  Every once in a while, they
dragged somebody "important" in, knowing that I would give them high marks
for doing a very good job.  One year later we put in for medium to large
orders.  They waited patiently until that happened, never giving up on me.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.




"Dan" <daniel.deconinck@sympatico.ca> wrote in message
news:cuLm5.140992$1h3.2683949@news20.bellglobal.com...
> Hello FPGA designers,
>
> Several years ago I attended a Xilinx promotional seminar hosted by the
> local rep.
> One of the speakers was a regional sales manager. He promissed all
> developers the 'one hundred piece price', on any 'single piece' purchase,
> for all new prototype designs. This policy was said to be backed by the
> distees. When I heard him present this offer, it sounded like a self
> initiated policy that likely, would not receive suffcient administering to
> be consumated. (based on my stereo type of the sales person 'personality
> type' and the character of this presenter) I could care less about the
offer
> ( I'll still take it) but I did learn something.
> Well, I brought this up with Insight several months later. They said, ' We
> wouldn't do that. There is nothing in it for us....'  (I countered, that
> fostering a lasting profitable relationship may justify foregoing initial
> profits but they just didn't buy it.)  I was reminded of this conversation
> recently when an Insight Xilinx FAE said to me, 'If you don't buy from us,
> then why should I help you ?'
> It looks like Insight has a calculated approach to their business. They
have
> discarded diplomatic nicities in favor of the cut to the chase direct
> approach.
> I understand them clearly but still feel some 'culture surprise' (one
notch
> less than 'shock')  This blunt talk does have an effect on my purchasing
> behaviour. I capitulate, against my nature.  I want to keep them on my
side.
> I have been helped in a pinch by their FAE in the past. His office is just
> around the corner from mine. I just shake my head and say to myself, '
> Wow..., now they're direct ! '
> I would like to know the nature of the relationship that others have
> experienced with the licensed FPGA distees.
>
> Sincerely
> Daniel DeConinck
> High Res Technologies, Inc.



Article: 24877
Subject: power consumption for spartan xcs05(XL)
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Mon, 21 Aug 2000 14:50:43 +0200
Links: << >>  << T >>  << A >>
Hi,

can anybody give me soem information about the power consumtion of a
Spartan XCS05 and XCS05XL ? How can I calculate this from the number of
toggling FFs and operation frequency ?

Matthias
Article: 24878
Subject: Re: Comparing Xilinx FPGAs
From: sulimma@my-deja.com
Date: Mon, 21 Aug 2000 12:52:36 GMT
Links: << >>  << T >>  << A >>
 The H-LUT in 4K
> could be programmed with any 3 input
> function, and the inputs could come
> directly from outside the CLB allowing
> you to use the 4 LUTs for unrelated
> stuff.

That's what the datasheet says.
But there was a mapper bug in all
version from xact up to foundation 2.1i
that prohibits to connect the DIN pin to the
H-LUT. Not even handcrafted and handplaced
XNF would help.

Of course you could do it in EPIC...

Kolja



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24879
Subject: FPGA'2001 CFP: Sept. 29 papers due
From: tessier@spock.ecs.umass.edu (Russell Tessier)
Date: 21 Aug 2000 13:53:34 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: 24880
Subject: Re: timing simulation vs functional one
From: erika_uk@my-deja.com
Date: Mon, 21 Aug 2000 14:01:41 GMT
Links: << >>  << T >>  << A >>
In article <39A08D15.35EC733D@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> YIKES! That's scary.  It probably means you have parts of the design
that are
> depending on the delays through logic.  If that is the case then
you'd best head
> back to the drawing board because it is likely to bite you hard when
you get it
> into production.

No Ray, you teach us that the design must be fully synchronous. My
design is fully synchronous


> On the other hand it could be a simple cockpit problem with your
simulation.
> For example, is your simulation switching inputs right at the clock
edge?  In a
> timing simulation you'll probably get away with that because the
delays are
> modeled.  In a functional simulation, it might be getting the data
into the
> input flip-flops on the same clock edge the clock is changing on.
I've seen
> that happen, and it can cause some headscratching until you figure
out what you
> did wrong in the setup.  If you have a design that mixes instantiated
clocked
> primitives with inferred registers you might also want to turn off the
> TimingChecksOn Generic on the unisim library elements (I'm arrogantly
assuming
> xilinx for the moment).  I've had occasional trouble in the past if I
left them
> on in a functional simulation.


I am using F2.1i, schematic entry.
i don't know how to turn off the  TimingChecksOn Generic on the unisim
library elements ...any help

thanks

--Erika














>
> erika_uk@my-deja.com wrote:
> >
> > hey
> >
> > i read once, on this news grp, that there is no need for timing
> > simulation if the design is well synchronised. the functional does
the
> > job
> >
> > my design contains plenty of FSM, and also the BRAM. if i use the
> > timing simulation, it works fine, whereas it fails for functional
> > simulation.
> >
> > any help please
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> -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
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24881
Subject: Re: timing simulation vs functional one
From: erika_uk@my-deja.com
Date: Mon, 21 Aug 2000 14:04:15 GMT
Links: << >>  << T >>  << A >>
In article <KV_n5.32154$9T1.240677@typhoon.tampabay.rr.com>,
  "S. Ramirez" <sramirez@cfl.rr.com> wrote:
Can you give us a hint as to what failed?  We can't help you if you
don't give us the information.  What kind of error messages did you
get?

I am not getting error message, but the output waveform is not what i
expect, whenver i use functionnal simulation. It works pretty well for
timing simulation


What
> tools are you using?  What FPGA vendor are you using?

Xilinx Virtex-e, F2.1i, schematic entry

Thanks

--Erika

> -Simon Ramirez
>
> <erika_uk@my-deja.com> wrote in message
news:8npkro$fin$1@nnrp1.deja.com...
> > hey
> >
> > i read once, on this news grp, that there is no need for timing
> > simulation if the design is well synchronised. the functional does
the
> > job
> >
> > my design contains plenty of FSM, and also the BRAM. if i use the
> > timing simulation, it works fine, whereas it fails for functional
> > simulation.
> >
> > any help please
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24882
Subject: Re: Arg! 8051 - 6502 and friends
From: "Jan Gray" <jsgray@acm.org>
Date: Mon, 21 Aug 2000 14:40:16 GMT
Links: << >>  << T >>  << A >>
"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message
news:399F67A5.5923E50A@jetnet.ab.ca...
>
> > XESS Corp. is releasing the eighth section of its "myCSoC" tutorial for
> > free downloading at http://www.xess.com/myCSoC-CDROM.html.  We will
> > release a new section each week.
> > Each section describes a design example for the Triscend configurable
> > system-on-chip device (CSoC).  The Triscend TE505 CSoC integrates an
> > 8051 microcontroller core with a programmable logic array to create a
> > chip whose software and hardware are both reprogrammable.
>
>  Why do all the design tutorials settle on 8 bit cpu's or
> 16 bit RISC's or PDP-8's. Would not a medium sized project
> (24/32/36) be better examples to show both the power and the
> limitations of FPGA's. Or is it that the low cost/student development
> systems can only handle the low end (ie small) FPGA's.

The XSOC/xr16 articles/kit [1] builds a 16-bit RISC because

1) 16-bits is often a better fit for a small embedded system.  Smaller
pointers, smaller code addresses => smaller memory footprint.

2) 16-bits adequately demonstrates all of the design issues of FPGA CPU+SoC
development.  A 32-bit processor would not have been more educational.

3) the prototype board (the XESS XS40 [2]) provided only 8-bit-wide RAM.
(The XSOC design reads a byte on each clock edge).  A 32-bit instruction or
data word machine would have required 2-4 clock cycles per
instruction/load/store and constrained the performance of the machine.

4) XSOC fits in a very small FPGA (an XC4005XL).  It is quite possible to
build a 32-bit RISC in about half of an XC4010XL, there was the j32 [3], and
the presently unreleased xr32, which will run fine (but for the 8-bit RAM
problem just mentioned) in an XC4010XL in the XESS XS40-010XL.  With enough
care it is possible to build a 32-bit RISC in an XC4005XL!  (Hint:
architecture width need not equal datapath implementation width.)

The current Xilinx Foundation Student Edition 1.5i supports chips up to
XC4010XL and XCS40 (comparable to a XC4020XL).  So there's plenty of
headroom.  For example, it is quite possible to build a 2-processor 32-bit
pipelined RISC using the current student tools.  I understand there is a new
version of Student Ed. on the way that may provide support for small Virtex
devices.

A 24-bit machine (12-13 CLBs tall) would fit naturally in an XC4005XL or
Spartan 10 (14x14 CLBs).

Jan Gray
Gray Research LLC

[1] http://www.fpgacpu.org/xsoc/cc.html
[2] http://www.xess.com/prod004.html
[3] http://www3.sympatico.ca/jsgray/homebrew.htm



Article: 24883
Subject: hard FPGA CPU cores do not moot soft cores
From: "Jan Gray" <jsgray@acm.org>
Date: Mon, 21 Aug 2000 15:32:07 GMT
Links: << >>  << T >>  << A >>
"Peter Alfke" <palfke@earthlink.net> wrote in message
news:39A02EF4.A11EFEE2@earthlink.net...
> As you may have read, Xilinx will put PowerPCs in the Virtex-II chips.
That
> might make part of this discussion moot.

I most respectfully disagree.  A fast hard CPU core will be a welcome
development, but it won't moot the utility of slower, more versatile,
programmable logic soft cores.

For example, a fast hard processor core could prove to be a nice management
interface coprocessor for a Virtex-II-based network router building block
chip made from an array of 32 or more routing-optimized (*) 100 MHz soft
processor cores.

For example, the 2M "gate" XCV2000E has 80x120x4 logic cells + 160 block
RAMs  At 600-800 logic cells + 2-4 block RAMs per CPU (educated guess), this
indicates a 32-processor chip-MP with 30% LUTs uncommitted.  Just think of
what you might do with a 10M "gate" Virtex-II.

Soft processor cores will play a huge role in future FPGA SoCs designs.

Jan Gray
Gray Research LLC
www.fpgacpu.org

(*) routing-optimized: multithreaded, integrated DMA, special instructions,
function units, tables, etc.  Even the lowly xr16 core has an integrated
15-channel DMA engine, at a cost of only 16 LUTs to the datapath.



Article: 24884
Subject: Re: Non-disclosures in job interviews, Round One
From: Neil Nelson <n_nelson@pacbell.net>
Date: Mon, 21 Aug 2000 08:32:50 -0700
Links: << >>  << T >>  << A >>
Jon Kirwan wrote:

> This kind of "I'm practical about life" kind of argument justifies all
> manner of behavior and explains little.  But I do also understand that
> it is a common way of saying, "I'm doing what I have to."
>
> We all do what we must, but in practice there are wide ranges of
> behavior that such practical considerations allow us.  In the end,
> what really helps better to make a better world is when each of us
> takes small actions together.  Not when we allow others to divide and
> split us into expedient behaviors, practical for the moment.  The neat
> thing that's even better about that, is that it actually can work out
> better in the long run too, from a personal perspective.
>
> Some folks will just fold their cards on the first push.  They can
> make it worse for themselves and others, being so easy.  Luckily, we
> do live in a day and age in the US where we actually *can* take a hike
> from a company that's asking everyone to sign a visitor's log that is
> also a sneaky contract and not look back.  Wasn't always that way.
>
> I was born to a very poor family.  My dad died at 31 and we had very
> little to live on.  I understand deeply the need to "do what one
> must," since I've had to live on free dried bread from stores that
> couldn't sell it and milk and sugar to add taste.  (I got to like it,
> actually.)  And I'm glad for the efforts others have taken that allow
> me to live a wonderful life today, work on wonderful projects, and not
> to be treated poorly in spite of my meager beginnings.  I owe a lot to
> the efforts of others.

Though I applaud statements and efforts to make the world better for
all and well recognize and appreciate sacrifices made by committed and
courageous individuals to make a better world now than we had, the
problem I see is an assumption that there is Jon Kriwan's standard of
behavior for a better world that one should live by and if one does
not one is less committed to a better world.

I think we will easily agree that different people have different
ideas of what a better world should be, and that different people have
different abilities to pursue their better world.  E.g., two people
may agree that some action would make the world better, but the price
one of those people may pay to take that action may be many times more
than what the other would pay for the same action.  In the worst case,
we may have someone who urges people to take actions and sacrifices
that that someone would not take himself.  But my primary point is
that it is easy to obtain a narrow view of how we should all behave
and forget that we do not easily know what another person's abilities
and personal aspirations are.  We think others should be more like us
when they are thinking we should be more like them.

And then there are better and worse ways to go about obtaining our
better world.  E.g., several people have expressed a position against
employers requesting job seekers to sign NDAs for job interviews.
The solution objective appears to be that it would be recognized as
a standard in law or in commonplace ethics that NDAs would not be
a part of job interviews.  The suggested solution path appears to be
that job seekers should not sign NDAs, they perhaps should make some
kind of protest during the interview sequence, they should place
demands on the interviewing company to clarify its NDA subject, and
they should make their anti-NDA position known in a public forum.

This seems to be a particularly weak plan of action.  Except for
making widely known our position, we will have very likely over the
near term, if we are somewhat persuasive, some small number of job
seekers reducing their chances of employment with little movement
toward our objective.  I.e., we will have persuaded other people,
in many cases, to make sacrifices for some very marginal, if any,
progress toward the objective.

I think that if we expect _others_ to pay a certain price for _our_
vision of a better world that we should make a good argument that such
a price was worth it.  Beyond just wanting a better world we need
to have a realistic plan to obtain a better world.  This roughly
comes under the heading of coordinated political action.

Regards,

Neil Nelson



Article: 24885
Subject: Mealy vs Moore FSM model
From: "Jimmy Roberts" <j_robby@hotmail.com>
Date: Mon, 21 Aug 2000 16:59:32 +0100
Links: << >>  << T >>  << A >>
Hi Folks,

What are the advantages and disadvantages of using Mealy model of FSMs vs
Moore model, on FPGA.
In Mealy model, the outputs depends on the states only, whereas in Moore
model, the outputs depend on the states and the actual inputs. I presume
Mealy model is better (less combinatorial logic). Do you agree? Any other
thoughts.


Article: 24886
Subject: Re: Distributor attitude !!
From: "John Janusson" <jjanusson@nospami-o.com>
Date: Mon, 21 Aug 2000 16:08:46 GMT
Links: << >>  << T >>  << A >>
>snip<
>I would like to know the nature of the relationship that others have
>experienced with the licensed FPGA distees.
>snip<

We've had a pretty good relationship with our Xilinx distributor (Marshall,
now Avnet) and rep (BP Sales) here in Texas.  Perhaps a contributing factor
to your problem is the industry wide crunch for electronic parts.  We had
some wild problems procuring certain parts.  We had to negotiate hard with
volumes higher than we wanted to get stock for our beta prototypes.  It's a
seller's market right now, and you have to play the game if you want to get
your parts.  I can't say I blame the reps or distributors for this... It's
just the way the industry is right now...  In many cases the manufacturer
will tell the reps exactly who gets what during crunch times.  Serving a few
big orders is easier than many small orders, so the little guy looses out...

In your case, it sounds like a combination of your sales guy on a bad day
and a generally shaky relationship with the vendor.  Building a decent
relationship with vendors during design and backing it up with loyalty while
shipping in volume will generally get you all the free engineering samples
you'll ever need...  But if your current vendor doesn't have the time for
you or tells a few too many lies, maybe you need to look elsewhere...

Good Luck!
John



Article: 24887
Subject: Looks like Xilinx is at it again!
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 16:58:34 GMT
Links: << >>  << T >>  << A >>
Hey folks, has anyone tried to get support from xilinx lately for 3.1?  They've
now got a web page you have to log into to get support.  All well and good if it
worked I suppose.  Thing is I've registered several times now.  For registering
you get an autogenerated note back saying it will take a day to grant access to
websupport.  THing is even after two weeks it still gives you the new
registration page when you log in (frustrating part is it fills in all the
blanks except the registration code, so I'm already there in the data base). 
Used to be you could submit a case directly without this crap.  No more though. 
Now we have to waste more time dealing with stupidity to get legitimate issues
on registered and licensed software resolved.  I suppose this is par for the
course in the trend to make the tools and support more customer unfriendly. 
Whoever came up with this farce ought to be taken out back and shot.
-- 
-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: 24888
Subject: Leonardo Spectrum with Altera - am I being stupid???
From: steve (Steve Rencontre)
Date: Mon, 21 Aug 2000 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
I've been trying to get the free version of Leonardo Spectrum from 
Altera's web site to work. It seems fine up to place-and-route, when the 
MaxPlus2 compiler starts complaining it "Can't find design file DFF". 
Since that's an Altera primitive, it's not surprising it isn't in a design 
file! A bit of experimenting suggests it can't find /any/ of the 
primitives.

I've tried it with an absolutely minimal design (see below) and it's just 
not having any of it. My installation of MaxPlus2 seems fine and I can 
compile non-Leonardo projects with no difficulty. I'm using Windows 2000, 
but the same thing happens with NT4.

Anyone know the big secret?

=======================================
library ieee;
use ieee.std_logic_1164.all;

entity test is
port
  (
  	CLK	: in	std_logic;
	D	: in	std_logic;
	NOT_D	: out	std_logic
  );
end test;

architecture a of test is
begin

	process (CLK)
	begin
		if CLK'event and CLK = '1' then
			NOT_D	<= not D;
		end if;

	end process;

end a;



--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>

Article: 24889
Subject: Re: Mealy vs Moore FSM model
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 21 Aug 2000 10:49:44 -0700
Links: << >>  << T >>  << A >>
Jimmy Roberts wrote:
> 
> Hi Folks,
> 
> What are the advantages and disadvantages of using Mealy model of FSMs vs
> Moore model, on FPGA.
> In Mealy model, the outputs depends on the states only, whereas in Moore
> model, the outputs depend on the states and the actual inputs. I presume
> Mealy model is better (less combinatorial logic). Do you agree? Any other
> thoughts.

A Moore design description shows input synchronization
as part of the machine state vector. 

A Mealy design description does not show input synchronization.
The design still requires an input synchronization process for 
reliable operation, but this synchronization is not shown on 
the bubble diagram or the derived HDL text.

If you understand how to provide input synchronization 
and handle the resulting delays, a Mealy description 
is more concise. 

If you don't, you will likely get bit by logic races.

Note that with today's synthesis tools, you are no longer
limited to only two state machine design views. 
I prefer a single process machine using 
variables for internal states.


--    mike.treseler@flukenetworks.com or
--             tres@tc.fluke.com
Article: 24890
Subject: Re: Further FPGA metastability questions
From: Paul Walker <paul@4Links.co.uk>
Date: Mon, 21 Aug 2000 19:01:31 +0100
Links: << >>  << T >>  << A >>
In article <8nn9t8$etm@src-news.pa.dec.com>, Hal Murray
<murray@pa.dec.com> writes
>Anybody got any other ideas?

Not followed all the discussion, so I'm not sure exactly what has been
suggested. There seem to be three problems. One is getting the flops to
dither in the first place, the next is measuring the duration of the
dither, and the third is using the results of the characterization to
give us a synchronizer element in the design tools.

To excite the dither, would it be possible to use a pair of clocks
running at almost the same frequency, but separated by a few ppm.

Suppose they are both nominally 100MHz, or 10ns period, and the
difference between the frequencies is 10ppm, then the phase difference
between them should change by about 0.1ps on each clock cycle. 

If that is not a small enough increment to hit the metastable point,
then selecting crystals separated by 0.3ppm and running at 300MHz should
make a phase shift of about 1fs on each cycle. That may be over the top,
but somewhere in between ought to do.

For detecting the length of the dither, would it be possible to sample
with four phases from the DLL? The actual delay does not matter, but if
a count is made of the number of times each sample registers the flip-
flop value, then any difference between the counts points to a
metastable delay.

Of course there are some problems. Both clock input and "Data" input to
the flop need to be straight, and not via the quantized correction of
the DLLs. Chaos suggests that oscillators tend to synchronise to each
other. And others have made the point that noise is likely to be much
bigger than the "signal". Nor am I sure how easy or expensive it is to
get such small differences between clock frequencies.

Even when all this work is done, the third problem is probably much the
biggest. But surely it must be possible for the design tools to have an
element which ignores set-up and hold times but which has a propagation
delay dependent on the MTBF the user is designing for? 

At least Xilinx enter into this discussion. Any offers from the others?

Paul
-- 
Paul Walker                            Chair of the 1355 Association
paul@4Links.co.uk    www.4Links.co.uk                   www.1355.org

NB: Please note new address and phone numbers NB:

4Links Limited ---- Boards, chips, IP and consultancy ... for Links
Registered company in England no. 3938960 
P O Box 816, Bletchley Park                  phone  +44 1908 64 2001
Milton Keynes MK3 6ZP, UK                    fax    +44 1908 64 2011
Article: 24891
Subject: Re: power consumption for spartan xcs05(XL)
From: Marc Baker <marc.baker@xilinx.com>
Date: Mon, 21 Aug 2000 11:05:20 -0700
Links: << >>  << T >>  << A >>
Power consumption for Xilinx devices, especially the XCS05 and XCS05XL, is
discussed on the Xilinx web site at
http://www.xilinx.com/techdocs/5500.htm.  There is more general information
available at http://www.xilinx.com/apps/3volt.htm.  A preliminary version
of a power estimator worksheet has been made available to our sales force -
contact your local Xilinx salesperson or FAE for more information.

Matthias Fuchs wrote:

> Hi,
>
> can anybody give me soem information about the power consumtion of a
> Spartan XCS05 and XCS05XL ? How can I calculate this from the number of
> toggling FFs and operation frequency ?
>
> Matthias

--
Marc Baker
Xilinx Applications


Article: 24892
Subject: Re: Non-disclosures in job interviews, Round One
From: Jon Kirwan <jkirwan@easystreet.com>
Date: Mon, 21 Aug 2000 12:12:51 -0700
Links: << >>  << T >>  << A >>
On Mon, 21 Aug 2000 08:32:50 -0700, Neil Nelson <n_nelson@pacbell.net>
wrote:

<snip>
>This seems to be a particularly weak plan of action.
<snip>

There is little to worry about, in my experience.  It's hardly any
different than refusing to eat bad food at a poor restaurant...  It's
slightly stressful to let them know you didn't like it, but you just
get up and go find another potentially good restaurant to eat at (or
else you go back and spend time arguing with the chef, if he'll
listen.)

And as I mentioned before....  At a first interview, I rather doubt a
responsible employer would start disclosing such information.  We've
been discussing the case of NDAs for first time applicant interviews.
Not NDAs, generally.  I just don't see a proper place for NDAs hidden
in visitor logs and explicitly required for the first-time interview.

You appear to be arguing that technical employees-to-be are hurting
themselves if they don't cooperate and that's the reason they should
do so.  I don't agree at all.  The real fact is that a good technical
employee is very hard to find.  They have every right to not expect
this kind of treatment on their first contact.

Jon
Article: 24893
Subject: Re: Looks like Xilinx is at it again!
From: apeters@noao.edu
Date: Mon, 21 Aug 2000 19:26:30 GMT
Links: << >>  << T >>  << A >>
On Mon, 21 Aug 2000 16:58:34 GMT, Ray Andraka <ray@andraka.com> wrote:
> Hey folks, has anyone tried to get support from xilinx lately for 3.1?  They've
> now got a web page you have to log into to get support.  All well and good if it
> worked I suppose.  Thing is I've registered several times now.  For registering
> you get an autogenerated note back saying it will take a day to grant access to
> websupport.  THing is even after two weeks it still gives you the new
> registration page when you log in (frustrating part is it fills in all the
> blanks except the registration code, so I'm already there in the data base). 
> Used to be you could submit a case directly without this crap.  No more though. 
> Now we have to waste more time dealing with stupidity to get legitimate issues
> on registered and licensed software resolved.  I suppose this is par for the
> course in the trend to make the tools and support more customer unfriendly. 
> Whoever came up with this farce ought to be taken out back and shot.

Oh, Ray, stop complainin'!  At least they sent you the software. ;)  

I just got the maint. renewal form.  Maybe they're waiting for me to renew for NEXT 
year before sending me what they owe me for THIS year?

Apparently you've got to register before you can download the 3.1 service packs (up 
to #2 already, and I still don't have the software).  What's annoying is that I've 
already registered.  Maybe they should figure out how to get their databases to talk 
to each other.  You know, like the database that says, "This guy's paid his maint. 
for this year -- maybe we should send him his software."

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

Article: 24894
Subject: Re: Looks like Xilinx is at it again!
From: Greg Neff <gregneff@my-deja.com>
Date: Mon, 21 Aug 2000 19:31:04 GMT
Links: << >>  << T >>  << A >>
In article <39A15F1A.5321452@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> Hey folks, has anyone tried to get support from xilinx lately for
3.1?  They've
> now got a web page you have to log into to get support.  All well and
good if it
> worked I suppose.  Thing is I've registered several times now.  For
registering
> you get an autogenerated note back saying it will take a day to grant
access to
> websupport.  THing is even after two weeks it still gives you the new
> registration page when you log in (frustrating part is it fills in
all the
> blanks except the registration code, so I'm already there in the data
base).
(snip)

Well, it works for me.  I go to this page:

http://www.xilinx.com/support/clearexpress/websupport.htm

And hit the big 'LOG IN' button.  This does not bring me back to the
registration page, as you described.

My experience has been that responses to web support questions have
been prompt (less than 1 business day).  I find this easier than trying
to work via telephone, because of our 3 hour time difference.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24895
Subject: Re: Usage of ROC (Foundation 2.1i)
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 21 Aug 2000 12:45:40 -0700
Links: << >>  << T >>  << A >>
The logic being optimized away should not be related to your
reset style. The optimizeation (also called trimming) is the result
usually of output signal that go nowhere (i.e. to an I/O pad) or
that ultimately only source themselves. An example of this would
be a 16 bit counter, where only the lower 8 output bits go anywhere.
In this case, the top 8 bits would be trimmed out.

When you compile the design, a map.mrp file is created, and it details
what logic has been trimmed, and why. Find a flip flop you expected
to be in your design, then trace back to find out why it was trimmed
out.


On Mon, 21 Aug 2000 13:19:58 +0200, "Michael Ljunggren"
<info@alienconnections.com> wrote:

>Hi.
>We don't have a dedicated external reset pin on our Spartan device,
>and it cannot be expected we will have one either.
>The idea was insted using ROC (Reset on configuration) which is
>generated internally. (We are using Foundation 2.1i.)
>...but it doesn't work. All blocks connected to the internal reset is
>magically optimized away. The Floorplanner shows a pretty empty
>design.
>I have been reading the docs, but that doesn't help. Is there something I
>can do?
>Am I doing some common error?
>Thanks all!
>/Michael Ljunggren

Philip Freidin

Mindspring that acquired Earthlink that acquired Netcom has
decided to kill off all Shell accounts, including mine.

My new primary email address is    philip@fliptronics.com

I'm sure the inconvenience to you will be less than it is for me.
Article: 24896
Subject: Re: Looks like Xilinx is at it again!
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Mon, 21 Aug 2000 20:43:46 GMT
Links: << >>  << T >>  << A >>
You guys should talk to the Xilinx FAE about this.  He can straighten it out
in a femtosecond or two.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.



> Apparently you've got to register before you can download the 3.1 service
packs (up
> to #2 already, and I still don't have the software).  What's annoying is
that I've
> already registered.  Maybe they should figure out how to get their
databases to talk
> to each other.  You know, like the database that says, "This guy's paid
his maint.
> for this year -- maybe we should send him his software."
>
> -andy



Article: 24897
Subject: Re: Usage of ROC (Foundation 2.1i)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 21:06:16 GMT
Links: << >>  << T >>  << A >>
COuld also result in the improper instantiation of the ROC component.  That
should be a black-box with a syn_noprune (synplicity) or similar attribute on it
so the synthesis doesn't make it disappear.  Off hand, I'd say even if it does
dissappear, you should be OK, because I believe the synthesizer will connect
undriven inputs to logic zero.  Most likely then, your problem is elsewhere. 
You might try wiring your ROC signal to ground to see if it makes any
difference.  

Philip Freidin wrote:
> 
> The logic being optimized away should not be related to your
> reset style. The optimizeation (also called trimming) is the result
> usually of output signal that go nowhere (i.e. to an I/O pad) or
> that ultimately only source themselves. An example of this would
> be a 16 bit counter, where only the lower 8 output bits go anywhere.
> In this case, the top 8 bits would be trimmed out.
> 
> When you compile the design, a map.mrp file is created, and it details
> what logic has been trimmed, and why. Find a flip flop you expected
> to be in your design, then trace back to find out why it was trimmed
> out.
> 
> On Mon, 21 Aug 2000 13:19:58 +0200, "Michael Ljunggren"
> <info@alienconnections.com> wrote:
> 
> >Hi.
> >We don't have a dedicated external reset pin on our Spartan device,
> >and it cannot be expected we will have one either.
> >The idea was insted using ROC (Reset on configuration) which is
> >generated internally. (We are using Foundation 2.1i.)
> >...but it doesn't work. All blocks connected to the internal reset is
> >magically optimized away. The Floorplanner shows a pretty empty
> >design.
> >I have been reading the docs, but that doesn't help. Is there something I
> >can do?
> >Am I doing some common error?
> >Thanks all!
> >/Michael Ljunggren
> 
> Philip Freidin
> 
> Mindspring that acquired Earthlink that acquired Netcom has
> decided to kill off all Shell accounts, including mine.
> 
> My new primary email address is    philip@fliptronics.com
> 
> I'm sure the inconvenience to you will be less than it is for me.

-- 
-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: 24898
Subject: Re: timing simulation vs functional one
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 21:09:08 GMT
Links: << >>  << T >>  << A >>
Not sure there.  It might not be an issue with the schematics.  CHeck to make
sure you are not changing the inputs right at the active clock edges.  Other
than that, perhaps you can give us more of a clue than it fails functional
simulation but not timing.  

erika_uk@my-deja.com wrote:
> 
> In article <39A08D15.35EC733D@andraka.com>,
>   Ray Andraka <ray@andraka.com> wrote:
> > YIKES! That's scary.  It probably means you have parts of the design
> that are
> > depending on the delays through logic.  If that is the case then
> you'd best head
> > back to the drawing board because it is likely to bite you hard when
> you get it
> > into production.
> 
> No Ray, you teach us that the design must be fully synchronous. My
> design is fully synchronous
> 
> > On the other hand it could be a simple cockpit problem with your
> simulation.
> > For example, is your simulation switching inputs right at the clock
> edge?  In a
> > timing simulation you'll probably get away with that because the
> delays are
> > modeled.  In a functional simulation, it might be getting the data
> into the
> > input flip-flops on the same clock edge the clock is changing on.
> I've seen
> > that happen, and it can cause some headscratching until you figure
> out what you
> > did wrong in the setup.  If you have a design that mixes instantiated
> clocked
> > primitives with inferred registers you might also want to turn off the
> > TimingChecksOn Generic on the unisim library elements (I'm arrogantly
> assuming
> > xilinx for the moment).  I've had occasional trouble in the past if I
> left them
> > on in a functional simulation.
> 
> I am using F2.1i, schematic entry.
> i don't know how to turn off the  TimingChecksOn Generic on the unisim
> library elements ...any help
> 
> thanks
> 
> --Erika
> 
> >
> > erika_uk@my-deja.com wrote:
> > >
> > > hey
> > >
> > > i read once, on this news grp, that there is no need for timing
> > > simulation if the design is well synchronised. the functional does
> the
> > > job
> > >
> > > my design contains plenty of FSM, and also the BRAM. if i use the
> > > timing simulation, it works fine, whereas it fails for functional
> > > simulation.
> > >
> > > any help please
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> > --
> > -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
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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: 24899
Subject: Re: Looks like Xilinx is at it again!
From: Ray Andraka <ray@andraka.com>
Date: Mon, 21 Aug 2000 21:12:54 GMT
Links: << >>  << T >>  << A >>
Ditto, except in my case the log in button always brings me back to the
registration page. **Sigh**

Greg Neff wrote:
> 
> In article <39A15F1A.5321452@andraka.com>,
>   Ray Andraka <ray@andraka.com> wrote:
> > Hey folks, has anyone tried to get support from xilinx lately for
> 3.1?  They've
> > now got a web page you have to log into to get support.  All well and
> good if it
> > worked I suppose.  Thing is I've registered several times now.  For
> registering
> > you get an autogenerated note back saying it will take a day to grant
> access to
> > websupport.  THing is even after two weeks it still gives you the new
> > registration page when you log in (frustrating part is it fills in
> all the
> > blanks except the registration code, so I'm already there in the data
> base).
> (snip)
> 
> Well, it works for me.  I go to this page:
> 
> http://www.xilinx.com/support/clearexpress/websupport.htm
> 
> And hit the big 'LOG IN' button.  This does not bring me back to the
> registration page, as you described.
> 
> My experience has been that responses to web support questions have
> been prompt (less than 1 business day).  I find this easier than trying
> to work via telephone, because of our 3 hour time difference.
> 
> --
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

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


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