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 30000

Article: 30000
Subject: Re: Book on FPGA-Design with Xilinx chips
From: Ray Andraka <ray@andraka.com>
Date: Tue, 20 Mar 2001 13:54:43 GMT
Links: << >>  << T >>  << A >>
Are you using time constraints and checking the timing analysis?  If your timing
analysis is passing, then the design should work over the entire temperature
range.  At 50 MHz, even a full chip is not normally going to get so hot that
cooling is needed to make it operate, unless your IOs are overloaded.

Rainer Storn wrote:
> 
> Hi all,
> 
> I want to make myself knowledgeable in FPGA-Design
> with Xilinx-Chips. We have found that for small designs
> everything is pretty straightforward. However, for
> high clock frequencies (50MHz) and more complex designs
> clock delay and skew as well as the clock signal quality
> which enters the chip seem to have crucial importance.
> In fact even if the VHDL-code is correct, proven by
> simulation, the actual implementation sometimes doesn't
> work (or does so only with cooling). Can anyone name me
> some good references where I can get more insight into
> the pits and trapfalls of FPGA-design ?
> 
> Regards
> 
> Rainer

-- 
-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

Article: 30001
Subject: Re: Packing density of Xilinx FPGAs
From: Ray Andraka <ray@andraka.com>
Date: Tue, 20 Mar 2001 14:03:49 GMT
Links: << >>  << T >>  << A >>
Your friend is not a very experienced Xilinx designer.  I routinely do Xilinx
designs that are 80% or more utilized at clock rates that are quite a bit
higher. The 40KXV parts are all capable of over 100MHz operation, but you'll
have to be careful to do you design such that it doesn't have many layers of
combinatorial logic between registers (ie, the signal should only pass through
one or two LUTs between flip-flops).  For higher clocks you may also find you
need to do some floorplanning, but not for a 43 MHz clock.  The XC40150XV has
sufficient routing resources for most designs.

By clock skew, I presume you are referring to the input delay to register.  You
should register incoming signals in the IOBs wherever possible for two reasons:
1) by doing so, you get the minimum delay from the pin to the first register,
and 2) the external timing gets decoupled from your design's internal layout and
routing solution so re-routes don't affect your system.  This also helps avoid
the so called pin locking problem, as the pin locations are not as critical.  I
don't have the data sheet in front of me at the moment, I think 2ns setup is
pretty close to what you get using the IOB registers in the 4KXV.

Rainer Storn wrote:
> 
> Hi All,
> 
> I am new to the FPGA design business so I would like
> to verify an information that was given to me by a
> fellow engineer. He said that once the packing
> density of Xilinx FPGAs exceeds 30% I may run into
> timing problems because of the delay variations that
> inevitably arise due to difficult routing. In fact we experienced
> these problems. It seems that certain clock skew constraints
> can never be met. (2ns, 43MHz clock rate, XC40150XV).
> 
> Is this a known problem ? Is there anything we can do
> about this ?
> 
> Regards
> 
> Rainer

-- 
-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

Article: 30002
Subject: Re: Book on FPGA-Design with Xilinx chips
From: "Austin Franklin" <austin@dark99room.com>
Date: Tue, 20 Mar 2001 09:04:53 -0500
Links: << >>  << T >>  << A >>
> I want to make myself knowledgeable in FPGA-Design
> with Xilinx-Chips. We have found that for small designs
> everything is pretty straightforward. However, for
> high clock frequencies (50MHz) and more complex designs
> clock delay and skew as well as the clock signal quality
> which enters the chip seem to have crucial importance.
> In fact even if the VHDL-code is correct, proven by
> simulation, the actual implementation sometimes doesn't
> work (or does so only with cooling). Can anyone name me
> some good references where I can get more insight into
> the pits and trapfalls of FPGA-design ?

