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 99075

Article: 99075
Subject: Re: HWICAP with the Virtex II Pro. Anybody? Bueller?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 20 Mar 2006 12:30:35 +1000
Links: << >>  << T >>  << A >>
Hi Scott,

scotto wrote:

> Hello, Does anybody out there actually know how to set up HWICAP in EDK?
> Has
> anyone ever got this to work?

It works - I've even wrapped a Linux driver around it to make a
self-reconfiguring MicroBlaze system.  That was version 1.00.a - it's up
to 1.00.b now but don't think much has changed.

> If you've ever looked into this, you know there's very little
> documentation on how to setup and use HWICAP. Would someone please post a
> C file instantiating, initializing, and perhaps even reading/writing a
> frame through ICAP? That would be extremely helpful.

The trick with this core is to realise that it's buffered - you send
your reconfig frames to a BRAM buffer (memory mapped on the OPB bus),
then trigger the core to do the actual reconfig.

Readback is the reverse - trigger the frame read, then get the data from
the buffer.

In /path/to/edk/sw/XilinxProcessorIPLib/hwicap_v1_00_a is the source of
the level 0 drivers, and some example code as well.

Also, in the core directory itself

/path/to/edk/hw/XilinxProcessorIPLib/pcores/opb_hwicap_v1_00_b.

/doc has a nice data sheet, and the /hdl subdirectory is the full source
in nicely commented VHDL.

Use the source, Luke!

John


Article: 99076
Subject: Re: FPGA FIR advice
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 19 Mar 2006 18:49:58 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> Roger Bourne wrote:
> > Hello,
> >
> > I never actually implemented FIR filters in FPGAs. But, if I am able to
> > assume, I would say that  FIR filters take up a SIGNIFICANT amount of
> > space in an FPGA.
> > E.g. 20th-order FIR filter, 16 bit, would require at the very least 320
> > FFs. Then there is all the combinationnal logic that will be employed
> > to multiply the output of each 16bit-delay element by its respective
> > tap (at least the taps can be hardcoded). And finally  there is the 16
> > bit accumulator register at the output.
> > I am sure that I am oversimplifying the realization of the FIR filter;
> > there must be some major details that I am overlooking. And there is
> > also optimization techniques that the FPGA device probably offers that
> > I have not mentionned.
> >
> > Still, I feel that the above description does give a good description
> > on the realization of FIR filters. Would that be accurate? I mean that
> > FIR filters (or IIR filers) do take up a considerable chunck of FPGA
> > space ?
> >
> > Thx in advance
> > -Roger
> >
>
> 20 Tap FIR filters don't occupy all that much room in FPGAs, especially
> the modern parts which have quite a bit more logic resources than
> earlier chips.  First, most times we can run the clock at a multiple of
> the sample rate, which allows us to time share the hardware either by
> using the same multiplier for several tap coefficients, or by using
> several clock cycles to accomplish the multiplies (distributed
> arithmetic takes that a step further to postpone the shift-adds).  A
> brute force full parallel implementation will be the largest, but for 20
> taps, even that is not all that large, especially if you take advantage
> of the embedded multipliers present in most of the current families.
> Look at the multipliers and distributed arithmetic pages on my website
> for a bit of a tutorial: http//:www.andraka.com

Hi Ray and Peter,

I am sorry for hijacking your thread Roger , but I think my question is
relevant.

I was thinking of using about 8 FIR (bandpass) filters in parallel to
create a graphic equalizer. Now I know there are some phase problems
with this method but it seems to me like a very logical way to go about
this problem. I was wondering if you guys know of any better methods?

I also was thinking of using 16 taps each.

320 FF's is not a lot actually. My XC3S200 (which is probably dirt
cheap) has almost 4000 FF's. Enough for your filter network and much
more.

-Isaac


Article: 99077
Subject: Re: reading data off a virtex-ii pro board
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 19 Mar 2006 21:15:50 -0600
Links: << >>  << T >>  << A >>
>I have some program receiving data on a virtex-ii pro board. I'm trying
>to obtain information from the board, so I can process the data in a
>PC. The amount of data I try to retrieve is about at least 2MB. Can
>anyone suggest an efficient method to do so? Thanks.

What's wrong with RS-232?  You'll need some software on a PC to
catch the data, but you'll need something like that anyway.

115Kbits/sec works fine on most PCs.  You can kludge things if the
cables are short.  We use TTL levels rather than real RS-232 all the
time.

