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 60725

Article: 60725
Subject: Re: opinions are OK
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 20 Sep 2003 13:40:34 +1200
Links: << >>  << T >>  << A >>
rob d wrote:
> 
<snip> Lets just suppose that ff1 was only just metastable and was
nearly
> high. In this scenario with meta unknown then, the mux on ff2 may be
> switching wildly or trying to average (I don't know modern semi
> theory) the two inputs to ff2. However ff1 is just about 1 and so is
> "not ff2" and ff2 will see a solid 1.
> 
> There may be a hole in my "design" but unless there is something about
> op amp comparators I have forgotten (I did the theory about 15 yrs
> ago) then this isn't it.
> 
> The problem with a forum like this is that someone steps out of the
> box and other people think that the "out of boxer" has no experience
> at all. As my last sentence sort of implied I'm not looking for a
> solution, the maths for metastability is well understood and I'm not
> looking to pay the obvious penalties for not using the classic
> solution.

 Try thinking also in the time domain, as well as the voltage domain.

 (ideal) Comparators may solve a voltage domain uncertainty, but
what about a signal like in Philip's photos, that 
'heads one way, then changes it's mind', but is otherwise valid in
a digital sense.  ( effectively a runt pulse )
 Hard to see how any extra sensing can 'fix that after the event' ?

-jg

Article: 60726
Subject: Re: ISE 6.1 and Redhat 9
From: "Matt" <bielstein2002@comcast.net>
Date: Sat, 20 Sep 2003 03:25:38 GMT
Links: << >>  << T >>  << A >>
Question... have you done any benchmarks for performance relative to
Windows? (Synthesis/Translate/Map/PAR) Same or similar hardware would be
best.

Thanks in advance!

"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message
news:1nzab.364$4G3.59567@newsfep2-gui.server.ntli.net...
> Try (bash),
>
> export LD_ASSUME_KERNEL=2.4.1
>
> It runs fine on my RH9,
> Hans.
> www.ht-lab.com
>
> "Garry Allen" <garrya@ihug.com.au> wrote in message
> news:3abc4240.0309181808.3e1b9cbc@posting.google.com...
> > I am very thankful that Xilinx is now supporting Linux directly in
> > ISE6.1. However, out of the box it only directly supports Redhat 7.3
> > and Redhat 8. Has anyone managed to install it under Redhat 9 and what
> > if anything did you need to do to get it to call the glibc libraries
> > successfully?
> >
> > At the moment when I run ./setup, it fails with an error msssage
> > stating that it cannot find the glibc libraries. I am unsure if I can
> > run multiple versions of the gcc compiler
> > Comments
> > Thanks
> > Garry Allen
>
>



Article: 60727
Subject: Configuration Options:
From: shabana_rizvi@yahoo.com (rider)
Date: 19 Sep 2003 21:17:30 -0700
Links: << >>  << T >>  << A >>
Hi!
Thanks for the group to reply my previous query "Xilinx Parallel Cable
4 (PC4) and Platform Flash JTAG". Specially to Antti Lorenzo and
Aurelian Lazarut. Continuing with the same topic of configuration, i
have a few more queries:

1)In the Xilinx's latest document "Configuration Quick Start
Guidelines" http://www.xilinx.com/bvdocs/appnotes/xapp501.pdf page 13,
the author shows a snap from iMPACT software(fig: 9 Startup options
for Virtex and Spartan 2). The author states:

"Start-Up Clock  The bitstream must be generated with the appropriate
startup clock option for the PART to be configured properly. The
"Start-Up Clock" option by default is set to "CCLK" for Master Serial
Mode. When generating a bitstream for Boundary Scan (JTAG) Mode the
option must be set to "JTAGCLK" in the pull-down menu of the GUI or
using bitgen's command line:
 For configuring using Boundary Scan (JTAG):
bitgen g startupclk:jtagclk designName.ncd
 For configuring via Master-Serial:
bitgen g startupclk:cclk designName.ncd"

My question is that when she talks of Master Serial Mode and CCLK,
does she mean she is creating a file for PROM only[PART is PROM here],
because Master Serial mode requires a PROM . The file cannot be loaded
directly to FPGA. And when she talks of JTAG and jtagclk, the PART
could be PROM or FPGA ? Am i right ?

2) I have Xilinx ISE5.1 , does it support the configuration of latest
Xilinx Platform PROM XCF02S via JTAG?

Thanks

