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 43275

Article: 43275
Subject: Re: Virtex2 placement problem
From: Martin <>
Date: Fri, 17 May 2002 13:51:04 -0800
Links: << >>  << T >>  << A >>
Hi Marcus,

tzhe first idea here that comes to my mind is the difference for the numbering in Virtex-II compared to Virtex. 
In the 'old' Virtex architechture you started in the top left corner and counted down and to the right in rows and columns. Now in the V-II architecture you start in the bottom-left corner and count in a kind of x-y-diagram to the right and upwards.

Check if you still have the old syntax. Previously the syntax would have been something like ...RxCy.S0.
This must be now something like ...XaYb.

My 2 Euro-Cent.

Martin

Article: 43276
Subject: Re: PCI Board Project
From: "Austin Franklin" <austin@dark98room.com>
Date: Fri, 17 May 2002 18:38:47 -0400
Links: << >>  << T >>  << A >>
Hey, these days, I'm just happy to get my arithmetic correct ;-)

"Stephan Neuhold" <stephan.neuhold@xilinx.com> wrote in message
news:3CE52C82.E9F0600D@xilinx.com...
> Yes of course. My mistake. I was looking at the reset signal. Add to this
2^25
> clocks at 33MHz and get 1.0666secs. So, 100ms + 1.0666secs = more than
enough
> time for configuration. Thanks for pointing out the mistake.
>
> Austin Franklin wrote:
>
> > "Stephan Neuhold" <stephan.neuhold@xilinx.com> wrote in message
> > news:3CE4BB8F.A4A8D821@xilinx.com...
> > > Yes, according to the new spec. there should be a time of 100ms
provided
> > before
> > > your device actually needs to be active on the bus.
> >
> > Stephan,
> >
> > I believe the PCI 2.2 spec says in Table 4-6 that it is  2^25 clocks
from
> > RST# high to First configuration Access.  And...since the PCI bus powers
up
> > at 33MHz, no matter what's in the slots (so it can check 66MHz
capability),
> > that would be 0.000_000_030 seconds times 2**25th which I believe is 1
> > second.
> >
> > An issue to be aware of, is that this was not spec'd in the 2.1 and
earlier
> > PCI spec, but...having designed quite a few Xilinx FPGA interfaces, and
them
> > being in thousands of production boards for some near 10 years now, I
have
> > never run into a problem, at least that I've heard of ;-)
> >
> > Austin
>



Article: 43277
Subject: Re: virtex 2 block rams
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 17 May 2002 23:51:43 +0100
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> "word of wisdom"
> I think ( note the cautious wording) that you can eliminate this problem
> by reorganizing your input data, effectively scrambling it, so bit 0 is
> written in one BlockRAM, 1 in the next BlockRAM, etc. I am pretty sure
> this works for 128 bits in 4 BlockRAMs.
> I got a headache figuring it out for 3 BRAMs.
> Maybe I am all wrong, but if it works, it would be really neat...
> Peter Alfke, Xilinx Applications
> ===================================
> shparekh@yahoo.com wrote:
>

I don't think its possible that way. I remember coming to that conclusion
for the 4-5 mapping needed for the old video DRAMs (written 32 bits wide,
extracted 40 bits wide to feed into a Brooktree RAMDAC). What we did then, &
what should work here, is to put the read address through a lookup table
(held in an SRAM and loaded by s/w if my memory serves me right).


Article: 43278
Subject: Re: Reading GSR signal of Spartan-II
From: Scott Schlachter <scott.schlachter@xilinx.com>
Date: Fri, 17 May 2002 15:57:08 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------6446B17197EA822F659997A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Stephanie,
Just happened across your posting.  To drive/monitor GSR, probably best to use the
Startup block as what's already been suggested - although in that case you can only
monitor whatever you use to drive GSR, rather than directly monitoring GSR.
Although it is fairly cumbersome and not asynchronous, if you just want to poll the
status of GSR from time to time, and you also happen to have (or have the ability
of designing in) access to the JTAG port, you can read the output of the "Status
Register", one bit of which will report the GSR status (GSR_B).  See the following
app notes:
http://www.xilinx.com/xapp/xapp188.pdf
http://www.xilinx.com/xapp/xapp151.pdf
Hope that helps,
-Scott S.

Stephanie McBader wrote:

> OK, that I understand.. But what I need is to *read* the GSR net - how can I do
> that?
>
> Still looking out for help :)
>
> - Cross posted to comp.arch.fpga
>
> Best Regards,
>
> Stephanie McBader
> Researcher/Design Engineer
> NeuriCam S.p.A
> Via S M Maddalena 12
> 38100 Trento TN, Italy
> Tel: +39-0461-260552
> Fax: +39-0461-260617
>
> Allan Herriman wrote:
>
> > [snip]
>
> > You can drive GSR (to reset or set every flip flop in the chip) by
> > asserting the GSR input on the startup block at any time.
> >
>
> I earlier wrote:
>
> > >> Hi there,
> > >>
> > >> Apologies if this has come up before - I have searched both newsgroups
> > >> and the Xilinx support website but I have not found *exactly* what I'm
> > >> looking for.
> > >>
> > >> Is it possible to *read* the GSR signal of a Spartan-II FPGA? The
> > >> problem is that we have a system in which a controller must be
> > >> implemented inside the FPGA but which does not provide any form of reset
> > >> signal as an input to the FPGA logic. I have had a look at the
> > >> Spartan-II datasheet and on page 19 there is a waveform describing the
> > >> start-up sequence of the FPGA after programming. The GSR is evidently
> > >> active high and is negated shortly after DONE goes high. I would like to
> > >> be able to use the GSR value as an asynchronous reset input to the logic
> > >> implemented in the FPGA.. How do I do this?
> > >>
> > >> I have seen numerous answers pointing to the STARTUP block, but this
> > >> only has the GSR signal as an *input*! I need to read it somehow and I
> > >> do not know which source to use..
> > >>
> > >> Oh, we're using VHDL by the way (just thought I'd mention it even though
> > >> this *is* comp.lang.vhdl)
> > >>
> > >> Your help would be much appreciated.
> > >>
> > >> Regards,
> > >>
> > >> Stephanie McBader