2M bytes is 174 seconds.  Extra credit if you add a checksum.


If you want something faster, I'd try ethernet.  You'll have to
wrap things into a UDP packet.  That's just putting a constant
on the front end and a CRC on the back.  If you want to get fancy
you could include a sequence number and/or start/end flags.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 99078
Subject: Re: FPGA FIR advice
From: John_H <johnhandwork@mail.com>
Date: Mon, 20 Mar 2006 04:15:46 GMT
Links: << >>  << T >>  << A >>
Isaac Bosompem wrote:
> Hi Ray and Peter,
> 
> I am sorry for hijacking your thread Roger , but I think my question is
> relevant.
> 
> I was thinking of using about 8 FIR (bandpass) filters in parallel to
> create a graphic equalizer. Now I know there are some phase problems
> with this method but it seems to me like a very logical way to go about
> this problem. I was wondering if you guys know of any better methods?
> 
> I also was thinking of using 16 taps each.
> 
> 320 FF's is not a lot actually. My XC3S200 (which is probably dirt
> cheap) has almost 4000 FF's. Enough for your filter network and much
> more.
> 
> -Isaac

Another great advantage to FPGA FIRs: most of the time the FIRs are 
symmetric which allows half the taps (half the multipliers) to implement 
the full FIR by adding t-δ to t+δ before multiplying by the common 
coefficient, the implementation is more elegant.

Article: 99079
Subject: Re: Urgent Help Needed!!!!!
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 00:04:40 -0800
Links: << >>  << T >>  << A >>
The cultural and class bigotry in this tread is appalling. If some of
the OLD TIMERS in this group wish to be mentors, they first need to
learn to be a bit more flexible, and not riddicule and insult others at
the drop of a hat.

This is not a native US born and educated form. It has many posters
struggling to communicate in a non-native foriegn language based on
language skills learned in chat rooms, IRC's, and a number of other
forums.

This list also includes posters like myself that are dyslexic, and find
it extremely difficult to proof our own writings because misspellings,
transpositions, missing/wrong characters and words are all "corrected"
incorrectly by our brains as we reread our own work.

Spelling and grammar flame wars like this thread are nothing short of
bigotry.


Article: 99080
Subject: Re: slice macro replace the bus macro in the virtex-4 how to do that?????
From: Stephane <stephane@nospam.fr>
Date: Mon, 20 Mar 2006 09:16:07 +0100
Links: << >>  << T >>  << A >>
Ivan wrote:
> Hi Jean-Baptiste,
> 
> you can download a presentation about my work in:
> http://www.ii.uam.es/~igonzale/recursos/Self_Reconfigurable_Coprocessors.pdf 

Hi Ivan,

could you please comment, on your slide 63, how you compute the values 
for the options PartialMask0,1,2 ?

Thanks

> 
> 
> I think it will be useful to understand how to develop slice-based bus 
> macros :)
> 
> Regards
> 
> Ivan
> 
> jean-baptiste wrote:
> 
>> Hello Ivan,
>>
>> I would like to do a slice-based bus macro.
>>
>> But i don't know how to do. Could you help me or show me the direction?
>>
>> Jean-Baptiste

Article: 99081
Subject: Re: Microblaze FSL peripheral problem
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 20 Mar 2006 10:31:10 +0100
Links: << >>  << T >>  << A >>
Can you explore "not working as intended"?

The C code looks a little strange.
You write on FSL channel 0 but read on FSL channel 1.
Is that how you have connected the FSL accelerator to MicroBlaze?

Gran Bilski




Article: 99082
Subject: Re: microprocessor design: where to go from here?
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 20 Mar 2006 10:36:34 +0100
Links: << >>  << T >>  << A >>
burn.sir@gmail.com wrote:
> Hello everyone
> 
> 
> In the last couple of months, I have become very interested in CPU
> design. Specially the ones that you can actually build and fire up
> right on your kitchen table (i.e. the ones you can get into a decent
> FPGA). I have read the classic texts on the subject (Enoch Hwangs book,
> Jan Grays articles and scanned all code I could find on OpenCores, to
> name a few). What I am still missing is some real-world design
> examples. You know, things like L1 and L2 caches, TLB and all that
> stuff. Things that differs PicoBlaze from ARM9 :)
> 
> While ago, I saw a recommendation here in the group about few books
> that taught state-of-the-art techniques. It contained references to
> things like the newest ARM, Intel and AMD CPUs. Unfortunately, I cannot
> find the post anymore.
> 
> Any idea which book or books it was?
> 
> (any general recommendation is also very welcome)
> 
> 
> regards
> - Burns
> 

