Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 102750

Article: 102750
Subject: Re: Clocking ZBT RAM via DCM on ML40x board
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 19 May 2006 11:42:28 -0700
Links: << >>  << T >>  << A >>
This is part of the console output when I run the FPGA editor.
Use a wide screen to view it.
Why don't you look to see if it matches what you get?


Bank 4 has 16 pads, 2 (12%) are utilized.
     Name                 IO  Select Std     Vref   Vcco   Pad    Pin
     ----                 --  ----------     ------ ------ ------ ------
     sys_clk_in           I   LVCMOS33       NR     3.30   IOB_X1Y55 AE14 
None     L
     sram_clk_fb          I   LVCMOS33       NR     3.30   IOB_X1Y51 AD17 
None    Vr-Term  L

Brad Smallridge
AI Vision

> When I set the IO standard for sram_clk_fb, as in your example,
> I cannot get through the PAR stage as it terminates with errors:
>
> ERROR:Place:311 - The IOB ZBTRAM_CLKFB_PIN is locked to site IOB_X1Y51
> in bank 4. This violates the SelectIO banking
> ERROR:Place:207 - Due to SelectIO banking constraints, the IOBs in
> your design cannot be automatically placed.
>
> This confuses me a lot since it's not the first time I've got this
> message (it happens quite frequently when I set IO standards
> manually). There are no other specific constraints in my design that
> could mess with those settings (or at least I think there aren't),
> I just make some simple pin assignments.
>
> Regards,
> Tomasz Dziecielewski
>



Article: 102751
Subject: Re: CPLD (CoolRunner failures)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 20 May 2006 07:48:18 +1200
Links: << >>  << T >>  << A >>
Didi wrote:
> Jim,
> 
> 
>>  Sounds a strange idea - how does one macrocell, know that it's
>>neighbours are used ?
> 
> 
> strange things like that can indeed happen. On the oldest
> coolrunner, for which I have written my logic compiler, there
> was a possibility to use some more multiplexor paths than
> the manufacturers software was using (IIRC it was 40 vs. 36).
> I tried it only to discover that when it came to that, the
> chip was becoming unstable... so I lowered my limit as well.

That's rather a different case, even unique :)

> Perhaps it is about power distribution, who knows.

Coolrunners are low power devices - All I could think of was
possibly longer programming times, for more device usage, but
that is also a stretch...

That's why the TIME-LINE of failures is important.

Also, Vcc shorts do not sound like any device-mapping failures, but
do sound like ESD/latchup ....

-jg
> 
> Nigel,
> the fpga newsgroup should be better for this thread,
> Austin or Peter (both highly knowledgeable Xilinx employees)
> might be able to give some more info.
> 
> Dimiter
> 
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
> 
> http://www.tgi-sci.com
> ------------------------------------------------------
> 
> Jim Granville wrote:
> 
>>Nigel wrote:
>>
>>>has anyone experienced problems when operating Cool Runner (XPLA3)
>>>CPLDs near the capacity of their macrocells? specifically, i have two
>>>devices that have failed independently with hard short circuits to
>>>ground on the 3.3V power supplies. i have heard some anecdotal evidence
>>>that this can happen when too many of the macrocells are used. has
>>>anyone heard of this or seen it documented or reported elsewhere?
>>
>>  Sounds a strange idea - how does one macrocell, know that it's
>>neighbours are used ?
>>  Check things like ESD ratings, and latchUp ratings.
>>When  did the failures occur ?
>>
>>-jg
> 
> 


Article: 102752
Subject: PLB clocking
From: "Fizzy" <fpgalearner@gmail.com>
Date: 19 May 2006 12:58:15 -0700
Links: << >>  << T >>  << A >>
Hi,

I have a cutom IP that i want to run at lest say at 80 Hz. I want to
atatch this IP to PLB Bus which has clock running at 100 MHz. The IPIF
interface provides you the Bus clock and all the required interface
signals. What are my options to make the data cross from 100 Mhz clock
domain to 80 Hz clock domain. i also need to drive 80 Hz clock from 100
Mhz clock so the both can be synchronous.

Thanks


Article: 102753
Subject: Re: "disappointing" performance
From: fpga_toys@yahoo.com
Date: 19 May 2006 13:05:01 -0700
Links: << >>  << T >>  << A >>

c d saunter wrote:
> Perhaps the real battleground is the software environments - development
> and runtime.  HDLs embrace parallelism naturally, but are stuck at a very
> low level, procedural languages map to how most people thing and how CPU
> cores work, and stink at parallelism.  Many attempts are in various stages
> of existence for a mix between these two extremes, none have yet to find
> acceptence, and none (AFAIK) are usable across the range of technologies.
>
> Perhaps this is the real battleground?

Not Really, software is one component of the greater architectural
problem. What it does show is that Intel is willing to address cost
issues, which are critical in the consumer and high end systems
markets, while mappi9ng a course that will intersect with the cash
market that Xilinx is seeking to grow into. Any die with hundreds of
cores becomes a cluster on a chip and will need ready access to high
speed external connects for memory, storage and communications.

The solution that Intel maps out, intersects solidly with using Xilinx
parts for reconfigurable computing, and it would not suprise me of at
some point the end solution was a mix of ISA cores meshed into FPGA
fabric.

While FPGAs are very low density functionality wise with high overheads
in little used interconnects, a dense ISA core design will have both
high functional density and high utilitization on the interconnect by
using both bus and on chip networking solutions. When these two
architectures turn into systems, the Intel design provides more usable
performance for the buck.

Given Xilinx's inability to think visonary at the systems level and
manage costs by design of their product and process, I suspect one
likely course is that they are swallowed up with the stroke of a pen
for their patents by a consumer level systems company. Sun, Intel, AMD,
Sony, Fujitsu, etc ....

The whole Itanium 64 bit thing has been the best case of doing
something stupid, as heat and power grow faster than usable
performance. The other end of the spectrum is bit serial, which has
high architectural overheads. The sweet spot in size, heat, power is a
dense fabric of simple cores, and lots of them to deliver the
performance ... which is where reconfigurable computing has had it's
small wins by building that using an inefficient FPGA technology.

Wearing my Sr Architect hat, I've looked past FPGAs as the short term
solution, into a path not that different in strategy to Intels ... but
not using large x86 ISA cores, using something much smaller and cache
dominated to balance the memory/processing ratio.


Article: 102754
Subject: Re: "disappointing" performance
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 19 May 2006 13:05:52 -0700
Links: << >>  << T >>  << A >>
cds,

Very astute.

I agree with you.

When we get together, and ponder the future, is it the technology, 
architecture, or tools?

Or, is it all of the above?

More and more of our customers want a 'pre-baked' solution that they can 
add their 'secret sauce' to (sorry for the mixed metaphor, not very 
appealing...no one bakes burgers).

How can anyone possibly create IP for every possible application?  Yet, 
that is what we are being asked to do.

I hope you found the link to the pdf of the Intel talk that was also 
posted by me.  It is certainly worth looking though, especially since 
Intel felt it was worth presenting.  The caveat is that this 
presentation of Intel's is just one of many possible futures.

How the future may change may not be obious, but it will change.

Austin


c d saunter wrote:

> Austin Lesea (austin@xilinx.com) wrote:
> : All,
> 
> : A recent Intel presentation at an IEEE Workshop admitted that clock 
> : frequency has max'd out, and now has to go down (not up) in order to not 
> : create heat.
> 
> : We have known that for years now.  So has AMD.
> 
> : The only choice is "multi."
> 
> : Intel proposes a future with more than 200 x86 cores on one die, with a 
> : "communications fabric" and many memories.  All on one die.  Small 
> : software problem to be solved by the need to have it solved....
> 
> : One attendee of the conference (not me!) quipped, "sounds like you are 
> : describing a FPGA..."
> 
> : Boy did the presenter get mad!  To be ccompared to a lowly FPGA!  He was 
> : spitting venom back at the attendee.  "There is no comparison!  FPGAs 
> : are fine grained, and this is not!"
> 
> : Sounds like if that is the only difference, the FPGA wins.  Again.
> 
> : Oh, and I can't wait for Intel to stub their toes on that 
> : "communications fabric" (left as an exercise for the student).  Or the 
> : software.
> 
> It looks to me like different technologies - CPUS, FPGAs - are on a 
> collision course - FPGAs are incoperating more and more advanced corse 
> grained features and CPUs are segmenting, going parallel and more fine 
> grained, there're flexible interconnects in the former and roadmapped in 
> the later.  Middle(ish) ground devices like offerings from Clearspeed and 
> the STI Cell procssor already exist.  
> 
> Convergence of the differnet hardware solutions is happening.
> 
> Perhaps the real battleground is the software environments - development 
> and runtime.  HDLs embrace parallelism naturally, but are stuck at a very 
> low level, procedural languages map to how most people thing and how CPU 
> cores work, and stink at parallelism.  Many attempts are in various stages 
> of existence for a mix between these two extremes, none have yet to find 
> acceptence, and none (AFAIK) are usable across the range of technologies.
> 
> Perhaps this is the real battleground?
> 
> cds

Article: 102755
Subject: Re: Superscalar Out-of-Order Processor on an FPGA
From: Eric Smith <eric@brouhaha.com>
Date: 19 May 2006 13:38:13 -0700
Links: << >>  << T >>  << A >>
"alpha" <zhg.liu@gmail.com> writes:
> My design is from scratch. Its instruction set is almost same as MIPS
> 3000 (without Multiplication). Lcc C compilier was ported.
> I can publish the source verilog files, do we have public domain for
> this purpose?

I'm not sure I understand your question.  If you've written it yourself,
you can certainly put it in the public domain if you so choose.  Or you
could release it under any of a number of existing "open source" licenses.

If you're asking about places to distribute it, you could try
submitting it as a project for www.opencores.org.  If you don't find
anywhere else, you could send it to me, and I'd be happy to put it on a
web page for you.

Eric

Article: 102756
Subject: Re: Ethernet & ML401
From: Eric Smith <eric@brouhaha.com>
Date: 19 May 2006 14:09:13 -0700
Links: << >>  << T >>  << A >>
"Marco T." <marc@blabla.com> writes:
> You can use also emac from opencores, but in this way you don't have any 
> kind of support in your design.

The OpenCores Ethernet MAC seems to work fine.

It's very large, though.  I think it should be possible to design a much
smaller one, by using a simple microprogrammed controller to replace much
of the hardwired logic.  (I'm not complaining; getting a functional Ethernet
MAC core for free is very nice.)



Article: 102757
Subject: Re: "disappointing" performance
From: fpga_toys@yahoo.com
Date: 19 May 2006 14:25:32 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> When we get together, and ponder the future, is it the technology,
> architecture, or tools?
>
> Or, is it all of the above?

It's certainly all of the above, as being weak in any area just drags
down the ability to perform well in the other areas. Having the vision
to staff broadly and design broadly is the difference between a
technology vendor (IE FPGA/CPLD company) and a systems level company
(that architects, designs, and implements) with both broad market and
detailed systems level implementations as core architectural/design
constraints.

> More and more of our customers want a 'pre-baked' solution that they can
> add their 'secret sauce' to (sorry for the mixed metaphor, not very
> appealing...no one bakes burgers).

pre-baked is just another word for systems level requirements.

> How can anyone possibly create IP for every possible application?  Yet,
> that is what we are being asked to do.

Yep ... which is a real problem. Xilinx is too small to be a full
systems level company (and isn't staffed with the vision to become one
in the short term), but rather sees itself as a technology only company
(a rather big fish, in a very little pond).

There are ways to deal with it ... like leveraging the customer
community as a broad partnership to provide the parts that Xilinx
hasn't, or cann't, staff and manage well ... systems level architecture
and systems level software. But that does mean that Xilinx needs to be
much more customer oriented, have an open interface to cusomter
community, and actively seed, support, and foster that partnership.
Open source is one of several alternative models to leverage the
customer community to fill in the rest of the solution to drive changes
in architecture, software, and tools.

> How the future may change may not be obious, but it will change.

yep :)