Article: 43279
Subject: Re: Need Help on FPGA and Spiking Neurons
From: Traveler <eightwings@hotmail.com>
Date: Fri, 17 May 2002 23:10:21 GMT
Links: << >>  << T >>  << A >>
In article <3CE46EE1.79BD05C@yahoo.com>, rickman
<spamgoeshere4@yahoo.com> wrote:

>But the trick to it all is to define what you need in terms of
>arithmetic or logic functions.  Can you do that, or will you need help? 

I appreciate your help but I don't see the relevance of going into
arithmetic or logic functions. What I really want to find out is
whether or not it is feasible to use FPGA to implement a cellular
system that can be programmed to make (or break) an indefinite number
of connections to multiple cells on the fly. I have already read
reports of FPGAs being used to implement neurons with a fixed number
of connections. My neurons do not have on-off states. They send a
1-bit signal to other neurons when their input conditions are
satisfied.

Temporal Intelligence:
http://home1.gte.net/res02khr/AI/Temporal_Intelligence.htm

Article: 43280
Subject: Re: SDRAM pricing
From: amolitor-at@visi-dot-com.com
Date: Fri, 17 May 2002 23:30:28 GMT
Links: << >>  << T >>  << A >>
In article <3CE57484.D9777F38@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>Interesting web site, but these prices are largely irrelevant.  None of
>this is open to me to purchase.  Even after I register, I don't see a
>way to buy.  I expect these prices are for very large orders.  

	You need to get plugged into your local distribution
channels. If you need 1-10 pieces of some part that's not
too expensive (e.g. <$US50?) you can generally get samples
for free.

	If you need a few dozen, you probably have to pay, but
your local distribution channels are (in my experience) pretty
good guys who will try to help out. They want your business,
but the guys I know are willing to go pretty far just for your
goodwill. I've told people that I need ONE part, and I will
NEVER need another one, and they still sample me a couple :)

	If your employer happens to buy lots of parts, you can
probably do even better.


		Andrew


Article: 43281
Subject: Re: SDRAM pricing
From: Jerry Avins <jya@ieee.org>
Date: Fri, 17 May 2002 20:18:23 -0400
Links: << >>  << T >>  << A >>
amolitor-at@visi-dot-com.com wrote:
> 
> In article <3CE57484.D9777F38@yahoo.com>,
> rickman  <spamgoeshere4@yahoo.com> wrote:
> >Interesting web site, but these prices are largely irrelevant.  None of
> >this is open to me to purchase.  Even after I register, I don't see a
> >way to buy.  I expect these prices are for very large orders.
> 
>         You need to get plugged into your local distribution
> channels. If you need 1-10 pieces of some part that's not
> too expensive (e.g. <$US50?) you can generally get samples
> for free.
> 
>         If you need a few dozen, you probably have to pay, but
> your local distribution channels are (in my experience) pretty
> good guys who will try to help out. They want your business,
> but the guys I know are willing to go pretty far just for your
> goodwill. I've told people that I need ONE part, and I will
> NEVER need another one, and they still sample me a couple :)
> 
>         If your employer happens to buy lots of parts, you can
> probably do even better.
> 
>                 Andrew

For the record, Andy, he _is_ his employer.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 43282
Subject: Re: SDRAM pricing
From: amolitor-at@visi-dot-com.com
Date: Sat, 18 May 2002 00:28:34 GMT
Links: << >>  << T >>  << A >>
In article <3CE59DCF.6DEF0AB@ieee.org>, Jerry Avins  <jya@ieee.org> wrote:
> [ re, rickman ]
>For the record, Andy, he _is_ his employer.

	Now that I actually look at the gentleman's signature,
I have a horrible suspicion he could teach me a thing or two about
winkling parts outta distribution.

	My apologies! Didn't mean to come off condescending.

Article: 43283
Subject: Re: RPMs
From: rjshaw@iprimus.com.au (russell)
Date: 17 May 2002 19:01:28 -0700
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3CE55872.3B8BC1F2@andraka.com>...

> Russell wrote:
> 
> > Hi all,
> >
> > I placed various primitives in floor-planner
> > (webpack 4.2, spartan2), then grouped and
> > bound it to make an RPM. I then put it back
> > into the hierarchy window, so that PAR can
> > place the RPM. I also saved the constraints
> > to the .ucf and .mfp files.
> >
> > However, when i open floor-planner after PAR,
> > the group (GRP0) has been placed, but all the
> > primitives have been re-arranged (structure is
> > lost). Has anyone got RPMs to work right?
>
> Yes, but not ones created in the floorplanner and then left
> unplaced.

That may be the case for older tools, but i think a new
feature is that if you 'unplace' an RPM created graphically
in the floor-planner, then PAR should place it itself. It's
in webpack 4.2 help:

  Note:  At this point, you can drag the newly created RPM
  from the Floorplan window to the Design Hierarchy window.
  When you run PAR, the RPM gets placed. If you leave the RPM
  in the Floorplan window, it is locked in place as seen in
  the Floorplan window. 

I've been able to create and place RPMs by modifying the
.ucf file with RLOC and RLOC_ORIGIN, but still have trouble
getting it to work hierarchially. In the help, it says
the RLOC_ORIGIN coordinates are added to all the lower
RLOCs in a macro, then all the RLOCs become LOCs.
However, if i put a LOC on a macro instantiation,
doesn't that do the same thing as an RLOC_ORIGIN?

