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 98450

Article: 98450
Subject: Re: FPGA imple. of aes
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 10 Mar 2006 15:12:07 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <1141986452.587421.137510@i40g2000cwc.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>Allan Herriman wrote:
>> You want to try it in your C -> hardware compiler?  I'd be interested
>> in the results.
>
>Me too :)
>
>I'll take a look at it this weekend, as it might make another
>interesting example for the next FpgaC release. I have a pipelined
>RSA-72 I did two years ago when looking at building dnet engines that
>is a monster because of the barrel shifters and LUT RAMS required for
>retiming. First glance at the referenced materials suggests the problem
>with AES is going to be 80 or more block rams for S box lookups tables
>to get any reasonable parallelism. It's not clear there is an easy way
>to avoid using sbox tables, as the algorithm for creating the table is
>itterative.

There has been a lot of research put into efficient implementations of
the S-boxes without using lookup tables;

http://www.st.com/stonline/press/magazine/stjournal/vol00/pdf/art08.pdf

might be an example.  I went to a conference in August where
http://class.ee.iastate.edu/tyagi/cpre681/papers/AESCHES05.pdf was
presented, which runs AES at 25Gbits/second on an XC3S2000; the round
function is pipelined into seven stages of three levels of LUT each.

Tom

Article: 98451
Subject: EDK8.1: Is adding IP core parameters stiil possible?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 10 Mar 2006 10:40:13 -0500
Links: << >>  << T >>  << A >>
In EDK7.1 I could easily add any parameters to any of the IP cores. I can't
find how this is done in 8.1... Is it still possible? It seems that even if
I add a parameter manually to the MHS file, the tool then deletes it at some
point...

Thanks,
/Mikhail



Article: 98452
Subject: Re: for all those who believe in ASICs....
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 10 Mar 2006 07:51:16 -0800
Links: << >>  << T >>  << A >>
Paul,

Nice post.  Not often we agree.

Overall, I am very pleased with the thread.

LSI Logic was the dominant structured ASIC player with 42M$ in 2005 
(numbers from ISuppli).  There are 10 other vendors left now in this 
space, for a total market of 155M$ in 2005 (same source).

Out of those 10 vendors, Toshiba announced in June that "there is no 
money in this market" (from a EE Times article, 6/5/2005).  Is this a 
case of the "emperor having no clothes?"  Or just no money in this business?

5 of those vendors offer 90nm, the rest all have older technologies, 
some as old as .18 micron.

Two vendors that used to be in that business also left in the last year.

If Altera gets some of that 42M$ that LSI has dropped (although LSI will 
convert anyone who desires to the standard cell flow), then that will be 
good for Altera.  Good for the other 9 players, too.

Generally, the structured ASIC venbdors have as many mask sets as they 
have customers, which means that the vendors have not saved a penny, and 
in fact are losing money.

So, it is a great deal for a customer who wants a cheaper ASIC, but how 
long will companies stay in the business of losing money?