Article: 60728
Subject: Re: LVDS in Xilinx (Spartan-3)
From: Andrew Paule <lsboogy@qwest.net>
Date: Fri, 19 Sep 2003 23:49:35 -0500
Links: << >>  << T >>  << A >>
Don't quote me on this, but I seem to remember that CE required a 15KV 
human body model - you might look it up just to make sure, but if you 
plan to ship to the CE, you'll need this.

Andrew

Jason Daughenbaugh wrote:

>Hello all,
>
>I am considering using the LVDS mode in spartan-3 FPGAs to run
>offboard via a cat-5 RJ-45 connector.  We have been doing this for a
>long time with LVDS parts from TI and National, but using the FPGA
>directly would be a cost savings (but also require a lot of pins!)
>
>I am concerned about exposing these I/O pins this way, I feel much
>safer with the layer of protection the LVDS parts put between the FPGA
>and the outside world.  I have no doubt that these parts are safer,
>but do I need this?  Most Xilinx parts claim a 2kV ESD spec,
>human-body model, whereas the LVDS components spec 20kv.  Or maybe I
>would need to diode-protect these (expensive).
>
>Does anyone have any advice, or has anyone had any good or bad
>experiences doing this?  Along these lines, what do you recommend to
>protect any exposed FPGA pin?  We usually try to avoid them, but
>otherwise we will use series resistors and diode protection depending
>on the application.
>
>Thanks!
>Jason Daughenbaugh
>http://www.aedbozeman.com
>  
>


Article: 60729
Subject: Re: Transistor count
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sat, 20 Sep 2003 19:37:55 +1200
Links: << >>  << T >>  << A >>
I think that's because one of the standards counts transistors in its MTBF..
so a PAL is more reliable than an FPGA but less reliable than an HC00.

Simon

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F6B9895.CB08B483@xilinx.com...
> I think the answer is " more than 100 million, but less than 300 million".
>
> We are caught between embarrassment: "that's how many we need"  and
> pride: "that's how good we are, to be able to make and sell that many
> for a reasonable price".
>
> An then there still are some people who really and seriously (!) think
> they can calculate device reliability and MTBF from the total number of
> transistors. These guys do not seem to die out, even though we have told
> them, and proven to them, again and again, that such calculations are
> utter nonsense.
>
> So Ray is right, you would need another seven or eight fingers...
> Peter Alfke
> ========================
> Ray Andraka wrote:
> >
> > More than you can count on both hands and feet, even if you count in
binary
> > :-)
> >
> > Arnaldo Oliveira wrote:
> >
> > > Hi!
> > >
> > > Could someone tell me how many transistors are integrated on the
XC3S5000
> > > Spartan-3 device?
> > > Thank You.
> > > Arnaldo.
> > >
> > > --
> >
> > --
> > --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: 60730
Subject: show-ahead FIFOs
From: Bertrik Sikken <bertrik@zonnet.nl>
Date: Sat, 20 Sep 2003 10:38:35 +0200
Links: << >>  << T >>  << A >>
Hi all,

I worked on a project using an Altera FPGA and I noticed that
their FIFOs have a 'show-ahead' feature. Currently I'm working
with an FPGA from Xilinx and I could not find a similar feature
on their FIFO's.

It seems to me such a feature can be very useful since it
allows you to get at the data one clock earlier.

Why don't the Xilinx FIFOs have such a feature?
(Or am I perhaps overlooking something some crucial
drawback of show-ahead FIFOs?)

Regards,
Bertrik Sikken


Article: 60731
Subject: Re: ISE 6.1 and Redhat 9
From: "Hans" <hansydelm@no-spam-ntlworld.com>
Date: Sat, 20 Sep 2003 12:21:34 +0100
Links: << >>  << T >>  << A >>
Hi Matt,

No I haven't (too busy). Also you know what they say about benchmarks "Lies,
Damn Lies and Benchmarks :-)

Hans.