Article: 102758
Subject: Re: How to decide Fanout limit?
From: Ken McElvain <ken@synplicity.com>
Date: Fri, 19 May 2006 14:36:45 -0700
Links: << >>  << T >>  << A >>
Replication can help timing mostly by generating more placement
freedom.   Actual loading effects are minimized in modern FPGAs
by buffering in the routing.   Synplify will automatically perform
some replication based on estimated timing, but tries to avoid
increasing the area to much because that can backfire.   A fanout
constraint is most useful when you discover that Synplify's timing estimates
have diverged from P&R results and use it surgically to force some
replication.   A good alternative is to use Synplify Premier which
performs full placement and local routing (on singles and doubles).
Timing in Synplify Premier correlates much better with final P&R so
it optimizes in the right places.

- Ken
CTO
Synplicity, Inc.


srini wrote:

> Hi,
> My target architecture is ViretxII FPGA. I dont know whether there is
> any fanout limitation or not. But I was of the opinion that a driver
> having a high fanout might affect the timing in my design and I kept it
> to minimum(100). I could see some synthesis notes telling that some of
> the nets were replicated 'x' times bcoz of soft fanout limit of 100. I
> am meeting my timing constraints with this spevs. Now, if I increase
> the fanout limit to the default value of 10,000, will it affect my
> timing or will there be any change in the synthesis results?
> 


