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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 23750

Article: 23750
Subject: Re: Virtex-E PCI (MB with 3.3Vsignaling)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 07 Jul 2000 00:17:18 +0100
Links: << >>  << T >>  << A >>


Rickman wrote:

> Rick Filipkiewicz wrote:
> >
> >
> > It would give you wider access to cheap motherboard if you buffer you
> > PCI through QuickSwitch type parts. These, originally supplied by
> > Quality Semiconductor - now part of IDT, are really just a bunch of pass
> > transistors that clamp the output voltage to about Vcc-0.7. The trick is
> > to set down from the nominal 5V to 3.9, they take almost no power so a
> > simple Zener is sufficient. We have solved the 5V/3.3V PCI problem in
> > this way for a long time as do a lot of [older] motherboards.
> >
> > Other suppliers of these type of parts are Pericom & Phillips.
>
> Doesn't this violate the PCI spec in that although you only have one set
> of pins literally on the bus, this part acts as a wire which gives you
> *three* sets of pins electrically on the bus, QuickSwitch in,
> QuickSwitch out and PCI chip in. I expect the added capacitance and stub
> length would screw up a PCI bus and not let you reach the maximum board
> count and/or speed.
>

It certainly violates the PCI plug-in card spec. but we've never put them on a
a PCI card, only on a motherboard where the rules aren't so strict. In this
case I think it just limits the max number of devices in the motherboard
section of the PCI bus. If you look at some old motherboards you will see
these devices used in just this way.

We've successfully run a 4 device motherboard + 3 loaded slots @ 40MHz +
Did this by accident when the wrong link settings to a clock synth chip put it
into a mode where the PCI clock = CPU clock/2 with the CPU clock @83MHz.
Didn't notice for several hours ?!

Article: 23751
Subject: Re: Remedies after the Fathers' Day Massacre
From: Robert Binkley <robert.binkley@spamfreexilinx.com>
Date: Thu, 06 Jul 2000 19:19:52 -0700
Links: << >>  << T >>  << A >>
Simon,

We answered that one too.

MS Excel spreadsheets for the Spartan-II pin-out tables (seven files zipped
together) can now be found on Xilinx's web site at the following URL:

http://www.xilinx.com/products/spartan2/s2_pin.zip

There will be no page links for another week yet. After downloading, you
can save the excel files as text files with different delimiters (see
included readme file). Please let me know if you have any questions.

Robert Binkley
Xilinx Applications


Simon wrote:

> Just leaves the plain-text pin lists to be dealt with...
>
> Peter Alfke wrote in message <395EE570.BFCB052C@earthlink.net>...
> >Two weeks ago, some of you posted strong opinions about the
> >user-unfriendliness of our Applinx CD-ROM.
> >These were your main objections:
> >
> >1. "I don't want to see the Hollywood opening"
> >2. "I refuse to add anything to my pc-installation. Windoze is fragile
> >enough. I just want to read the data sheets and app notes."
> >3."Spartan files should not be locked. I want to cut and paste"
> >4."The CD-ROM should not expire"
> >5."I hate marketing"
> >
> >We took a serious look at these complaints and came up with the
> >following solutions:
> >
> >1. As I posted already: Just hit ESCAPE
> >
> >2. As I posted already: Open the CD with Explorer.
> >Then you can either double-click on the databook.htm file, and open it
> >with Explorer,
> >or you double-click on the databook.pdf files and open them with
> >Acrobat.
> >
> >3. Never again will we copy-protect a data sheet or app note. Spartan
> >info on the web is now unprotected, thanks to your comments.
> >
> >4. The CD-ROM does not "expire". Bad choice of word on our part. You can
> >use any Applinx CD-ROM until your Pentium turns to dust. After six
> >months we just remind you that you might be better off getting a new
> >CD-ROM. Ignore that, if you really feel like it. The same goes for our
> >software. You will then be without updates and support, but nothing will
> >evaporate or die or explode.
> >
> >5. Marketing is a necessary function. You may dislike the style ( as I
> >do I sometimes), but without marketing, there would be no new products.
> >Somebody has to coordinate the introduction, promotion, pricing,
> >production, sales etc. Learn to accept marketing, life without them
> >would be worse.
> >
> >Greetings, and keep designing with Virtex and Spartan.  Neat parts!
> >
> >Peter Alfke, Xilinx Applications
> >
> >
> >
> >

Article: 23752
Subject: Re: VHDL code for LFSR
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 07 Jul 2000 00:43:05 -0400
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> Jan Decaluwe wrote:
> > Rickman wrote:
> > >   process(clock)
> > >     variable feedback: bit;
> > >   begin
> > >     if clock'EVENT and clock='1' then
> > >       feedback := LFSR(3);
> > >       LFSR(0) <= feedback;
> > >       LFSR(1) <= LFSR(0) xor feedback;
> > >       LFSR(2) <= LFSR(1);
> > >       LFSR(3) <= LFSR(2);
> > >     end if;
> > >     q <= LFSR;
> > >   end process;
> > > end;
> > The variable "feedback" doesn't require a FF because it
> > is always assigned before it is used in the process.
> > However, the assignment to signal q in the process is
> > questionable (note that LFSR is not in the sensitivity list)
> > and would typically be placed outside the process as
> > a concurrent signal assignment.
> 
> It would make sense if LFSR were
> localized by defining it as a variable
> instead of a signal.
> 
> In that case the assignment to signal q
> would have to occur before the end of
> the process when the variable goes out of scope.
> Assignments would have to be reordered
> in this case but the code would be easier
> to understand and trace in the debugger.