"Matt" <bielstein2002@comcast.net> wrote in message
news:SMPab.521826$YN5.347243@sccrnsc01...
> Question... have you done any benchmarks for performance relative to
> Windows? (Synthesis/Translate/Map/PAR) Same or similar hardware would be
> best.
>
> Thanks in advance!
>
> "Hans" <hansydelm@no-spam-ntlworld.com> wrote in message
> news:1nzab.364$4G3.59567@newsfep2-gui.server.ntli.net...
> > Try (bash),
> >
> > export LD_ASSUME_KERNEL=2.4.1
> >
> > It runs fine on my RH9,
> > Hans.
> > www.ht-lab.com
> >
> > "Garry Allen" <garrya@ihug.com.au> wrote in message
> > news:3abc4240.0309181808.3e1b9cbc@posting.google.com...
> > > I am very thankful that Xilinx is now supporting Linux directly in
> > > ISE6.1. However, out of the box it only directly supports Redhat 7.3
> > > and Redhat 8. Has anyone managed to install it under Redhat 9 and what
> > > if anything did you need to do to get it to call the glibc libraries
> > > successfully?
> > >
> > > At the moment when I run ./setup, it fails with an error msssage
> > > stating that it cannot find the glibc libraries. I am unsure if I can
> > > run multiple versions of the gcc compiler
> > > Comments
> > > Thanks
> > > Garry Allen
> >
> >
>
>



Article: 60732
Subject: Re: Configuration Options:
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Sat, 20 Sep 2003 11:29:54 GMT
Links: << >>  << T >>  << A >>
"rider" <shabana_rizvi@yahoo.com> ha scritto nel messaggio
news:ca3a68c8.0309192017.809fc2f@posting.google.com...

> 2) I have Xilinx ISE5.1 , does it support the
> configuration of latest
> Xilinx Platform PROM XCF02S via JTAG?

Yes! But be afraid of iMPACT user interface, which is the worst
nightmare ever invented. I've lost more than ten minutes to understand
how to use a PROM with iMPACT...

-- 
Lorenzo



Article: 60733
Subject: Re: divide by on spartan3?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Sep 2003 09:20:13 -0400
Links: << >>  << T >>  << A >>
Terry,

This sounds like an ideal application for delta-sigma converters, since your control
is really based on the deltas not on the absolute values.  I'd have to work through
the design, but it seems like it would work.

The thought came about because the division could start before the A/D conversion was
complete if the partial results were available.  The ADC, assuming a successive
approximation type, gets the most significnt bits first then improves the mesurement
by refining the lsbs.  Division is inherently MSB first as well.  You can see where I
am going here.

"Theron Hicks (Terry)" wrote:

> Sorry Ray,
>     I meant to give a little more detail than I ended up with.  The number of
> clock cycles per divide is not critical.  I cannot accept any pipeline delay, but
> I am willing to wait a few clock cycles before I get a final result.  I basically
> need to get a divide-by result as quickly as possible.  The inputs are 2 16 bit
> numbers and I need a minimum of 14 bits in the result.  I would really like to get
> to 16 bits if possible.  The resultant resistance (the quotient) is subtracted
> from the desired resistance.  This difference serves as the input to a very fast
> PID controller.  This controller serves to control the temperature of a hot-wire
> sensor in a research grade hot-wire anemometer.     Based on that, the time delay
> between requesting a quotient and the time when that quotient is valid needs to be
> minimum.  The 16 bit A/D currently has a latency of 460ns.  The remainder of the
> PID control loop should take about 30ns.  I want the division to be substantially
> faster than the sum of those two times if possible.  As a maximum, it must be
> faster that 500ns.  If it were much faster (~100ns) then I could look at faster
> A/D converters for an even higher system throughput when desired.  I hope this
> clarifies things.
>
> Thanks,
> Theron
>
> Ray Andraka wrote:
>
> > You need to decide what your requirements are:
> > size, precision, accuracy,  number of clocks per sample and clock rate.
> > You aren't going to get all of them at once, however if you can compromise on
> > accuracy, a normalize -> look up -> denormalize might be the best approach.
> >
> > Theron Hicks wrote:
> >
> > > Hello,
> > >     I have a project in mind where I would like to caclculate the resistance
> > > of a sensor.  Because of the remainder of the circuit configuration, this
> > > must be done using a voltage divider.  If I implement this in a spartan3,
> > > what is the fastest I can do a 16bit divide (unsigned)  Obviously I can do a
> > > shift and subtract, but I would prefer something a little faster.  Any
> > > suggestions?  (I know I could go to a fast DSP but again, I would prefer to
> > > stick with what I am most comfortable with (FPGAs).  My intent is to use the
> > > smallest spartan3 if posible.
> > > Thanks,
> > > Theron Hicks
> >
> > --
> > --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

--
--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: 60734
Subject: Re: pipelined divider
From: yog_aga@yahoo.co.in (ykagarwal)
Date: 20 Sep 2003 07:41:09 -0700
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3F6B8B64.F3EBCA2B@andraka.com>...
> Depends on how clever the designer is.  I'd wager that better than 95%t of the
> hardware engineers today couldn't design the 360/91 from scratch with 10 times
> the logic resources of the original.
> 
> Glen Herrmannsfeldt wrote:
> 
> >
> > I do wonder how many Virtex devices it would take to implement a 360/91.
> >
> > -- glen
> 
> --
> --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
hello,

360/91 machine and associated history is really an inspiration to 
younger designers like me ..
and your comments too :)