My bible on CPU design is "Computer Architecture, A Quantitative Approach".

I never stop reading it.

Gran Bilski

Article: 99083
Subject: Re: for all those who believe...
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 01:42:00 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> Jim Granville wrote:
>
> > > Stupid isn't the right word. Complacent with their margins is probably
> > > a better descripton. It's why they are only a $1.3B company instead of
> > > $10-40B dollar company like Sun Microsystems or Microsoft which are
> > > similar ages.
> >
> > But in quite different fields, so impossible to compare.
>
> Nothing could be farther from the truth.

So your first thought was "right", laced with sarcasm. Let's examine
this a bit. Xilinx produces about as many board level products as Apple
Computer did in 1984, including an outstanding entry into the system
level market with the ATX form factor ML310 motherboard.  It's "only"
problem is it's cost of ownership coupled with marginal software
support to actually use it as a reconfigurable computer -- IE nearly a
complete lack of software support for the applications developer
community, focusing instead on embedded markets. Considering the Xilinx
ROI for those boards, and Apples ROI for it's board development, there
are questions to consider.

Consider that Apple produced 1 million systems with the MacIntosh 128,
512, and Plus design, with a price tag of over $2K each over three
years from introduction. That nearly doubled the companies sales in
just over a year, to just under $2B for 1985 and 1986 while redefining
the personal computer industry.  Apple did this with one of the most
agressive cost of ownership designs in the computer industry at the
time, and aggressively creating a developer network that produced some
800 application programs that "sold" the MacIntosh for Apple.

           http://apple.computerhistory.org/stories/storyReader$24

Everything on the ML310 board, except the VP30, can be found on a
commodity $50 retail ATX motherboard. The value that Xilinx failed to
capitalize on was taking reconfigurable computing mainstream by
agressively pricing this product, and creating a large reconfigurable
computing developer network to produce applications for the platform.
Having Xilinx FPGA literate developers, and lots of them, would easily
push Xilinx's chip sales and market share for an explosive growth.

Missing at Xilinx was system product level architects and a management
team visionary enough to build and capitalize on a systems level growth
market.  To do so, would require Xilinx doing an about face on it's
software product licensing and embracing open software in a very
different way.

I believe that Xilinx leading the reconfigurable computing market could
easily take 5-10% of the global computing market share, just as Apple
has for the last two decades. Apple for fiscal 2005, generated revenue
of $13.93 billion, ten times Xilinx concentrating on chip sales.

With it's patent protection for the cash cows expiring, and a very
likely boom in off shore competition in the comodity FPGA market, I
believe that Xilinx needs to seriously pick up some vision about it's
future. While it has some major volume design in's for the US auto
industry, it has also created a huge introductory market for off shore
fabs to produce FPGA's for foriegn auto producers that will follow the
US lead.

So, while the Xilinx staff here are critical of offering "advise"
because they are so successful, that "success" does have other
measures.  There is another view that Xilinx doesn't need advice, it
needs a completely different "vision" in it's management team to create
new and larger markets as FPGAs go comodity and off shore competitors
chip away at the cash cows.  The $155M structured ASIC market is
peanuts compared to the possiblities as a systems level company.

Xilinx with an agressive cost of ownership strategy, could produce
ML310 like motherboards into the market at pretty substantial volumes,
along with fully packaged retail systems later.  Deep seeding of the
educational and open source developers communities would result in a
rapid expansion of RC literate programmers, and applications, creating
an RC market that has a very likely chance of securing 5-10% of the
computer market inside a few years. RC established on Xilinx product,
would set a defacto binary standard (and resulting market share) that
would be hard to erase for a long time - the Intel effect. Or, one of
the A-Team companies, or new off shore entrants, can establish that
standard first.


Article: 99084
Subject: Re: SerialATA with Virtex-II Pro
From: =?ISO-8859-15?Q?Michael_Sch=F6berl?= <MSchoeberl@mailtonne.de>
Date: Mon, 20 Mar 2006 10:59:06 +0100
Links: << >>  << T >>  << A >>
> None of these would work? 
> * http://www.siliconimage.com/products/productfamily.aspx?id=3