Article: 102759
Subject: Re: PLB clocking
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 19 May 2006 23:59:23 +0200
Links: << >>  << T >>  << A >>
Fizzy schrieb:
> Hi,
> 
> I have a cutom IP that i want to run at lest say at 80 Hz. I want to
> atatch this IP to PLB Bus which has clock running at 100 MHz. The IPIF
> interface provides you the Bus clock and all the required interface
> signals. What are my options to make the data cross from 100 Mhz clock
> domain to 80 Hz clock domain. i also need to drive 80 Hz clock from 100
> Mhz clock so the both can be synchronous.

Still the same problem? But hey, what kind of stuff is running at 80 Hz? 
Such things are much better done in software.
But to answer your your question (again). Run the 80 Hz stuff at 100 MHz 
and use a 80 Hz clock enable.

Regards
Falk
> 
> Thanks
> 

Article: 102760
Subject: xilinx V4 obufds_25 and 3.3 V
From: leevv <>
Date: Fri, 19 May 2006 15:12:07 -0700
Links: << >>  << T >>  << A >>
Hi All,

Let say I have one bank in V4 device with all single ended outputs and one differential output. I'd like to have VCCO =3.3V.

This is not allowed in V4, because obufds_33 doesn't exist in V4 and PAR ends with error.

What going to happen if I'll declare all outputs in this bank as LVCMOS_25 and LVDS_25, but physically connect VCCO to 3.3V on board?