I don't know of any book that I would consider useful for the level of
design you are talking about.  The Xilinx data sheets are a great place to
start.  Understanding the architecture of the CLBs and the chip is critical
in making informed decision on how to design.  Knowing the architecture will
help you design to minimize logic, and take advantage of the architecture.
You can not use an ASIC mentality when designing FPGAs, though the vendors
like to tell you you can.

 I believe there are application notes for HDLs that suggest ways of using
HDLs to generate the logic you want, both FPGA vendor specific, and tool
vendor specific.  Learn how to use TIMESPECs, which are documented in the
Xilinx tool documentation, and there is also, I believe, a Xilinx tutorial
on this.

One thing to keep in mind for FPGAs, is to keep the logic between flops
minimized to make your clock frequency.  Learning how to use the tools to
see how your design is being implemented and where your timing problems are,
is very useful.  If you are using Synplicity, it has an RTL viewer
available, and this is an excellent tool.

I would suggest that slogging through the problems of making your design
make timing, learning how to use the tools well, and asking questions here,
is probably a far better learning experience than any book can give you.

There are many levels you can design to, everything from pushing the button
to instantiating your gates, mapping the logic, and doing
floorplanning...and it depends on what you are trying to do that dictates
how many of these steps you need to take to implement your design
successfully.




Article: 30003
Subject: Re: TOA measurement
From: "Michal Kvasnicka" <m.kvasnicka@era.cz>
Date: Tue, 20 Mar 2001 15:05:49 +0100
Links: << >>  << T >>  << A >>
OK ...

Situation is probably litle bit more clear. I need probably "matched
filter". Do you know some good reference on this subject? I need the
suitable starting point for my next work.

Thanks, Michal
"Ray Andraka" <ray@andraka.com> píse v diskusním príspevku
news:3AB75FA8.E8915255@andraka.com...
> DIfferent animal.  That was a bit pattern correlator.  He needs a matched
filter
> in this case.
>
> Kolja Sulimma wrote:
> >
> > Juri Kanevski wrote:
> >
> > > FPGA can implement the correlation with the sampling frequency ca 100
> > > MHz.
> >
> > There was a 16 channel correlator published years ago that achieved 250
MHz in
> > XC3192A
> > I admit it was a 100% FPGA-Editor design - I guess those people would
have kille to
> > get their
> > hands on JBits - but with Virtex-E or Virtex-II higher frequency should
be possible.
> >
> > Kolja
>
> --
> -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



Article: 30004
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: Ray Andraka <ray@andraka.com>
Date: Tue, 20 Mar 2001 14:08:51 GMT
Links: << >>  << T >>  << A >>
One would think so, but it is not there.

Simon Bacon wrote:
> 
> I guess the logic should be available in a simulation library.

-- 
-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

Article: 30005
Subject: Re: TOA measurement
From: "Michal Kvasnicka" <m.kvasnicka@era.cz>
Date: Tue, 20 Mar 2001 15:09:22 +0100
Links: << >>  << T >>  << A >>
I do not understand well now what is your final suggestion. "matched
filtering" or something else and better?

Michal
"Ray Andraka" <ray@andraka.com> píse v diskusním príspevku
news:3AB760AC.122D2B51@andraka.com...
> Yes. As well as possibly using fractionally placed parallel filters for
> fractional range bin resolution.  Reading more of the posts this morning
it is
> evident that your transmit pulse is not well controlled, which makes it
much
> tougher...Matched filtering isn't going to work that well.  If you could
nail
> down either the pulse width or the rise/fall time or both you'd have
better
> success.
>
>
>
> Kolja Sulimma wrote:
> >
> > > The FPGA can handle 5-10 ns range gates fairly easily.  Getting much
shorter
> > > than that will require more specialized tricks or some high speed
external
> > > logic.
> >
> > You mean like connecting the signal to multiple pins and then having
IFFs with four
> > clock
> > phases?
> >
> > Kolja
>
> --
> -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