they only list various PCI to SATA chips or SATA to PATA-(device)
... All those chips that could be used in the mass-market
for desktop PCs :-(

looks like there is no way other than using PCI-whatever?


SI once had a SATA phy on their homepage but it was far
from beeing available ... their local representation
did not even know about it ...


BTW: some time ago there was an announcement from TI to build
a DSP with some Rapid-IO interface (C6455) ... It would be
really cool to connect *that* to PCI-e and SATA directly ...
I asked them - they did not even think about that opportunity :-(


bye,
Michael

Article: 99085
Subject: Re: for all those who believe in ASICs....
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 02:28:58 -0800
Links: << >>  << T >>  << A >>

Eric Smith wrote:
> fpga_toys@yahoo.com writes:
> > My family is from the show me state .... and I'd like to see the
> > numbers behind the spin that testing is responsible for a 25-80%
> > savings over a 50K FPGA order converting to easypath.
>
> I work for a fabless semiconductor company (though I'm not speaking for
> them), and I can confirm that testing is expensive.  Sometimes after a
> product has already been in production for a while, we're able to come up
> with a new set of test vectors that provides the same coverage in less
> time, and this *significantly* reduces our costs.

The flip side of that is tester time is so expensive that a die can
only spend a short time on it, so intermitant failures don't get
caught. I've been on the system end of the problem most of my life,
doing operating systems, drivers, and diagnostics combined with
hardware design. There was a reason we did burn-in with tests
specifically targeting intermittants, and heavy qualification in an
environmental chamber.

As a systems guy, we provided burn-in support that directly augmented
board level ATE testing.

With a systems guy view, I can only wonder why die level and package
level ATE is required. Design for test has to be one of the most
critical requirements in the process - from die to system. It would
seem that the the ATE function should probably be redundant on the
wafer at fab, tightly integrated to the application die's IO pads --
AND critical internal logic not visible from pads. The wafer in this
environment would have surface metalization on one edge for power and a
network interface.  The ATE function on the wafer would include power
control for each die, an on wafer jtag chain, plus an on wafer gigabit
network, each bused to a set of pads on one keyed edge of the wafer.
The wafers would be racked into a test/burnin fixture that would
provide power and network connectivity to the wafer (thousands of
wafers) with an external test controller and logger. Each wafer's on
silicon ATE system would then test each die (possibly hundreds in
parallel) and leave a rest report for the external logger.

This can be done by the fab, as they build up a multi-project wafer, or
by the fabs customers for single customer wafers.

Xilinx is such a large company, it would seem that designing a standard
on wafer ATE function to free themselves of expensive die probing ATE
would be a huge priority. IT would also allow for entire batchs of
wafers to be tested with a full range of environmentals over a
significant period of time to better issolate intermittants coupled to
particular environmental ranges.

Similarly, a subset of that on each die would facilitate package level
testing both after packaging, and after customer board mounting.

There is nothing special about the ATE's test interfaces, that can not
be implemented on wafer with some good test for design strategies.

>
> Every second a part spends on a tester costs real money, and a big FPGA
> probably spends a LOT of time on a tester.  I'd be surprised if Xilinx
> didn't employ a fair number of engineers whose entire job is optimizing
> test vectors for high coverage in short test time.

One of the biggest problems in any industry .... "we have always done
it that way".


Article: 99086
Subject: Re: SerialATA with Virtex-II Pro
From: "Antti" <Antti.Lukats@xilant.com>
Date: 20 Mar 2006 02:40:33 -0800
Links: << >>  << T >>  << A >>
marvell has PATA<->SATA bridge that is available for low volume
ordering - it easier to connect than PCI-SATA

Antti


Article: 99087
Subject: Re: Disk/LCD defect tolerant models for FPGA sales
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 02:47:36 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> It appears to me that perhaps you are assuming the yeild is high, more
> than 50% anyway.  What happens to your assumption if the yield is more
> like, say, 10-20%.  It seems to me that the lower the yield, the more
> attractive easypath becomes, especially if, as Austin indicated, most
> yield fallout is only one defect.

Actually the concept of managed defects becomes even stronger
economically with lower yeilds, as the ratio to valuable recovered
defect product to discards gets higher. Instead of discarding 80-90% of
the product, you then add that yield to your revenue.  Only untestable
dies (those with power rail shorts, failed jtag interfaces, failed
configuration paths, etc) are discarded. And even some of those can be
recovered with additional design for failure strategies.

> Maybe if you have enough spare cycles in your RC system, you can do that
> in the background and hope you don't hit a defect in operational builds
> before the defect map for the system is completed.

Every system I've worked with has spare cycles ... doing
testing/scrubbing in the idle loop is always a possibility.

> The current tools make this even harder since the user has little
> control over the what routing resources are used (there's directed
> route, but it is tedious to use and is a largely manual effort), and
> even less control over what routing resources can't be used.  Granted,
> this is a tools issue more than anything else, but the fact remains that
>   with the current state of the tools, I don't see this as feasible
> right now.  Yeah, I know, this supports your contention that the tools
> should be open.

Yep.

>
> Look at it from Xilinx's point of view though.  What is in it for them?

As I've posted elsewhere in this thread, increasing their revenue by
10-20x in a few years, and their long term market share substantially.
Or, just staying in business.

> More software that would need development and testing, more user
> support, devices with defects out on the market that could wind up in
> the hands of people thinking they have zero defect devices,

or, as the disk drive market ... just assume every device has defects
and design for it.

> not to
> mention their increased testing and administration cost to even
> partially map the defects, or even determine to what degree the part
> fails.

Designing for defect detection and management changes the entire view
of their process and ATE .... as I posted just a few minutes ago, why
isn't this integrated on wafer, instead of continuing to do it with ATE
as has been done for several decades?

> I can see where the cost of doing it could exceed the potential
> benefit.  If it were profitable for them to do it, I'm sure they would
> be pursuing it.  In any event, it is a business decision on their part;
> one they have every right to make.

I can see where the cost of ATE could make the difference between being
in business, or not. Designing for test, in a very different wafer
oriented way I see as critical.

>
> Anyway, it still seems to me that the amount of extra work to manage
> parts with defects would cost more than the cost savings in the part
> prices not just for XIlinx, but also for the end user.

For some applications sure .... for system level RC applications it's
completely trival (and necessary) in the grand scheme of things. A very
very minor amount of software.

Consider that a new system could be brought up using triple redundancy
and run live in that reduced capacity configuration for it's first few
hundred/thousand hours, then back off to single redundancy for
checking, and after the part is well qualified run only with background
idle loop testing and scrubbing.

Using the racked wafer strategy this is very viable to hold wafers in
test for 72 hours or more before they are cut and packaged. Then the
same strategy is extended to the package after it's brought up in a
system.

Designing for test, good test, coupled with defect management should
only increase yields, lower costs, and benifit both the mfg and
customer long term.


Article: 99088
Subject: VHDL LUT
From: "al99999" <alastairlynch@gmail.com>
Date: 20 Mar 2006 03:01:35 -0800
Links: << >>  << T >>  << A >>
Hi,

Can anybody please tell me what is wrong with the following code?  In
post-translate simulation there are a few unexpected short pulses.
Thanks,

Alastair

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity divcontrol is
   port (
q      : in    std_logic_vector (7 downto 0);
          pulse, shift, rstout,ledinc,ledread: out   std_logic
        );
end divcontrol;

architecture BEHAVIORAL of divcontrol is
begin

with q select
   pulse <= '1' when x"00",
	'1' when x"14",
	'1' when x"28",
	'1' when x"3C",
   '0' when others;

with q select
   rstout <= '1' when x"4D",
   '1' when x"4E",
   '1' when x"4F",
   '0' when others;

with q select
   shift <= '1' when x"03",
	'1' when x"04",
	'1' when x"17",
	'1' when x"18",
	'1' when x"2B",
	'1' when x"2C",
	'1' when x"3F",
	'1' when x"40",
  	'0' when others;

with q select
   ledinc <= '1' when x"49",
	'1' when x"4A",
	'1' when x"4B",
	'1' when x"4C",
  	'0' when others;

with q select
   ledread <= '1' when x"41",
	'1' when x"42",
	'1' when x"43",
	'1' when x"44",
  	'0' when others;


end BEHAVIORAL;


Article: 99089
Subject: Re: Disk/LCD defect tolerant models for FPGA sales
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 03:07:13 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> A few points:
> 1)  The routing structure is many times larger than the LUT structures.
>   A defect in the FPGA is far more likely to show up in the routing
> structure, and it may not be a hard failure.

Very true. Having been responsible for both factory level burnin
testing and field testing, intermittants are by far the toughest nut to
crack as they seldom show up at the ATE station.

> 2)  The testing only identifies bad devices.  It does not isolate or map
> the exact fault, to do so would add considerably to the tester time for
> a part that can't be sold at full price anyway.