Mike, 

Your commments sound like you understand this stuff, but I did not get
it. Can you explain in a different way? Are you saying that the code
would be easier to debug if LFSR were defined as a variable within the
process, but in order to do this, the assignments need to be reordered? 

How would you go about reordering them?


-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23753
Subject: Re: HOW DO YOU MANUALLY CONFIGURE AND READ CLB's ON A RUNNING FPGA???
From: Simmler Harald <simmler@ti.uni-mannheim.de>
Date: Fri, 07 Jul 2000 08:43:17 +0200
Links: << >>  << T >>  << A >>
>
> QUESTIONS:
>
> 1.) How do you associate the CLB data that you read out of the FPGA with
> the variables in your VHDL code etc?
>

All used resources of the FPGA design are listed in the logic allocation
file(.ll). There you will find your registers, RAM cells that you are
interested in. Disadvantage in the file is, that e.g. a VHDL Compiler will
replace the original names with his own names which makes the variable
assignment sometimes a bit tricky.

>
> 2.) Can you use the .fnf file that is generated at compile time to tell
> you where the CLB's are associated with the internal variables that do
> not go out to IO pins?  If you can't is there such a file that tells you
> what the CLB data means in terms of your HDL code?
>

The .fnf file is generated by the floor planner. This is one solution which
can be quite timeconsuming and not everyone will do that.
Again, the logic location file tells which logic, register and ram cell is
placed on which resource in the FPGA.


>
> 3.) Does Xilinx have any software that will read the CLB data back and
> show you what the states of the internal variables are as your FPGA is
> running?
>

Have a look at the hardware debugger that is a tool within the foundation or
alliance paket.
Another possibility is the Virtex simulator that comes with JBits. However,
this simulator is not conected to the hardware, but gives you a nice view
into the FPGA.

>
> 4.) Is there any VHDL or Verilog specific instructions that you need to
> use to read the CLB's via boundary scan?
>

When you want to readback only the CLB Ram or the Block Ram, then no
additional logic or blocks are necessary. In case of CLB or IOB Register
readback the "CAPTURE_VIRTEX" component must be instantiated and a clock and
capture signal must be present at that block. Without that block, you can
only verify the bitstream.

I don't know anything about the boundary interface and the necessary
components for that but I would recommend you to use the selected map
interface for configuration and readback, because this is around 8 to 16
times faster than the boundary scann interface. ( example: I need around
12-13ms for config/readback on  XCV400 device )

HS

Article: 23754
Subject: Re: Clock Buffer
From: Jens Hildebrandt <hil@e-technik.uni-rostock.de>
Date: Fri, 07 Jul 2000 09:02:47 +0200
Links: << >>  << T >>  << A >>


Andy Peters wrote:
> 
> Kai Schulze wrote in message <3964734C.D088118F@ee.nec.de>...
> >Hi,
> >
> >I'm working with a XILINX XC40250XV and I have following problem:
> >
> >There is an signal input port and a internal clock should be generated
> >from this signal.
> >How can I push synopsis to create the internal clock buffer for this
> >internal clock automatically.
> >Is there at all a way to say "synopsis do this".
> 
> If that signal is connected to only flip-flop clocks, the tool should infer
> the proper global buffer.
> 
As far as I know Synopsys, this is done only for external clock inputs
(i.e. inputs that drive only flip-flops or that are explicitly set to
pad-type "clock")
For internally generated clocks like the divided-by-X or multiplied-by-Y
or gated-by-Z input clock etc. you have to instantiate a BUFG clock
buffer (for XC4k) and set a dont_touch attribute to it. 
BTW,in that case, if you use the timing constraint "clock" for that
signal you have to define it for the buffer output signal as the Xilinx
tools don't propagate such a constraint through a clock buffer.

Jens
Article: 23755
Subject: RE: 56 independent PN streams
From: "Juan-Luis Lopez" <jl.lopez@REMOVETHIS.ieee.org>
Date: Fri, 7 Jul 2000 09:06:46 +0200
Links: << >>  << T >>  << A >>
Dear Jeff;

The autocorrelation function of a PN only has a peak at the point of t=0
(delay zero), so maybe your application can used 56 PN streams with the
following properties:

1) each stream is the same long secuence (UIT-T O.151 2^23-1, for instance)
2) any pair of streams has a relative shift (delay) of some bits.

For typical telecomm testing applications requiring to fill many timeslots
with "random" uncorrelated signals, this is usually enough.

Apparently this approach seems to require many identical LFSR with different
"start point" or seeds, or a single LFSR plus long shift registers to delay
the streams. But there can be an easier solution.

The trick is based on the following fact: the XOR function of one PN stream
with a replica of itself shifted some bits, is again the same PN stream, but
with a different shift (this can be used in a recursive way).