Will it damage the device?

Probably I'll get some out-of-spec voltage levels for LVDS output. But it's fine for me.

My situation is that diff output CLK signal was overlooked on the board and placed in the 3.3V bank. Board can work with single ended CLK signal but it's better to have differential.

Thanks

Article: 102761
Subject: Re: CPLD (CoolRunner failures)
From: paul$@pcserviceselectronics.co.uk (Paul Carpenter)
Date: Fri, 19 May 2006 23:24:44 +0100 (BST)
Links: << >>  << T >>  << A >>
On Sat, 20 May 2006 07:48:18 +1200, in article
     <446e20cb@clear.net.nz> no.spam@designtools.co.nz
     "Jim Granville" wrote:
>Didi wrote:
>> Jim,

...

>> Perhaps it is about power distribution, who knows.
>
>Coolrunners are low power devices - All I could think of was
>possibly longer programming times, for more device usage, but
>that is also a stretch...
>
>That's why the TIME-LINE of failures is important.
>
>Also, Vcc shorts do not sound like any device-mapping failures, but
>do sound like ESD/latchup ....

Don't rule out manufacturing problems, I remember a short on a CPLD
(which just happened to be a Philips Coolrunner), but our clue was
the short was not permanent. turned out to be a tiny ball of solder
under a PLCC package, careful 'nudging' and heating a few pins in turn
made it melt onto an existing pad only.

Some conductive muck may have got on one batch of boards, that went to one
site as well.


-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate


Article: 102762
Subject: Re: "disappointing" performance
From: "Peter Alfke" <peter@xilinx.com>
Date: 19 May 2006 15:28:45 -0700
Links: << >>  << T >>  << A >>
John, you like to point out that Xilinx is not a systems company, and
you probably are right.