Good software based diagnostics generally attempt issolation to a
component set. Which in the FPGA sense, would include searching for the
specific resource set that fails. I generally see design for testing to
use ATE for screening of dangerous hard failures (power faults) and
completely dead devices.

> 3) Defect map dependent PAR is necessarily unique to each device with a
> defect, so you wind up not being able to use the same bitstream for each
>   copy of a product.  Fine for onesy-twosy, but a nightmare for anything
> that is going into production.  The administration cost would far exceed
> the savings even if you get the parts for free.

Production in an RC world ... not problem. Production for an embedded
design that is not defect aware a complete nightmare.  Designing for
test, desiging for defect management, I believe is not an option ...
even for embedded.

> 4)  Each part would need to come with a defect map stored electronically
> somewhere.  Since the current parts have no non-volatile storage, that
> means a separate electronic record has to be kept for each part.  This
> is expensive to administer for everyone involved from the manufacturer,
> the distributors, and the end user.  Again, the administration costs
> would overshadow any savings for parts with a reasonable yield.

Seems that it can be completely transparent with very very modest
effort. The parts all have non-volatile storage for configuration. If
the defect list is stored with the bitstream, then the installation
process to that storage just needs to read the defect list out before
erasing it, merge the defect list into the new bit stream, as the part
is linked (place and routed) for that system.
With a system level design based on design for test, and design for
defect management, the costs are ALWAYS in favor of defect management
as it increases yeilds at the mfg, and extends the life in the field by
making the system tollarent of intermittants that escape ATE and life
induced failures like migration effects.