unnecessarily jumped
--yka

Article: 60735
Subject: Re: show-ahead FIFOs
From: Rene Tschaggelar <some@know.me>
Date: Sat, 20 Sep 2003 16:51:33 GMT
Links: << >>  << T >>  << A >>
Bertrik Sikken wrote:
> Hi all,
> 
> I worked on a project using an Altera FPGA and I noticed that
> their FIFOs have a 'show-ahead' feature. Currently I'm working
> with an FPGA from Xilinx and I could not find a similar feature
> on their FIFO's.
> 
> It seems to me such a feature can be very useful since it
> allows you to get at the data one clock earlier.
> 
> Why don't the Xilinx FIFOs have such a feature?
> (Or am I perhaps overlooking something some crucial
> drawback of show-ahead FIFOs?)

A time machine ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 60736
Subject: Re: pipelined divider
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 20 Sep 2003 11:26:13 -0700
Links: << >>  << T >>  << A >>
Changing times...  Logic resources are cheap compared to a designer's
time (and time to market considerations).  Same argument can be made
with software.  How many current software engineers could write a full
game (or complete programming language) that fits on an 8kbyte
cartridge?

It's certainly an interesting question.

   Jake


Ray Andraka <ray@andraka.com> wrote in message news:<3F6B8B64.F3EBCA2B@andraka.com>...
> Depends on how clever the designer is.  I'd wager that better than 95%t of the
> hardware engineers today couldn't design the 360/91 from scratch with 10 times
> the logic resources of the original.
> 
> Glen Herrmannsfeldt wrote:
> 
> >
> > I do wonder how many Virtex devices it would take to implement a 360/91.
> >
> > -- glen
> 
> --
> --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: 60737
Subject: Re: Parallel JTAG cable on a USB-only W2K laptop?
From: "CF" <carl@notsoform.com>
Date: Sat, 20 Sep 2003 22:10:02 GMT
Links: << >>  << T >>  << A >>
Thank you for confirming my suspicion that I cannot accomplish this task
with a USB adapter.
I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter.
I believe it will install as an LPT device properly and do the job.
Thank you again.
Carl



Article: 60738
Subject: Re: show-ahead FIFOs
From: Andrew Paule <lsboogy@qwest.net>
Date: Sat, 20 Sep 2003 23:11:58 -0500
Links: << >>  << T >>  << A >>
I think a better way to look a this is a FWFT (first word fall through) 
- standard fifo trick - you can do these in any FPGA - transparent 
latch, data available tpd after clock edge.  No one can get data before 
it exists.

Andrew

Bertrik Sikken wrote:

> Hi all,
>
> I worked on a project using an Altera FPGA and I noticed that
> their FIFOs have a 'show-ahead' feature. Currently I'm working
> with an FPGA from Xilinx and I could not find a similar feature
> on their FIFO's.
>
> It seems to me such a feature can be very useful since it
> allows you to get at the data one clock earlier.
>
> Why don't the Xilinx FIFOs have such a feature?
> (Or am I perhaps overlooking something some crucial
> drawback of show-ahead FIFOs?)
>
> Regards,
> Bertrik Sikken
>


Article: 60739
Subject: Re: show-ahead FIFOs
From: "Bob" <nimby1_not_spmmm@earthlink.net>
Date: Sun, 21 Sep 2003 05:03:47 GMT
Links: << >>  << T >>  << A >>
[snip]
> No one can get data before it exists.
>
> Andrew
>

I can. You see, I've met Peter Alfke.

;-p

Bob



Article: 60740
Subject: Re: Parallel JTAG cable on a USB-only W2K laptop?
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sun, 21 Sep 2003 17:19:37 +1200
Links: << >>  << T >>  << A >>
I have a feeling you might be pushing it .. but I'd like to hear the
outcome.. The parallel port is treated as a bit bashed I/O port by the
downloader's where as the USB to parallel port is a printer port.. or an EPP
port..