For instante, in the 2^23-1 sequence, if you XOR a reference sequence with
its 5 bit delayed version, you would get the sequence 18 bits "advanced" to
the reference one. This is trivial, corresponding with the 2^23-1 taps
position.

So, if you already have an LFSR to generate the "basic" PN stream, you have
"for free" many shifted versions of the same PN (23 if you generate the
2^23-1 sequence), and simply XORing the outputs of the LFSR by pairs you can
get some extra delayed sequences. Circuits needed are 23 FF's (sticking with
the 2^23 example) and some tens of 2 input XOR's.

Limitation: I do not know the relationship between any arbitrary delay at
the XOR input and the equivalent delay of the resulting sequence at the
output. Can somebody answer that?

As usual, http://www.xilinx.com/xapp/xapp052.pdf has very useful info
regarding serial PN generators.

Good luck

Juan-Luis
Spain



Article: 23756
Subject: Re: Virtex Demo Board
From: David Gilchrist <david.gilchrist@NOSPAM.com>
Date: Fri, 07 Jul 2000 10:08:39 +0100
Links: << >>  << T >>  << A >>
John Fielden wrote:
> 
> I'm looking for a Virtex demonstration board.  Something that has at >least
> one of the larger parts (1000 or 1000E, and above).  I would prefer an >E
> part.
> 
> Does anyone know who makes such a thing?
> 
> Thanks,
> 
> John Fielden

I know a company Nallatech make a variety of PCI type Virtex development
board.  You could give the web site a try http://www.nallatech.com

Cheers

David G




-- 
To reply replace NOSPAM with BAESYSTEMS

__________________________________

David Gilchrist
Developement Engineer
BAE SYSTEMS

Article: 23757
Subject: Re: Remedies after the Fathers' Day Massacre
From: "Simon" <simonb@tile.demon.co.cuthis.uk>
Date: Fri, 7 Jul 2000 10:27:03 +0100
Links: << >>  << T >>  << A >>
Thanks

Robert Binkley wrote in message <39653E47.D1B09224@spamfreexilinx.com>...

>Simon,
>
>We answered that one too.
>
>MS Excel spreadsheets for the Spartan-II pin-out tables (seven files zipped
>together) can now be found on Xilinx's web site at the following URL:
>
>http://www.xilinx.com/products/spartan2/s2_pin.zip
>



Article: 23758
Subject: Re: Altera's promises unfulfilled???
From: Nial Stewart <nials@sqf.hp.com>
Date: Fri, 07 Jul 2000 10:35:49 +0100
Links: << >>  << T >>  << A >>
"Mike H." wrote:
> 
> Nial Stewart <nials@sqf.hp.com> wrote in message news:39648C8B.B92714AE@sqf.hp.com...
> > I've been interested in evaluating the free versions of Leonardo
> > and FPGA Express that Alera have been promising for the
> > last few months and so have been keeping an eye on their
> > web site.
> >
> > Initially this was announced early this year as being
> > "available in May". Nothing happened, there was no sign
> > of any software then mid May the text mysteriously changed
> > to "available in June". It's not approaching mid July
> > guess what .....
> 
> We received our Leonardo/FPGA Express software from
> Altera about a month ago. Seems to work OK.
> 
> You should have a word with your local Altera rep.
> 
> MH

So they _are_ shipping it free? I was going to download it in 
work and blow a CD rom to take it home :-).


What sort of limitations do these versions of the synthesis
tools have? Are they just locked to Altera devices?

Nial.
Article: 23759
Subject: Re: Altera's promises unfulfilled???
From: "Mike H." <mikeh@spamless.imageproc.com>
Date: Fri, 7 Jul 2000 11:11:52 +0100
Links: << >>  << T >>  << A >>

Nial Stewart <nials@sqf.hp.com> wrote in message news:3965A475.BC87B26A@sqf.hp.com...
> 
> So they _are_ shipping it free? I was going to download it in 
> work and blow a CD rom to take it home :-).
> 
> What sort of limitations do these versions of the synthesis
> tools have? Are they just locked to Altera devices?


Certainly the tools are locked to Altera parts only.
I can't comment about the limitations of the software, since
we normally use Synplicity rather than FPGA Express
or Leonardo and I'm not very familiar with the "full" version
of these tools.

The software arrived via CDROM in the mail.

HTH

Mike H.



Article: 23760
Subject: Re: 56 independent PN streams
From: Jonas Thor <thor@sm.luth.se>
Date: Fri, 07 Jul 2000 13:45:57 +0200
Links: << >>  << T >>  << A >>
Jeff,

Not sure if this will help but you could take a look at my ms thesis
paper at 

http://epubl.luth.se/1402-1617/1999/175/index.html

where I'm using the RAM in Xilinx XC4000XL to generate GPS gold codes.

/ Jonas Thor 

On Thu, 6 Jul 2000 10:56:31 -0700, "Jeff Reeve"
<jreeve@spectralinc.com> wrote:

>I seek advice on the following....
>
>I would like to generate 56 PN streams (using LFSRs)  that exhibit as little
>cross-correlation between each other as possible. Each LFSR will be clocked
>at 100kHz and each LFSR shall have a maximal count of at least 30 seconds.
>(>= 22 taps). Is there a way to select the polynomials to minimize the cross
>correlation? Can this be done with 11 PN streams and then use gold codes to
>generate an additional 45 streams? Any advice, pointers to papers, web sites
>etc. would be much appreciated. I plan on taking advantage of SRL16's of the
>Virtex devices but am struggling with the proper polynomials for the LFSRs.
>
>Many thanks in advance!
>Jeff
>

Article: 23761
Subject: Virtex Debug
From: Michael Boehnel <boehnel@iti.tu-graz.ac.at>
Date: Fri, 07 Jul 2000 13:59:01 +0200
Links: << >>  << T >>  << A >>
I use Xilinx Foundation 2.1i (SP6),  XChecker Cable and Parallel Cable
III (DLC5) under Windows NT. As far as I have understood the Xilinx
documentation no debug facility is given for devices >256k (like Virtex
devices).

1. Did I understand the Xilinx documentation correctly?
2. Does the term "Readback/Verify" in the Xilinx documentation stand for
"read the configuration back without debug facility", that means only to
check if the device was programmed without errors?
3. Is there a possibility to Readback/Verify the Virtex device with
above HW/SW?
4. Is there a possibility to Debug (Readback/Capture) the Virtex device
with above HW/SW?
5. Does anybody have information if debugging is possible under
(hopefully near future) Foundation 3.1i?

Thank you.

Regards,

Michael



Article: 23762
Subject: calculating modulo N
From: Christopher Malkin <malkin@lep-philips.fr>
Date: Fri, 07 Jul 2000 14:52:24 +0200
Links: << >>  << T >>  << A >>
Hello,

I was wondering whether anyone had a neat way of calculating a modulo N.

I am working on implementing an algorithm which requires me to take a
modulo N of a 15 bit number, where N is a 10 bit number that can take
the following values : (48, 64, 212, 220, 228, 424, 432, 440, 848, 856,
864, 752).

I would obviously like to implement this in the most resource economic
way possible and am therefore hoping that there may be a trick that will
allow me to avoid using a division.

Thanks for your ideas,


Chris Malkin



Article: 23763
Subject: Re: calculating modulo N
From: husby@fnal.gov (Don Husby)
Date: Fri, 07 Jul 2000 14:31:16 GMT
Links: << >>  << T >>  << A >>
cdmalkin@iee.org wrote:
> I am working on implementing an algorithm which requires me to take a
> modulo N of a 15 bit number, where N is a 10 bit number that can take
> the following values : (48, 64, 212, 220, 228, 424, 432, 440, 848, 856,
> 864, 752).

You could possibly make use of the relation:

 X % M == (int(X/F) % (M/F)) * F  + (X % F)

where F is a factor of M.  This would allow you to reduce the
operation to division by the prime factors of M.  But, you would
still have to do some divisions (and multiplies).

Probably, you would only want to do this where F is a power of 2.
For example, all of your M's appear to be divisible by 4, so you can easily
take advantage of this to reduce your input from 16 to 14 bits, and your
M's from 10 to 8 bits.





--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 23764
Subject: FPGA Express/Foundation Error 470
From: Jens Popp <njp@rs.uni-siegen.de>
Date: Fri, 07 Jul 2000 16:32:28 +0200
Links: << >>  << T >>  << A >>
Hi,

does anybody know what this is? It happens when I try to invoke a Syntax
Check/ Synthesis of Verilog Code in Foundation.


Initialize DPM...

Checking license...

License check OK.

Source:	G:\FNDTN\ACTIVE\PROJECTS\CPU\mux16.v.
Create project...
DPM Error: Project creation/opening failed.Ausnahmefehler des Servers.  


Thanks
-- 

Jens Popp
Institut fuer Rechnerstrukturen 
Universitaet Siegen
Hoelderlinstr.3
D-57068 Siegen
Germany