> 5) Timing closure has to be considered when re-spinning an FPGA
> bitstream to avoid defects.  In dense high performance designs, it may
> be difficult to meet timing in a good part, much less one that has to
> allow for any route to be moved to a less direct routing.

In RC that is not a problem ... it's handled by design. For embedded
designs, that is a different problem.


Article: 99090
Subject: Re: for all those who believe
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 03:08:42 -0800
Links: << >>  << T >>  << A >>

austin wrote:
> That is a very strange thought.
> 
> Both Peter and I are "retire-adverse."

But is your employeer?


Article: 99091
Subject: Re: for all those who believe in ASICs....and can't stop ranting
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 03:23:13 -0800
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> Are we continuing this thread until John (aka Mr Toy) has made a
> complete fool of himself ?
> His ranting is neither coherent nor entertaining or amusing anymore.
> Peter Alfke

Your turn.


Article: 99092
Subject: Re: Urgent Help Needed!!!!!
From: "JJ" <johnjakson@gmail.com>
Date: 20 Mar 2006 05:25:24 -0800
Links: << >>  << T >>  << A >>
That is complete nonsense.

The OP comes from a country in which English is widely used claiming
more good speakers than the country that gave it to them. Nobody is
offended  by the minor grammatical and typos error some of us make more
often than others. People don't hear accents here.  I also get
confused between UK and US English, and often use google for spell
checking.

What this thread is about is very simple, "deliberate" unnecessary
destruction of a language that can only confuse people who trully are
having problems learning the language. If all they see is the terse
cell phone encodings, that is hardly going to help them with their own
English, they might even come to think that i,u,ur are acceptable.

If I were to visit any non English speaking country and talk or write
in jibberesh as if I should be understood when I could as easily speak
or write better, I wouldn't expect a great reception. I am also quite
used to having my own written English corrected by non native speakers.

But we are just repeating ourselves.

John Jakson


Article: 99093
Subject: Re: Urgent Help Needed!!!!!
From: fpga_toys@yahoo.com
Date: 20 Mar 2006 06:24:07 -0800
Links: << >>  << T >>  << A >>

JJ wrote:
> That is complete nonsense.

It's a VERY common form of TECH SPEAK used on every BBS, Chat, and IRC
system.

It doesn't matter where the poster was from, the nature and intent of
the post would make any non-english poster firmly feel unwelcome.

Maybe we need to be politically correct in this global formun, at take
the top 52 languages and use one a week, or month, or year.

John


Article: 99094
Subject: What are the major difference between MXE 6.0 and MXE 5.7?
From: "Novice" <novice@novice.com>
Date: Mon, 20 Mar 2006 22:27:55 +0800
Links: << >>  << T >>  << A >>
I am using the MXE 5.7 with free license, but sometimes it seems unable to 
handle
too large designs. What are the main upgrades of MXE 6.0?