Xilinx do a USB to FPGA downloader box for about US$500.. that would be my
best thought.. or there's a few USB - JTAG boxes that might also work.
Altera have a similar device similar price..

I have often thought an EZ-USB would make a great FPGA downloader and at the
same price as the parallel port downloader's.

Simon


"CF" <carl@notsoform.com> wrote in message
news:_e4bb.2249$YO5.1748748@news3.news.adelphia.net...
> Thank you for confirming my suspicion that I cannot accomplish this task
> with a USB adapter.
> I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter.
> I believe it will install as an LPT device properly and do the job.
> Thank you again.
> Carl
>
>



Article: 60741
Subject: Re: show-ahead FIFOs
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sun, 21 Sep 2003 17:20:35 +1200
Links: << >>  << T >>  << A >>
he he.. if you couldn't get data before exists .. salesmen would be out of a
job :-)


"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message
news:Tiabb.731$gR1.144@newsread4.news.pas.earthlink.net...
> [snip]
> > No one can get data before it exists.
> >
> > Andrew
> >
>
> I can. You see, I've met Peter Alfke.
>
> ;-p
>
> Bob
>
>



Article: 60742
Subject: Re: pipelined divider
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sun, 21 Sep 2003 17:23:41 +1200
Links: << >>  << T >>  << A >>
But my PC which runs the latest version of the CAD tools I brought 10 years
ago.. has the power dissipation of a small heater.. and the software runs
slower.. good thing I don't live in California where there's not enough
power :-)

Simon

"Jake Janovetz" <jakespambox@yahoo.com> wrote in message
news:d6ad3144.0309201026.78874571@posting.google.com...
> Changing times...  Logic resources are cheap compared to a designer's
> time (and time to market considerations).  Same argument can be made
> with software.  How many current software engineers could write a full
> game (or complete programming language) that fits on an 8kbyte
> cartridge?
>
> It's certainly an interesting question.
>
>    Jake
>
>
> Ray Andraka <ray@andraka.com> wrote in message
news:<3F6B8B64.F3EBCA2B@andraka.com>...
> > Depends on how clever the designer is.  I'd wager that better than 95%t
of the
> > hardware engineers today couldn't design the 360/91 from scratch with 10
times
> > the logic resources of the original.
> >
> > Glen Herrmannsfeldt wrote:
> >
> > >
> > > I do wonder how many Virtex devices it would take to implement a
360/91.
> > >
> > > -- glen
> >
> > --
> > --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: 60743
Subject: Re: Xilinx Parallel Cable 4 (PC4) and Platform Flash JTAG
From: antti@case2000.com (Antti Lukats)
Date: 21 Sep 2003 04:20:49 -0700
Links: << >>  << T >>  << A >>
Aurelian Lazarut <aurash@xilinx.com> wrote in message news:<3F6B1811.FD334DE@xilinx.com>...
> Antti Lukats wrote:
> 
> Antti,
> why are you saying that the boundary scan is not supported with PAR cable
> IV ?? - or it's a wild guess... 
> Aurash
>  __
> / /\/\ Aurelian Lazarut
> \ \  / System Verification Engineer
> / /  \ Xilinx Ireland
> \_\/\/
> 
> phone: 353 01 4032639
> fax: 353 01 4640324

Dear Xilinx Verification Engineer,

No it is not a wild guess. Sure Cable IV hardware support all JTAG
(inclusive boundary scan of course) but 99% of Xilinx customers who
own Cable IV can not use it for boundary scan because there are no
software available for that purpose.

Cable IV: 
 hardware is boundary scan capable
 can not be used for boundary scan because no software or API is available.

I had a pretty urgent need to use boundary during development of on board
with Xilinx FPGA, I have Cable IV (only because it was bundled with
ML300 kit), but I could not use Cable IV, because the lack of software.

Cable IV hardware description and software driver API are all kept Xilinx
confidential and secret, so 3rd party software can not use Cable IV.

If the API (or register level description of the hardware interface)
would be public it would be real simple to modify STAPL player to support
Cable IV. Unfortunatly this is not possible and STAPL player hardware support
ends with Cable III (i.e. simple LPT download cable).
Xilinx provided XSVF player also does not support Cable IV.