When the dominant (that means #1) supplier of structured ASICs calls it 
quits, that is not a sign of a healty market (IMHO).

So, while Altera runs off to do (structured) ASICs, we will instead 
continue to believe that programmable devices are the future, and 
continue to spend all of our effort (as in R&D $) on innovation in that 
field.

Austin


Article: 98453
Subject: Re: can bus protocol on fpga
From: =?ISO-8859-1?Q?Andre_Sch=E4fer?= <n-light@gmx.de>
Date: Fri, 10 Mar 2006 17:26:55 +0100
Links: << >>  << T >>  << A >>
The opencores pci bridge can act as a wishbone bus master, so you can 
connect it directly to the CAN core. I don't know if you use your own 
PCI core, if so, you propably have to write a wishbone interface for it.

Connecting the core to a CAN transceiver is simple. If you are using an 
FPGA without 5V tolerant I/Os use a 3.3V powered transceiver or a level 
converter.

Weeeeeeekend!!

Andre

> 
> Hi Adrien,
> 
> Maybe this is already clear to you, my apologies if so, but the
> CAN protocol block and the PCI bridge are both peripherals which
> are connected to the wishbone bus. Typically there will be
> a bus master such as a micro-processor core (or equivalent state
> machine) which will drive the bus to set-up the slave peripherals,
> monitor the status registers of the slaves, identify when some
> data needs to be moved from one to the other, and perform the
> move or configure a DMA bus peripheral to do the move.
> 
> So your project is not simply a case of connecting the CAN block
> to the PCI block, you will also need a controller of some sort
> sitting on the bus (micro-processor core etc).
> 
> Not a trivial project, but not impossible either by any means.
> 
> Alan
> 
> 
> 
> 
> 
> 
> 
> 

Article: 98454
Subject: Re: EDK8.1: Is adding IP core parameters stiil possible?
From: "Marco T." <marc@blabla.com>
Date: Fri, 10 Mar 2006 17:31:10 +0100
Links: << >>  << T >>  << A >>

"MM" <mbmsv@yahoo.com> wrote in message 
news:47dki2Fem3plU1@individual.net...
> In EDK7.1 I could easily add any parameters to any of the IP cores. I 
> can't
> find how this is done in 8.1... Is it still possible? It seems that even 
> if
> I add a parameter manually to the MHS file, the tool then deletes it at 
> some
> point...
>
> Thanks,
> /Mikhail
>
>

Double click on the core and appears a window where you can change 
parameters.

Marco 



Article: 98455
Subject: Re: FIFO Simulation Oddities!
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 10 Mar 2006 16:45:00 GMT
Links: << >>  << T >>  << A >>
<simon.stockton@baesystems.com> wrote in message 
news:1141983034.185650.25270@z34g2000cwc.googlegroups.com...
> Both FIFOs, and their respective READ_ENABLE signals, are manipulated
> from within STATE MACHINES (clocked on the rising edge of the
> respective READ_CLK's).

For grins...
For simulation...
Delay the READ_ENABLE as seen by the FIFO by 1 nanosecond.

These kinds of problems you're seeing are just *so* often a simulation 
problem because your RTL isn't simulation-ready when combined with models 
that have delay elements included. 



Article: 98456
Subject: Re: a problem with coolrunner CPLD (XC2C256) GCK0 pin
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Fri, 10 Mar 2006 17:50:35 +0100
Links: << >>  << T >>  << A >>
Hows about making the signal drive some flip-flops inside the device.
Make sure that the output of the flip-flops gets used somewhere else it'll 
all be optimised away.
Oh, and I don't know your situation, but be careful about any unusual 
functions that you may have inferred on the CLK0, I did some tests with an 
XC95144XL a while ago:
A clock in of 10MHz had a jitter of 70ps when it was directly output, that 
rose to 150ps when combinational stages appeared before the output. (well, 
in a simplified manner that's what I saw)
Hope that helps.
Ben

"Arash Majd" <arash_majd@ee.sharif.edu> wrote in message 
news:1141989340.207522.111170@z34g2000cwc.googlegroups.com...
> Hello and thanks for your attention
>
> Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some
> other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the
> other signals routed in our CPLD. I can not change my pin assignment,
> because the zl_1944_clk comes into CPLD only from only GCK0 pin.
> What I should do to make ISE consider zl_1944_clk as a global signal?
>
> (I would be grateful if  possible for you to provide me with a phone
> number to speak to you)
> 



Article: 98457
Subject: Re: Digilent Spartan-3 Starter Kit w/ JTAG-USB Problem/Solution
From: "Scott M. Kroll" <none@nowhere.com>
Date: Fri, 10 Mar 2006 12:18:50 -0500
Links: << >>  << T >>  << A >>
Believe it or not, just taking jumper M0 off let me program the .bit 
file and it worked.  But the USB cable is always hot, even when not 
programming (it's plugged into my laptop right now, without the 
Spartan-3 Board, and it's very warm/near hot.  Still, I think that 
Digilent needs to do a little work with their software to avoid this 
inconvenience.

But like I mentioned before, just pulling that jumper let it work, 
although it doesn't boot from the PROM anymore (because the jumper 
changes a mode setting).

c d saunter wrote:
> Hi Scott,
> 	I can't shed any light on the issue you describe, but...
> 
> When the SRAM fails to work, does the 'socket' (i.e. the shrinkwrapped IC 
> and PCB etc.) on the end of the JTAG-USB cable get very very hot?
> 
> Twice now I have had occasions when programming .bit files through one of 
> these cables the end gets very very hot - although everything still seems 
> to work.  Due to this and other not quite definable oddities I've switched 
> to programming the platform flash with .svf files and using this to 
> program the FPGA.
> 
> It doesn't inspire faith in the things...
> 
> cds
> 
> Scott M. Kroll (none@nowhere.com) wrote:
> : Well, I'm not sure if anyone here has had the same problem, but I have, 
> : and it has been driving me nuts.  My primary machine is a laptop, which 
> : has no parallel port, so I am stuck with USB.  Also, I am in a class 
> : where we are doing projects using the Spartan-3 Starter Kit from Digilent.
> 
> : Since I have no parallel port, I have been using Digilent's JTAG-USB 
> : cable, which, for the most part, works great.  However, there are two 
> : problems.
> 
> : 1. You cannot use Xilinx IMPACT to program the Spartan-3
> : 2. The external SRAM does not work when using a .bit file
> 
> : Well, #2 seems awfully strange.  I know it did for me, I thought I was 
> : having a problem with VHDL, and that's why I thought it wasn't working. 
> :   Well, I spent a long time tinkering with it over our winter break (I 
> : know, I know, but it's what I did) and just today I came up with the 
> : solution.
> 
> : A little explanation for this is probably needed.  Basically, anything I 
> : write and compile in IMPACT would work fine.  LEDs light up, the 
> : 7-segment display works fine, everything I've done works great. 
> : However, every time I tried to write to the SRAM, nothing changed, I 
> : simply got back garbage/random data.  Every time, no questions asked, it 
> : just didn't work.  To make a long story short, here's a solution I 
> : discovered (which, is a whole another story to how I figured it out).
> 
> : 1. Start IMPACT
> : 2. Edit -> Add Device -> Xilinx Device
> : 3. Loaded c:\Program Files\Xilinx\spartan3\data\xc3s200_ft256.bsd
> : 4. Right-Clicked Device, Assigned Configuration File
> : 5. Mode -> File Mode
> : 6. Clicked SVF-STAPL-XSVF tab, clicked "Yes" when it asked to load from 
> : Boundary Scan
> : 7. Chose to generate a new SVF file, named it
> : 8. Right-Clicked Device, chose Program.
> : 9. Output -> SVF -> Stop Writing to SVF File
> : 10. Quit Impact
> : 11. Started Export, did Device Scan, loaded SVF into the xc3s200, set 
> : the prom to bypass, hit program.  Everything worked right.
> 
> : Seems like a strange solution, but what I want to know, has anyone here 
> : had a problem like this?  I have a feeling that loading a different .BSD 
> : file for other Xilinx chips should work just as well with the JTAG-USB 
> : cable/Digilent's ExPort software, but I couldn't tell you.
> 
> : Hope this helps people out.
> 
> : If anyone wants to contact me with any more information via email, 
> : please use: skroll at gmail dot com
> 


Article: 98458
Subject: Re: Digilent Spartan-3 Starter Kit w/ JTAG-USB Problem/Solution
From: "Antti" <Antti.Lukats@xilant.com>
Date: 10 Mar 2006 09:29:12 -0800
Links: << >>  << T >>  << A >>
I belive you.

there are some 'odd' things regarding the JTAG config, when during jtag
config
some other (serial or parallel) interface what is been selected by mode
pins
does clock in a valid config header things go crazy -
there is a xilinx AR workaround also I think suggesting mode pin change

Antti


Article: 98459
Subject: Re: for all those who believe in ASICs....
From: "RobJ" <rsefton@abc.net>
Date: Fri, 10 Mar 2006 17:33:21 GMT
Links: << >>  << T >>  << A >>
Austin, Paul -

Why no mention of EasyPath or HardCopy? Where do those flows fit into the 
FPGA vs. structured ASIC battle? Can you guys share any numbers for your 
respective "ASIC conversion" programs? As in how many design conversions per 
year, trends up or down over the last few years, profit margins vs. your 
FPGA business, cost for an EasyPath or HardCopy part vs. an equivalent 
structured ASIC part from one of the nine remaining vendors? Are these 
programs viable and will they continue? I've seen both of you guys bail from 
similar programs in the past.

Good thread.

Rob 



Article: 98460
Subject: Re: for all those who believe in ASICs....
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 10 Mar 2006 10:30:18 -0800
Links: << >>  << T >>  << A >>
Rob,

Easypath is not a structured ASIC, it is an FPGA.  Identical in every 
way to what the customer is already using.  Except that we haven't 
tested the bits they don't use.

As for "success" of Easypath, it requires no design, no software, and no 
support.  No R&D.  Completely different business model.

So just one customer for Easypath is direct $ to the bottom line.

Obviously, we have more than one customer, yet I am not able to give you 
the exact number (as we consider it proprietary).

I do not consider Easypath as a competitor to ASICs (structured or 
otherwise), but as a cost lowering alternative for FPGA customers who no 
longer need to reconfigure their product.  In effect, this is a new 
segment of an existing market.

Would these customers go to an ASIC if Easypath was not an option?  I 
really don't know.  I suspect not.  I suspect they would just move on to 
the next product, and either end the life of the one, or accept reduced 
profits and reduced sales.

I know that Easypath is positioned as an alternative to Altera's 
HardCopy, but I disagree:  Easypath is just that - easy.  HardCopy is 
just that - hard.

One is buying exactly the same silicon for a lower price, and moving on.

The other is converting from a FPGA prototype of your design, to an 
ASIC, with all of those real risks (and I have heard of real cases of 
failure to converge from customers doing just that) and time to market 
issues.

We did have a program for cost reduction, and hardening the FPGA design. 
  It was called Hardwire.  We had Hardwire 1, 2, 3...  All we learned 
from this was the ASIC business is not our business (it is totally 
different business).  And, we also learned that it is incredibly hard to 
make any money.  Lots of competitors, many that are very hungry, and 
will drop the prices to take business beyond sanity.

The structured ASIC shell and pea game is just that.  Some of our 
hardwire products were just vias to short out memory cells, so the 
"conversion" was only a couple of masks, and costs were supposed to be 
incrediby low.  Not.  The story was good, but the reality was horrible: 
  it didn't work the way it was supposed to (sound familar?).  We 
eventually ended up with a standard cell ASIC flow after a gate array 
flow.  Guess what?  Didn't matter what the flow, it was still the ASIC 
business.  You still did an incredible amount of work once, for one 
customer, with no guarantee of success, with no future, and no reuse of 
anything for the next technology node.

With a real chance of failure.  If the customer makes a mistake, we both 
fail.

I like the model for FPGAs:  if the customer makes a mistake, they fix 
it, and move on.  Meanwhile we are succeeding with all of the other 
customers.  They will succeed, too.

If you will, we already have "been there, done that" and decided that we 
should stick with the customers, markets, business and business models 
that have made us the success we are today.

Let those nine companies circle the drain, the plug has been pulled.

Austin


Article: 98461
Subject: Re: EDK8.1: Is adding IP core parameters stiil possible?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 10 Mar 2006 13:32:02 -0500
Links: << >>  << T >>  << A >>
"Marco T." <marc@blabla.com> wrote in message
news:dus9k9$lc1$1@nnrp.ngi.it...
>
> Double click on the core and appears a window where you can change
> parameters.
>
That's the problem! You can change the existing parameters, but you cannot
add new parameters!

/Mikhail



Article: 98462
Subject: Re: for all those who believe in ASICs....
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 11 Mar 2006 07:41:04 +1300
Links: << >>  << T >>  << A >>
RobJ wrote:
> Austin, Paul -
> 
> Why no mention of EasyPath or HardCopy? Where do those flows fit into the 
> FPGA vs. structured ASIC battle? Can you guys share any numbers for your 
> respective "ASIC conversion" programs? As in how many design conversions per 
> year, trends up or down over the last few years, profit margins vs. your 
> FPGA business, cost for an EasyPath or HardCopy part vs. an equivalent 
> structured ASIC part from one of the nine remaining vendors? Are these 
> programs viable and will they continue? I've seen both of you guys bail from 
> similar programs in the past.
> 
> Good thread.

Paul did mention this, in another branch :
>  HardCopy II is particularly exciting because it uses a very efficient
> fine-grained logic fabric and provides a choice of migration devices
> allowing greater cost reductions than previous members of the family.
> HardCopy II also provides a significant speed-up over the equivalent
> Stratix II FPGA devices and cuts power consumption in half.

  Which is interesting, because that offers a lot more than Xilinx's 
subset testing - and as Paul also mentions, it is the Prototyping, and 
tool flows, that make a large difference in taking this step.

  What is pretty much the same, in X & A's 'custom' offerings, is both
will do the component testing, on their FPGA testers.

  Unlike other ASIC vendors, the FPGA players have (very) large 
investments in the SW side of their business.
  Of course HardCopy paths are only for a tiny % of customers, so
from a design-start viewpoint, they are insiginifcant, but the revenue
potential of that small group are significant.

  Still, if I were a Xilinx stock holder I might be a bit worried
about their ignoring this sector. Let's see where they stand in 2008..

-jg


Article: 98463
Subject: Z80 Support Cores
From: ziggy <ziggy@fakedaddress.com>
Date: Fri, 10 Mar 2006 18:45:21 GMT
Links: << >>  << T >>  << A >>
Was just wondering if there were any cores out there ( not for a 
commercial product, just hobby experimentation here ) for the common 
support chips for a Z80.  ( like SIO, DMA, etc ).

I know a couple of CPU cores exist.. 


tks all.

Article: 98464
Subject: Re: EDK8.1: Is adding IP core parameters stiil possible?
From: Paulo Dutra <paulo.dutra@NOSPAM.com>
Date: Fri, 10 Mar 2006 10:56:46 -0800
Links: << >>  << T >>  << A >>
How was it possible add new parameters to a core at the MHS level?
EDK tools would issue an error stating property not found. This DRC
goes far back to EDK3.1 days.

You can only add a parameter if it also exists on the MPD of the core.



MM wrote:
> "Marco T." <marc@blabla.com> wrote in message
> news:dus9k9$lc1$1@nnrp.ngi.it...
>> Double click on the core and appears a window where you can change
>> parameters.
>>
> That's the problem! You can change the existing parameters, but you cannot
> add new parameters!
> 
> /Mikhail
> 
> 

Article: 98465
Subject: Re: a problem with coolrunner CPLD (XC2C256) GCK0 pin
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 11 Mar 2006 07:59:58 +1300
Links: << >>  << T >>  << A >>
Arash Majd wrote:

> Hello and thanks for your attention
> 
> Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some
> other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the
> other signals routed in our CPLD. I can not change my pin assignment,
> because the zl_1944_clk comes into CPLD only from only GCK0 pin.

So you mean you have a pile of completed PCBs, and are after a
'SW only' solution ?

> What I should do to make ISE consider zl_1944_clk as a global signal?

Does the 19.44Mhz clock anything inside the CPLD ?
If not, then it will not form a gCLK - but you could create a
register for it to clock, and thus change the routing paths.

How far, physically, between the IN and OUT pins ?

Also, noise on Vcc/Gnd will aggravate this - PCB layers, decoupling ?

What else happens to the 19.44Mhz ? - ie could you use a TinyLogic
gate as Buffer/Switch, skipping the CPLD entirely - tiny logic devices 
will have very low jitter, as they have only one gate with its very-own 
supply rails.  No common mode inductance at all....

-jg


Article: 98466
Subject: Re: EDK8.1: Is adding IP core parameters stiil possible?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 10 Mar 2006 14:14:25 -0500
Links: << >>  << T >>  << A >>
"Paulo Dutra" <paulo.dutra@NOSPAM.com> wrote in message
news:dusi59$o7j1@cliff.xsj.xilinx.com...
> How was it possible add new parameters to a core at the MHS level?
> EDK tools would issue an error stating property not found. This DRC
> goes far back to EDK3.1 days.
>
> You can only add a parameter if it also exists on the MPD of the core.

You might be right that the parameter had to exist in the MPD-file, although
I believe I did add a parameter which didn't exist in the MPD in the past.
Correct me if I am wrong, but in 8.1 it doesn't seem to display all the
available parameters, but rather only the ones it thinks you might need to
change.


/Mikhail



Article: 98467
Subject: Re: for all those who believe in ASICs....
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 10 Mar 2006 11:22:52 -0800
Links: << >>  << T >>  << A >>
Jim,

Let's see, Xilinx is "ignoring" a piece of a 155 M$ business with lousy 
margins and 9 other vendors competing and willing to drop prices below 
their costs?

As a Xilinx stockholder, I am pleased to see that Xilinx can keep their 
eye on the prize, and not stray off to the "gold ring du jour."

I do agree that having a cost reduction path is important for business.

I do not agree that spending a proportion of your revenue is warranted 
to "capture" it.  A simple ROI calculation will reveal if it is real 
business, or just plain dumb.

Toshiba figured it out.

LSI figured it out.

We figured it out years ago.

Two others figured it out (too late as they drove themselves right into 
the ground).

Austin


Article: 98468
Subject: Re: for all those who believe in ASICs....
From: Evan Lavelle <me@seesig.com>
Date: Fri, 10 Mar 2006 20:13:50 +0000
Links: << >>  << T >>  << A >>
I know it's a mistake getting involved in this thread, but...

here are some observations on EasyPath and (Structured) ASICs which
don't appear to have come up elsewhere:

1 - EasyPath has an NRE. I don't have real numbers, but Xilinx's
literature gives figures between $75K and $300K, and an MOQ of 50K
pieces. It's not cheap.

2 - If you commit to EasyPath, you can't change your design without
paying the NRE again. In this respect, EasyPath is the same as an
ASIC. You have to be absolutely sure that it'll work. Just like an
ASIC, in fact.

3 - The RapidChip NRE, for a device with about the same capacity as a
very large Virtex-4, came in at about $100K - $150K, with much smaller
MOQs. And this is a *small* device.

4 - EasyPath is not 'just the same' as the FPGA you were buying
before. When I last looked, it was a device that had failed test.
Perhaps someone from Xilinx could comment on whether this is true or
not. This matters, because fewer devices will fail testing when yields
go up, as they will. You're going to have to ask yourself whether
Xilinx will carry on selling you cheap devices when they could sell
them to someone else at full price.

5 - As I said in my other post in this thread, there is no comparison
between EasyPath and even a 'structured' ASIC when it comes to
capacity, performance, and power consumption.

6 - You can (or could) get RapidChip prototypes in about 8 weeks from
handoff. I don't have EasyPath figures, but it's not going to be a lot
less than that.

7 - I've seen (in several places) the claim that EasyPath devices are
cheap because they require less testing. I don't believe it. They're
cheap because they failed test in the first place, and so would have
no value at all without the EasyPath route. It would be nice to have a
definitive statement from someone in Xilinx if they happen to disagree
with this.

Where I agree with Austin is "I do not consider Easypath as a
competitor to ASICs". So, what on earth is the point of spending all
this (uninformed) effort knocking ASICs? If someone can get the
business model right, then Structured ASICs will fit very nicely into
the space between FPGAs and standard cell. And they will make no
difference at all to the vast majority of the FPGA market.

Evan
--
Riverside
emlat
riverside-machinesdotcodotuk

Article: 98469
Subject: Re: a problem with coolrunner CPLD (XC2C256) GCK0 pin
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 10 Mar 2006 20:31:49 GMT
Links: << >>  << T >>  << A >>
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> 
wrote in message news:dusaos$gv9$1@sunnews.cern.ch...
> Hows about making the signal drive some flip-flops inside the device.
> Make sure that the output of the flip-flops gets used somewhere else it'll 
> all be optimised away.
> Oh, and I don't know your situation, but be careful about any unusual 
> functions that you may have inferred on the CLK0, I did some tests with an 
> XC95144XL a while ago:
> A clock in of 10MHz had a jitter of 70ps when it was directly output, that 
> rose to 150ps when combinational stages appeared before the output. (well, 
> in a simplified manner that's what I saw)
> Hope that helps.
> Ben

The 70ps and 150ps numbers are cleaner that what I expected but make good 
sense.  The 0.12 UI doesn't make sense at 19.44 MHz but does for 
significantly higher output rates slaved off the 19.44 MHz clock.

To the original poster or anyone else doing designs that have excessive 
constraints on jitter such as telecom systems and high speed/accuracy A/D 
converters, PLEASE design to provide the cleanest clock in the system to the 
stages that need the cleanest clock.

Generic logic with unrelated activity "close by" will cause jitter either at 
the input to the chip or coming back off the chip.  That's the nature of the 
beast.  A discrete buffer would have been a better way to achieve the 
required low jitter levels.




Article: 98470
Subject: Re: for all those who believe in ASICs....
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 10 Mar 2006 20:52:16 GMT
Links: << >>  << T >>  << A >>
First, I would like to see the Xilinx take on these items as well.  Although 
I fell I "know" the issues, it's nice to have reassurance.

Comments below:

"Evan Lavelle" <me@seesig.com> wrote in message 
news:0tl3129i2hvcfs7ok5vliafonvf37blhbh@4ax.com...
>
> 4 - EasyPath is not 'just the same' as the FPGA you were buying
> before. When I last looked, it was a device that had failed test.
> Perhaps someone from Xilinx could comment on whether this is true or
> not. This matters, because fewer devices will fail testing when yields
> go up, as they will. You're going to have to ask yourself whether
> Xilinx will carry on selling you cheap devices when they could sell
> them to someone else at full price.

At a structured ASIC presentation, I railed on the guy that said that Xilinx 
was selling bad parts.  It's been underscored here before that the parts are 
*not* rejects from the main testing that get shoved over to the easypath 
line in the same sense as harddrives with bad sectors that didn't need 
"those" sectors.  The parts are UNTESTED to begin with, have a yied% chance 
of being a 100% good device, and are *guranteed* not only for your explicit 
bitmap but for 100% LUT operation as well.  100% LUTs are good.  100% of the 
routing and resources you need are also good.  If you have an error in the 
silicon, it doesn't burn a hole in your board; an unused feature or routing 
segment doesn't work which is inconsequential.  Keep in mind that devices 
with redundancy have MANY chips that are shipped with KNOWN defects that are 
just "programmed out."  *IF* you have a defect with EasyPath, it won't screw 
up the design that you submitted to them for 100% testing.

> 7 - I've seen (in several places) the claim that EasyPath devices are
> cheap because they require less testing. I don't believe it. They're
> cheap because they failed test in the first place, and so would have
> no value at all without the EasyPath route. It would be nice to have a
> definitive statement from someone in Xilinx if they happen to disagree
> with this.

I worked at a company that produced a high-end piece of test equipment as 
well as a low-end box.  The difference in the hardware was *minimal* but we 
opened ourselves to a market that required mininal NRE.  The development for 
the big box was already bought and paid for.  We still made a decent profit 
on the lower-cost box but it wasn't quite the margin of the more expensive 
brother.  The margin we lost was made up for in reduced NRE costs up front. 
It's great when you can make *more* money by expanding your market without 
losing your base.

It's *quite* probable that Xilinx doesn't save the cost difference between a 
production FPGA and an EasyPath FPGA with just the savings in test time. 
It's likely that they take a lower margin on the devices to keep customers 
who might change to a lower-cost, higher NRE solution by lowering their 
margins.  They still make money.  They don't need to provide the support and 
development to support 50 1k/yr customers compared to 1 50k/yr customers. 
Xilinx gets more profits.  Customers get less costly solutions.  The only 
folks left out are those that had alternative paths to offer beyond the 
Xilinx flow.


My thoughts, my opinions.  I like the business case.
- John_H 



Article: 98471
Subject: AC97 Codec
From: "Eric" <dasani8888@hotmail.com>
Date: 10 Mar 2006 13:00:53 -0800
Links: << >>  << T >>  << A >>
Hi,

I plan to do a project using the AC97 codec on a Virtex-II Pro board.
I'm thinking to read inputs from MIC, do some filtering work, and the
output to speakers. I do not have any experience with audio devices.
Does anyone know good references for a starter? Thanks!

-Eric


Article: 98472
Subject: Re: a problem with coolrunner CPLD (XC2C256) GCK0 pin
From: "Arash Majd" <arash_majd@ee.sharif.edu>
Date: 10 Mar 2006 13:04:30 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
> Arash Majd wrote:
>
> > Hello and thanks for your attention
> >
> > Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some
> > other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the
> > other signals routed in our CPLD. I can not change my pin assignment,
> > because the zl_1944_clk comes into CPLD only from only GCK0 pin.
>
> So you mean you have a pile of completed PCBs, and are after a
> 'SW only' solution ?
>
> > What I should do to make ISE consider zl_1944_clk as a global signal?
>
> Does the 19.44Mhz clock anything inside the CPLD ?
> If not, then it will not form a gCLK - but you could create a
> register for it to clock, and thus change the routing paths.
>
There is only two or three signal assignments.
for example :
CKREF0<=ZL_1944_CLK
CKREF1<=ZL_1944_CLK
How should I create a register for it ? you mean that I implement a
counter in my design?

> How far, physically, between the IN and OUT pins ?
>
The input pin(GCK0) belongs to functional block5 and the CKREF0 pin
(output pin) belongs to FB15. and the CKREF0 and the optical driver
module is nearly 10 cm far.

> Also, noise on Vcc/Gnd will aggravate this - PCB layers, decoupling ?
>
I am sure that the power planes are O.K and the decoupling capacitances
are proper, because when I input this signal from another input (by
wire ) the output jitter is O.K.


> What else happens to the 19.44Mhz ? - ie could you use a TinyLogic
> gate as Buffer/Switch, skipping the CPLD entirely - tiny logic devices
> will have very low jitter, as they have only one gate with its very-own
> supply rails.  No common mode inductance at all....
You mean that I change my PCB?


> 
> -jg


Article: 98473
Subject: Re: for all those who believe in ASICs....
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 10 Mar 2006 13:35:14 -0800
Links: << >>  << T >>  << A >>
Evan,

Thanks for bringing this up,

Answers below,

Austin

-snip-
> 1 - EasyPath has an NRE. I don't have real numbers, but Xilinx's
> literature gives figures between $75K and $300K, and an MOQ of 50K
> pieces. It's not cheap.
Nope.  We ask that folks are serious.  Just like for ASICs.  Don't want 
to waste our time on non-real requirements.
> 2 - If you commit to EasyPath, you can't change your design without
> paying the NRE again. In this respect, EasyPath is the same as an
> ASIC. You have to be absolutely sure that it'll work. Just like an
> ASIC, in fact.
Not true:  you may change any LUT contents that you already are using, 
and you may change any IO standard on any pin you are already using. 
There are other changes which are allowed.  Try that with an ASIC! We 
call it the ECO capability of EasyPath (some stuff we have to test 100%, 
so you benefit).
> 3 - The RapidChip NRE, for a device with about the same capacity as a
> very large Virtex-4, came in at about $100K - $150K, with much smaller
> MOQs. And this is a *small* device.
RapidChip?  Oh those guys that just left the business? Oh well.  I could 
offer you gasoline at 8 cents a gallon, and I am sure I would have a 
long line at my station...
> 4 - EasyPath is not 'just the same' as the FPGA you were buying
> before. When I last looked, it was a device that had failed test.
Not true:  it is a device that is only tested for what you need.
> Perhaps someone from Xilinx could comment on whether this is true or
> not.
Commonly asserted by others to apply FUD.
  This matters, because fewer devices will fail testing when yields
> go up, as they will. You're going to have to ask yourself whether
> Xilinx will carry on selling you cheap devices when they could sell
> them to someone else at full price.
We will start wafers just to meet EasyPath.  It is that cost effective. 
  And, we do just that.
> 5 - As I said in my other post in this thread, there is no comparison
> between EasyPath and even a 'structured' ASIC when it comes to
> capacity, performance, and power consumption.
Ohe really? I think one can comapre them.  Some areas (like leakage) the 
ASIC will win.  Some areas (like 10 Gb/s MGTs and a PPC, and a TEMAC) 
the EasyPath will win, as these IPs are not even available all together 
in 90nm!
> 6 - You can (or could) get RapidChip prototypes in about 8 weeks from
> handoff. I don't have EasyPath figures, but it's not going to be a lot
> less than that.
Yes.  Except that now, RapidChip will arrive "never."  When EasyPath 
arrives, there is nothing to do, but plug it in, and ship it.  No 
requalification is required:  there is NO DIFFERENCE in what goes in the 
socket.  Re-qual costs can be substantial, and the re-qual can take 
months...
> 7 - I've seen (in several places) the claim that EasyPath devices are
> cheap because they require less testing. I don't believe it.
Well, I can't convince you without desrcibing why.  And in describing 
why, I will educate you.  And I have no incentive to do that.  You may 
look up the patent if you wish.
  They're
> cheap because they failed test in the first place, and so would have
> no value at all without the EasyPath route. It would be nice to have a
> definitive statement from someone in Xilinx if they happen to disagree
> with this.
Definitive statement:  testing a product for one use saves an incredible 
amount of money.  Look at ASICs....
> Where I agree with Austin is "I do not consider Easypath as a
> competitor to ASICs". So, what on earth is the point of spending all
> this (uninformed) effort knocking ASICs? If someone can get the
> business model right, then Structured ASICs will fit very nicely into
> the space between FPGAs and standard cell. And they will make no
> difference at all to the vast majority of the FPGA market.
Oh, I don't know, sounds like you learned something today?  And, you and 
I agreed on something.  Not a bad result for a thread.

Article: 98474
Subject: Re: EDK8.1: Is adding IP core parameters stiil possible?
From: Paulo Dutra <paulo.dutra@NOSPAM.NOSPAM>
Date: Fri, 10 Mar 2006 13:55:40 -0800
Links: << >>  << T >>  << A >>
The tools do visually hide parameters that are automatically computed.
There are tags within the MUI file that define the parameter as hidden.
If you edit the MHS with a texteditor you'll can enter the value
for the hidden parameter.

MM wrote:
> "Paulo Dutra" <paulo.dutra@NOSPAM.com> wrote in message
> news:dusi59$o7j1@cliff.xsj.xilinx.com...
> 
>>How was it possible add new parameters to a core at the MHS level?
>>EDK tools would issue an error stating property not found. This DRC
>>goes far back to EDK3.1 days.
>>
>>You can only add a parameter if it also exists on the MPD of the core.
> 
> 
> You might be right that the parameter had to exist in the MPD-file, although
> I believe I did add a parameter which didn't exist in the MPD in the past.
> Correct me if I am wrong, but in 8.1 it doesn't seem to display all the
> available parameters, but rather only the ones it thinks you might need to
> change.
> 
> 
> /Mikhail
> 
> 



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