Article: 43284
Subject: Re: Reading GSR signal of Spartan-II
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Fri, 17 May 2002 22:15:44 -0400
Links: << >>  << T >>  << A >>
Sweir,

Thanks for this response.  It was the most useful and serious response given.
The other responses really did not answer the question as the original poster
(and my echo) stated the inquiry.

Theron Hicks

sweir wrote:

> Stephanie,
>
> I think what you are trying to ask is:
>
> "How do I use the internal global reset in a design that does not have an
> external reset pin?"
>
> If so, then all you need to do is instantiate the ROC ( reset on
> configuration ) component in your design.  You can connect that output to
> RTL that has async reset logic.
>
> Regards,
> "Stephanie McBader" <mcbader@neuricam.com> wrote in message
> news:3CE4AE8C.7016211F@neuricam.com...
> > OK, that I understand.. But what I need is to *read* the GSR net - how can
> I do
> > that?
> >
> > Still looking out for help :)
> >
> > - Cross posted to comp.arch.fpga
> >
> > Best Regards,
> >
> > Stephanie McBader
> > Researcher/Design Engineer
> > NeuriCam S.p.A
> > Via S M Maddalena 12
> > 38100 Trento TN, Italy
> > Tel: +39-0461-260552
> > Fax: +39-0461-260617
> >
> >
> > Allan Herriman wrote:
> >
> > > [snip]
> >
> > > You can drive GSR (to reset or set every flip flop in the chip) by
> > > asserting the GSR input on the startup block at any time.
> > >
> >
> > I earlier wrote:
> >
> > > >> Hi there,
> > > >>
> > > >> Apologies if this has come up before - I have searched both
> newsgroups
> > > >> and the Xilinx support website but I have not found *exactly* what
> I'm
> > > >> looking for.
> > > >>
> > > >> Is it possible to *read* the GSR signal of a Spartan-II FPGA? The
> > > >> problem is that we have a system in which a controller must be
> > > >> implemented inside the FPGA but which does not provide any form of
> reset
> > > >> signal as an input to the FPGA logic. I have had a look at the
> > > >> Spartan-II datasheet and on page 19 there is a waveform describing
> the
> > > >> start-up sequence of the FPGA after programming. The GSR is evidently
> > > >> active high and is negated shortly after DONE goes high. I would like
> to
> > > >> be able to use the GSR value as an asynchronous reset input to the
> logic
> > > >> implemented in the FPGA.. How do I do this?
> > > >>
> > > >> I have seen numerous answers pointing to the STARTUP block, but this
> > > >> only has the GSR signal as an *input*! I need to read it somehow and
> I
> > > >> do not know which source to use..
> > > >>
> > > >> Oh, we're using VHDL by the way (just thought I'd mention it even
> though
> > > >> this *is* comp.lang.vhdl)
> > > >>
> > > >> Your help would be much appreciated.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Stephanie McBader
> >
> >
> >


Article: 43285
Subject: Building a relaxation oscillator with a Xilinx 9536XL
From: l.l.chisholm@paradise.net.nz (Len Chisholm)
Date: Sat, 18 May 2002 02:32:09 GMT
Links: << >>  << T >>  << A >>
Hi all,

One of the Xilinx FPGA demo boards has a relaxation oscillator circuit
attached to a 3000 series FPGA, where there are external RC networks
attached to a pair of cross-coupled I/O blocks.

Is there any reason why this would be a bad idea for a 9536XL ? The
datasheet says that there is 50mV hysteresis on the inputs in the XL
family but not the standard 9500s. I've cobbled a circuit together
which seems to run OK, but I'm looking for any gotchas which I've
overlooked.

I need a not-particularly-accurate clock signal to run a state
machine, and if I can get an oscillator for 'free' then that's a good
thing.

Thanks,

Len Chisholm.

Article: 43286
Subject: Re: virtex 2 block rams
From: shparekh@yahoo.com
Date: 17 May 2002 20:31:02 -0700
Links: << >>  << T >>  << A >>
I'll write again what I earlier wrote to Peter.