There is only one wacked way to use Cable IV for boundary scan, but that
really not an option - SystemACE files may contain SVF so if you have systemACE
that you program using Cable IV then you could optionally create a SVF that 
does the needed boundary scan, program the systemACE and let systemACE to
perform the JTAG boundary scan.

Except that I am not aware of any means of using Cable IV for boundary scan.
Correct me if I am wrong. There might be some JTAG software that cost some
thousands of $$$ and support Cable IV, but an regular Xilinx customer who
has to deal with Xilinx FPGAs and owns Cable IV can not use it boundary scan.

PLEASE, PLEASE SAY I am wrong. (I dont think I am)

antti
who does not work for xilinx but in most cases knows more than those who do.

Article: 60744
Subject: Re: show-ahead FIFOs
From: Bertrik Sikken <bertrik@zonnet.nl>
Date: Sun, 21 Sep 2003 15:17:13 +0200
Links: << >>  << T >>  << A >>
Andrew Paule wrote:
> I think a better way to look a this is a FWFT (first word fall through) 
> - standard fifo trick - you can do these in any FPGA - transparent 
> latch, data available tpd after clock edge.  

Yes, that was what I meant.
However, FIFOs from both Altera and Xilinx don't have this by default.
For Altera you need to set the "show-ahead" property on the FIFO and
Xilinx does not have this feature at all (as far as I could find).
I wonder why. Could be it the latch that makes this a problem?

Again, it looks like a very useful feature to get the data a bit
earlier (no, obviously not before it exists...). So instead of
telling the fifo "give me some data on the next clock", you already
have the data and tell the fifo "i've seen the data, on to the next".

 > No one can get data before
> it exists.

I didn't mean to imply that.

> Andrew
> 
> Bertrik Sikken wrote:
> 
>> Hi all,
>>
>> I worked on a project using an Altera FPGA and I noticed that
>> their FIFOs have a 'show-ahead' feature. Currently I'm working
>> with an FPGA from Xilinx and I could not find a similar feature
>> on their FIFO's.
>>
>> It seems to me such a feature can be very useful since it
>> allows you to get at the data one clock earlier.
>>
>> Why don't the Xilinx FIFOs have such a feature?
>> (Or am I perhaps overlooking something some crucial
>> drawback of show-ahead FIFOs?)
>>
>> Regards,
>> Bertrik Sikken
>>
> 


Article: 60745
Subject: Re: show-ahead FIFOs
From: Andrew Paule <lsboogy@qwest.net>
Date: Sun, 21 Sep 2003 11:30:09 -0500
Links: << >>  << T >>  << A >>
Sounds like you have to roll your own - and yes, sales guys can get data 
before it exists. You can get the flops in a Xilinx part to go 
transparent - black box em as D types - then all you've got to deal with 
is the cell delay and the pad I/O delay.

BTW, I've never met Peter Alfke, although I do correspond with him, but 
he did invent the first fifo (Fairchild - you can look it up - name's on 
the patent app), and he is one of the few factory people who seem to 
have something up top.  I'm not a Xilinx person (prefer other 
architectures closer to ASIC types - Actel in particular), but don't get 
on his case about stuff - he's in a position where he can't malign his 
company - even though there are those who put out misleading data- don't 
blame him, blame the guy who okayed putting the stuff out.

Andrew
 
Bertrik Sikken wrote:

> Andrew Paule wrote:
>
>> I think a better way to look a this is a FWFT (first word fall 
>> through) - standard fifo trick - you can do these in any FPGA - 
>> transparent latch, data available tpd after clock edge.  
>
>
> Yes, that was what I meant.
> However, FIFOs from both Altera and Xilinx don't have this by default.
> For Altera you need to set the "show-ahead" property on the FIFO and
> Xilinx does not have this feature at all (as far as I could find).
> I wonder why. Could be it the latch that makes this a problem?
>
> Again, it looks like a very useful feature to get the data a bit
> earlier (no, obviously not before it exists...). So instead of
> telling the fifo "give me some data on the next clock", you already
> have the data and tell the fifo "i've seen the data, on to the next".
>
> > No one can get data before
>
>> it exists.
>
>
> I didn't mean to imply that.
>
>> Andrew
>>
>> Bertrik Sikken wrote:
>>
>>> Hi all,
>>>
>>> I worked on a project using an Altera FPGA and I noticed that
>>> their FIFOs have a 'show-ahead' feature. Currently I'm working
>>> with an FPGA from Xilinx and I could not find a similar feature
>>> on their FIFO's.
>>>
>>> It seems to me such a feature can be very useful since it
>>> allows you to get at the data one clock earlier.
>>>
>>> Why don't the Xilinx FIFOs have such a feature?
>>> (Or am I perhaps overlooking something some crucial
>>> drawback of show-ahead FIFOs?)
>>>
>>> Regards,
>>> Bertrik Sikken
>>>
>>
>