TEL  +49 271 740 2376
FAX  +49 271 740 2473
mailto:popp@rs.uni-siegen.de
Article: 23765
Subject: Re: Before and after configuration, are the undefined I/O ports input or
From: Tom Fischaber <tom.fischaber@xilinx.com>
Date: Fri, 07 Jul 2000 09:01:13 -0600
Links: << >>  << T >>  << A >>
For the XC95288:
Before initial powerup, IOs are pulled up with ~10K resistor (http://www.xilinx.com/partinfo/9500.pdf page 15 table 5)
After configuration, unused I/O pins in the XC9500 devices are floating unless an entire function block is empty, then there is a pullup on all I/O in that
function block.  However, you can also select all unused IO to be programmable grounds through the software fitter options.

For the XCV800
Before configuration, all IO are selectable as either floating or pulled up.  This is set by the mode pins, as seen in
http://www.xilinx.com/partinfo/ds003.pdf page 15 Table 9.  The default setting of slave serial (111) has the IO floating.
After configuration, all unused IO are configured as outputs that are tri-stated with a weak pulldown.

Tom Fischaber
Xilinx Applications

wenger wrote:

>     Before and after configuration, are the undefined I/O
> ports of Xilinx CPLD XV95288 and Xilinx FPGA XCV800 inputs
> or outputs? For the Xilinx FPGA XCV800 , we use the default
> mode of M0,M1,M2 , Slave-serial mode.
>
> * Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful

Article: 23766
Subject: Re: PLXMon sources
From: Dominique SZYMIK <szymik@nospam.univ-lille1.fr>
Date: Fri, 07 Jul 2000 17:56:37 +0200
Links: << >>  << T >>  << A >>
Hello,

Well, I think PLXMon is invaluable for hardware debugging. 
I started knowing nothing about driver programming, and
anyway you can't start making a driver before you are sure
your hardware in fair working order.
I lost much time wondering about plug and play configurations
I wasn't able to check, when I started playing with drivers.
Now I am more at ease with drivers, but I still miss the possibility
to fiddle with PLXMon in Windows.

d.

Joel Kolstad wrote:
> 
> "Dominique SZYMIK" <szymik@nospam.univ-lille1.fr> wrote in message
> news:3959B7C8.D7B15412@nospam.univ-lille1.fr...
> > Once PLXTech offered to download the
> > sources of their PCI debuggers,
> > PLXMon and PLXMon95, and phyacc.vxd
> > driver.
> >
> > I would like to see if I can adapt the
> > VxD to win98, it only works for win95.
> 
> Do you really want to do this?  PLXMon is not exactly the world's
> friendliest or most sophisticated program, and although I'm very, very happy
> that PLX includes _any_ sort of initial debugging program like PLXMon, you
> very rapidly get to the point where you need to start writing your own test
> code anyway (either using PLX's API -- which is not particularly fancy, but
> does get the job done -- or your own device driver).
> 
> Heck, in Windows 95/98 you can still do evil things like write directly to
> any memory or port you want to.  You can whip up test programs pretty fast
> in such an environment.
> 
> ---Joel Kolstad

Article: 23767
Subject: Re: BIST in FPGAs?
From: Robert Posey <muddy_take_out_this@raytheon.com>
Date: Fri, 07 Jul 2000 11:51:22 -0500
Links: << >>  << T >>  << A >>


Rickman wrote:
> 
> I disagree that you can't get 100% coverage for test. I am sure that
> Xilinx tests every chip they make 100%. Since the chip is fully
> programmable, I doubt that they needed to design in special test
> circuitry or modes. Certainly this may take more than a single bit file.
> But I am sure that you can test every transistor, every wire and every
> connection in a Xilinx FPGA if you need to do that.
> 
Its an absolute fact you can't get 100% coverage of all the possible failure
modes of an FPGA.  You could get 100% coverage of I/O and Macro cells fairly
easily with special load modes, and even get 100% coverage of logic in each
cell at considerably more expense.  Getting 100% coverage of the RAM in the
part would be a little harder, if not impossible.  How could you test all
the possible BIT leakage combinations in a reasonable time.  You can test the
configuration RAM for a given operational load fairly well by reading back the
down load, but this is by no means a 100% coverage.  If you have a RAM Cell
that floats, it may return the correct value part of the time.  Then you have
the issue that all the RAM and Logic Cells have the potential to leak to 
any cell that is close to in some manner.  RAMs have faults that cause certain
memory cells to change for a correct 0 to a 1, only when all surrounding 
cells are also 1's.  Are these errors very likely no, but the combination of
various leakage errors in data cells, and addressing can amount to well over
1-4% of total RAM failures by failure rate.  In terms of effort, 99.0% coverage
is no where close to 100%.  You will never, ever get 100% coverage of all
possible faults in a real physical system if only for the 10 Million to 1
chance of a Quantum type random event.  I work in Embedded Test, and the
easiest way to stop a BS description of test performance is a statement of
100% Isolation, Detection etc.  

Robert Posey

> As I said in my other post, I once met an engineer who was designing bit
> files for Xilinx chips to do 100% test in military systems. They would
> do a complete test of the hardware every time they powered up. I think
> this was in the XC3000 and XC4000 parts.
>
I work in Military Test Design, and if he was using the Military definition
of test coverage, he should switch to trying to turn Lead Into Gold, since
that is at least possible in theory.  No Military system or specification I
have ever seen claimed to have 100% detection of faults.  Assuming he 
wasn't an idiot, he must of meant that he was testing either all the 
functions implemented in the FPGA, or maybe he was covering all the logic
and RAM cells.  If he is claiming in writing to achieve 100% detection, he
should end up in jail unless he is simply too stupid to know better.
Article: 23768
Subject: Quattus Automatic clock Selection
From: " S.K. Sharma" <sanjay.kumar.sharma@philips.com>
Date: Fri, 7 Jul 2000 17:15:14 GMT
Links: << >>  << T >>  << A >>
Hi All,
Does any one know how to disable the Automatic Clock selection in Quartus.
The problem is it is detecting an input signal as clock in my VHDL design,
which is infact an input signal. I am getting clock skew problem because of
this unwanted clock signal.
a part of report generated by Quartus is attached below...
----------------
Warning: Design has registers and/or memories but no clock assignments.
Quartus will try to detect your clock pins and/or memory enable pins
automatically.
  Info: Node |xclk is assumed to be a clock
  Info: Node |dto_freq_sel is assumed to be a clock
Error: The 1 path(s) clocked by clock |xclk have clock skew larger than the
data delay -- Circuit will not operate.
------------------------------
In this design dto_freq_sel is just a selection input for a MUX.

Thanks in advance.....
Sanjay Sharma



Article: 23769
Subject: Re: Quattus Automatic clock Selection
From: "Xanatos" <deletemeaoe_londonfog@hotmail.com>
Date: Fri, 07 Jul 2000 17:43:51 GMT
Links: << >>  << T >>  << A >>
Hi Sanjay,

Goto Timing Wizard.
Select "No, I want to Assign Clock Myself" (or something like that)
Hit "NEXT"
You can select your clock here.

I suggest that before you do this, Compile the design and Place the design
(but don't do a timing analysis). Then, go back to the timing wizard, and
where it said "Specifiy Clock", goto Post Synth and select your clock.

Any more questions, feel free to email me (aoe_londonfog AT hotmail.com)

Cheers,
Dave

" S.K. Sharma" <sanjay.kumar.sharma@philips.com> wrote in message
news:FxC7xF.9y1@natlab.research.philips.com...
> Hi All,
> Does any one know how to disable the Automatic Clock selection in Quartus.
> The problem is it is detecting an input signal as clock in my VHDL design,
> which is infact an input signal. I am getting clock skew problem because
of
> this unwanted clock signal.
> a part of report generated by Quartus is attached below...
> ----------------
> Warning: Design has registers and/or memories but no clock assignments.
> Quartus will try to detect your clock pins and/or memory enable pins
> automatically.
>   Info: Node |xclk is assumed to be a clock
>   Info: Node |dto_freq_sel is assumed to be a clock
> Error: The 1 path(s) clocked by clock |xclk have clock skew larger than
the
> data delay -- Circuit will not operate.
> ------------------------------
> In this design dto_freq_sel is just a selection input for a MUX.
>
> Thanks in advance.....
> Sanjay Sharma
>
>
>


Article: 23770
Subject: Re: BIST in FPGAs?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 07 Jul 2000 14:13:53 -0400
Links: << >>  << T >>  << A >>
Robert Posey wrote:
> 
> Rickman wrote:
> >
> > I disagree that you can't get 100% coverage for test. I am sure that
> > Xilinx tests every chip they make 100%. Since the chip is fully
> > programmable, I doubt that they needed to design in special test
> > circuitry or modes. Certainly this may take more than a single bit file.
> > But I am sure that you can test every transistor, every wire and every
> > connection in a Xilinx FPGA if you need to do that.
> >
> Its an absolute fact you can't get 100% coverage of all the possible failure
> modes of an FPGA.  

Perhaps we need to qualify this statement. Certainly you can never get
100% coverage for ALL modes of failure. There are time variant failures
the can never be detected by test unless you get lucky. I was referring
to "stuck at" faults. These are the ones that can be systematically
analyzed and accounted for and are most common. Less common are the
"shorted" faults where two nodes are shorted together. Shorted faults do
not result in a defined behavior. When shorted and driving different
states, two nodes may drive a high, a low or an indeterminate value
which has very poorly defined behavior (failing sometimes and not
others). So "shorted" faults can not be systematically analyzed. 

Other faults such as opens will either mimic "stuck at" faults or behave
in a time dependent manner which can not be analyzed. These faults also
are not as common. 

>You could get 100% coverage of I/O and Macro cells fairly
> easily with special load modes, and even get 100% coverage of logic in each
> cell at considerably more expense.  Getting 100% coverage of the RAM in the
> part would be a little harder, if not impossible.  

I don't understand why this is hard. RAM is easy to test by loading and
testing patterns. Each bit can be independently tested with simple
patterns. The bits can be tested against the neighbors with more complex
patterns. The largest array of RAM in a Xilinx part is 4K bits.
Certainly this is not time exhaustive to test?

> How could you test all
> the possible BIT leakage combinations in a reasonable time.  You can test the
> configuration RAM for a given operational load fairly well by reading back the
> down load, but this is by no means a 100% coverage.  If you have a RAM Cell
> that floats, it may return the correct value part of the time.  Then you have
> the issue that all the RAM and Logic Cells have the potential to leak to
> any cell that is close to in some manner.  RAMs have faults that cause certain
> memory cells to change for a correct 0 to a 1, only when all surrounding
> cells are also 1's.  

This is true for standard memory such as SRAMs. But the configuration
memory is made of D FFs and are not co-located with memory from the
other CLBs. So you don't have the same test problems that you have with
SRAM.

> Are these errors very likely no, but the combination of
> various leakage errors in data cells, and addressing can amount to well over
> 1-4% of total RAM failures by failure rate.  In terms of effort, 99.0% coverage
> is no where close to 100%.  You will never, ever get 100% coverage of all
> possible faults in a real physical system if only for the 10 Million to 1
> chance of a Quantum type random event.  I work in Embedded Test, and the
> easiest way to stop a BS description of test performance is a statement of
> 100% Isolation, Detection etc.

Yes, you are right. Is a well known fact that you can NEVER prove that a
system is working by testing. You can only prove that it is not working
by finding faults. But the absence of faults during a test does not
prove the absence of faults in the system. 

But that is not normally what we mean when we talk about coverage of
test sets. We assume a much simplified failure model and test against
that. Other failure modes need to be tested separately. So we would need
a different set of test vectors to test against quantum fluctuations in
the sub-space field.  ;)


-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23771
Subject: Re: Clock Buffer
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 7 Jul 2000 11:39:11 -0700
Links: << >>  << T >>  << A >>
Jens Hildebrandt wrote in message
<39658097.32F7DDE9@e-technik.uni-rostock.de>...
>
>
>Andy Peters wrote:
>>
>> Kai Schulze wrote in message <3964734C.D088118F@ee.nec.de>...
>> >Hi,
>> >
>> >I'm working with a XILINX XC40250XV and I have following problem:
>> >
>> >There is an signal input port and a internal clock should be generated
>> >from this signal.
>> >How can I push synopsis to create the internal clock buffer for this
>> >internal clock automatically.
>> >Is there at all a way to say "synopsis do this".
>>
>> If that signal is connected to only flip-flop clocks, the tool should
infer
>> the proper global buffer.
>>
>As far as I know Synopsys, this is done only for external clock inputs
>(i.e. inputs that drive only flip-flops or that are explicitly set to
>pad-type "clock")
>For internally generated clocks like the divided-by-X or multiplied-by-Y
>or gated-by-Z input clock etc. you have to instantiate a BUFG clock
>buffer (for XC4k) and set a dont_touch attribute to it.
>BTW,in that case, if you use the timing constraint "clock" for that
>signal you have to define it for the buffer output signal as the Xilinx
>tools don't propagate such a constraint through a clock buffer.

Actually, with FPGA Express v3.3, if you create a divided clock, a la:

    clkdiv : process (fastclk, reset) is
    begin
        if reset = 0 then
            slowclk <= '0';
        elsif rising_edge(fastclk) then
            slowclk <= not slowclk;
        end if;
    end process clkdiv;

and you then use slowclk for flops only, it WILL instantiate a clock buffer
and that buffer's output will drive your slow-clocked flops clock inputs.
Unfortunately, the tool gives the output of that buffer a stupid name (such
as N3012) so every time you synthesize, you have to figure out hat the new
name of the slow clock net is and edit your P+R constraints accordingly.

If anyone knows a way to apply a period constraint to flops clocked by the
derived clock without having to figure out what the clock net is called, I'd
love to hear it.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"A sufficiently advanced technology is indistinguishable from magic"
     --Arthur C. Clarke



Article: 23772
Subject: Re: Using LUTs in Virtex with ViewDraw and ViewSim
From: fliptron@netcom.com (Philip Freidin)
Date: 7 Jul 2000 18:49:15 GMT
Links: << >>  << T >>  << A >>
In article <396498F8.6BB201B6@yahoo.com>,
Rickman  <spamgoeshere4@yahoo.com> wrote:
>I'm impressed Philip. You have a lot of stamina!!!
>

or insomnia

>What would it take to get the EQN to simulate? That is, what would the
>vendor need to do? Not that I am planning on ringing anyone's phone to
>ask them to do it. But would this require a Viewlogic change to Viewsim
>and/or VSM? I take it that VSM outputs a Viewlogic specific netlist?

VSM would have to change because it treats '@' as a special character for
passing variable attributes (like @INIT :-) and amazingly has no way to
escape it. '@' can be used in EQN strings. Fortunately the EDIF writer is
not sensitive to this. 

Viewsim would need to be able to handle arbitrary boolean EQN strings.
This I suspect would be nontrivial to do, and hard for them to justify 
given the number of users.


>I'll review my Viewlogic 101 notes. Let's see, there are WIR files and
>SCH files and SYM files. I know that WIR files are generated when you
>"check" a schematic. Ah... there it is, VSM makes a... .vsm file! So I
>guess the EQN would need to be supported by VSM (perhaps translated to
>gates!!?) and maybe also Viewsim. 

Right.

>Hmmm... since these are all text files (nice to have an open format,
>eh?) The EQN to @INIT string could be done by a separate program, no?

Which is what Don's program did, except it converted EQN to new netlist 
stuff with equivalent gates and nets.

>Let VSM generate the .vsm file and then use another program to translate
>the EQN parameter in the VSM file, or if it doesn't get there, read it
>from the WIR file. 

>Rick Collins

I think a better solution would be to run a program on the SCH
directory, searching all SCH files for LUT symbols with EQN attributes. 
When one is found, the EQN is evaluated, and the correct @INIT value is 
set. This would basically be updating your schematic, and you would see 
the new @INIT values next tine you viewed the schematic. After these 
changes, are made, you would need to recreate the files in the WIR 
directory to reflect the changes to the schematics.

Then both the VSM process, and the EDIF writer would work without further 
effort.

Don's program would probably be a good place to start.

Philip Freidin

Article: 23773
Subject: Re: BIST in FPGAs?
From: Robert Posey <muddy_take_out_this@raytheon.com>
Date: Fri, 07 Jul 2000 14:59:34 -0500
Links: << >>  << T >>  << A >>


rickman wrote:
> 
> Robert Posey wrote:
> >
> > Rickman wrote:
> > >
>
> 
> >You could get 100% coverage of I/O and Macro cells fairly
> > easily with special load modes, and even get 100% coverage of logic in each
> > cell at considerably more expense.  Getting 100% coverage of the RAM in the
> > part would be a little harder, if not impossible.
> 
> I don't understand why this is hard. RAM is easy to test by loading and
> testing patterns. Each bit can be independently tested with simple
> patterns. The bits can be tested against the neighbors with more complex
> patterns. The largest array of RAM in a Xilinx part is 4K bits.
> Certainly this is not time exhaustive to test?

The question is how can you access it,  to test a memory to 98% using a
venerable March II takes about 4 patterns, at 8 memory accesses per-cell, 
per-pattern.  According to their website, XILINX XC4000XV has over
270,000 RAM bits.  If you are using Serial Access mode, that means you have
to perform 270Kx4x8 ~= 8 Megabit Reads and Writes which I admit is not 
impossible, takes awhile.  That only gives you 98% coverage of all hard and
soft faults.  I over-estimated how many RAM cells there where, so it is doable
even through the serial port.  I not well versed in the the RAM cell accessing
methods, but if its not random this number would go way, way up.  Of course for
to detect stuck at faults the number of patterns should be far less.  You can't
test individual RAM Bits, it must always be against its neighbors, to catch all
even hard faults.  The classic alternating A's and 5's only detects 1/2 the
data bit faults, and tests only 1 address line.  I am by no means saying that 
you can't get upper 90's coverage, but you can't get 100% detection on anything.


> 
> > How could you test all
> > the possible BIT leakage combinations in a reasonable time.  You can test the
> > configuration RAM for a given operational load fairly well by reading back the
> > down load, but this is by no means a 100% coverage.  If you have a RAM Cell
> > that floats, it may return the correct value part of the time.  Then you have
> > the issue that all the RAM and Logic Cells have the potential to leak to
> > any cell that is close to in some manner.  RAMs have faults that cause certain
> > memory cells to change for a correct 0 to a 1, only when all surrounding
> > cells are also 1's.
> 
> This is true for standard memory such as SRAMs. But the configuration
> memory is made of D FFs and are not co-located with memory from the
> other CLBs. So you don't have the same test problems that you have with
> SRAM.
To really know, you have to look at how isolated each piece is on the actual
die.  If the RAM cells are embedded in the logic, then the logic states may
cause unwanted changes or the reverse.  It is likely you are somewhat less
likely to have this problem in FPGA, than other Memories.


> 
> But that is not normally what we mean when we talk about coverage of
> test sets. We assume a much simplified failure model and test against
> that. Other failure modes need to be tested separately. So we would need
> a different set of test vectors to test against quantum fluctuations in
> the sub-space field.  ;)