But let me also point out that I know of no company that is
simultaneously good at broad-based systems and at broad-based
components.

Most of the system companies you mention are abominable at components.
Sun and IBM never were seriously in the component business, except for
internal consumption.
Intel is very narrowly focused on a certain systems and a narrow
components sector, as is AMD.
They are both getting better and better at less and less.

Xilinx is focused on programmable devices for a very wide range of
systems applications, from glue logic in cell phones to telecom routers
and medical / instrumentation / mil/aerospace applications.
Reconfigurable computing, large on your RADAR screen, is a tiny part of
our business (and attention).

In order to be successful in our chosen field, we have to satisfy many
conflicting requirements and many different customers.
We are not perfect, but we are not as bad as you try to make us look.

Peter Alfke, Xilinx


Article: 102763
Subject: Re: V5 and carry lookahead
From: fpga_toys@yahoo.com
Date: 19 May 2006 15:35:13 -0700
Links: << >>  << T >>  << A >>

Ben Jones wrote:
> I love the LUT6 architecture, particularly for muxes (4:1 in a single LUT,
> 16:1 in a single slice, with no wasted inputs).

Yep ... I was already looking at that for the RC5 cracker demo code I
did last year, as it should have a much better fit and performance. Not
that many LX330 devices would have equiv performance to all of dnet,
assuming you can actually power the device and keep it cool fully
packed.