Article: 30006
Subject: Re: FFT in FPGAs
From: "Erik Widding" <widding@birger.com>
Date: Tue, 20 Mar 2001 10:13:41 -0500
Links: << >>  << T >>  << A >>
"Rick Collins" <spamgoeshere4@yahoo.com> wrote in message
news:3AB708AD.31959698@yahoo.com...
> Peter Alfke wrote:
> > Rick Collins wrote:
> > >  So if the XC2V40 and XC2V1000 parts were available
> > > now and I had some reason to believe that I could get them at
reasonable
> > > prices by the point of production (like a quote) I would love to
design
> > > them in.
> >
> > Consider them available, and - in your time frame- the XC2V3000 also.
>
> I will contact distribution. But I have not had much success in the past
> getting any real data. Normally the best they can tell you is price and
> delivery, and normally not even that on such new parts.

Try NuHorizons.  We placed an order for XC2V1000-4FG456CES on 3/9.
Yesterday they confirmed a factory ship date of 4/13.  I think we can trust
that
atleast XC2V40 and XC2V1000 are available as engineering samples.


Regards,
Erik Widding.

--
Birger Engineering, Inc.  --------------------------------  781.481.9233
38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com





Article: 30007
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 20 Mar 2001 08:10:28 -0800
Links: << >>  << T >>  << A >>
All,