Article: 60746
Subject: Italy is out of FPGA world?
From: "Valeria Dal Monte" <aaa@bbb.it>
Date: Sun, 21 Sep 2003 16:34:13 GMT
Links: << >>  << T >>  << A >>
Some days ago Xilinx did workshops in many european states.
Why Italy was excluded?





Article: 60747
Subject: Re: show-ahead FIFOs
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 21 Sep 2003 19:24:54 GMT
Links: << >>  << T >>  << A >>
On Sat, 20 Sep 2003 23:11:58 -0500, Andrew Paule <lsboogy@qwest.net> wrote:
>I think a better way to look a this is a FWFT (first word fall through) 
>a standard fifo trick - you can do these in any FPGA - transparent 
>Latch, data available tpd after clock edge.  No one can get data before 
>it exists.

And

On Sun, 21 Sep 2003 11:30:09 -0500, Andrew Paule <lsboogy@qwest.net> wrote:
>Sounds like you have to roll your own - and yes, sales guys can get data 
>before it exists. You can get the flops in a Xilinx part to go 
>transparent - black box em as D types - then all you've got to deal with 
>is the cell delay and the pad I/O delay.

I am sorry to say that this is not a good idea. Transparent latches
in synchronous designs is a mine field for timing problems.

The correct way to implement FWFT is to make some changes to
the FIFO control state machine.

The internals of a FIFO can be thought of as comprising the following
blocks:

1) Dual port memory
2) Write logic
3) Read logic
4) State machine
5) Flags logic

Within the Read Logic portion, there is the output of the memory,
that feeds an output register.

When data is written to a fifo, it is written to the memory,
counter(s) are updated, and the Empty flag is deasserted.

When the external read side logic sees the Empty flag deasserted, it
can issue a ReadEnable, that causes the FIFO logic to read the
appropriate location of memory, load it into the output register,
and update counters and flags.

For FWFT, the difference is that logically the name of the flag
Empty is renamed to DataValid, and the state machine is changed.
Unlike normal mode where the Empty flag is telling you the status
of the internal memory (or rather, its validity), the DataValid
flag is telling you the status of the output register.

When the FIFO is empty, the DataValid flag is deasserted.
When data arrives, if the DataValid flag is deasserted, the
FIFO state machine automatically reads a word from the memory,
transfers it to the output register, and asserts DataValid.
The ReadEnable command input of a normal FIFO is also renamed
to DataTaken, and this is used by the external read side logic
to indicate that the current contens of the output register
are not needed any more. If there is no more valid data in
the memory, DataValid is deasserted, otherwise the next data
item is transfered to the output register.

The difference in the state machine logic to implement this
FWFT mode is typically less than 10 gates.

Since the output is still comming from a register clocked
by the read side clock, the static timing model is the same
for both modes, while the logic timing is as desired for
each mode.


Philip








Philip Freidin
Fliptronics

Article: 60748
Subject: Re: opinions are OK
From: rjd@transtech-dsp.com (rob d)
Date: 21 Sep 2003 15:03:19 -0700
Links: << >>  << T >>  << A >>
Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3F6BB012.1C31@designtools.co.nz>...
> rob d wrote:
> > 
> <snip> Lets just suppose that ff1 was only just metastable and was
> nearly
> > high. In this scenario with meta unknown then, the mux on ff2 may be
> > switching wildly or trying to average (I don't know modern semi
> > theory) the two inputs to ff2. However ff1 is just about 1 and so is
> > "not ff2" and ff2 will see a solid 1.
> > 
> > There may be a hole in my "design" but unless there is something about
> > op amp comparators I have forgotten (I did the theory about 15 yrs
> > ago) then this isn't it.
> > 
> > The problem with a forum like this is that someone steps out of the
> > box and other people think that the "out of boxer" has no experience
> > at all. As my last sentence sort of implied I'm not looking for a
> > solution, the maths for metastability is well understood and I'm not
> > looking to pay the obvious penalties for not using the classic
> > solution.
> 
>  Try thinking also in the time domain, as well as the voltage domain.
> 
>  (ideal) Comparators may solve a voltage domain uncertainty, but
> what about a signal like in Philip's photos, that 
> 'heads one way, then changes it's mind', but is otherwise valid in
> a digital sense.  ( effectively a runt pulse )
>  Hard to see how any extra sensing can 'fix that after the event' ?
> 
> -jg