> I don't believe you get anything to cascade between slices, but a single
> SLICEM will give you 256x1-bit by using all four LUTs. You can also get a
> variety of dual-port configurations: up to 128x1 true dual-port, or up to
> 64x3-bit simple dual-port per slice. My personal favourite: 32x2 or 64x1
> quad-port per slice (that's 1xRW and 3xRO ports).

Yippie ... that is more than enough(for now) ... and the dual/quad port
configurations are exactly what I've found useful in FpgaC for typical
loops, one, two or three references with a writer. Being able to have
both the array storage and most of the arithmetics LUTS packed into the
same slice/clb really cuts down on routing requirements/delays.

> It's also possible (with some degree of cunning) to create an efficient
> 3-input adder in the fabric, although there is some speed penalty to this.

Hmm ... interesting ... space/time tradeoffs are another area we need
to spend more time looking at for FpgaC.  So far that balance has been
static, and favors performance in most cases. Dense packing like that
could certainly be useful.

One of the interesting side effects of doing bit level optimization and
packing in FpgaC, is applications like the RC5 cracker end up packing
both arithmetics and the barrel shifter components into the same LUT
and avoids wasting inputs and logic levels (which offsets the
poor/general technology mapping to some extent) ... that just gets
better with LUT6s. The down side is that it get's harder to extract
from the truth table possible fits to specialized logic in the slice as
the truth table grows 2^n in size and the number of permutations to
search does as well.


Article: 102764
Subject: Re: CPLD (CoolRunner) failures.
From: "Atmel_PLDs_Rock" <ydhami@gmail.com>
Date: 19 May 2006 15:59:02 -0700
Links: << >>  << T >>  << A >>
Hi:

You may as well cross over to Atmel ATF15xx Family of CPLDs

You can take advantage of Atmel's Architecture and Software to pack in
twice the logic.

For your application check if you have a Bus contention issue ;
Are you driving a number of I/Os ? 

Yad


Article: 102765
Subject: Re: CPLD (CoolRunner) failures.
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sat, 20 May 2006 01:41:46 +0200
Links: << >>  << T >>  << A >>
Atmel_PLDs_Rock schrieb:
> Hi:
> 
> You may as well cross over to Atmel ATF15xx Family of CPLDs
> 
> You can take advantage of Atmel's Architecture and Software to pack in
> twice the logic.

Blablablabla.
The marketing-droids are in town!
Safe our kids!

Regards
Falk

Article: 102766
Subject: Re: "disappointing" performance
From: fpga_toys@yahoo.com
Date: 19 May 2006 17:03:20 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> John, you like to point out that Xilinx is not a systems company, and
> you probably are right.

Systems companies span from embedded to super computers, both ends of
which cover both ends of the Xilinx product line and target markets.
The lack of systems level tools for both ends is clearly a problem in
getting broader market penitration to drive chip sales.

> We are not perfect, but we are not as bad as you try to make us look.

Nobody is perfect, that is for sure. Speculating about futures isn't so
much about making Xilinx look bad, as being objective about core
limitations that impact potential success and bottom line growth for
your stock holders -- and design in decisions by your chip customers.

There are clear dollar limits that Xilinx can achieve as an FPGA and
PLD supplier, and the huge amounts of dollars get spent for systems
level tools that don't drive high volume chip sales or  turn into high
revenue sources (like expensive development boards, ML310 for example).
That market I suspect will be the target of off shore competitors with
a mean and lean agressive competitive style ... something Xilinx isn't,
and patent protection for those markets will remain difficult with core
patent expiration and lots of prior art.

Having Intel propose chips which severely cut away at the upper end of
Xilinx's market, with a large number of cores and interconnect fabric,
will ultimately limit severely Xilinx DSP, communications, and
specialty reconfigurable computing sales for high end applications. All
markets that Intel has targeted before, and continues to. Including PPC
cpu cores and communications interfaces on FPGAs puts Xilinx clearly in
Intel's sights. It's not hard to figure out which of the two companies
has a strong alliance with software developers to deliver systems level
solutions in high volumes, or to compare the degree of openness to 3rd
party developers.

Being a chip supplier and a systems company is a difficult balance, as
one competes with the other divisions customers either way. So there is
a reason that Sun, HP, IBM, SGI had problems selling chips and systems
at the same time .... and is almost certainly why Intel walks a careful
line doing so as well.  Even Motorola had a difficult time at it, did
some spinoffs and became a systems level company. That solution, which
some have used, is to spin off the chip technologies as arms length
divisions, that are only partially captive, combined with licensing.

So that certainly begs the question today, of where is Xilinx headed in
the market with their technology given threats to both the bottom and
top end that are likely. So just where and how is Xilinx going to
maintain their "market share", revenue and profitability, to avoid a
stock holder purge of the current Xilinx management? I don't think it's
another decade of business as usual. Do you?

Now is a critical time in the market, as nearly every company is trying
to plot their future for the next 7 years to ride the next tech wave,
before the next bubble burst in the early to mid 2010 decade. With that
comes a lot of second guessing long term viability of suppliers
critical to your product line and strategy, plus buying into certain
technologies with are core to your product.

If Intel, AMD, IBM, and some half dozen other large players are headed
into the high core count highly integrated cpu business, they will run
into Xilinx and Altera's patents ... where litigation or licensing may
be far more expensive than purchasing 15-25% of the common stock and
doing a takeover without a bidding war . That is one potential to
consider, that either or both of the high end FPGA companies may go
largely capitive for their IP value. Xilinx thumping around with we are
taking over the world and circle the drain talk, could make the more
likely, than sliding under the radar. Similar consolidation is possible
at the bottom end too.

Another is that Xilinx and Altera, which have been moving up into the
embedded systems CPU business, go ahead find some way to expand solidly
into systems businesses in one or more markets, plus sit the fence as a
chip supplier to smaller systems companies in other markets. Follow the
Motorola path, more or less.

The current road map of expanding share holder returns by continuing to
expand into Intels market, doesn't look nearly as rosey these days.


Article: 102767
Subject: ispLEVER Starter 6.0 FPGA Design Software Available
From: "bart" <bart.borosky@latticesemi.com>
Date: 19 May 2006 17:21:43 -0700
Links: << >>  << T >>  << A >>
Lattice has released a new version of our downloadable ispLEVER Starter
software, concurrent with version 6.0. Device support includes the 90nm
LatticeECP2-50 and can be downloaded here:
http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm

Regards,
Bart Borosky, Lattice


Article: 102768
Subject: Why do the electronics manufacturers have to spam me?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 19 May 2006 17:40:52 -0700
Links: << >>  << T >>  << A >>
I give my email address in order to get support and Xilinx feels the
need to send me spam.  I know it is through the support channels
because I create a different address every time I use support.  Every
time I end up getting spam.

It's not just Xilinx, I once contacted Altera because I was getting
spam from a third party at an address I only gave to Altera.

I don't recall using this address, tektronix.drawing@arius.com, but I
don't know why I would be receiving spam from Analog Devices using it.


The list goes on and on.  Don't these companies realize the ill will it
creates?


Article: 102769
Subject: Re: CPLD (CoolRunner failures)
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 20 May 2006 14:00:33 +1200
Links: << >>  << T >>  << A >>
Paul Carpenter wrote:

>>Coolrunners are low power devices - All I could think of was
>>possibly longer programming times, for more device usage, but
>>that is also a stretch...
>>
>>That's why the TIME-LINE of failures is important.
>>
>>Also, Vcc shorts do not sound like any device-mapping failures, but
>>do sound like ESD/latchup ....
> 
> 
> Don't rule out manufacturing problems, I remember a short on a CPLD
> (which just happened to be a Philips Coolrunner), but our clue was
> the short was not permanent. turned out to be a tiny ball of solder
> under a PLCC package, careful 'nudging' and heating a few pins in turn
> made it melt onto an existing pad only.
> 
> Some conductive muck may have got on one batch of boards, that went to one
> site as well.

Good point. Replacement=works, does not always mean the removed device 
is faulty, the OP should verify that failure on the removed devices.
I was assuming his description was precise, but you could be right...

-jg


Article: 102770
Subject: Re: PLB clocking
From: "motty" <mottoblatto@yahoo.com>
Date: 19 May 2006 21:14:48 -0700
Links: << >>  << T >>  << A >>
Yeah, you keep posting the same question but never really tell what you
are doing.  Why don't you explain what the super-slow signals are being
used for.  Maybe you have in one of your multiple other posts about
this and I don't know.


Article: 102771
Subject: Re: "disappointing" performance
From: fpga_toys@yahoo.com
Date: 19 May 2006 22:03:13 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> We are not perfect, but we are not as bad as you try to make us look.

Given other Xilinx employees posturing and dissing, even in this
thread,
shouldn't be so thin skinned when someone provides counter points.


Article: 102772
Subject: Re: LISP Workshop at ECOOP06
From: "=?iso-8859-1?B?SGFucyBI/GJuZXI=?=" <hans.huebner@gmail.com>
Date: 19 May 2006 22:14:02 -0700
Links: << >>  << T >>  << A >>
Hennesy and Patterson do not consider reconfigurable logic and their
prime concern is the raw performance of general-purpose processors.
Even though the techniques they describe make sense, given this goal,
reconfigurable logic makes it possible to reconsider their initial
assumptions, maybe coming to different conclusions.

-Hans


Article: 102773
Subject: Re: Ethernet & ML401
From: "Marco T." <marc@blabla.com>
Date: Sat, 20 May 2006 09:03:08 +0200
Links: << >>  << T >>  << A >>

"Eric Smith" <eric@brouhaha.com> wrote in message 
news:qhodxt90xy.fsf@ruckus.brouhaha.com...
> "Marco T." <marc@blabla.com> writes:
>> You can use also emac from opencores, but in this way you don't have any
>> kind of support in your design.
>
> The OpenCores Ethernet MAC seems to work fine.
>
> It's very large, though.  I think it should be possible to design a much
> smaller one, by using a simple microprogrammed controller to replace much
> of the hardwired logic.  (I'm not complaining; getting a functional 
> Ethernet
> MAC core for free is very nice.)
>
>

Eric, you are right.
 It's a great thing getting a fully functional emac core for free.
Opencores is a wonderful site, and also all developers which have 
contributed to it.

But if you decide to put that emac core into your design and you find some 
errors, you can't contact the assistance.
It is a trouble if you don't have the necessary time to solve by yourself.

Marco




Article: 102774
Subject: Re: ispLEVER Starter 6.0 FPGA Design Software Available
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 20 May 2006 09:44:40 +0200
Links: << >>  << T >>  << A >>
"bart" <bart.borosky@latticesemi.com> schrieb im Newsbeitrag 
news:1148084503.179769.316340@j73g2000cwa.googlegroups.com...
> Lattice has released a new version of our downloadable ispLEVER Starter
> software, concurrent with version 6.0. Device support includes the 90nm
> LatticeECP2-50 and can be downloaded here:
> http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm
>
> Regards,
> Bart Borosky, Lattice
>

are XP devices now suported in schematic?

antti 





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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