As the chips scale, driving a 1" long wire became slower and slower (relative to
the whole picture).  Recently we removed TBUF's and replaced them with mux's in
a few thousands of designs, and without replacing and rerouting, the designs
were all faster.  They also took up more area (the mux's).  By removing TBUF's
we gain that area back (TBUF's have to be huge to drive the long wires), so that
now are still more area efficient, and higher speed than before.  With PAR, the
designs are all "better" than before.

As always, removing something is always a tough decision, and we made sure we
had a way of succeeding before we asked everyone to give them up forever (which
may happen in the future).

They were great while they lasted,

Austin

TBUF: RIP 200?

Juri Kanevski wrote:

> Neil Franklin wrote:
> >
> > In the earlier Xilinx chips (3000, 4000, 5200) there is always 2
> > TBUFs per CLB of 2 LUT+FF. And both TBUF lines can be read.
> >
> > In Virtex and Spartan-II it is down to 2 TBUFS for the 4 LUT+FF of an
> > CLB, so only one slice can be routed to them, and even only 1 line for
> > reading back from TBUF lines.
> >
> > In Virtex-II there is even only 2 TBUFs for 8 LUT+FF per CLB. Which
> > makes even connecting the output of the 4-wide 2 slices of an single
> > carry chain to an bus impossible. The data sheet does not give the
> > amount of readbacks.
> >
> > From this I get the impression, that Xilinx regards TBUF buses as going
> > out of fashion. After all, the TBUFs cost in chip space is next to nothing
> > relative to them many PIPs (about 900 per CLB in Virtex).
> >
> >
> > So I have a question: What is the Xilinx-suggested replacement for TBUFs?
> > Is one supposed to use MUXes implemented in the CLBs? Is there an other
> > trick I have not yet stumbled over?
>
> I think that Xilinx
> found a compromise in the space functionality-cost.
> For these TBUFs and tristate wires
> Xilinx's devices were 2 fold more costly than Altera's ones, I suppose,
> because of their heavy technology.
>
> And therefore the only solution is
> to try to do without large multiplexors and shared busses.
> The way to do without large shared busses in the chip
> is the stable tendency now and in the future
> because they do not support the clock frequency increase,
> and afford the high switshing energy .
>
> A.Ser.


Article: 30008
Subject: Re: Do I need to tie unused CPLD pins to GND?
From: Arthur <>
Date: Tue, 20 Mar 2001 08:45:38 -0800
Links: << >>  << T >>  << A >>
Hello -

  There is a fitter option labelled "User Programmable Grounds" that will help you. When selected, it ties all unused IO pins to ground internally so you don't need to terminate them externally.

  Regards,
  Arthur

Article: 30009
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Tue, 20 Mar 2001 11:46:25 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> All,
> 
> As the chips scale, driving a 1" long wire became slower and slower (relative to
> the whole picture).  Recently we removed TBUF's and replaced them with mux's in
> a few thousands of designs, and without replacing and rerouting, the designs
> were all faster.  They also took up more area (the mux's).  By removing TBUF's
> we gain that area back (TBUF's have to be huge to drive the long wires), so that
> now are still more area efficient, and higher speed than before.  With PAR, the
> designs are all "better" than before.
> 
> As always, removing something is always a tough decision, and we made sure we
> had a way of succeeding before we asked everyone to give them up forever (which
> may happen in the future).
> 
> They were great while they lasted,
> 
> Austin
> 
> TBUF: RIP 200?

When you say that the muxes were added, are you saying that there are
"special" muxes available? Or are you referring to the LUTs in the CLBs? 

I guess I need to read the VII data sheet in detail and learn the
architecture. It seems to be the chip to beat these days.


-- 

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

Article: 30010
Subject: Re: FFT in FPGAs
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Tue, 20 Mar 2001 12:23:57 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> BTW, word is that the start-up current on Spartan-II is being improved, and the
> current is now kind-of proportional to size (i.e. part number). So the small 15 and
> 30 spartan-II devices have a low start-up current.

This is a real make or break issue with me. What will it take to get
more info on this? Do you have any idea of when this info will be
available? Even if I can't get the info today, it will be useful to know
when it will be available. I can put off my FPGA decision for awhile,
but not without some idea of the schedule. 


-- 

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

Article: 30011
Subject: Re: TOA measurement
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 20 Mar 2001 09:37:18 -0800
Links: << >>  << T >>  << A >>
Seems to me that the fine-resolution clock phase shift in Virtex-II could help. You can
place and move a clock edge with a resolution of 1/256 of the clock period, or 50 ps,
whichever is greater. With a repetitive signal, you might use trial and error.
But Ray knows so much more about radar...

Peter Alfke
====================================
Ray Andraka wrote:

> Yes. As well as possibly using fractionally placed parallel filters for
> fractional range bin resolution.  Reading more of the posts this morning it is
> evident that your transmit pulse is not well controlled, which makes it much
> tougher...Matched filtering isn't going to work that well.  If you could nail
> down either the pulse width or the rise/fall time or both you'd have better
> success.
>
> Kolja Sulimma wrote:
> >
> > > The FPGA can handle 5-10 ns range gates fairly easily.  Getting much shorter
> > > than that will require more specialized tricks or some high speed external
> > > logic.
> >
> > You mean like connecting the signal to multiple pins and then having IFFs with four
> > clock
> > phases?
> >
> > Kolja
>
> --
> -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


Article: 30012
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Tue, 20 Mar 2001 09:49:37 -0800
Links: << >>  << T >>  << A >>

Hi,

There is no component in the unisim library, as
Ray indicated, but the back annotation tools are
aware of the component and what it does.  If you
are really dying to know what is in there, you
can manually create an NCD using fpga_editor,
and then use NGD2VER or NGD2VHDL to write out
a simulation model of it.

Eric

Ray Andraka wrote:
> 
> One would think so, but it is not there.
> 
> Simon Bacon wrote:
> >
> > I guess the logic should be available in a simulation library.

Article: 30013
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: Kolja Sulimma <kolja@bnl.gov>
Date: Tue, 20 Mar 2001 18:54:39 +0100
Links: << >>  << T >>  << A >>
As I understand it, Austin is stating that the area that was saved by removing the
TBUFs is now used for extra CLBs
(or reducing the ASIC cost per CLB)
With 90% of the FPGA area beeing in the interconnect (Andre DeHons estimates) I doubt
that you gain much of a CLB
(including its interconnect) from removing a TBUF.
Someone stated in this group that the TBUFs are not really TBUFs anymore internally
but are realized in some other patented manner. Maybe thats the reason. (The TBUFs
worst case timing got MUCH faster with virtex when compared to the carry chain, for
example)
But of course, the longlines get faster when less TBUFs are connected to them

But remember: Marketing argument are often more important that technical aspects.
Because of the huge amount of area
dedicated to routing in an FPGA it is better to waste CLBs than to waste routing and
therefore poorly routable FPGAs
are much more area efficient.then highly routable designs.
But they got bad press for bad routability, and therefore greatly improve routability.
The new trade-off may be more
expensive to manufacture, but its easier to use and less people complain.

But wait: Everybody feels happier if he has a reason to complain so they discounted
the equivalent gate count metric, and now we have a reason to complain again.

CU,
        Kolja



Rick Collins wrote:

> Austin Lesea wrote:
> >
> > All,
> >
> > As the chips scale, driving a 1" long wire became slower and slower (relative to
> > the whole picture).  Recently we removed TBUF's and replaced them with mux's in
> > a few thousands of designs, and without replacing and rerouting, the designs
> > were all faster.  They also took up more area (the mux's).  By removing TBUF's
> > we gain that area back (TBUF's have to be huge to drive the long wires), so that
> > now are still more area efficient, and higher speed than before.  With PAR, the
> > designs are all "better" than before.
> >
> > As always, removing something is always a tough decision, and we made sure we
> > had a way of succeeding before we asked everyone to give them up forever (which
> > may happen in the future).
> >
> > They were great while they lasted,
> >
> > Austin
> >
> > TBUF: RIP 200?
>
> When you say that the muxes were added, are you saying that there are
> "special" muxes available? Or are you referring to the LUTs in the CLBs?
>
> I guess I need to read the VII data sheet in detail and learn the
> architecture. It seems to be the chip to beat these days.
>
> --
>
> 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


Article: 30014
Subject: Re: FFT in FPGAs
From: Chris Dick <chrisd@xilinx.com>
Date: Tue, 20 Mar 2001 09:56:16 -0800
Links: << >>  << T >>  << A >>
Hi Rick, Xilinx currently has a 1024-pt 16b (16-bit precision for both I and
Q) complex FFT
that runs in Virtex and Virtex-E. The design occupies 1930 slices and easliy
runs at 100 MHz.
The transform time is 41 microseconds. This implementation was a balance
between reasonable performance
and area ... usual tradeoff. We are doing more FFT work. The FFTs will be
ported to the Virtex-II fabric
and use the embeded mutlipliers. We will do a port of the current FFTs and
will also be releasing a new family
of higher performance FFTs later this year. This will include some new
transform lengths.
When the current 1024-pt FFT is ported to Virtex-II it will occupy
approximately 1100 logic slices.
If you would like some more details about the FFTs please feel free to
contact me

best regards
Chris

Rick Collins wrote:

> I am looking at performing real data, fixed point FFTs in an FPGA and I
> would like to get some info on the processing time and logic size
> required. The input data is 14 bit, 2048 points. A standard optimization
> for processing real data is to fold the data into the complex input
> array, so that you only process a 1024 point FFT and then unfold the
> real data in an extra step. We have a DSP available which can do the
> final unfolding step.
>
> I checked the Altera web site and found info on their megacore function.
> For a 1K FFT, they use about 3000 LE's and 10 block rams (EABs). They
> claim the max speed is 90 MHz for 57 uS per block. This is only 3x what
> I can get from the DSP chip!
>
> Is the Altera megacore not highly optimized for speed? Are there other
> cores available that can process the data at a higher clock rate? The
> data is clocked in at 100 MHz burst rate, if it is fully pipelined and
> can start another butterfly each 4 clock cycles it should be able to
> process the data in 20 uS. Perhaps that is too much to expect since
> there are log2(N)/2 passes. I would like to process the block in 20 uS.
> At that point the processing time becomes insignificant in the overall
> process. Is that too much to expect from a hardware solution without
> using a thousand dollar chip?
>
> --
>
> 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

--
Dr Chris Dick
Xilinx DSP Group Manager
DSP Chief Architect
Xilinx Inc
2100 Logic Drive
San Jose
CA 95124

Phone: 408.879.5377
Fax:   408.626.6440
eFax:  508.355.7668



Article: 30015
Subject: Re: TOA measurement
From: Jerry Avins <jya@ieee.org>
Date: Tue, 20 Mar 2001 13:08:50 -0500
Links: << >>  << T >>  << A >>
Michal Kvasnicka wrote:
> 
  ...
> 
> Radar pulse can be approximated by trapezoidal (symmetric or asymmetric)
> pulse wit the following parameters:
> pulse width = 0.5 - 500us (50% amplitude level)
> rise time = 20-100ns
> fall time = 20-200ns
> sample interval = 1 - 10ns
> Pulse repetition interval = 1 - 5000us
> 
  ...

Why is the width (and shape) unknown? Where is the transmitter? Can you
sample the outgoing pulses and match them up with the returns?

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

Article: 30016
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: Kolja Sulimma <kolja@bnl.gov>
Date: Tue, 20 Mar 2001 20:50:36 +0100
Links: << >>  << T >>  << A >>
OK. That's what I did.
Was not as easy as it sounds, because you need to place constraints of
the type LOC=RPCILOGIC and so on.
Her is the result in cube notation:
IRDY TRDY I1 I2 I3 PCI_CE
-0--0 : 1
---1-  : 1
0-00- : 1

In other words:
PCI_CE <= I2 or (not TRDY and not I3) or (not IRDY and not I1 and not
I2);

PCI_CE connects to the output clock enable of many pins.

Has anybody any suggestions on what this is good for?

Kolja Sulimma

Eric Crabill wrote:

> Hi,
>
> There is no component in the unisim library, as
> Ray indicated, but the back annotation tools are
> aware of the component and what it does.  If you
> are really dying to know what is in there, you
> can manually create an NCD using fpga_editor,
> and then use NGD2VER or NGD2VHDL to write out
> a simulation model of it.
>
> Eric
>
> Ray Andraka wrote:
> >
> > One would think so, but it is not there.
> >
> > Simon Bacon wrote:
> > >
> > > I guess the logic should be available in a simulation library.


Article: 30017
Subject: RC5 implementations
From: Adam Elbirt <aelbirt@ece.wpi.edu>
Date: Tue, 20 Mar 2001 15:48:26 -0500
Links: << >>  << T >>  << A >>
Anyone know of published RC5 implementations in FPGAs?

Thanks.

-------------------------------------------------------------------------------------
Adam Elbirt
Cryptography and Informations Security Laboratory
Electrical and Computer Engineering Department
Worcester Polytechnic Institute
Worcester, Massachusetts
508-831-5840 Phone
508-831-5491 Fax

"Actually intelligence has far less practical use than you would think."
          -- Mensa member to Dilbert


Article: 30018
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Tue, 20 Mar 2001 12:49:09 -0800
Links: << >>  << T >>  << A >>

Hi,

You may want to double check that, I think it should be:

PCI_CE <= I2 or (not TRDY# and not I3) or (not IRDY# and not I1);

> Has anybody any suggestions on what this is good for?

It may be a useful piece of a PCI 2.2 compliant output flip flop
clock enable function...  One that meets 66 MHz timing, with no
effort required from the user or the router.

Eric

Article: 30019
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: Philip Freidin <philip@fliptronics.com>
Date: Tue, 20 Mar 2001 13:33:51 -0800
Links: << >>  << T >>  << A >>
On Tue, 20 Mar 2001 14:08:51 GMT, Ray Andraka <ray@andraka.com> wrote:
>One would think so, but it is not there.
>
>Simon Bacon wrote:
>> 
>> I guess the logic should be available in a simulation library.


It is basically a function of 5 variables. If you assumed it was
a 5-lut, then

tada ....

0xf0f0f1f1

This is the truth table with the variable ordering (msb to lsb):

PCILOGIC.TRDY PCILOGIC.I3 PCILOGIC.I2 PCILOGIC.I1 PCILOGIC.IRDY

I leave it as an exercise for the reader to figure out the gate
equivalents.

This information was derived by Mark Shand about 2 years ago,
by building it and exercising it.

At the time Mark did this, the proposed solution of the back annotation
method (proposed in another article) gave a different result.  The back
annotation was patently wrong since the logic function you got was of
no use in implementing the output CE required by PCI.  Let's hope
they have since fixed their simulation models.

Philip Freidin

Philip Freidin
Fliptronics

Article: 30020
Subject: XESS Prototyping boards - Is there a difference between...
From: lamb_baa@hotmail.rem4spam.com (Eric)
Date: 20 Mar 2001 23:23:06 GMT
Links: << >>  << T >>  << A >>
Is there a difference between the XS40-005XL+ Prototyping Board with 128 KByte 
RAM and the XS95-108+ Prototyping Board with 128 KByte SRAM other than the 
CPLD/FPGA chip?

I was thinking of just buying the CPLD board and then extracting the CPLD and 
replacing it with an FPGA when I needed it and back.

Does anyone know of any schematics/plans to make a protoboard?

Thanks
E


Article: 30021
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 20 Mar 2001 15:32:03 -0800
Links: << >>  << T >>  << A >>
All Mux's are special :)

The replacement was with CLB's (LUT's and special clb logic), which may implement the
F5, F6, F7 or even F8 in Virtex II, so they can be very efficient.

The fast that you could retarget the synthesis, and use even more powerful structures
(e.g. horizontal cascade carry) makes things even faster with less area.

The TBUF's occupy a large area in interconnect (metal wires) and buffers, and mux
trees to get in and out.  There are these strange warts that hang off the CLB and run
really slowly now that everything has scaled so well into the ultra deep sub-micron
world.

Austin

Rick Collins wrote:

> Austin Lesea wrote:
> >
> > All,
> >
> > As the chips scale, driving a 1" long wire became slower and slower (relative to
> > the whole picture).  Recently we removed TBUF's and replaced them with mux's in
> > a few thousands of designs, and without replacing and rerouting, the designs
> > were all faster.  They also took up more area (the mux's).  By removing TBUF's
> > we gain that area back (TBUF's have to be huge to drive the long wires), so that
> > now are still more area efficient, and higher speed than before.  With PAR, the
> > designs are all "better" than before.
> >
> > As always, removing something is always a tough decision, and we made sure we
> > had a way of succeeding before we asked everyone to give them up forever (which
> > may happen in the future).
> >
> > They were great while they lasted,
> >
> > Austin
> >
> > TBUF: RIP 200?
>
> When you say that the muxes were added, are you saying that there are
> "special" muxes available? Or are you referring to the LUTs in the CLBs?
>
> I guess I need to read the VII data sheet in detail and learn the
> architecture. It seems to be the chip to beat these days.
>
> --
>
> 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


Article: 30022
Subject: Re: XESS Prototyping boards - Is there a difference between...
From: Dave Vanden Bout <devb@xess.com>
Date: Tue, 20 Mar 2001 19:44:04 -0500
Links: << >>  << T >>  << A >>
Eric wrote:

> Is there a difference between the XS40-005XL+ Prototyping Board with 128 KByte
> RAM and the XS95-108+ Prototyping Board with 128 KByte SRAM other than the
> CPLD/FPGA chip?
>
> I was thinking of just buying the CPLD board and then extracting the CPLD and
> replacing it with an FPGA when I needed it and back.

The XS40 and XS95 Boards look similar but all the wiring is different, so you
cannot replace the CPLD in the XS95 with an FPGA.

>
>
> Does anyone know of any schematics/plans to make a protoboard?

We have complete schematics for all our boards in their respective user manuals.
You can also find a complete description of how to build a slightly stripped-down
version of the XS95 and XS40 Boards in an appendix of the old "Practical Xilinx
Designer Lab Book" (if you can find a copy of it since it went out of print).

>
>
> Thanks
> E




--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 30023
Subject: Re: IRDY/TRDY (was Re: More detailed Spartan II CLB drawings?)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 21 Mar 2001 02:05:30 +0000
Links: << >>  << T >>  << A >>


Kolja Sulimma wrote:

> Chris Dunlap wrote:
>
> > You can always look in FPGA editor.  Nothing can be left out there.  If its
> > routed or routable, its there.
>
> Sure it can be.
> Or can you used the mysterious undocumented IRDY/TRDY pins special features of
> Spartan-II in FPGA editor?
>
> Using a dominance in the FPGA market to get an advantage in the PCI-core market
> looks at lot like the
> Microsoft Internet Explorer case to me.
>
> CU,
>         Kolja

O.k now this one's sorted on to the next magic PCI question. In the bitgen args
list there is a set of  global clock parameters called Gclkdel0-3. I've been
assuming/wondering for some time if this is to do with meeting PCI66MHz setup
timing. The give-away is the comment line:

``You should not use this option unless instructed by Xilinx''

Any ideas ?



Article: 30024
Subject: Re: TBUFs in Virtex and later chips, going out of fashion, what instead
From: Ray Andraka <ray@andraka.com>
Date: Wed, 21 Mar 2001 02:23:19 GMT
Links: << >>  << T >>  << A >>
The problem with the CLB muxes is that they don't match the pitch of the carry
chain, so If I have a set of counters for instance that I want to address to
read onto a common bus, it is a royal pain in the patoot without the Tbufs. 
It's a good thing there is more routing in these chips!

For example, in Virtex, if I want to use the F6 mux, which would be the one I
need to mux between two slices, I need to use the F5 muxes to feed the F6. 
Since the F5 selects between the F and  G LUTs, this structure is broken for
connecting to carry chain logic.  


Austin Lesea wrote:
> 
> All Mux's are special :)
> 
> The replacement was with CLB's (LUT's and special clb logic), which may implement the
> F5, F6, F7 or even F8 in Virtex II, so they can be very efficient.
> 
> The fast that you could retarget the synthesis, and use even more powerful structures
> (e.g. horizontal cascade carry) makes things even faster with less area.
> 
> The TBUF's occupy a large area in interconnect (metal wires) and buffers, and mux
> trees to get in and out.  There are these strange warts that hang off the CLB and run
> really slowly now that everything has scaled so well into the ultra deep sub-micron
> world.
> 
> Austin
> 
> Rick Collins wrote:
> 
> > Austin Lesea wrote:
> > >
> > > All,
> > >
> > > As the chips scale, driving a 1" long wire became slower and slower (relative to
> > > the whole picture).  Recently we removed TBUF's and replaced them with mux's in
> > > a few thousands of designs, and without replacing and rerouting, the designs
> > > were all faster.  They also took up more area (the mux's).  By removing TBUF's
> > > we gain that area back (TBUF's have to be huge to drive the long wires), so that
> > > now are still more area efficient, and higher speed than before.  With PAR, the
> > > designs are all "better" than before.
> > >
> > > As always, removing something is always a tough decision, and we made sure we
> > > had a way of succeeding before we asked everyone to give them up forever (which
> > > may happen in the future).
> > >
> > > They were great while they lasted,
> > >
> > > Austin
> > >
> > > TBUF: RIP 200?
> >
> > When you say that the muxes were added, are you saying that there are
> > "special" muxes available? Or are you referring to the LUTs in the CLBs?
> >
> > I guess I need to read the VII data sheet in detail and learn the
> > architecture. It seems to be the chip to beat these days.
> >
> > --
> >
> > 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

-- 
-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



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