Hey for Reagen's Star Wars program to have worked, they would have had to
detect and correct for those on the fly to get the 100's million part system to
work. :)  Most of the difference is the location of the testing.  My tests run
over a large temperature range, and on systems exposed to radiation (hopefully
just in space).  If you read NASA pages on FPGA's you will find that they 
feel the need to recheck the program load in the FPGA's periodically during
operation to correct Single Event Upsets of RAM Cells.  In Space Applications,
this is a real problem, and you can be fairly sure your system won't work
for long if you don't handle this issue.  There is also a severe shortage of
IC Test Machines on the battle field, thus all test support is in system.
I am well aware of what test coverage means in most of the commercial world,
but the original 100% poster was quoting someone from the defense industry that
has a well defined concept of failure detection that is based on failure rate,
and includes soft and hard failures.

Robert Posey



> 
> --
> 
> Rick 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
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com
Article: 23774
Subject: Re: calculating modulo N
From: "Alun" <alun101@DELETEtesco.net>
Date: Fri, 7 Jul 2000 21:13:39 +0100
Links: << >>  << T >>  << A >>
> I am working on implementing an algorithm which requires me to take a
> modulo N of a 15 bit number, where N is a 10 bit number that can take
> the following values : (48, 64, 212, 220, 228, 424, 432, 440, 848, 856,
> 864, 752).
>
> I would obviously like to implement this in the most resource economic
> way possible and am therefore hoping that there may be a trick that will
> allow me to avoid using a division.

Well the dumbest way to do it is to just keep subtracting M frm N until you
go negative.
That would take at most 683 operations with your numbers.
Can you spare the time?

If you can't, why not subtract M*16 (say) until you go -ve to get N modulo
(M*32), then subtract M until you go -ve as before.
About 47 operations at most.
Have a lok in Knuth's Semi-numerical algorithms:
'Volume 2 of Donald Knuth's classic series The Art of Computer Programming
covers seminumerical algorithms, with topics ranging from random number
generators to floating point operations and other optimized arithmetic
algorithms. Truly comprehensive and meticulously written, this book (and
series) is that rarest of all creatures--a work of authoritative scholarship
in classical computer science, but one that can be read and used profitably
by virtually all working programmers.'

Alun
Camdigital




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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search