There is an issue if FF1 is metastable on two successive clock edges
when the input is slowly rising as FF2 will toggle twice, which simple
design practice can solve, but there is no issue if FF1 is meta twice
with an input pulse at exactly the clock period (FF2 toggling twice is
what the input has done). Other than that I haven't understood you.

Article: 60749
Subject: Re: show-ahead FIFOs
From: Andrew Paule <lsboogy@qwest.net>
Date: Sun, 21 Sep 2003 17:40:15 -0500
Links: << >>  << T >>  << A >>
Hi Philip -

you're right on all cases - only thing is that you are going to be 
either a half or full clock behind.  FWFT Fifo's are done with 
transparent latches (that's the limiter) - you have to be cautious in 
use of them.  I've done fifo's using the transparent latch trick that 
are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA, 
unless you pay attention to how you're routing the thing, you can have a 
nightmare (One of the reasons I like Actels) - the true FWFT types have 
the flags updated on the rising edge of the incoming clock and have the 
synched flops (look at a Cypress or IDT design) done with the same flop 
that's used for the empty flag.  What you are doing is great for 
avoiding problems in designs that are not well followed through, and 
should be a design standard.  What goes on in the newsgroups is that 
some folks out there will take a quick look at things and then try to 
implement them without understanding the real problems in post route 
timing (especially over temperature).

Andrew

Philip Freidin wrote:

>On Sat, 20 Sep 2003 23:11:58 -0500, Andrew Paule <lsboogy@qwest.net> wrote:
>  
>
>>I think a better way to look a this is a FWFT (first word fall through) 
>>a standard fifo trick - you can do these in any FPGA - transparent 
>>Latch, data available tpd after clock edge.  No one can get data before 
>>it exists.
>>    
>>
>
>And
>
>On Sun, 21 Sep 2003 11:30:09 -0500, Andrew Paule <lsboogy@qwest.net> wrote:
>  
>
>>Sounds like you have to roll your own - and yes, sales guys can get data 
>>before it exists. You can get the flops in a Xilinx part to go 
>>transparent - black box em as D types - then all you've got to deal with 
>>is the cell delay and the pad I/O delay.
>>    
>>
>
>I am sorry to say that this is not a good idea. Transparent latches
>in synchronous designs is a mine field for timing problems.
>
>The correct way to implement FWFT is to make some changes to
>the FIFO control state machine.
>
>The internals of a FIFO can be thought of as comprising the following
>blocks:
>
>1) Dual port memory
>2) Write logic
>3) Read logic
>4) State machine
>5) Flags logic
>
>Within the Read Logic portion, there is the output of the memory,
>that feeds an output register.
>
>When data is written to a fifo, it is written to the memory,
>counter(s) are updated, and the Empty flag is deasserted.
>
>When the external read side logic sees the Empty flag deasserted, it
>can issue a ReadEnable, that causes the FIFO logic to read the
>appropriate location of memory, load it into the output register,
>and update counters and flags.
>
>For FWFT, the difference is that logically the name of the flag
>Empty is renamed to DataValid, and the state machine is changed.
>Unlike normal mode where the Empty flag is telling you the status
>of the internal memory (or rather, its validity), the DataValid
>flag is telling you the status of the output register.
>
>When the FIFO is empty, the DataValid flag is deasserted.
>When data arrives, if the DataValid flag is deasserted, the
>FIFO state machine automatically reads a word from the memory,
>transfers it to the output register, and asserts DataValid.
>The ReadEnable command input of a normal FIFO is also renamed
>to DataTaken, and this is used by the external read side logic
>to indicate that the current contens of the output register
>are not needed any more. If there is no more valid data in
>the memory, DataValid is deasserted, otherwise the next data
>item is transfered to the output register.
>
>The difference in the state machine logic to implement this
>FWFT mode is typically less than 10 gates.
>
>Since the output is still comming from a register clocked
>by the read side clock, the static timing model is the same
>for both modes, while the logic timing is as desired for
>each mode.
>
>
>Philip
>
>
>
>
>
>
>
>
>Philip Freidin
>Fliptronics
>  
>




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