TIA



Article: 99095
Subject: Looking for a V4FX development board
From: "Georgios Pouiklis" <gpouikli@ee.duth.gr>
Date: Mon, 20 Mar 2006 06:34:25 -0800
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a V4FX devel. board, with both optical (e.g. SFP)MGTs and ddr2 memory (especially one with DIMM modules, if two ddr2 busses are available even better).

Can someone suggest something, I haven't found one incorporating both features.

Thanks, George

Article: 99096
Subject: Re: Urgent Help Needed!!!!!
From: John_H <johnhandwork@mail.com>
Date: Mon, 20 Mar 2006 14:34:44 GMT
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:
> The cultural and class bigotry in this tread is appalling. If some of
> the OLD TIMERS in this group wish to be mentors, they first need to
> learn to be a bit more flexible, and not riddicule and insult others at
> the drop of a hat.

Flexibility is in the eye of the beholder.  It's insulting to see 
language - any language - needlessly butchered.  As many others on this 
forum, I have sincere respect for those who don't know the nuances of 
English but try to communicate in this second (or third or forth) 
langauge.  There is no need for mentors to put up with disrespect. 
Disrespect is what it is, plain and simple.  Bcoz u cant tolr8 r 
annoyance with eye cancer doesn't mean we need to be tolerant of 
purposful butchering.  If the post is MADE from a cell phone, I'd 
personally be willing to give some leeway.

Given the strong support from so many who don't regularly contribute to 
threads of a more personal nature, the shorthand just isn't welcome. 
I've seen now 2 posts in mild support of gibberish, the majority against.

> This is not a native US born and educated form. It has many posters
> struggling to communicate in a non-native foriegn language based on
> language skills learned in chat rooms, IRC's, and a number of other
> forums.

If we had a hint that the poster wasn't an english speaker, the 
tolerance would be greater; the posts read as if the individual was a 
native english speaker.  If English is not their first language and chat 
is the second language, I applaud the original poster for being able to 
otherwise communicate rather well; I seriously doubt this is the case.

> This list also includes posters like myself that are dyslexic, and find
> it extremely difficult to proof our own writings because misspellings,
> transpositions, missing/wrong characters and words are all "corrected"
> incorrectly by our brains as we reread our own work.

Misspellings and transpositions are easy to deal with especially for 
anyone who has dealt with a tremendous amount of chat and email over the 
development of the internet.  The issue is a lack of desire to put any 
respect into the communication.

> Spelling and grammar flame wars like this thread are nothing short of
> bigotry.

The issue isn't spelling (there were no unintentional spelling 
mistakes).  The issue isn't grammar (the "cool" chat appreviations were 
in well constructed sentences).  The issue is about communication and 
any level of respect for the communication medium - the English 
langauge.  Dyslexics and foreign language posters still have respect for 
language.


SO, are you trying to agitate again this late in the thread?  Are you 
trying to be the devils' advocate to help out the mentors on this board 
or are you becoming an ass again?  I do love to start my morning being 
pissed; if that's your goal, you succeed rather well.

Article: 99097
Subject: SMTP
From: leibnizster@gmail.com
Date: 20 Mar 2006 06:37:42 -0800
Links: << >>  << T >>  << A >>
hello,


I have to do a program in VHDL which sends email via the SMTP protocol
on the Pegasus board. I have to use the XILINX ISE and the EDK. I
haven't worked with the EDK before, so any help would be welcomed.

thank you


Article: 99098
Subject: DDS
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Mon, 20 Mar 2006 08:46:29 -0600
Links: << >>  << T >>  << A >>
I would like to implement a DDS on a Spartan device. Here are is my spec.
Clocked at 200MHz. Max Output of 80MHz. 1uHz increments. Is this possible
on a Spatan?

Cheers

Jon

Article: 99099
Subject: Re: What are the major difference between MXE 6.0 and MXE 5.7?
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Mon, 20 Mar 2006 07:23:40 -0800
Links: << >>  << T >>  << A >>
Novice wrote:
> I am using the MXE 5.7 with free license, but sometimes it seems unable to 
> handle
> too large designs. What are the main upgrades of MXE 6.0?

None of the free versions are usable with large designs.
Some low cost simulators are usable:
http://groups.google.com/groups/search?q=modelsim+altera+crippled+simili
Call Mentor to evaluate other versions.


        -- Mike Treseler



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