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 36925

Article: 36925
Subject: Re: How to make an implementable big counter?
From: edick@hotmail.com (Richard Erlacher)
Date: Mon, 26 Nov 2001 15:54:47 GMT
Links: << >>  << T >>  << A >>
see below, plz.

Dick

On Sun, 25 Nov 2001 04:10:13 GMT, Peter Alfke <palfke@earthlink.net>
wrote:

>Dick, the way I understand this, you have a continuously running counter
>that sampels incoming data. Every 16 clock ticks you dump the assembled data
>
Actually, I want a 22-bit synchronous and monotonic counter, the
outputs of which are valid for every count, as I need them for
addressing the buffer RAM.  I also need this to fit into a PLCC-84
package.  I don't believe there's a part that fits in the PLCC-84 that
also has enough RAM space.  (Perhaps an updated databook would help me
here ... My last one's from 1999).  There's good economic reason for
the PLCC package, but it's not relevant to this discussion.  The
counter doesn't run all the time, and it uses the MSB as a
count-disable.  When it's reset, it runs until the MSB is set.

>word into a DRAM ( why not SRAM, which would save you the fancy control and
>the refresh ? And in Virtex-II you could easily store it in the BlockRAMs
>inside...)

Have you got parts that one can afford, costing less than 10x what the
DRAM costs and with 512KB of RAM available in a package one can use at
reasonable cost in quantities numbered in dozens rather than multiples
of 1k/week? 

>Absolutely under all circumstances use a modern FPGA with dedicated carry,
>like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II.
>Depending on the family, the carry delay is between 50 and 100 ps per bit,
>so you should not have any difficulty with your 22 bits.
>But if you are very conservative, you can break the counter into a 4-bit
>front-end, decode its all-ones state (F), and use it as a count enable for
>the remaining 18 bits.This is all very easy, and is totally synchronous. It
>does not create any pipeline delay or other funnies. Your code is all
>binary, like you want it to be.
>
Yes, the current stuff is all that's under consideration, though I'm
looking at some CPLD's as well because the logic is actually pretty
simple.  The problem is simply in getting a long enough counter that
runs at the desired speed without having too many pins on the package
and the associated cost per pin.  Once the package is bigger than the
PLCC-84 the costs associated with using the package seem to go through
the roof for a number of reasons.  I know I can shorten the counter by
separating the 
>
>Have fun!
>
>Peter Alfke, Xilinx Applications
>============================
>Richard Erlacher wrote:
>
>> Well, OK ... Let's try this.
>>
>> We have a data stream that has to be sampled at 120 MHz, assembled
>> into words and shoved into an external DRAM.  The DRAM is small
>> (256Kx16) and the data will be assembled and then registered as words
>> before being pipelined off into the RAM.  States of the fast end of
>> the counter have to be decoded in order to synchronize the operation
>> with the RAM, and the MSB of the counter is a "DONE" bit.  When the
>> counter is reset, it runs until the msb, used as the count enable,
>> goes true.  That's a 22-bit counter ...  Not terribly long, but long
>> enough.  I suppose this could be done as 3-bit counter and a 19-bit
>> counter, but, either way, it's painful.  The DRAM access has to be
>> done in short (page-mode) bursts, which is why the synchronization of
>> the decoding of the lower 3-bit section of the counter is critical.
>>
>> How close to the required 120 MHz can this counter be made to go in an
>> FPGA with 5-volt-tolerant I/O?  It's got to be synchronous and the
>> sequence has to be monotonic, so the same counter will be useable to
>> accomplish refresh as required.  LFSR's don't produce that sort of
>> sequence.  What other alternatives are there?
>>
>> Dick
>>
>


Article: 36926
Subject: Re: slew rate of virtex output buffers figures
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 26 Nov 2001 08:08:35 -0800
Links: << >>  << T >>  << A >>
Rick,

I was having a bad week last week, so I apologize to everyone for my curt
comments.

I will say that I get tired of people asking me the same question over and
over, and the joke around here is to answer every question with:  "Did you
simulate it?"  And, as I said before, we do simulate test cases, and real
pcb's for our customers through the hotline.

The full blown HyperLynx form Innoveda is less than one proto run of the pcb
boards.

Now, how can you argue with that?

You say to your boss (or the company you are contracting for),

"I need this tool.  It costs about the same as one proto run of boards -
fab, parts, assembly.  If I have this tool, the number of times we go
through the task of building boards is reduced by at least ONE.  In the
future, with experience, the number of board turns will almost never exceed
ONE (at least for signal integrity reasons!)"

The demo on Innoveda's website for HyperLynx is free.  It doesn't allow you
to store, or print, or load new IBIS files, but it is great for "what if I
did this..." kind of things.  Once you start to use it, you are hooked, and
you need to go sell it to your 'cost savings' accounting department (as a
true means of lowering costs).

I have made the cost argument here, so folks will just go spend some money
wisely.

There is another argument:  can you continue to exist when your competition
made their prototypes work in one quarter the time, and at three times less
money than you did?

Austin

Rick Filipkiewicz wrote:

> Peter Alfke wrote:
>
> > Let me make a constructive suggestion:
> >
> > We will publish a step-by-step cookbook how you can use the free
> > version of HypeLynx to analyze output behavior with astounding
> > accuracy and surprising ease.
>
> Do you mean the "demo" version or is there something else I can't see on
> the site? I had a look there some while ago but the word "demo" to me
> tends to mean next-to-useless. Maybe my cynisism is misplaced in this
> case ...
>
> <snip>
>
> >
> > That's what Austin meant when he mentioned the need to learn how to
> > fish.
> > Signal integrity is no longer a subject only for the speed-demons, it
> > affects every design.
> > We all have got lo learn this "new" discipline, whether we want to or
> > not.
> > And the available tools actually make it fun, once you master them.
>
> I agree & I want to, finally, start getting to grips with this stuff. In
> the past, though, what's tended to put me off is the quantity of $$$s
> required to get into it, a bit like simulation & synthesis tools until
> ModelSIM-PE & Synplicity came along.


Article: 36927
Subject: Re: How to make an implementable big counter?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 26 Nov 2001 09:42:15 -0800
Links: << >>  << T >>  << A >>

--------------079A41933EB3582B88A78609
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Dick, I suggest the XCS05 or XCS05XL.
They come in PLCC84 packages ( we call it PC84)
They have a 10 x 10 matrix of Logic Blocks, each with 2 flip-flops.
The carry chain runs vertically,  so I would create an 18-bit counter in 9 CLBs,
and drive the clock enable from the decoded F of the less significant 4 bits.
That gives you a synchronous 22-bit counter. Teh carry-chain delay is irrelevant
since it has 16 clock ticks to settle. You can make the 4-bit front end run at
up to 200 MHz in the -5 speed grade XCS05XL.
All this takes less than 15% of the chip, so you can still add a lot of stuff.
And the XCS05 ( Vcc=5V) and XCS05XL (Vcc=3.3V) are really cheap., the cheapest
FPGAs we make.
I would use the 3.3-V -XL device, since it is much faster, and I would not start
any new design today with a 5-V device.
5V is definitely obsolete !  State-of-the-art is now 1.5 V.

For detailed information, click on:

http://www.xilinx.com/partinfo/ds060.pdf

Peter Alfke, Xilinx Applications
========================================
Richard Erlacher wrote:

> see below, plz.
>
> Dick
>
> On Sun, 25 Nov 2001 04:10:13 GMT, Peter Alfke <palfke@earthlink.net>
> wrote:
>
> >Dick, the way I understand this, you have a continuously running counter
> >that sampels incoming data. Every 16 clock ticks you dump the assembled data
> >
> Actually, I want a 22-bit synchronous and monotonic counter, the
> outputs of which are valid for every count, as I need them for
> addressing the buffer RAM.  I also need this to fit into a PLCC-84
> package.  I don't believe there's a part that fits in the PLCC-84 that
> also has enough RAM space.  (Perhaps an updated databook would help me
> here ... My last one's from 1999).  There's good economic reason for
> the PLCC package, but it's not relevant to this discussion.  The
> counter doesn't run all the time, and it uses the MSB as a
> count-disable.  When it's reset, it runs until the MSB is set.
>
> >word into a DRAM ( why not SRAM, which would save you the fancy control and
> >the refresh ? And in Virtex-II you could easily store it in the BlockRAMs
> >inside...)
>
> Have you got parts that one can afford, costing less than 10x what the
> DRAM costs and with 512KB of RAM available in a package one can use at
> reasonable cost in quantities numbered in dozens rather than multiples
> of 1k/week?
>
> >Absolutely under all circumstances use a modern FPGA with dedicated carry,
> >like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II.
> >Depending on the family, the carry delay is between 50 and 100 ps per bit,
> >so you should not have any difficulty with your 22 bits.
> >But if you are very conservative, you can break the counter into a 4-bit
> >front-end, decode its all-ones state (F), and use it as a count enable for
> >the remaining 18 bits.This is all very easy, and is totally synchronous. It
> >does not create any pipeline delay or other funnies. Your code is all
> >binary, like you want it to be.
> >
> Yes, the current stuff is all that's under consideration, though I'm
> looking at some CPLD's as well because the logic is actually pretty
> simple.  The problem is simply in getting a long enough counter that
> runs at the desired speed without having too many pins on the package
> and the associated cost per pin.  Once the package is bigger than the
> PLCC-84 the costs associated with using the package seem to go through
> the roof for a number of reasons.  I know I can shorten the counter by
> separating the
> >
> >Have fun!
> >
> >Peter Alfke, Xilinx Applications
> >============================
> >Richard Erlacher wrote:
> >
> >> Well, OK ... Let's try this.
> >>
> >> We have a data stream that has to be sampled at 120 MHz, assembled
> >> into words and shoved into an external DRAM.  The DRAM is small
> >> (256Kx16) and the data will be assembled and then registered as words
> >> before being pipelined off into the RAM.  States of the fast end of
> >> the counter have to be decoded in order to synchronize the operation
> >> with the RAM, and the MSB of the counter is a "DONE" bit.  When the
> >> counter is reset, it runs until the msb, used as the count enable,
> >> goes true.  That's a 22-bit counter ...  Not terribly long, but long
> >> enough.  I suppose this could be done as 3-bit counter and a 19-bit
> >> counter, but, either way, it's painful.  The DRAM access has to be
> >> done in short (page-mode) bursts, which is why the synchronization of
> >> the decoding of the lower 3-bit section of the counter is critical.
> >>
> >> How close to the required 120 MHz can this counter be made to go in an
> >> FPGA with 5-volt-tolerant I/O?  It's got to be synchronous and the
> >> sequence has to be monotonic, so the same counter will be useable to
> >> accomplish refresh as required.  LFSR's don't produce that sort of
> >> sequence.  What other alternatives are there?
> >>
> >> Dick
> >>
> >

--------------079A41933EB3582B88A78609
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Dick, I suggest the XCS05 or XCS05XL.
<br>They come in PLCC84 packages ( we call it PC84)
<br>They have a 10 x 10 matrix of Logic Blocks, each with 2 flip-flops.
<br>The carry chain runs vertically,&nbsp; so I would create an 18-bit
counter in 9 CLBs, and drive the clock enable from the decoded F of the
less significant 4 bits.
<br>That gives you a synchronous 22-bit counter. Teh carry-chain delay
is irrelevant since it has 16 clock ticks to settle. You can make the 4-bit
front end run at up to 200 MHz in the -5 speed grade XCS05XL.
<br>All this takes less than 15% of the chip, so you can still add a lot
of stuff.
<br>And the XCS05 ( Vcc=5V) and XCS05XL (Vcc=3.3V) are really cheap., the
cheapest FPGAs we make.
<br>I would use the 3.3-V -XL device, since it is much faster, and I would
not start any new design today with a 5-V device.
<br>5V is definitely obsolete !&nbsp; State-of-the-art is now 1.5 V.
<p>For detailed information, click on:
<p><u><A HREF="http://www.xilinx.com/partinfo/ds060.pdf">http://www.xilinx.com/partinfo/ds060.pdf</A></u><u></u>
<p>Peter Alfke, Xilinx Applications
<br>========================================
<br>Richard Erlacher wrote:
<blockquote TYPE=CITE>see below, plz.
<p>Dick
<p>On Sun, 25 Nov 2001 04:10:13 GMT, Peter Alfke &lt;palfke@earthlink.net>
<br>wrote:
<p>>Dick, the way I understand this, you have a continuously running counter
<br>>that sampels incoming data. Every 16 clock ticks you dump the assembled
data
<br>>
<br>Actually, I want a 22-bit synchronous and monotonic counter, the
<br>outputs of which are valid for every count, as I need them for
<br>addressing the buffer RAM.&nbsp; I also need this to fit into a PLCC-84
<br>package.&nbsp; I don't believe there's a part that fits in the PLCC-84
that
<br>also has enough RAM space.&nbsp; (Perhaps an updated databook would
help me
<br>here ... My last one's from 1999).&nbsp; There's good economic reason
for
<br>the PLCC package, but it's not relevant to this discussion.&nbsp; The
<br>counter doesn't run all the time, and it uses the MSB as a
<br>count-disable.&nbsp; When it's reset, it runs until the MSB is set.
<p>>word into a DRAM ( why not SRAM, which would save you the fancy control
and
<br>>the refresh ? And in Virtex-II you could easily store it in the BlockRAMs
<br>>inside...)
<p>Have you got parts that one can afford, costing less than 10x what the
<br>DRAM costs and with 512KB of RAM available in a package one can use
at
<br>reasonable cost in quantities numbered in dozens rather than multiples
<br>of 1k/week?
<p>>Absolutely under all circumstances use a modern FPGA with dedicated
carry,
<br>>like e.g. Xilinx Spartan, Spartan XL, Spartan-II, Virtex, or Virtex-II.
<br>>Depending on the family, the carry delay is between 50 and 100 ps
per bit,
<br>>so you should not have any difficulty with your 22 bits.
<br>>But if you are very conservative, you can break the counter into a
4-bit
<br>>front-end, decode its all-ones state (F), and use it as a count enable
for
<br>>the remaining 18 bits.This is all very easy, and is totally synchronous.
It
<br>>does not create any pipeline delay or other funnies. Your code is
all
<br>>binary, like you want it to be.
<br>>
<br>Yes, the current stuff is all that's under consideration, though I'm
<br>looking at some CPLD's as well because the logic is actually pretty
<br>simple.&nbsp; The problem is simply in getting a long enough counter
that
<br>runs at the desired speed without having too many pins on the package
<br>and the associated cost per pin.&nbsp; Once the package is bigger than
the
<br>PLCC-84 the costs associated with using the package seem to go through
<br>the roof for a number of reasons.&nbsp; I know I can shorten the counter
by
<br>separating the
<br>>
<br>>Have fun!
<br>>
<br>>Peter Alfke, Xilinx Applications
<br>>============================
<br>>Richard Erlacher wrote:
<br>>
<br>>> Well, OK ... Let's try this.
<br>>>
<br>>> We have a data stream that has to be sampled at 120 MHz, assembled
<br>>> into words and shoved into an external DRAM.&nbsp; The DRAM is small
<br>>> (256Kx16) and the data will be assembled and then registered as
words
<br>>> before being pipelined off into the RAM.&nbsp; States of the fast
end of
<br>>> the counter have to be decoded in order to synchronize the operation
<br>>> with the RAM, and the MSB of the counter is a "DONE" bit.&nbsp;
When the
<br>>> counter is reset, it runs until the msb, used as the count enable,
<br>>> goes true.&nbsp; That's a 22-bit counter ...&nbsp; Not terribly
long, but long
<br>>> enough.&nbsp; I suppose this could be done as 3-bit counter and
a 19-bit
<br>>> counter, but, either way, it's painful.&nbsp; The DRAM access has
to be
<br>>> done in short (page-mode) bursts, which is why the synchronization
of
<br>>> the decoding of the lower 3-bit section of the counter is critical.
<br>>>
<br>>> How close to the required 120 MHz can this counter be made to go
in an
<br>>> FPGA with 5-volt-tolerant I/O?&nbsp; It's got to be synchronous
and the
<br>>> sequence has to be monotonic, so the same counter will be useable
to
<br>>> accomplish refresh as required.&nbsp; LFSR's don't produce that
sort of
<br>>> sequence.&nbsp; What other alternatives are there?
<br>>>
<br>>> Dick
<br>>>
<br>></blockquote>
</html>

--------------079A41933EB3582B88A78609--


Article: 36928
Subject: Simple Logic State Analyser
From: "Gunther May" <g.may@tu-bs.de>
Date: Mon, 26 Nov 2001 19:40:57 +0100
Links: << >>  << T >>  << A >>
Dear FPGA experts,

does someone have got a design for a simple logic analyser, for example a
PC-controlled circuit?
I am a student and I  would like to have such a device with at least 16
inputs and 50MHz sample rate.
In the internet, I found a nice design which was unfortunately based an
older PLD which is not available any more.

Thank you very much!
Gunther May



Article: 36929
Subject: Re: ALTERA's Mercury CDR
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 26 Nov 2001 19:44:27 +0100
Links: << >>  << T >>  << A >>
"Wolfgang Loewer" <wolfgang.loewer@elca.de> writes:

> Peter,
> you write "the granularity of the clocking scheme is 300 ps at best". Can
> you please elaborate on what this assertion is based upon.
> 
> From: AN 130, CDR in Mercury Devices, page 8:
> "... Each of the eight equally-spaced phase clocks is divided into seven
> fractions; therefore, the resulting best-case clock granularity is 1/56 of
> the clock period. ..."

"best case": It can absolutely, never, ever get better than this, but
possibly worse.

14 ps seems pretty good. Perhaps you hit another limit at high frequencies.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 36930
Subject: Re: ALTERA's Mercury CDR
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 26 Nov 2001 11:07:23 -0800
Links: << >>  << T >>  << A >>
The Virtex-II data sheet shows that the Xilinx devices support the LVDS standard, driving 250 to
400 mV across the 100 Ohm termination resistor. This takes a total of max 8 mA Icc for the
transmitter, since there also is internal termination at the driving end. ( the receiver uses 2
mA) This dc current must be multiplied by Vcc, which is either 2.5 or 3.3 V.
It's as simple as that, and nobody can be any better.

Peter Alfke
==============================
Rotem Gazit wrote:

> Peter,
> Can you elaborate (or give a pointer) on how Xilinx calculates its
> LVDS buffers power consumption ?
> Do Xilinx LVDS buffers support the full LVDS specification, or just
> the "reduced range" ?.
>
> Thanks,
> Rotem Gazit
> MystiCom LTD
> mailto:rotemg@mysticom.com
> http://www.mysticom.com/
>
> Peter Alfke <palfke@earthlink.net> wrote in message news:<3C015E9A.B98CA518@earthlink.net>...
> > Here are some observations from my not-so-impartial viewpoint:
> >
> > 1. The Altera clock recovery requires a specialized training sequence.
> >
> > 2. The claim that it eliminates the need for balanced pc-bord trace length is
> > somewhat strange, since the granularity of the clocking scheme is 300 ps at
> > best. That is equivalent to about 2 inches or 5 cm trace length. For any of the
> > more realistic smaller differences in trace length, this adaptive per-bit
> > clocking scheme offers no advantage.
> >
> > 3. And finally, Altera makes bogus claims about LVDS power consumption, where
> > they quote not the consumed power (Vcc x Icc ) in the driver, but rather the
> > power dissipated in the 100 Ohm termination resistor. Nobody cares about this
> > nice low number, which makes it a candidate for the "Misleading Marketing"
> > award of the year.
> >
> > Parallel busses with 800 Mbps per channel are challenging today.
> > Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking.
> > Xilinx goes for fine-granularity ( 50 ps ) common clocking.
> > Guess which one I like better.
> >
> > And next year, self-clocking bit-serial 2.5 Gbps,
> > with 4-channel bonding for 10 Gbps data traffic will become the standard.
> >
> > Peter Alfke, Xilinx Applications Engineering.
> > ========================================
> > Arie Zychlinski wrote:
> >
> > > I would be much obliged to learn for your experience with the ALTERA's
> > > Mercury CDR using the M1GXCVR core. we intend to use it in a new project for
> > > 800 Mbps links.
> > > thank you in advance.
> > >
> > > --
> > >
> > >                            yours -
> > >                                      Arie Z.
> > >
> > > ============================================
> > >  Arie  Zychlinski
> > >  R&D Consulting & Development
> > >  P.O.Box  536
> > >  Kfar-Saba  44104
> > >  ISRAEL
> > >
> > >  Mobile: 972-58-320230
> > >  Phone:  W: 972-9-7673074   H: 972-9-7658268
> > >
> > >  E-Mail:  ariez@attglobal.net
> > >  ===========================================


Article: 36931
Subject: Re: fpga programming using microcontroller
From: Eric <erv_fedupwith_spam@sympatico.ca>
Date: Mon, 26 Nov 2001 14:32:56 -0500
Links: << >>  << T >>  << A >>
Hi,

swan a écrit :

> hi,
> i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?

It's much easier than it seems, using the slave serial mode (and not JTAG).

Assuming that you have a 8 bits controller with external bus, connect the Spartan's D0 line to
the processor's  D7 line, CCLK to a decoded "Chip Select" output (simple qualified address
decoding),  and PROGRAM to a port pin (can be tied with the processor's Reset if you have
an external watchdog).

The software does the following :

- Apply a pulse to the "PROGRAM" pin (if PROGRAM is not tied to Reset)
- Wait at least 1 ms
- Start reading the ".bit" file until you find a $FF followed by a $2x (this is to skip the header)
  (if your ROM space is tight, you can safely remove the header from the ".bit" file before
  it's linked to your application)
- Write each subsequent byte to the CS decoded address (8 times per byte, with left rotation)
- Write $FF twice (can't remember why I did that, maybe you can skip it)

That's it ! Your Spartan should be configured.

Note that neither "INIT" or "DONE" is used since (unless the processor & FPGA functions are
completely unrelated after configuration) the processor can check the FPGA to determine if it's
properly configured or not (I usually add a loadable counter with inverted output as an internal
register to my designs for this purpose).

If configuration failed, it can be retried (if  PROGRAM is connected to the processor's reset,
just "hang" the processor in an endless loop and wait for the watchdog reset).

You can find below x86 code that does it all. It's written in 16 bits Delphi/assembly for an embedded
target, but it's simple enough to give you some clues.

hope this helps...

Eric.

--------------------------------------------------------------------------------------------------------------------------------

unit XiLoad;

interface
uses SysLib,Cpu186;

const BitStream_XCS05 = 6900; {}

Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;

implementation

{Din = D7 / PROGRAM pin = P1-3(80C186EB) }

procedure Xil_WB (B:Byte;Addr:Word);

begin
 asm
  MOV   AL,[BP+06]
  MOV   DX,[BP+04]
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  end;
end;


Procedure xil_block (p:pointer;l,addr:Word);

begin
 asm
  LES   DI,[BP+08]
  MOV   CX,[BP+06]
@1:
  MOV   AL,ES:[DI]
  MOV   DX,[BP+04]
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  INC   DI
  DEC   CX
  JNZ   @1
  end;
end;


Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;

var f,state : word;
    by  : Byte;
    byp : ^byte absolute p;
    Position:Longint;

Begin
 Result:=False;
 if byp<>Nil then
  begin
   Set_Control(P1LTCH,$000F); { Program pin inactive }
   Dly (1); { Delay so that the pulse is long enough }
   Set_Control(P1LTCH,$0007);; { Pulses "PROGRAM" (INIT) pin low }
   Dly (16); { Delay so that the pulse is long enough }
   Set_Control(P1LTCH,$000F); { Program pin inactive }
   Dly (1); { Delay so that the pulse is long enough }
   state:=0;
   Position:=0;
   Result:=True;
   while (Position<L) and Result do
    begin
     by:=byp^;
     inc (byp);
     Inc(position);
     case state of
      1 : if by and $F0 = $20 then
            begin
             xil_wb($FF,Addr);
             xil_wb(by,Addr);
             xil_block (byp,word(l-Position),Addr);
             Position:=L;
            end
           else
            state:=0;
      0 : if by=$FF then state:=1;
      end;
    end;
   xil_wb($FF,Addr);
   xil_wb($FF,Addr);
   Result:=true;
  end;
End;



Article: 36932
Subject: Re: ALTERA's Mercury CDR -- whoops, misplaced comments
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 26 Nov 2001 11:34:13 -0800
Links: << >>  << T >>  << A >>

--------------AB840AD6FD044D218C3530FC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Wolfgang,

Correct, we are just a bit excited about some other claims we have heard lately
regarding Apex II.

To guess the average phase of a single serial stream in Mercury's all two family
devices (120K gates, and 350K gates) dedicated 1.25 Gb/s
serializer/deserializers, you are correct.

The 50 ppm clock requirement is pretty tight in Mercury, I thought all those
quoted industry specs require a 200 ppm clock tolerance?.....



In Apex II's LVDS (Appnote 157, 162, 166), the per bit deskew is pretty useless
(Figure 6, page 7), which was Peter's (misplaced) comment.

It is one thing to claim "per bit deskew" in Mercury (where it is at least
possible), it is another to claim it in Apex II, where it is clearly not
possible (what has gotten Peter excited of late).

Peter's oversight was his Apex II comment about Mercury's CDR.  Peter has
realized this, but was running off to a meeting right now, so I offered to
respond.


As for Virtex II's clock granularity, it does not claim, and does not have CDR
for high speed gigabit serial channels.  The granularity of the DCM is useful
for the LVDS wide bus application, which does compare favorably with the Apex II
solution (Peter's point).

It is no secret we purchased Rocket Chips, and it is also no secret we licensed
proven IP from Connexant/Mindspeed.  Stay tuned ....  exciting times to come!

Austin



Wolfgang Loewer wrote:

> Peter,
> you write "the granularity of the clocking scheme is 300 ps at best". Can
> you please elaborate on what this assertion is based upon.
>
> From: AN 130, CDR in Mercury Devices, page 8:
> "... Each of the eight equally-spaced phase clocks is divided into seven
> fractions; therefore, the resulting best-case clock granularity is 1/56 of
> the clock period. ..."
>
> 1/56 of a 1.25 GHz clock is equal to about 14 ps.
>
> 14 ps in today's Altera devices compared to 50 ps granularity in future
> Xilinx devices - please correct me if I have misinterpreted something here,
> but guess which one I like better.
>
> Wolfgang
> http://www.elca.de
>
> "Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
> news:3C015E9A.B98CA518@earthlink.net...
> > Here are some observations from my not-so-impartial viewpoint:
> >
> > 1. The Altera clock recovery requires a specialized training sequence.
> >
> > 2. The claim that it eliminates the need for balanced pc-bord trace length
> is
> > somewhat strange, since the granularity of the clocking scheme is 300 ps
> at
> > best. That is equivalent to about 2 inches or 5 cm trace length. For any
> of the
> > more realistic smaller differences in trace length, this adaptive per-bit
> > clocking scheme offers no advantage.
> >
> > 3. And finally, Altera makes bogus claims about LVDS power consumption,
> where
> > they quote not the consumed power (Vcc x Icc ) in the driver, but rather
> the
> > power dissipated in the 100 Ohm termination resistor. Nobody cares about
> this
> > nice low number, which makes it a candidate for the "Misleading Marketing"
> > award of the year.
> >
> > Parallel busses with 800 Mbps per channel are challenging today.
> > Altera goes for coarse-granularity ( 300 ps ) individual per-bit clocking.
> > Xilinx goes for fine-granularity ( 50 ps ) common clocking.
> > Guess which one I like better.
> >
> > And next year, self-clocking bit-serial 2.5 Gbps,
> > with 4-channel bonding for 10 Gbps data traffic will become the standard.
> >
> > Peter Alfke, Xilinx Applications Engineering.
> > ========================================
> > Arie Zychlinski wrote:
> >
> > > I would be much obliged to learn for your experience with the ALTERA's
> > > Mercury CDR using the M1GXCVR core. we intend to use it in a new project
> for
> > > 800 Mbps links.
> > > thank you in advance.
> > >
> > > --
> > >
> > >                            yours -
> > >                                      Arie Z.
> > >
> > > ============================================
> > >  Arie  Zychlinski
> > >  R&D Consulting & Development
> > >  P.O.Box  536
> > >  Kfar-Saba  44104
> > >  ISRAEL
> > >
> > >  Mobile: 972-58-320230
> > >  Phone:  W: 972-9-7673074   H: 972-9-7658268
> > >
> > >  E-Mail:  ariez@attglobal.net
> > >  ===========================================
> >

--------------AB840AD6FD044D218C3530FC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Wolfgang,
<p>Correct, we are just a bit excited about some other claims we have heard
lately regarding Apex II.
<p>To guess the average phase of a single serial stream in <b>Mercury's
all <u>two</u> family devices (120K gates, and 350K gates) </b>dedicated
1.25 Gb/s serializer/deserializers, you are correct.
<p>The 50 ppm clock requirement is pretty tight in Mercury, I thought all
those quoted industry specs require a 200 ppm clock tolerance?.....
<br>&nbsp;
<br>&nbsp;
<p>In <b>Apex II's</b> LVDS (Appnote 157, 162, 166), the per bit deskew
is pretty useless (Figure 6, page 7), which was Peter's (misplaced) comment.
<p>It is one thing to claim "per bit deskew" in Mercury (where it is at
least possible), it is another to claim it in Apex II, where it is clearly
not possible (what has gotten Peter excited of late).
<p>Peter's oversight was his Apex II comment about Mercury's CDR.&nbsp;
Peter has realized this, but was running off to a meeting right now, so
I offered to respond.
<br>&nbsp;
<p>As for Virtex II's clock granularity, it does not claim, and does not
have CDR for high speed gigabit serial channels.&nbsp; The granularity
of the DCM is useful for the LVDS wide bus application, which does compare
favorably with the Apex II solution (Peter's point).
<p>It is no secret we purchased Rocket Chips, and it is also no secret
we licensed proven IP from Connexant/Mindspeed.&nbsp; Stay tuned ....&nbsp;
exciting times to come!
<p>Austin
<br>&nbsp;
<br>&nbsp;
<p>Wolfgang Loewer wrote:
<blockquote TYPE=CITE>Peter,
<br>you write "the granularity of the clocking scheme is 300 ps at best".
Can
<br>you please elaborate on what this assertion is based upon.
<p>From: AN 130, CDR in Mercury Devices, page 8:
<br>"... Each of the eight equally-spaced phase clocks is divided into
seven
<br>fractions; therefore, the resulting best-case clock granularity is
1/56 of
<br>the clock period. ..."
<p>1/56 of a 1.25 GHz clock is equal to about 14 ps.
<p>14 ps in today's Altera devices compared to 50 ps granularity in future
<br>Xilinx devices - please correct me if I have misinterpreted something
here,
<br>but guess which one I like better.
<p>Wolfgang
<br><a href="http://www.elca.de">http://www.elca.de</a>
<p>"Peter Alfke" &lt;palfke@earthlink.net> schrieb im Newsbeitrag
<br><a href="news:3C015E9A.B98CA518@earthlink.net">news:3C015E9A.B98CA518@earthlink.net</a>...
<br>> Here are some observations from my not-so-impartial viewpoint:
<br>>
<br>> 1. The Altera clock recovery requires a specialized training sequence.
<br>>
<br>> 2. The claim that it eliminates the need for balanced pc-bord trace
length
<br>is
<br>> somewhat strange, since the granularity of the clocking scheme is
300 ps
<br>at
<br>> best. That is equivalent to about 2 inches or 5 cm trace length.
For any
<br>of the
<br>> more realistic smaller differences in trace length, this adaptive
per-bit
<br>> clocking scheme offers no advantage.
<br>>
<br>> 3. And finally, Altera makes bogus claims about LVDS power consumption,
<br>where
<br>> they quote not the consumed power (Vcc x Icc ) in the driver, but
rather
<br>the
<br>> power dissipated in the 100 Ohm termination resistor. Nobody cares
about
<br>this
<br>> nice low number, which makes it a candidate for the "Misleading Marketing"
<br>> award of the year.
<br>>
<br>> Parallel busses with 800 Mbps per channel are challenging today.
<br>> Altera goes for coarse-granularity ( 300 ps ) individual per-bit
clocking.
<br>> Xilinx goes for fine-granularity ( 50 ps ) common clocking.
<br>> Guess which one I like better.
<br>>
<br>> And next year, self-clocking bit-serial 2.5 Gbps,
<br>> with 4-channel bonding for 10 Gbps data traffic will become the standard.
<br>>
<br>> Peter Alfke, Xilinx Applications Engineering.
<br>> ========================================
<br>> Arie Zychlinski wrote:
<br>>
<br>> > I would be much obliged to learn for your experience with the ALTERA's
<br>> > Mercury CDR using the M1GXCVR core. we intend to use it in a new
project
<br>for
<br>> > 800 Mbps links.
<br>> > thank you in advance.
<br>> >
<br>> > --
<br>> >
<br>> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
yours -
<br>> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Arie Z.
<br>> >
<br>> > ============================================
<br>> >&nbsp; Arie&nbsp; Zychlinski
<br>> >&nbsp; R&amp;D Consulting &amp; Development
<br>> >&nbsp; P.O.Box&nbsp; 536
<br>> >&nbsp; Kfar-Saba&nbsp; 44104
<br>> >&nbsp; ISRAEL
<br>> >
<br>> >&nbsp; Mobile: 972-58-320230
<br>> >&nbsp; Phone:&nbsp; W: 972-9-7673074&nbsp;&nbsp; H: 972-9-7658268
<br>> >
<br>> >&nbsp; E-Mail:&nbsp; ariez@attglobal.net
<br>> >&nbsp; ===========================================
<br>></blockquote>
</html>

--------------AB840AD6FD044D218C3530FC--


Article: 36933
Subject: Re: fpga programming using microcontroller
From: Eric <erv_fedupwith_spam@sympatico.ca>
Date: Mon, 26 Nov 2001 14:57:19 -0500
Links: << >>  << T >>  << A >>
Hi,

swan a écrit :

> hi,
> i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?
> rgds
> swan

It's much easier than it seems, using the slave serial mode (and not JTAG).

Assuming that you have a 8 bits controller with external bus, connect the Spartan's D0 line to
the processor's  D7 line, CCLK to a decoded "Chip Select" output (simple qualified address
decoding),  and PROGRAM to a port pin (can be tied with the processor's Reset if you have
an external watchdog).

The software does the following :

- Apply a pulse to the "PROGRAM" pin (if PROGRAM is not tied to Reset)
- Wait at least 1 ms
- Start reading the ".bit" file until you find a $FF followed by a $2x (this is to skip the header)
  (if your ROM space is tight, you can safely remove the header from the ".bit" file before
  it's linked to your application)
- Write each subsequent byte to the CS decoded address (8 times per byte, with left rotation)
- Write $FF twice (can't remember why I did that, maybe you can skip it)

That's it ! Your Spartan should be configured.

Note that neither "INIT" or "DONE" is used since (unless the processor & FPGA functions are
completely unrelated after configuration) the processor can check the FPGA to determine if it's
properly configured or not (I usually add a loadable counter with inverted output as an internal
register to my designs for this purpose).

If configuration failed, it can be retried (if  PROGRAM is connected to the processor's reset,
just "hang" the processor in an endless loop and wait for the watchdog reset).

You can find below x86 code that does it all. It's written in 16 bits Delphi/assembly for an embedded
target, but it's simple enough to give you some clues.

hope this helps...

Eric.

--------------------------------------------------------------------------------------------------------------------------------

unit XiLoad;

interface
uses SysLib,Cpu186;

const BitStream_XCS05 = 6900; { safe limit }
      BitStream_XCS10 = 12000; { safe limit }
      BitStream_XCS20 = 22450; { safe limit }
      BitStream_XCS30 = 31200; { safe limit }
      BitStream_XCS40 = 41400; { safe limit }

Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;

implementation

{Din = D7 / PROGRAM pin = P1-3(80C186EB) }

procedure Xil_WB (B:Byte;Addr:Word);

begin
 asm
  MOV   AL,[BP+06]
  MOV   DX,[BP+04]
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  end;
end;


Procedure xil_block (p:pointer;l,addr:Word);

begin
 asm
  LES   DI,[BP+08]
  MOV   CX,[BP+06]
  MOV   DX,[BP+04]
@1:
  MOV   AL,ES:[DI]
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  INC   DI
  DEC   CX
  JNZ   @1
  end;
end;


Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;

var by  : Byte;
    byp : ^byte absolute p;
    Position:Longint;

Begin
 Result:=False;
 if byp=Nil then then exit;
 Set_Control(P1LTCH,$000F); { Program pin inactive }
 Dly (1); { Delay so that the pulse is long enough }
 Set_Control(P1LTCH,$0007);; { Pulses "PROGRAM" (INIT) pin low }
 Dly (16); { Delay so that the pulse is long enough }
 Set_Control(P1LTCH,$000F); { Program pin inactive }
 Dly (1); { Delay so that the Spartan can complete internal reset }
 Position:=L;
 while (Position>0) and not Result do { skip the header }
  begin
   by:=byp^;
   inc (byp);
   Dec(position);
   if (by=$FF) and (byp^ and $F0 = $20) then
     begin
      dec (byp);
      xil_block (byp,word(Position),Addr); { Configure the FPGA }
      xil_wb($FF,Addr);
      xil_wb($FF,Addr);
      Result:=True;
     end
  end;
End;





Article: 36934
Subject: Re: fpga programming using microcontroller
From: Eric <erv_fedupwith_spam@sympatico.ca>
Date: Mon, 26 Nov 2001 15:05:07 -0500
Links: << >>  << T >>  << A >>
Hi,

swan a écrit :

> hi,
> i'm using spartan fpga in a design having microcontroller. I want to program the fpga through a microcontroller. i have gone through xapp058. but to implement this code one needs an operating system and also this code is too complicated to make any changes to it. is there any other way to achieve this?
> rgds
> swan

It's much easier than it seems, using the slave serial mode (and not JTAG).

Assuming that you have a 8 bits controller with external bus, connect the Spartan's D0 line to
the processor's  D7 line, CCLK to a decoded "Chip Select" output (simple qualified address
decoding),  and PROGRAM to a port pin (can be tied with the processor's Reset if you have
an external watchdog).

The software does the following :

- Apply a pulse to the "PROGRAM" pin (if PROGRAM is not tied to Reset)
- Wait at least 1 ms
- Start reading the ".bit" file until you find a $FF followed by a $2x (this is to skip the header)
  (if your ROM space is tight, you can safely remove the header from the ".bit" file before
  it's linked to your application)
- Write each subsequent byte to the CS decoded address (8 times per byte, with left rotation)
- Write $FF twice (can't remember why I did that, maybe you can skip it)

That's it ! Your Spartan should be configured.

Note that neither "INIT" or "DONE" is used since (unless the processor & FPGA functions are
completely unrelated after configuration) the processor can check the FPGA to determine if it's
properly configured or not (I usually add a loadable counter with inverted output as an internal
register to my designs for this purpose).

If configuration failed, it can be retried (if  PROGRAM is connected to the processor's reset,
just "hang" the processor in an endless loop and wait for the watchdog reset).

You can find below x86 code that does it all. It's written in 16 bits Delphi/assembly for an embedded
target, but it's simple enough to give you some clues.

hope this helps...

Eric.

--------------------------------------------------------------------------------------------------------------------------------

unit XiLoad;

interface
uses SysLib,Cpu186;

const BitStream_XCS05 = 6900; { safe limit }
      BitStream_XCS10 = 12000; { safe limit }
      BitStream_XCS20 = 22450; { safe limit }
      BitStream_XCS30 = 31200; { safe limit }
      BitStream_XCS40 = 41400; { safe limit }

Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;

implementation

{Din = D7 / PROGRAM pin = P1-3(80C186EB) }

procedure Xil_WB (B:Byte;Addr:Word);

begin
 asm
  MOV   AL,[BP+06]
  MOV   DX,[BP+04]
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  end;
end;


Procedure xil_block (p:pointer;l,addr:Word);

begin
 asm
  LES   DI,[BP+08]
  MOV   CX,[BP+06]
  MOV   DX,[BP+04]
@1:
  MOV   AL,ES:[DI]
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  ADD   AL,AL
  OUT   DX,AL
  INC   DI
  DEC   CX
  JNZ   @1
  end;
end;


Function XilinxLoadFromMemory (P:Pointer;addr:word;L:Longint):Boolean;

var by  : Byte;
    byp : ^byte absolute p;
    Position:Longint;

Begin
 Result:=False;
 if byp=Nil then exit;
 Set_Control(P1LTCH,$000F); { Program pin inactive }
 Dly (1); { Delay so that the pulse is long enough }
 Set_Control(P1LTCH,$0007);; { Pulses "PROGRAM" (INIT) pin low }
 Dly (16); { Delay so that the pulse is long enough }
 Set_Control(P1LTCH,$000F); { Program pin inactive }
 Dly (1); { Delay so that the Spartan can complete internal reset }
 Position:=L;
 while (Position>0) and not Result do { skip the header }
  begin
   by:=byp^;
   inc (byp);
   Dec(position);
   if (by=$FF) and (byp^ and $F0 = $20) then
     begin
      dec (byp);
      xil_block (byp,word(Position),Addr); { Configure the FPGA }
      xil_wb($FF,Addr);
      xil_wb($FF,Addr);
      Result:=True;
     end;
  end;
End;







Article: 36935
Subject: Device Support in Webpack
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 26 Nov 2001 15:50:22 -0500
Links: << >>  << T >>  << A >>
I checked out the info on which devices are supported by the ISE Webpack
software and it looks like Virtex II 40, 80 and 250 are supported in
addition to all of the Spartan II and IIE(?). 

http://www.xilinx.com/ise/products/webpack_config.htm

Can anyone verify that these devices are actually supported and working
in the current release of Webpack?

Also, it is clear that only a trial version of ModelSim is included and
you need to buy the XE version if you want to do real work with the
simulator. Are there any other pieces included that are not fully
functional? 

Finally, the only supported OS listed are 98, 2000 and NT 4.0. Anyone
know if they plan to update this list with something more current like
XP? I expect to be buying a new machine soon and hate to have to use an
old OS just for Xilinx. 


-- 

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: 36936
Subject: Re: ALTERA's Mercury CDR -- my mistake, sorry!
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 26 Nov 2001 14:21:23 -0800
Links: << >>  << T >>  << A >>
I am sorry to have made a basic mistake, and I apologize if I have mislead
anybody. The question was about Mercury, and I answered it as if it were about
APEX-II.
I had worked up so much steam about APEX-II that I mixed up the two families.
I'll be more careful in the future.

Peter Alfke



Article: 36937
Subject: Re: Device Support in Webpack
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Mon, 26 Nov 2001 17:21:43 -0500
Links: << >>  << T >>  << A >>
I have used the webpack for the virtex2-40 series device.  Web pack does not
support logiblox, coregen, and FPGA editor.  With those exceptions I found
it to be quite usable.  The so-called modelsim limitation is not entirely
true.  Modelsim is crippled in that as the simulations get more and more
lines of code the simulator gets bogged down.  It does not stop entirely.  I
have used it to simulate a virtex2-40 with 95% of the chip utilized.  The
worst thing I can say about the modelsim is that the models for DCM's and
other similar virtex2 specific devices are not simulatable at the behavioral
or post-translate levels.  Thus to simulate a DCM one has to at least map
the device to get a simulation result.  If you are just using standard VHDL
then model-sim webpack works great.

rickman wrote:

> I checked out the info on which devices are supported by the ISE Webpack
> software and it looks like Virtex II 40, 80 and 250 are supported in

Correct
also, the virtexE series up to 300K gates, spartan2, and spartan2E to
similar sizes.
also Coolrunner, coolrunner2, and XC9500, xc9500xl and xc9500xv series
devices.  These all show up in my options for devices.  I have gone to the
ISE4.1 package but only because I really wanted the coregen devices.  It was
$695 with the same modelsim as webpack.

By the way, if anyone knows a workaround for any of my complaints, please
let me know.

Thanks,
Theron Hicks

>
> addition to all of the Spartan II and IIE(?).
>
> http://www.xilinx.com/ise/products/webpack_config.htm
>
> Can anyone verify that these devices are actually supported and working
> in the current release of Webpack?
>
> Also, it is clear that only a trial version of ModelSim is included and
> you need to buy the XE version if you want to do real work with the
> simulator. Are there any other pieces included that are not fully
> functional?
>
> Finally, the only supported OS listed are 98, 2000 and NT 4.0. Anyone
> know if they plan to update this list with something more current like
> XP? I expect to be buying a new machine soon and hate to have to use an
> old OS just for Xilinx.
>
> --
>
> 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: 36938
Subject: Re: FFT with Distributed Arithmatic
From: Ray Andraka <ray@andraka.com>
Date: Mon, 26 Nov 2001 22:57:14 GMT
Links: << >>  << T >>  << A >>


Hananiel Sarella wrote:

> Hello folks,
>            Im trying to implement large FFTs on Xilinx vertex II FPGAs. I have a couple of questions.
> 1. There are multipliers on chip with 5ns delays.

Check the latest data sheets.  Those multipliers are not nearly that fast.

> There  is a paper by lez mintzer "large ffts on fpgas" which describes how to code one fft butterfly with DA tables. The pipeline delay in this case is less than the multiplier delay and there are more multiplies per stage delay.

The DA approach is inherently serial, although it can be paralleled up to get a fully parallel implementation.  For the fully parallel case, the resource usage is close to parity with a design built from multipliers, and in most cases so is the latency/speed.  Where virtexII has the
dedicated multipliers, you will use many less LUTs by using the multipliers...although that advantage is not as clear if you are using the multipliers and fabric at the highest possible speed.  There are other ways to skin the FFT cat too.  Even with the dedicated multipliers it may
be advatageous to use alternative algorithms to reduce the hardware complexity.

>
>   Can some one tell me which is better?
> 2. Im writing synthesizeable structural VHDL code for the butterfly processor. Im having to write code for controlling this for say, 8192 point FFT. Is this the way people do it. Like say guys writing xilinx cores. Or is there a better way you can suggest.

I'm not sure what you are referring to as "code"  VHDL is code, as is microcode for a state machine.  The cores are structurally instantiated, although many have been translated to a java script.

>
>
> Thanks a lot,
> Hananiel

--
--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: 36939
Subject: Which vendor to choose
From: "Jason Berringer" <jberringer@trace-logic.com>
Date: Mon, 26 Nov 2001 18:29:49 -0500
Links: << >>  << T >>  << A >>
Hello everyone,

Since everyone here has more experience with FPGAs than I, I will ask for
some advice. Since I'm just starting with FPGAs it seems to me a good idea
to pick a vendor and stick to it (and this seems to be cheaper since you
don't have to purchase everyone's tools). I would like some comments on
which vendor is the "preferred" vendor these days. In other words why should
I choose Altera over Xilinx over Atmel, etc. I'm looking for honest answers
and no sales calls. My applications will vary in size and speed so
flexibility is very important, along with relative costs of software and
ICs/demonstration boards.

I'm interested to know so I can save myself some head aches and make an
informed decision on which company to align myself with.

Thanks

Jason



Article: 36940
Subject: Re: Which vendor to choose
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 26 Nov 2001 16:07:07 -0800
Links: << >>  << T >>  << A >>
Jason Berringer wrote:
> 
> In other words why should
> I choose Altera over Xilinx over Atmel, etc.

Brand X and A are the biggest and most often 
mentioned in this group.
The parts are roughly equivalent.
Pick the vendor that gives you the best service.

 -- Mike Treseler

Article: 36941
Subject: Re: Which vendor to choose
From: Ray Andraka <ray@andraka.com>
Date: Tue, 27 Nov 2001 03:11:28 GMT
Links: << >>  << T >>  << A >>
It really depends on what your major applications are.  Altera has CAM built in,
which is very nice to nice in those network and sorter applications, whilc
xilinx's ability to use CLBs as small RAMs or shift registers is extremely
valuable in DSP applications.  You need to carefully look at the features and
architecture while thinking about how they will help or hurt your typical
designs.

Jason Berringer wrote:

> Hello everyone,
>
> Since everyone here has more experience with FPGAs than I, I will ask for
> some advice. Since I'm just starting with FPGAs it seems to me a good idea
> to pick a vendor and stick to it (and this seems to be cheaper since you
> don't have to purchase everyone's tools). I would like some comments on
> which vendor is the "preferred" vendor these days. In other words why should
> I choose Altera over Xilinx over Atmel, etc. I'm looking for honest answers
> and no sales calls. My applications will vary in size and speed so
> flexibility is very important, along with relative costs of software and
> ICs/demonstration boards.
>
> I'm interested to know so I can save myself some head aches and make an
> informed decision on which company to align myself with.
>
> Thanks
>
> Jason

--
--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: 36942
Subject: SPI implementation details
From: VR <nospam@nonexistantdoooomain.com>
Date: Tue, 27 Nov 2001 04:18:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hey all.

I am implementing a very basic, simple uC to FPGA(XC4010E-4) interface.

The uC simply updates an 8-bit register in the FPGA via SPI -- the FPGA
does not communicate back. The only real logic involved is an 8-bit shift
register. System clock in the FPGA is a fixed 40MHz.

The uC outputs(to the FPGA) are an SPI_Clock output, SPI_Data_Out (data
valid on rising edge of clock) and nDevice_Select (active low "enable" to
SPI device).

My SPI clock is <= 1MHz and speed isn't a big issue(it could be run in the
kHz if need be).

While the logic involved is straight I still have a few questions...

The most obvious and "direct" method of implementation is to use the SPI
clock from the uC as the clock for the 8-bit shift register in the FPGA
and use the nDevice_Select(synchronized) as a data "valid" for the block
that uses the data from the shift register.

However thinking about it, an approach that might be more suitable for an
FPGA might be to use the SPI clock (synchronized through a 2 DFF
"de-metastabilifier") as the Clock_Enable on the shift register FF's and
use a synchronized nDevice_Select as a data valid while the clock to the
shift register FF's is driven by my FPGA system clock.

A practical concern however is that I already have a simple design
(debugged, working) that when Xilinx P&R'ed runs @ 42MHz that needs to be
integrated with the SPI interface/register.

If I were to use implementation technique #2, does the possibility exist
of my existing circuit being forced to run at a lower clock rate? Are there
other caveats to either design choice?

Thanks!
VR.

Article: 36943
Subject: Re: Device Support in Webpack
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 26 Nov 2001 23:38:51 -0500
Links: << >>  << T >>  << A >>
Theron Hicks wrote:
> 
> I have used the webpack for the virtex2-40 series device.  Web pack does not
> support logiblox, coregen, and FPGA editor.  With those exceptions I found
> it to be quite usable.  The so-called modelsim limitation is not entirely
> true.  Modelsim is crippled in that as the simulations get more and more
> lines of code the simulator gets bogged down.  It does not stop entirely.  I
> have used it to simulate a virtex2-40 with 95% of the chip utilized.  The
> worst thing I can say about the modelsim is that the models for DCM's and
> other similar virtex2 specific devices are not simulatable at the behavioral
> or post-translate levels.  Thus to simulate a DCM one has to at least map
> the device to get a simulation result.  If you are just using standard VHDL
> then model-sim webpack works great.


Theron,

Thanks for the reply. This is useful info. 

I am aware of the ModelSim behavior. I did a project with it a little
over a year ago and it got to be a real pain at 500 lines of code. It
was not a gradual change in simulation time, but was about a 5x to 10x
reduction in speed once you reached the 500 line limitation. This made
it MUCH harder to get any real work done. Since it is not clearly
indicated in the documentation, it snuck up behind me in the middle of
this small project. Now I know better than to try to use any of the demo
tools for a project, even when they look useful. 

IIRC, logiblox lets you instantiate complex elements like counters,
adders, bus muxes and the like, right? I am not familiar with coregen. I
will read up on it at the Xilinx web site. FPGA editor is important. I
take it there are no replacement modules for Logiblox and FPGA editor in
WebPack? It would be a pain to work without these functions. 



-- 

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: 36944
(removed)


Article: 36945
Subject: Re: wget of WebPack
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 27 Nov 2001 09:10:52 +0100
Links: << >>  << T >>  << A >>
Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:

> Petter Gustad <newsmailcomp1@gustad.com> writes:
> > In case somebody is struggling with a not-internet-exporer-for-windows
> > web browser (like myself, using Opera under Linux) to download WebPack
> > - Here is how you can download it using wget:
> > 
> > wget --http-user USER --http-passwd PASS http://www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe
> > 
> > Where USER is your Xilinx registered username and PASS is your
> > selected password.
> 
> or even
> 
> wget http://USER:PASS@www.xilinx.com/webpack/41wp2/WebPACK_41wp20_full_installer.exe
> 
> I wonder how much money they spent developing that horrible navigation
> system?  It's almost as if their intent was to prevent people from

I wish they could have spent this effort on qualifying a Linux version
or a faster better synthesis and/or place and route tool (something
that would run effectively on a cluster).

Same thing with the Java based installation under Solaris: This effort
could also have been spent at the above mentioned tasks. I would
rather have a cpio based sh script which would complete in the matter
of minutes, not hours like the Java based installation tool.

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 36946
Subject: Re: Which vendor to choose
From: thomas.stanka@de.bosch.com (Thomas Stanka)
Date: 27 Nov 2001 08:13:22 GMT
Links: << >>  << T >>  << A >>
Hi,

"Jason Berringer" <jberringer@trace-logic.com> wrote:
> for some advice. Since I'm just starting with FPGAs it seems to me a
> good idea to pick a vendor and stick to it (and this seems to be
> cheaper since you don't have to purchase everyone's tools). 

Normaly you get the vendor-specific tools free. If your not only doing a 
few designs it's a good idea to get a full version of tools for synthesis 
and simulation. So don't stick to a vendor because of the tools.
Anyway it may be cheaper to buy all FPGA from the same vendor. 

> like some comments on which vendor is the "preferred" vendor these
> days. In other words why should I choose Altera over Xilinx over Atmel,
> etc. I'm looking for honest answers and no sales calls. My applications
> will vary in size and speed so flexibility is very important, along
> with relative costs of software and ICs/demonstration boards.

First you should think about RAM-based and Fuse-Based FPGA. RAM means 
normaly reloading your design every power-up. That's IMHO a major drawback 
for selling applications and a great advantage while prototyping.
A Fuse-Based FPGA needs a burner and you can't change anything if its once 
burned.

For prototyping only I would choose Xilinx (as I have no experience with 
Atmel or Altera *g*). Because of the wide spread experience of prototyping 
with Xilinx wherever I look (e.g. here in this NG). 

bye Thomas


-- 
Thomas Stanka BC/EMD4
Space Communications Systems
Tesat Spacecom GmbH & Co KG
thomas.stanka@de.bosch.com

Article: 36947
Subject: Re: Some question on Synplify
From: dottavio@ised.it (Antonio)
Date: 27 Nov 2001 00:15:39 -0800
Links: << >>  << T >>  << A >>
Really thanks, but what you mean with Clock Enable Inputs for derived frequencies?

Article: 36948
(removed)


Article: 36949
Subject: Re: Creating a jitter free clock
From: Adrian <>
Date: Tue, 27 Nov 2001 01:19:25 -0800
Links: << >>  << T >>  << A >>
Well, the point was to replace the couple hundred thousand dollar clock which can do it!



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