I think this is possible if the ratio of portA/portB is a root of 2. 
Because, the port size on brams is in power of 2.
Therefore, it works in case of 128(wider port)/32(narrower port) = 4
(# of brams).  i.e. scramble the 96bits in groups of 32(narrower
port)/4(# of brams) = 8 bits.

In my case, (portA = 96)/(portB = 32) = 3.  This will not work without
going through some hassle which I think will be more than using a mux
or tristate bufs.

Thanks all for feedback.
-sanjay

Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3CE5897F.94811CA@algor.co.uk>...
> Peter Alfke wrote:
> 
> > "word of wisdom"
> > I think ( note the cautious wording) that you can eliminate this problem
> > by reorganizing your input data, effectively scrambling it, so bit 0 is
> > written in one BlockRAM, 1 in the next BlockRAM, etc. I am pretty sure
> > this works for 128 bits in 4 BlockRAMs.
> > I got a headache figuring it out for 3 BRAMs.
> > Maybe I am all wrong, but if it works, it would be really neat...
> > Peter Alfke, Xilinx Applications
> > ===================================
> > shparekh@yahoo.com wrote:
> >
> 
> I don't think its possible that way. I remember coming to that conclusion
> for the 4-5 mapping needed for the old video DRAMs (written 32 bits wide,
> extracted 40 bits wide to feed into a Brooktree RAMDAC). What we did then, &
> what should work here, is to put the read address through a lookup table
> (held in an SRAM and loaded by s/w if my memory serves me right).

Article: 43287
Subject: Re: Building a relaxation oscillator with a Xilinx 9536XL
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 18 May 2002 16:06:53 +1200
Links: << >>  << T >>  << A >>
Len Chisholm wrote:
> 
> Hi all,
> 
> One of the Xilinx FPGA demo boards has a relaxation oscillator circuit
> attached to a 3000 series FPGA, where there are external RC networks
> attached to a pair of cross-coupled I/O blocks.
> 
> Is there any reason why this would be a bad idea for a 9536XL ? The
> datasheet says that there is 50mV hysteresis on the inputs in the XL
> family but not the standard 9500s. I've cobbled a circuit together
> which seems to run OK, but I'm looking for any gotchas which I've
> overlooked.
> 
> I need a not-particularly-accurate clock signal to run a state
> machine, and if I can get an oscillator for 'free' then that's a good
> thing.

Len,

Things to watch for:

Current consumption can be high, as the IP buffers spend time
quasi-linear.

Osc can be prone to 'frequency grabbing' due to ground noise, and Voh
level 
can often be 'noisy'. 
Choose pins nearest a GND terminal, and away from any async signals.

Check you have any lock-up state covered. Cross coupled Osc can have a 
illegal state. Three terminal ones are better behaved, but use 3 pins,
not 2.

For a 3 terminal OSC, best topology is NOT two inverters, but a Non-Inv
followed
by INV, as that makes regen feedback occur first.

 A Zero pin 'for free' OSC can be made using a 'foldback chain' in 
something like ATF1502ASVL. Because it is 100% buried, it also has good
EMC
characteristics, and does not use macrocells.

-jg

Article: 43288
Subject: Re: SDRAM pricing
From: hermanza8@netscape.net (Herman Oosthuysen)
Date: 17 May 2002 21:32:53 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3CE57484.D9777F38@yahoo.com>...
> Matt H wrote:
> > 
> > "rickman" <spamgoeshere4@yahoo.com> wrote in message
> > news:3CE54C57.E05567F8@yahoo.com...
> > > I am seeing the price of 256 Mbit SDRAM at about $20 to $25.  This is
> > > about 8 times what it costs for the same amount of memory on DIMMs.  I
> > > know that quantity makes a difference, but I can buy a single 256 MByte
> > > DIMM for $22 or I can buy 1k 32 MByte SDRAM chips at $20 each.  This
> > > seems very excessive.
> > >
> > > Anyone getting better pricing on 16x16 SDRAM?
> > >
> > >
> > > --
> > >
> > > Rick "rickman" Collins
> > >
> > > rick.collins@XYarius.com
> > 
> > Hi Rick,
> > Check out this community:
> > http://www.dramexchange.com/default.asp
> > It looks like the current price for 16x16 is about $8.  Perhaps you can find
> > a better price.
> > Good Luck,
> > Matt
> 
> Interesting web site, but these prices are largely irrelevant.  None of
> this is open to me to purchase.  Even after I register, I don't see a
> way to buy.  I expect these prices are for very large orders.  
> 
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Unless you are a large buyer, you are hooped.  In my experience, an
Asian factory can get stuff at half the price we are quoted for 10,000
quantities!

Cheers,

Herman
http://www.AerospaceSoftware.com

Article: 43289
Subject: Re: virtex 2 block rams
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 18 May 2002 04:41:27 -0000
Links: << >>  << T >>  << A >>
>I think this is possible if the ratio of portA/portB is a root of 2. 
>Because, the port size on brams is in power of 2.
>Therefore, it works in case of 128(wider port)/32(narrower port) = 4
>(# of brams).  i.e. scramble the 96bits in groups of 32(narrower
>port)/4(# of brams) = 8 bits.
>
>In my case, (portA = 96)/(portB = 32) = 3.  This will not work without
>going through some hassle which I think will be more than using a mux
>or tristate bufs.

I don't know how this fits into your tradeoffs, but I think you
can make Peter's suggestion work if you are willing to throw away
1/4 of your memory.

Write 4x32 bits.  Put garbage or a constant in the top word.
When reading, read words 0, 1, 2, but skip over word 3.

You can get that memory back if you are willing to put muxes
on the input side of the RAMs.  That's ugly, but it might be
less ugly than putting them on the outputside  - depends on how
your design works out.

-- 
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: 43290
Subject: P&R times
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 18 May 2002 10:04:16 +0200
Links: << >>  << T >>  << A >>
Hello,

we have a design with a XCS30XL, which is utilized to 96%.
Bad thing is, P&R takes about 30!!! minutes on a Athlon 500. The design uses
a lot of TBUFs and DP-RAMS.
Are there some tricks to speed up things? Some floorplanning? Timing
constraints?

--
MfG
Falk




Article: 43291
Subject: Re: virtex 2 block rams
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 18 May 2002 11:27:19 +0100
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> >I think this is possible if the ratio of portA/portB is a root of 2.
> >Because, the port size on brams is in power of 2.
> >Therefore, it works in case of 128(wider port)/32(narrower port) = 4
> >(# of brams).  i.e. scramble the 96bits in groups of 32(narrower
> >port)/4(# of brams) = 8 bits.
> >
> >In my case, (portA = 96)/(portB = 32) = 3.  This will not work without
> >going through some hassle which I think will be more than using a mux
> >or tristate bufs.
>
> I don't know how this fits into your tradeoffs, but I think you
> can make Peter's suggestion work if you are willing to throw away
> 1/4 of your memory.
>
> Write 4x32 bits.  Put garbage or a constant in the top word.
> When reading, read words 0, 1, 2, but skip over word 3.
>

In that case what we would have for the read side is:

BRAM address = read_addr / 3

BRAM select = read_addr % 3

Maybe I'm thinking of the case where the read address is random though. If
reading is always sequential then its easy.

Another approach, if there are 2 clocks available for each write, might be to use
a 64 bit wide input port:

input address 0 ->  ram address = 0: words 0, 1
                              ram address = 1: word 2 into lower

input address 1 -> ram address = 1: word 0 into upper
                             ram address = 2: words 1,2

Then the pattern repeats. For each even/odd pair of input addresses the first ram
address is

    3 * (input address/2)

which can be done either via a lookup table or the Virtex-2 h/w multiplier.

This approach would be less costly if the input went 128/256 bits wide since then
a 2 clock write is needed only on 1/2 or 1/4 of the incoming writes.

Note that if not enough clocks are available at the input speed you could always
use a DCM to generate a x2 clock (or x1.5 @128 bits or ...).


Article: 43292
Subject: Re: PCI Board Project
From: j.duran@teleline.es (Josep Duran)
Date: Sat, 18 May 2002 10:56:06 GMT
Links: << >>  << T >>  << A >>
<Falk.Brunner@gmx.de> wrote:
>> Spartan II
>> might need to get me some FPGAs for my own board in the sort-of-near
>> future. Is there any place to get them in < 10 quantity nowadays?
>
>Sure.
>
>www.nuhorizons.com
>

The '.de' in your signature made me believe that nuhorizons was
selling the SpartanII to Europe, which is not the case. They only sell
Xilinx parts to USA and Canada.
OTOH seems like digikey is now selling some parts in qty=1

Josep Duran.



Article: 43293
Subject: Re: Reading GSR signal of Spartan-II
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Sat, 18 May 2002 13:30:57 GMT
Links: << >>  << T >>  << A >>
On Fri, 17 May 2002 22:11:14 -0400, "Theron Hicks (Terry)"
<hicksthe@egr.msu.edu> wrote:

>
>--------------C946C7C3EF3D55C2B62DC7EA
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Allan,
>    Thanks for your response.  I will comment below.
>
>Allan Herriman wrote:
>
>> On Thu, 16 May 2002 18:20:21 -0400, "Theron Hicks (Terry)"
>> <hicksthe@egr.msu.edu> wrote:
>>
>> >I would also be interested in this.  I know that I can use the ISE software
>> >to set initial conditions but my device has a lot of filpflops to set/reset
>> >and connecting a "master reset" input to the GSR output would be just the
>> >trick  to initializing everything.  This assume that the GSR is activated at
>> >every power up event.
>>
>> You really should read the datasheet.
>
>I did.  When I read it I got the impresion that the startup block uses an input
>signal to trigger the GSR input to the flipflops.  It was not apparent as to how
>one can control whether the GSR acts as a set or a clear.  In my case I need to
>set the initial state of condition of several dozen flipflops.  While the
>constraints editor allows one to set the initial condition of flipflops, this is
>quite complex when the systen consists of several dozen flipflops.  This is
>especially true if these flipflops are within a EDIF file or other similar
>device.  (For example, the KCPSM microcontroller.)  In this case, the designer
>may be totally ignoant as to what the flipflops are doing.  An incorrect starting
>condition could result in a non-functioning design.  I have designed in an
>ansychronous master reset in the design.  I would like to set my design to the
>corect initial conditions via the internally generated GSR signal.

Hi Theron,

You don't need to have the reset signal in your source code (or your
EDIF) for the GSR to take effect!
GSR is *always* connected to all flip flops, and *always* driven
during configuration.

Whenever GSR is active a flip flop is forced to either 1 or a 0,
determined by the INIT property of that flip flop.
You can apply the INIT property to a flip flop directly, or you can
let the tools infer it.  INIT inferrence will require coding a GSR
though.  Since the xilinx flip flops don't have independently
programmable async and sync set or reset, applying a sync reset or set
to a flip flop will indirectly determine the value forced when GSR is
active.
If there is no INIT specified in the EDIF, the back end tools (map, I
think) will give it a default INIT value of 0.

Yet another way to specify the initial value is to use one of the
xilinx library elements that has a set or reset input, e.g. FDS (D
flip flop with set input).  Flip flops with reset inputs go to 0 when
GSR is active, and flip flops with set inputs go to 1 when GSR is
active.

It is always good practice to have an async reset (or set) signal in
your source code so that the simulation and synthesis behaviours
match.

The better synthesis tools will realise that the async reset signal in
your source code is actually the same as GSR, and not bother to put it
in the EDIF.  Even if it is in the EDIF, the back end tools (map,
again) will strip it out so that it doesn't waste general purpose
routing resources.
The synthesis tool will recognise that your reset signal is the same
as GSR by:
1.  tracing it to the GSR input on a startup block, or
2.  tracing it to the output of a POC block.

(NB I can't guarantee that all synthesis tools will follow these rules
exactly.)

If your fpga has an external reset pin, then I recomend connecting
that pin to the GSR input of the startup block, and also to the reset
signal in your source code.
If you don't have an external reset pin, use the POC block to provide
a reset during simulation.
You should always have either a startup block or a POC block in the
top sheet of your design.

My designs almost always have a reset pin (and a startup block) and I
find it useful to highlight that net in fpga editor.  If it goes from
the pin to anything other than the startup block I have made a mistake
in my source code somewhere.  (One exception would be the DLL reset
inputs, and any other fpga resources that aren't connected to the
dedicated GSR net.)


Gotcha:
If you don't specify a reset value in your source code, the default
will be 0, right?
Wrong.  You have not defined the initial value, so the synthesis tool
can do whatever it wants.  In particular, it can use the synchronous
set or reset input on a flip flop for logic reduction, potentially
saving a LUT.  If it needed to use the set input, then the flip flop
value will be 1 after GSR.
(There's a popular synthesis tool that will sometimes do this even if
you do specify a reset value, but that's a bug.  The suppliers of that
tool have asked not to be mentioned by name.  Moral: gate level
functional simulation is a good thing.)

Another Gotcha:
The GSR signal is asynchronous to your clocks and has skew.  Your
state machine may not get reset to the value you think it should get
because of (1) metastability problems and (2) skew.
There is no guarantee that all flip flops in your design get released
from GSR in the same clock cycle.  Indeed, for fast clocks (hundreds
of MHz) it is likely that some flip flops could come out of GSR a few
clocks before others.
So, for any state machine that you really care about (often you don't)
you should add some sort of *synchronous* reset or enable signal to
make sure it starts correctly.
The GSR net is also slow, so tricks like synchronising it to the clock
with an SRL16 (which isn't affected by GSR) won't work at realistic
clock speeds.
Note that it is not easy to find these sorts of problems in
simulation.

>> GSR is the output of the startup block.  GSR connects to every flip
>> flop in the chip, whether you have coded it that way or not.  GSR uses
>> a dedicated routing resource that you can't see in the tools (e.g.
>> fpga editor).
>>
>
>So how does the software know what I want to use it to set or reset my
>flipflops?  (Other than the constraints editor?)

Either of these should work:
1.  You have applied an INIT atribute to the flip flop, either in your
source code or in the constraints file.
2.  You have used a flip flop with a set or reset input (either async
or sync).  You could either infer or instantiate such a component.

Here's an example of inferring a flip flop with an aysnc reset:

label : process (my_reset, clk)
begin
  if my_reset = '1' then
    sig <= '0'
  elsif rising_edge(clk) then
    if clock_enable = '1' then
      sig <= something;
    end if;
  end if;
end process label;

Note that this flip flop will get reset when GSR is active, *even if
the my_reset signal in that code wasn't connected to GSR* (although it
should be - I'm a big hater of async design in FPGAs).

One exception to the above would be if you had tied the my_reset
signal in the code to '0', which would cause the synthesis tool to
strip it out.  Don't do that.

BTW, all processes meant to infer flip flops should look something
like the above example.  This should be in your VHDL coding style
guide.


I'm not sure if I fully understand the questions, but I hope this has
helped in some way.

Regards,
Allan.

Article: 43294
Subject: Re: xilinx foundation 2.1 RPC problem on win2000
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Sat, 18 May 2002 16:03:31 +0200
Links: << >>  << T >>  << A >>
"Brad" <hunter@dementedhampsters.com> ha scritto nel messaggio
news:Xns920F884805AAFdementedhampsters@216.146.128.7...

> Pcm  :Automation cause an exception, exit code 80010104
> Pcm  :RPC could not call the server or could not return
> the results of
> calling the server
> Pcm  :Automation caused and exception, exit code 800706BA
> Pcm  :The RPC server is unavailable.

It also happened to me. I solved the problem by expanding the
environment variables; for example if you have something like:

XILINX=c:\fndtn
PATH=[your path];%XILINX%

Expand it as:

PATH=[your path];c:\fndtn

Anyway, check the Xilinx support site; I found the fix there, insert the
RPC exit code as search key.


P.S. Foundation 2.1i is indeed a little old, but I find it *much* better
than ISE. I downgraded to it...

--
Lorenzo



Article: 43295
Subject: Re: Reading GSR signal of Spartan-II
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Sat, 18 May 2002 10:28:13 -0400
Links: << >>  << T >>  << A >>
Thanks,
That clarifies things a lot.
Theron

Allan Herriman wrote:

> On Fri, 17 May 2002 22:11:14 -0400, "Theron Hicks (Terry)"
> <hicksthe@egr.msu.edu> wrote:
>
> >
> >--------------C946C7C3EF3D55C2B62DC7EA
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >Allan,
> >    Thanks for your response.  I will comment below.
> >
> >Allan Herriman wrote:
> >
> >> On Thu, 16 May 2002 18:20:21 -0400, "Theron Hicks (Terry)"
> >> <hicksthe@egr.msu.edu> wrote:
> >>
> >> >I would also be interested in this.  I know that I can use the ISE software
> >> >to set initial conditions but my device has a lot of filpflops to set/reset
> >> >and connecting a "master reset" input to the GSR output would be just the
> >> >trick  to initializing everything.  This assume that the GSR is activated at
> >> >every power up event.
> >>
> >> You really should read the datasheet.
> >
> >I did.  When I read it I got the impresion that the startup block uses an input
> >signal to trigger the GSR input to the flipflops.  It was not apparent as to how
> >one can control whether the GSR acts as a set or a clear.  In my case I need to
> >set the initial state of condition of several dozen flipflops.  While the
> >constraints editor allows one to set the initial condition of flipflops, this is
> >quite complex when the systen consists of several dozen flipflops.  This is
> >especially true if these flipflops are within a EDIF file or other similar
> >device.  (For example, the KCPSM microcontroller.)  In this case, the designer
> >may be totally ignoant as to what the flipflops are doing.  An incorrect starting
> >condition could result in a non-functioning design.  I have designed in an
> >ansychronous master reset in the design.  I would like to set my design to the
> >corect initial conditions via the internally generated GSR signal.
>
> Hi Theron,
>
> You don't need to have the reset signal in your source code (or your
> EDIF) for the GSR to take effect!
> GSR is *always* connected to all flip flops, and *always* driven
> during configuration.
>
> Whenever GSR is active a flip flop is forced to either 1 or a 0,
> determined by the INIT property of that flip flop.
> You can apply the INIT property to a flip flop directly, or you can
> let the tools infer it.  INIT inferrence will require coding a GSR
> though.  Since the xilinx flip flops don't have independently
> programmable async and sync set or reset, applying a sync reset or set
> to a flip flop will indirectly determine the value forced when GSR is
> active.
> If there is no INIT specified in the EDIF, the back end tools (map, I
> think) will give it a default INIT value of 0.
>
> Yet another way to specify the initial value is to use one of the
> xilinx library elements that has a set or reset input, e.g. FDS (D
> flip flop with set input).  Flip flops with reset inputs go to 0 when
> GSR is active, and flip flops with set inputs go to 1 when GSR is
> active.
>
> It is always good practice to have an async reset (or set) signal in
> your source code so that the simulation and synthesis behaviours
> match.
>
> The better synthesis tools will realise that the async reset signal in
> your source code is actually the same as GSR, and not bother to put it
> in the EDIF.  Even if it is in the EDIF, the back end tools (map,
> again) will strip it out so that it doesn't waste general purpose
> routing resources.
> The synthesis tool will recognise that your reset signal is the same
> as GSR by:
> 1.  tracing it to the GSR input on a startup block, or
> 2.  tracing it to the output of a POC block.
>
> (NB I can't guarantee that all synthesis tools will follow these rules
> exactly.)
>
> If your fpga has an external reset pin, then I recomend connecting
> that pin to the GSR input of the startup block, and also to the reset
> signal in your source code.
> If you don't have an external reset pin, use the POC block to provide
> a reset during simulation.
> You should always have either a startup block or a POC block in the
> top sheet of your design.
>
> My designs almost always have a reset pin (and a startup block) and I
> find it useful to highlight that net in fpga editor.  If it goes from
> the pin to anything other than the startup block I have made a mistake
> in my source code somewhere.  (One exception would be the DLL reset
> inputs, and any other fpga resources that aren't connected to the
> dedicated GSR net.)
>
> Gotcha:
> If you don't specify a reset value in your source code, the default
> will be 0, right?
> Wrong.  You have not defined the initial value, so the synthesis tool
> can do whatever it wants.  In particular, it can use the synchronous
> set or reset input on a flip flop for logic reduction, potentially
> saving a LUT.  If it needed to use the set input, then the flip flop
> value will be 1 after GSR.
> (There's a popular synthesis tool that will sometimes do this even if
> you do specify a reset value, but that's a bug.  The suppliers of that
> tool have asked not to be mentioned by name.  Moral: gate level
> functional simulation is a good thing.)
>
> Another Gotcha:
> The GSR signal is asynchronous to your clocks and has skew.  Your
> state machine may not get reset to the value you think it should get
> because of (1) metastability problems and (2) skew.
> There is no guarantee that all flip flops in your design get released
> from GSR in the same clock cycle.  Indeed, for fast clocks (hundreds
> of MHz) it is likely that some flip flops could come out of GSR a few
> clocks before others.
> So, for any state machine that you really care about (often you don't)
> you should add some sort of *synchronous* reset or enable signal to
> make sure it starts correctly.
> The GSR net is also slow, so tricks like synchronising it to the clock
> with an SRL16 (which isn't affected by GSR) won't work at realistic
> clock speeds.
> Note that it is not easy to find these sorts of problems in
> simulation.
>
> >> GSR is the output of the startup block.  GSR connects to every flip
> >> flop in the chip, whether you have coded it that way or not.  GSR uses
> >> a dedicated routing resource that you can't see in the tools (e.g.
> >> fpga editor).
> >>
> >
> >So how does the software know what I want to use it to set or reset my
> >flipflops?  (Other than the constraints editor?)
>
> Either of these should work:
> 1.  You have applied an INIT atribute to the flip flop, either in your
> source code or in the constraints file.
> 2.  You have used a flip flop with a set or reset input (either async
> or sync).  You could either infer or instantiate such a component.
>
> Here's an example of inferring a flip flop with an aysnc reset:
>
> label : process (my_reset, clk)
> begin
>   if my_reset = '1' then
>     sig <= '0'
>   elsif rising_edge(clk) then
>     if clock_enable = '1' then
>       sig <= something;
>     end if;
>   end if;
> end process label;
>
> Note that this flip flop will get reset when GSR is active, *even if
> the my_reset signal in that code wasn't connected to GSR* (although it
> should be - I'm a big hater of async design in FPGAs).
>
> One exception to the above would be if you had tied the my_reset
> signal in the code to '0', which would cause the synthesis tool to
> strip it out.  Don't do that.
>
> BTW, all processes meant to infer flip flops should look something
> like the above example.  This should be in your VHDL coding style
> guide.
>
> I'm not sure if I fully understand the questions, but I hope this has
> helped in some way.
>
> Regards,
> Allan.


Article: 43296
Subject: Re: Need Help on FPGA and Spiking Neurons
From: Ray Andraka <ray@andraka.com>
Date: Sat, 18 May 2002 15:06:14 GMT
Links: << >>  << T >>  << A >>
OK, I didn't realize you were using 1 bit models.  When I dabbled with
neural nets a few years ago, the synapses carried a number to represent
analog behavior, hence there was arithmetic and logic to implement the
linear and non-linear behavior.  In any event, your neuron still needs some
logical function, perhaps a sum and binary threshold.  I was referring to
the model of the neuron.  Mine used a fixed connection network with the
strengths of the connections determined by the learning, where you
apparently want to actually make or break the connections.  You might look
at block memories as the connection matrix.

Traveler wrote:

> In article <3CE46EE1.79BD05C@yahoo.com>, rickman
> <spamgoeshere4@yahoo.com> wrote:
>
> >But the trick to it all is to define what you need in terms of
> >arithmetic or logic functions.  Can you do that, or will you need help?
>
> I appreciate your help but I don't see the relevance of going into
> arithmetic or logic functions. What I really want to find out is
> whether or not it is feasible to use FPGA to implement a cellular
> system that can be programmed to make (or break) an indefinite number
> of connections to multiple cells on the fly. I have already read
> reports of FPGAs being used to implement neurons with a fixed number
> of connections. My neurons do not have on-off states. They send a
> 1-bit signal to other neurons when their input conditions are
> satisfied.
>
> Temporal Intelligence:
> http://home1.gte.net/res02khr/AI/Temporal_Intelligence.htm

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 43297
Subject: Re: RPMs
From: Ray Andraka <ray@andraka.com>
Date: Sat, 18 May 2002 15:41:30 GMT
Links: << >>  << T >>  << A >>
My apologies if this does indeed work in 4.2  I am using mostly 3.3sp8 because the RPMs
don't work properly in the floorplanner for 4.2 for VIrtex/VirtexE, and currently the
majority of our designs are still in Virtex/E.  In 3.3, the bind and unbind works, but the
relative placement is not kept if you unplace the created macro.  I think this was fixed
in 4.x.

russell wrote:

> Ray Andraka <ray@andraka.com> wrote in message news:<3CE55872.3B8BC1F2@andraka.com>...
>
> > Russell wrote:
> >
> > > Hi all,
> > >
> > > I placed various primitives in floor-planner
> > > (webpack 4.2, spartan2), then grouped and
> > > bound it to make an RPM. I then put it back
> > > into the hierarchy window, so that PAR can
> > > place the RPM. I also saved the constraints
> > > to the .ucf and .mfp files.
> > >
> > > However, when i open floor-planner after PAR,
> > > the group (GRP0) has been placed, but all the
> > > primitives have been re-arranged (structure is
> > > lost). Has anyone got RPMs to work right?
> >
> > Yes, but not ones created in the floorplanner and then left
> > unplaced.
>
> That may be the case for older tools, but i think a new
> feature is that if you 'unplace' an RPM created graphically
> in the floor-planner, then PAR should place it itself. It's
> in webpack 4.2 help:
>
>   Note:  At this point, you can drag the newly created RPM
>   from the Floorplan window to the Design Hierarchy window.
>   When you run PAR, the RPM gets placed. If you leave the RPM
>   in the Floorplan window, it is locked in place as seen in
>   the Floorplan window.
>
> I've been able to create and place RPMs by modifying the
> .ucf file with RLOC and RLOC_ORIGIN, but still have trouble
> getting it to work hierarchially. In the help, it says
> the RLOC_ORIGIN coordinates are added to all the lower
> RLOCs in a macro, then all the RLOCs become LOCs.
> However, if i put a LOC on a macro instantiation,
> doesn't that do the same thing as an RLOC_ORIGIN?

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 43298
Subject: Re: HardPath
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sat, 18 May 2002 09:23:10 -0700
Links: << >>  << T >>  << A >>
On Fri, 17 May 2002 05:03:11 GMT, Phil Hays <SpamPostmaster@attbi.com>
wrote:

>
>Xilinx has a interesting idea with "EasyPath", in that they only test
>the parts of a Virtex-2 that are really used in your design, and save
>you some money in the process.
>
>http://www.xilinx.com/prs_rls/silicon_vir/0248easypath.html
>
>Of course, this isn't for everyone.  Some of the designs may reprogram
>devices to new designs frequently.  See:
>
>http://groups.google.com/groups?hl=en&lr=&selm 010731.103308.1239036029.24248%40polybus.com
>
>
>I would like to suggest "HardPath", in that Xilinx produces a more
>completely tested version of their parts, much as the above thread
>discussed.  As you may or may not know, Xilinx's parts are given a
>reasonable test, not a complete test.  This test is good enough for most
>users, however it may not be good enough for users that frequently
>reprogram devices to different designs, or where the cost of failing to
>correctly reprogram a device to a new design would be substantial.  So
>will Xilinx sell a version of their part with a more complete test?
>
>I know that tester time is expensive, and these parts would need to be
>priced higher, and that's ok.  I know that this doesn't guarantee that
>there still may be a defect that has been missed that will cause a
>device to fail work correctly with a new design.  After all, a complete
>test would take longer than practical.  I'm not looking for perfection. 
>I'd just like better odds than what I see now.
>
>Anyone else interested?


How about a yield sort: five categories

A : Perfect
B : something wrong
C, D, E : something else wrong

If you have a design that uses less than 75% of internal resources,
you could target the B,C,D or E version at compile time, buy just
those parts, and everything works. 

'Something wrong' could be by quadrant, mod-4 dead resources, or
something.

I do lots of designs that wind up being pin limited, and use only a
fraction of internal stuff.

John


Article: 43299
Subject: Re: HardPath
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Sat, 18 May 2002 16:48:41 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Our test coverage has increased radically over the last four years,
> and is still increasing.

So?  A complete test isn't practical.  For example, look at the small
switch box on the output of a CLB.  Notice that each of the 8 outputs
from this switch box can be programmed to one of 12 sources.  The number
of legal combinations is somewhat more than (12*12*12... eight times) or
12^8 or 429,981,696 different ways to program that switch box.  At 25 ms
per configuration load, all combinations could be verified in somewhat
more than 124 days.  The larger switch boxes would take rather longer. 
A check for interactions between switch boxes much longer still.  You
simply can't do a complete test, even if you wanted to.

A shorter than complete test needs to make assumptions that may well be
very good, but may well miss specific failures.  Understand, I'm not
looking for perfection.  I'm looking for a better test.  I'd like to buy
it as an off the shelf option, if I could.  I'd rather buy it from
Xilinx, but if not there are other options such as a third party test
house and/or do it in house.


> After all, we "sell" re-configuration, so we have to test for it as
> well.

The cost of a failure to re-configure varies with the application, as
does the odds of finding such an issue.  The standard test flow is good
enough for most users, as: re-programming isn't frequent, and the cost
of failing a reprogramming isn't that high, and the risk of failing will
vary with the application, but is fairly low.  Change any two of those,
however, and a more exhaustive part test becomes valuable.


-- 
Phil Hays



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