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 62925

Article: 62925
Subject: How to visit the files in CF cards
From: "#YU WEI#" <yuwei@pmail.ntu.edu.sg>
Date: Tue, 11 Nov 2003 21:42:33 +0800
Links: << >>  << T >>  << A >>
We have got a Virtex-II Multimedia Board which include CF card slot.

http://www.xilinx.com/xlnx/xebiz/board_detail.jsp?=3D&category=3D-21481&i=
Lan
guageID=3D1&key=3DHW-V2000-MLTA

How to visit the files in CF cards? Can I just copy the files to the CF
card? Or have to build some described files to let SystemACE recognize
the file?

=20

=20



Article: 62926
Subject: DCM input clock
From: andrewray@blueyonder.co.uk (Andyman)
Date: 11 Nov 2003 06:12:06 -0800
Links: << >>  << T >>  << A >>
Hi all,

I have a design which takes data from an external ADC.  The ADC
provides a 35 Mhz clock.

Currently the design feeds the input clock through a DCM and uses the
180 degree phase shifted version to sample and reassemble the ADC
data.  This all then passes to our system clock domain via one of the
(wonderfully useful) Xilinx self addressing asychronous FIFO's.

As this is for a communications system we need to perform clock
recovery (actually this might be better described as carrier recovery)
and the ADC provides a means to tune the clock it uses to sample with.
 Of course this means that the clock we are feeding into the DCM to
get our internal sampling clock (and driving the SAF - in essense a
block RAM) is going to be changing.  Each change could be in the order
of 200 Hz and performed a few thousand times a second.  The total
change from the clock the DCM locked with could be up to 100 KHz but I
could bodge...ahem...design my way round this to make it significantly
less.

Although the above is working fine at the moment I am worried about
the DCM loosing its lock due to the varying input clock.  Can anyone
suggest how much the DCM will tolerate before throwing a wobbly?

Thanks,

Andy

Article: 62927
Subject: Re: Multiple clock domains in a FPGA (using DLL's)
From: "Nial Stewart" <nial@spamno.nialstewart.co.uk>
Date: Tue, 11 Nov 2003 14:39:33 -0000
Links: << >>  << T >>  << A >>

takkaya <takkaya@hotmail.com> wrote in message
news:5c8d9153.0311110158.db6a06b@posting.google.com...
> I am targeting a Spartan IIE (400E) device with four global clock
> buffers (BUFG) and four DLL's.
>
> But I need five clock domains 25MHz(clkin, DLL1), 50MHz (clk2x, DLL1)
> and 30MHz (clkdv, DLL2), 60MHz (clkin, DLL2), 120MHz (clk2x, DLL2) in
> my design.
> I know that it is not allowed to use more than 2 BUFG per DLL.
> I would like to use the DLL's to have a zero propagation delay and low
> clock skew between output clock signals distributed throughout the
> device. The primary global nets are driven by global buffers (25, 50,
> 60 and 120 MHz).
> The 30 MHz clock domain (internal) is not so critical, so maybe I can
> use a secondary global nets?
> How can I drive the secondary global nets with an output of the DLL
> e.g. the 30 MHz?
> Thanks in advance.


Generate a /2 enable signal off the 60MHz clock and use this
with the 60MHz clock to drive logic at 30MHz.

You could give this a multi-cycle path constraint for P+R, but
60MHz isn't that fast so unless your device is very full you
could probably get away without this.


Nial

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk




Article: 62928
Subject: Re: Transforming vector position to binary value
From: andres.vazquez@gmx.de (Vazquez)
Date: 11 Nov 2003 06:48:51 -0800
Links: << >>  << T >>  << A >>
Dear Mr Bromley,

it is the following background:

The 32-bit vector can have up to 4 locations with '1', for example

0000 1000 0000 0000 0101 0000 0000 0100

The ones indicate that  a data packet has been found at the different
write-address-positions of a cam.
In a second step I have to fulfill a second check in a separate
RAM structure. For this purpose
I want to create out of the 32-bit-HIT-vector 4 addresses.
In the example shown that would mean that I have to create the
following
addresses (for the second check step):
1. b00010
2. b01010
3. b01110
4. b11011
These addresses will then be assigned sequentially to the RAM
wraddress port.
So is there a possibility to get these four addresses out of the
32-bit-vector within one clock cycle?

Thanks a lot.

Best Regards
Andres V.

Article: 62929
Subject: Re: Layout examples
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 11 Nov 2003 15:00:05 +0000
Links: << >>  << T >>  << A >>
Hi Jason,

"Jason Berringer" <look_at_bottom_of@email.com> writes:
<snip>
> I would like to see if possible some proven layouts showing where the caps
> are mounted and there possition relative to the power pins (and see how
> close they are). I've seen a lot of layouts where there are a few caps in
> the center of the IC on the underside of the board, but this does not lend
> itself nicely to the idea of being as  close as possible to the pins. I have
> also seen the Xilinx app note on BGA routing which is very helpful, but
> again no capacitor placement is shown.
> 
<snip>
If you have solid planes (prefereably closely spaced) you don't need
to worry about 'close' in the sense that you probably think of as
close.  If you have vias to the planes on *very* short tracks, or even
better in the pad, then the planes will act as a very low impedance
route for your currents.  If you think of the time the energy will
take to travel from capacitor to chip, the speed of light on FR4 is
around 2/3c or 2e8 m/s.  In 1ns, this is around 20cm.  Halve this for
the energy to get back and forth and even 10cm is "close".

I don't have any pictures to hand, but we've done boards like this
with 100MHz memory interfaces and 150MHz core DSP clocks that work fine.

Does that help?

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 62930
Subject: Re: Transforming vector position to binary value
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Tue, 11 Nov 2003 15:14:28 -0000
Links: << >>  << T >>  << A >>
"Vazquez" <andres.vazquez@gmx.de> wrote in message
news:eee19a7a.0311110648.5e79e75c@posting.google.com...

> The 32-bit vector can have up to 4 locations with '1', for example
>
> 0000 1000 0000 0000 0101 0000 0000 0100
>
> I want to create out of the 32-bit-HIT-vector 4 addresses.
> In the example shown that would mean that I have to create the
> following
> addresses (for the second check step):
> 1. b00010
> 2. b01010
> 3. b01110
> 4. b11011

That is a VERY different problem from the one you first posted!

> So is there a possibility to get these four addresses out of the
> 32-bit-vector within one clock cycle?

I'm sure it is possible, but it is certainly difficult and I
cannot see a clean solution right now.  However...

> These addresses will then be assigned sequentially
> to the RAM wraddress port.

If the four RAM writes are to be sequential, why not
obtain the four addresses sequentially?  That would be
much simpler.  Use a priority encoder (as Valentin
suggested) to locate the first 1 bit.  Then, while
you are writing to the chosen RAM location, clear that
first bit to 0 and use the same priority encoder again
to find the second 1 bit.  Keep going like this until
you have cleared the whole 32-bit input word to zero.

A 32-to-5-bit priority encoder is not trivial, but it
should be OK unless your clock speed is very fast.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 62931
Subject: Re: Linux and FPGA compatibility
From: sleepymish@hotmail.com (Michelle)
Date: 11 Nov 2003 07:39:50 -0800
Links: << >>  << T >>  << A >>
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:<jfgqb.87097$ao4.265693@attbi_s51>...
> "Michelle" <sleepymish@hotmail.com> wrote in message
> news:2b3db7ca.0311050941.3dc9ee2c@posting.google.com...
> > Hi,
> >
> > I'm a newbie to FPGA and Linux world. I have a general question
> > concerning both.
> >
> > I have a workstation with Linux installed. A Virtex II Pro FPGA Module
> > is plugged in the backplane of the workstation. I'm wondering if I
> > need to write a device driver for the FPGA module in order for the
> > Linux box to recognize the card?
> >
> > I want a software program running on the Linux machine to be able to
> > poll a few registers on the FPGA module, bascially through memory map.
> > Is this possible without a device driver?
> 
> Was the board designed to work with Linux?
> 
> Some years ago I worked with a variety of boards on Sun workstations. Sun
> provided device drivers that would map memory as an I/O device so that any
> device could be accessed that way.  A little less convenient than a
> dedicated device driver, but it did work.  I don't know that Linux provides
> that, though.
> 
> -- glen

Yeah I'm been looking all over the web and forums, can't seem to find
anything useful.

Article: 62932
Subject: Re: Linux and FPGA compatibility
From: sleepymish@hotmail.com (Michelle)
Date: 11 Nov 2003 07:40:45 -0800
Links: << >>  << T >>  << A >>
alann@accom.com (Alan Nishioka) wrote in message news:<a2db9b48.0311051625.39437e89@posting.google.com>...
> sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311050941.3dc9ee2c@posting.google.com>...
> > I have a workstation with Linux installed. A Virtex II Pro FPGA Module
> > is plugged in the backplane of the workstation. I'm wondering if I
> > need to write a device driver for the FPGA module in order for the
> > Linux box to recognize the card?
> 
> No.  By backplane do you mean PCI?
> 
> > I want a software program running on the Linux machine to be able to
> > poll a few registers on the FPGA module, bascially through memory map.
> > Is this possible without a device driver?
> 
> You might want to try:
> http://www.linuxjournal.com/article.php?sid=5442
> "User Mode Drivers"
> 
> Which talks about writing directly to PCI memory space.
> This is not a particularly nice/good/proper thing to do, but it is
> quick and dirty and good for starters.
> 
> Alan Nishioka
> alann@accom.com

Yes backplane as in the PCI bus of the Linux workstation. I will check
out the article you suggested, thanks!

Article: 62933
Subject: Re: Linux and FPGA compatibility
From: sleepymish@hotmail.com (Michelle)
Date: 11 Nov 2003 07:41:15 -0800
Links: << >>  << T >>  << A >>
johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0311052351.1f2db0a7@posting.google.com>...
> sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311050941.3dc9ee2c@posting.google.com>...
> > Hi, 
> > 
> > I'm a newbie to FPGA and Linux world. I have a general question
> > concerning both.
> > 
> > I have a workstation with Linux installed. A Virtex II Pro FPGA Module
> > is plugged in the backplane of the workstation. I'm wondering if I
> > need to write a device driver for the FPGA module in order for the
> > Linux box to recognize the card?
> > 
> > I want a software program running on the Linux machine to be able to
> > poll a few registers on the FPGA module, bascially through memory map.
> > Is this possible without a device driver?
> > 
> > Thanks in advance for all the help. 
> > 
> > Michelle
> 
> 
> The better FPGA board makers should include a ready to go PCI device
> driver. For Windows this would have been something like Numega IIRC,
> but for Linux I am less sure, most of my old links are long gone
> (thanks to MS ...).
> 
> Who is the board vendor?, check their site for driver support.
> 
> John
> 
> johnjaksonATusaDOTcom

Xilinx is the vendor.

Article: 62934
Subject: Re: DCM input clock
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Tue, 11 Nov 2003 07:43:35 -0800
Links: << >>  << T >>  << A >>
Andy,

100KHz out of 35 MHz is .1/35, or 1/350, or ~2800 ppm.  The spec in the
data sheet is +/- 100 ppm, but that was for an instantaneous change in
frequency (largest step size).  200 Hz out of 35 MHz is ~6 ppm.

The DCM tracts phase changes by moving its taps.  The tap movement for the
CLK0/CLK180 (DLL outputs) is 6*the 2's complement of the jitter filter
times the number of clocks for one tap change (~50 ps, V2, ~30ps, V2P).

By changing the jitter filters to 0xFFFFh, you can now track phase changes
much faster (roughly 6 clocks per tap, or 50ps in 6 35 MHz clocks, or
50ps/172ns).  This is roughly 34.99MHz to 35.01 MHz (10 KHz instant step
per every 6 clock cycles allowed).  With the default settings, it is ~256
times slower (or 10KHz/256 ~ 40 Hz)

I think you need to set your jitter filter settings to allow more change.

I think you will find that this is the fastest tracking capability of any
general purpose 24MHz to 420 MHz phase locked loop device in
exisitence......(and you can vary it by the jitter filter values).

That said, you can monitor the LOCKED signal, as it will lose lock it the
tap runs off either end of the delay line for any reason.  As well, if the
CLOCK_IN_STOPPED status bit goes high, that is an indication that the
input clock has missing pulses (really bad) and the DCM may need to be
reset.

The DFS has a different state machine, but also tracks frequency and phase
thru tap movements, and is faster than the DLL state machine (no jitter
filter at all), so the DLL is the limiting element.

Austin



Andyman wrote:

> Hi all,
>
> I have a design which takes data from an external ADC.  The ADC
> provides a 35 Mhz clock.
>
> Currently the design feeds the input clock through a DCM and uses the
> 180 degree phase shifted version to sample and reassemble the ADC
> data.  This all then passes to our system clock domain via one of the
> (wonderfully useful) Xilinx self addressing asychronous FIFO's.
>
> As this is for a communications system we need to perform clock
> recovery (actually this might be better described as carrier recovery)
> and the ADC provides a means to tune the clock it uses to sample with.
>  Of course this means that the clock we are feeding into the DCM to
> get our internal sampling clock (and driving the SAF - in essense a
> block RAM) is going to be changing.  Each change could be in the order
> of 200 Hz and performed a few thousand times a second.  The total
> change from the clock the DCM locked with could be up to 100 KHz but I
> could bodge...ahem...design my way round this to make it significantly
> less.
>
> Although the above is working fine at the moment I am worried about
> the DCM loosing its lock due to the varying input clock.  Can anyone
> suggest how much the DCM will tolerate before throwing a wobbly?
>
> Thanks,
>
> Andy


Article: 62935
Subject: Re: Xilinx S3 I/O robustness question
From: lecroy7200@chek.com (lecroy)
Date: 11 Nov 2003 08:04:48 -0800
Links: << >>  << T >>  << A >>
> Rick,
> 
> The IBIS models are based on the foundry spice models, which are pretty
> mature now, as the same transistors used for the IOs have been manufactured
> now for almost a year.
> 
> Just because others have absolutely lousy IBIS models out there does not
> mean we do:  We continually check the quality of the models.  Yes, Spartan 3
> has preliminary models but only because it is not released to production yet
> -- it is still int he ES phase.  This allows us to make changes easily as we
> discover issues.  So far, no issues with IBIS.
> 
> Austin

From a Xilinx S2 IBIS model..  
Note " .... this model is considered preliminary as it has not been
verified by actual silicon measurement."
And this is an old part.  How good do you think Xilinx models are for
the S3??


[Disclaimer]     The data in this model is derived from SPICE
simulations using
                 modeling information extracted from the target
process. While
                 a great deal of care has been taken to provide
information
                 that is accurate, this model is considered
preliminary as it
                 has not been verified by actual silicon measurement.
Treat the
                 data in this model as preliminary until actual
silicon
                 verification is performed. 
[Copyright]      Copyright 2000, Xilinx Inc., All rights reserved

Article: 62936
Subject: Re: XILINX Foundation Series 3_1i Problem with installation...
From: "Morten Leikvoll" <m-leik@online.nospam>
Date: Tue, 11 Nov 2003 17:23:09 +0100
Links: << >>  << T >>  << A >>
"Сергей Зорин" <zlogic@udm.ru> skrev i melding
news:boqoau$22r0$1@hq.mark-itt.ru...
> Hi, ALL.
>
> Problem with installation subj.
> In time installation  the program java.exe is under abnormal condition
> finished.
> It happens in WIN 98 and in WIN XP. Processor - CELERON 1700.
> What to do, help me, please.

My weak memory seem to remember something about java and this problem... You
needed the latest java runtime environment to install this?




Article: 62937
Subject: Re: Xilinx S3 I/O robustness question
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Tue, 11 Nov 2003 08:28:18 -0800
Links: << >>  << T >>  << A >>
Standard disclaimer.

We don't seem to get around to removing the caveats.....I'll look into that.

All parts once they are in production have been verified in MY lab.

By the way, folks have asked about duty cycle distortion in the outputs, and IBIS
models will allow you to simulate the FAST/STRONG corner and then the SLOW/WEAK
corner.  You can imagine that the rise vs. fall times could be (absolute worst
case) that different.  Godd thing to check when you want to know "is this standard
fast enough for my xxxx application?"*

Austin

This does use the low vcc, low temp, high vcc, high temp as part of the corners
(as well as the process variation which is what you are really concerned about
here), so it is more pessimistic than the reality (reality can not have a low vcc,
hot rising edge with a high vcc cold falling edge), but it is still a great way to
check if the IO standard you have chosen is reasonably well matched for the speed
you desire.

lecroy wrote:

> > Rick,
> >
> > The IBIS models are based on the foundry spice models, which are pretty
> > mature now, as the same transistors used for the IOs have been manufactured
> > now for almost a year.
> >
> > Just because others have absolutely lousy IBIS models out there does not
> > mean we do:  We continually check the quality of the models.  Yes, Spartan 3
> > has preliminary models but only because it is not released to production yet
> > -- it is still int he ES phase.  This allows us to make changes easily as we
> > discover issues.  So far, no issues with IBIS.
> >
> > Austin
>
> From a Xilinx S2 IBIS model..
> Note " .... this model is considered preliminary as it has not been
> verified by actual silicon measurement."
> And this is an old part.  How good do you think Xilinx models are for
> the S3??
>
> [Disclaimer]     The data in this model is derived from SPICE
> simulations using
>                  modeling information extracted from the target
> process. While
>                  a great deal of care has been taken to provide
> information
>                  that is accurate, this model is considered
> preliminary as it
>                  has not been verified by actual silicon measurement.
> Treat the
>                  data in this model as preliminary until actual
> silicon
>                  verification is performed.
> [Copyright]      Copyright 2000, Xilinx Inc., All rights reserved


Article: 62938
Subject: Re: Transforming vector position to binary value
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 11 Nov 2003 16:42:35 GMT
Links: << >>  << T >>  << A >>
Comment below:

"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:boqucv$8go$1$8300dec7@news.demon.co.uk...
> "Vazquez" <andres.vazquez@gmx.de> wrote in message
> news:eee19a7a.0311110648.5e79e75c@posting.google.com...
>
> > The 32-bit vector can have up to 4 locations with '1', for example
> >
> > 0000 1000 0000 0000 0101 0000 0000 0100
> >
> > I want to create out of the 32-bit-HIT-vector 4 addresses.
> > In the example shown that would mean that I have to create the
> > following
> > addresses (for the second check step):
> > 1. b00010
> > 2. b01010
> > 3. b01110
> > 4. b11011
>
> That is a VERY different problem from the one you first posted!
>
> > So is there a possibility to get these four addresses out of the
> > 32-bit-vector within one clock cycle?
>
> I'm sure it is possible, but it is certainly difficult and I
> cannot see a clean solution right now.  However...
>
> > These addresses will then be assigned sequentially
> > to the RAM wraddress port.
>
> If the four RAM writes are to be sequential, why not
> obtain the four addresses sequentially?  That would be
> much simpler.  Use a priority encoder (as Valentin
> suggested) to locate the first 1 bit.  Then, while
> you are writing to the chosen RAM location, clear that
> first bit to 0 and use the same priority encoder again
> to find the second 1 bit.  Keep going like this until
> you have cleared the whole 32-bit input word to zero.
>
> A 32-to-5-bit priority encoder is not trivial, but it
> should be OK unless your clock speed is very fast.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
UK
> Tel: +44 (0)1425 471223                    mail:
jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

I missed the original postings but the sequential detection sounds like a
great approach from what I see above.

The 32-to-5-bit priority encoder is something I worked with just recently,
targeting the Virtex-II architecture with Synplify Verilog.  The speeds I
was able to get were greater than 300 MHz.  If you're working with these
tools or just want to see the approach, feel free to reply-email directly.
I could probably (suggest ways to) push the speed even further with some
tricks I have left.

- John_H



Article: 62939
Subject: Re: VirtexII-Pro: Why is ICAP slower than SelectMAP?
From: "PO Laprise" <pl_REMOVE_apri@cim._NOTGOOD_.mcgill.ca>
Date: Tue, 11 Nov 2003 08:47:06 -0800
Links: << >>  << T >>  << A >>
I agree that it's ugly, but what I find mind-boggling is that you can 
get any sort of speed-up by going off-chip! 
  Also, I seem to recall (plz correct me if I'm wrong) that SelectMAP 
  allows for a form of "handshaking" using the "busy" signal, which allows 
  you to work SlaveSelectMAP at a slightly higher frequency (see Virtex-II 
  Users guide -> Configuration -> Slave SelectMAP Programming Mode -> 
  CCLK -> (...). Does this also work with the ICAP? What is the maximum 
  clock frequency then? 
Pierre-Olivier 

-- to contact me directly, remove the obvious from my email address -- 



Article: 62940
Subject: Re: Layout examples
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 11 Nov 2003 16:52:34 GMT
Links: << >>  << T >>  << A >>
Great comments, Martin.

A point I'd add to the original poster's concerns about the "swiss cheese"
ground and power planes you can get with too many vias, some numerical work
has shown that - at least for closely spaced ground/power pairs - the added
impedance from the swiss cheese under a BGA package (much worse than a QFP)
is sub-nanohenry.  Don't worry so much about the holes in the plane, worry
about the spacing between the planes (smaller is better, 4 mil perhaps?) and
good decoupling cap attachment.  Two vias are often used on each end of the
decoupling caps in high speed designs to halve the impedance to the ground
and power planes.  The "*very* short tracks" is a noteworthy comment as
well; it's easy to make a stiff decoupling cap a bit soft by adding a little
track between the pad and via(s).

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:uislr3q8a.fsf@trw.com...
> Hi Jason,
>
> "Jason Berringer" <look_at_bottom_of@email.com> writes:
> <snip>
> > I would like to see if possible some proven layouts showing where the
caps
> > are mounted and there possition relative to the power pins (and see how
> > close they are). I've seen a lot of layouts where there are a few caps
in
> > the center of the IC on the underside of the board, but this does not
lend
> > itself nicely to the idea of being as  close as possible to the pins. I
have
> > also seen the Xilinx app note on BGA routing which is very helpful, but
> > again no capacitor placement is shown.
> >
> <snip>
> If you have solid planes (prefereably closely spaced) you don't need
> to worry about 'close' in the sense that you probably think of as
> close.  If you have vias to the planes on *very* short tracks, or even
> better in the pad, then the planes will act as a very low impedance
> route for your currents.  If you think of the time the energy will
> take to travel from capacitor to chip, the speed of light on FR4 is
> around 2/3c or 2e8 m/s.  In 1ns, this is around 20cm.  Halve this for
> the energy to get back and forth and even 10cm is "close".
>
> I don't have any pictures to hand, but we've done boards like this
> with 100MHz memory interfaces and 150MHz core DSP clocks that work fine.
>
> Does that help?
>
> Cheers,
> Martin
>
> -- 
> martin.j.thompson@trw.com
> TRW Conekt, Solihull, UK
> http://www.trw.com/conekt



Article: 62941
Subject: Re: Implementing a very fast counterin VirtexII
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 11 Nov 2003 16:59:21 GMT
Links: << >>  << T >>  << A >>
Every clock cycle?  Not gated/enabled or cleared?

You split the counter into halves earlier, correct?  Pre-decode the terminal
count from the fast counter so you have a synchronous TC signal when the
32'hffff_ffff arrives (or 8'hff or whatever size you choose).  With the
synchronous TC fed to the enable of the top, slow counter you can achieve
great speeds.

Only a little more coordination is needed for proper enables, clears, or
loads, but the design should be easy to achieve once you understand the
"tricks" that will help you "retime" your synchronous designs.


"Erez Birenzwig" <erez_birenzwig@hotmail.com> wrote in message
news:W0Vrb.67$%o4.12245@news.xtra.co.nz...
> To be more precise the implementation requires the calculation of:
> a = a + 1
>
> When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6
> FPGA.
>
> Erez.



Article: 62942
Subject: Re: Reverse engineering an EDIF file?
From: rasti123@eunet.yu
Date: Tue, 11 Nov 2003 18:10:33 +0100
Links: << >>  << T >>  << A >>
Dear Allan,

Thank you for your answer. When you say binary format, what precisely
do you mean? On the other hand I was thinking of using Xilinx NGC
netlist instead of EDIF. Do you think this would help? I have read
that NGC is a encrypted netlist format, and if there is no easy way of
converting NGC to EDIF, than maybe it would be a solution to my
problem.

Best regards,
Rastislav

On Tue, 11 Nov 2003 10:45:47 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

>On Mon, 10 Nov 2003 23:10:39 +0100, Rastislav Struharik
><rasti@eunet.yu> wrote:
>
>>Hello,
>>
>>I would like to know does anyone knows, is it possible to reverse
>>engineer an edif netlist file? I am currently developing an FPGA core.
>>I would like to supply an evaluation version of the core, that would
>>have all the functionality of the final core, but would operate only
>>for a limited period of time. My fear is that there is a way to modify
>>the evaluation version edif netlist (find and remove modules that set
>>a time limit to the operation of the evaluation version), and thus
>>obtain completely functional core. Can something like this be done, or
>>am I being paranoid?
>>Every help and clarification on this subject is most welcome.
>
>I think you should distribute your design in a binary format, since
>it's fairly easy to reverse engineer EDIF:
>
>Use any text editor for editing.
>
>Use Aldec or Riviera for simulating.  (Both tools handle a combined
>VHDL / Verilog / EDIF flow).
>
>Use a recent version of Synplify to convert to (almost readable)
>schematics.
>
>Regards,
>Allan.1


Article: 62943
Subject: Re: Transforming vector position to binary value
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 11 Nov 2003 09:13:11 -0800
Links: << >>  << T >>  << A >>
As I had posted a while ago, the Virtex-II BlockRAM is surprisingly
efficient as a priority encoder.
Use one BlockRAM as a dual-ported 4K x 4 ROM.
Feed 12 inputs as address to one port, and the next 12 bits as address
to the other port. That gives you two sets of 4 outputs defining the
priority-encoded position in the two 12-bit inputs separately.No problem
with multiple 1s!  Should work at 200+ MHz, but note that the BlockROM
is a synchronous device, it operates on a clock edge!
The remaining 8 inputs and the combining of the eight BlockROM outputs
can be done the conventional way, but might also be done in another
BlockROM (generating a second clock latency!)
Peter Alfke, Xilinx Applications

Article: 62944
Subject: Re: Layout examples
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Tue, 11 Nov 2003 17:30:34 -0000
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> wrote in message
news:mt8sb.12$SZ3.1981@news-west.eli.net...
[...]
> The "*very* short tracks" is a noteworthy comment as
> well; it's easy to make a stiff decoupling cap a bit soft by adding a
little
> track between the pad and via(s).

Showing my age here....  when I was routinely designing PCBs
around 8-10 years ago, I was often given a very hard time by
assembly subcontractors if I put vias inside an SMD pad - they
used to complain about solder hogging or some such manufacturing
folklore.  What are the up-to-date design rules for putting vias
in or very close to a pad?

TIA
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.





Article: 62945
Subject: Re: Implementing a very fast counterin VirtexII
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 11 Nov 2003 09:45:28 -0800
Links: << >>  << T >>  << A >>
Erez
This is a good idea for a counter, but it does not work for a general
purpose incrementer where you would throw new vectors at it on every
clock cycle. In that case, my suggestion of detecting FFFF and
generating a wait state works well. (I hope you did not think I was just
brushing the problem under the carpet. I solve it with the additional
wait state ).
Regarding your 2-stage prescaler, I would extend this to three stages.
It gives you double the timing benefit, and it fits the 4-input LUT
structure very nicely.
I don't understand your item 4, but that may be just semantics.

Good luck, and happy counting at 400+MHz!
Peter Alfke, Xilinx Applications
=========================
Erez Birenzwig wrote:
> 
> Then when you read the counter every clock cycle once every 64K counts
> you'll
> get a wrong result. I don't think it's good enough.. Remember the FMUL bug ?
> 
> Anyway I got a good answer from another list :
> 
> 1) Build a fast 2-bit counter
> 2) Build a slow 62-bit counter, with enable
> 3) Use enable = q[1]&q[0]
> 4) latch the slow counter using the enable as well
> 
> You get a full 4 cycles for the carry to ripple through the upper 62
> bits.  Be careful in timing analysis.  Some systems let you specify that
> the carry chain is a multi-cycle path.  Other's force you to ignore
> these paths with falsepath commands.
> 
> (Thanks Bill for the help).
> 
> Erez.
> 
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3FB0230F.3FC83434@xilinx.com...
> > I would suggest detecting FFFF and generating a wait state or two when
> > you reach that value. The probability is one in 64K, so it should hardly
> > have any impact on performance.
> >
> > Peter Alfke
> > ==================
> > Erez Birenzwig wrote:
> > >
> > > To be more precise the implementation requires the calculation of:
> > > a = a + 1
> > >
> > > When a is a 64bit vector, every clock cycle at 200MHz, using a
> virtexII-6
> > > FPGA.
> > >
> > > Erez.
> > >
> > > "Peter Alfke" <peter@xilinx.com> wrote in message
> > > news:3FB01875.A2C23F2F@xilinx.com...
> > > > "Counter" can mean many things.
> > > > If you need a synchronous counter that gives you the updated value
> > > > before the next count pulse comes in, that is a demanding design and
> may
> > > > have timing problems at 200 MHz.
> > > >
> > > > If, at the other extreme, you just need a counter that can resolve 200
> (
> > > > or 500+ ) MHz, and you can wait some nanoseconds before you read the
> > > > final count value, that is trivial. In the extreme case you would just
> > > > concatenate 2-bit Johnson counters (at least at the input end), one
> > > > slice clocking the next. And there are many variations on this theme.
> > > > I built a 400 MHz frequency counter 5 years ago with
> XC4002XL...Playing
> > > > around, aiming at 1 GHz now.
> > > >
> > > > Peter Alfke, Xilinx Applications
> > > >
> > > >
> > > > Erez Birenzwig wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > >   I'm trying to write some code for a 64 bit counter for a VirtexII.
> > > > >
> > > > >   The problem I'm facing is that it has to run at least at 200MHz,
> and
> > > > > therefore
> > > > > a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to
> > > 114MHz).
> > > > >
> > > > >   I've tried a split approach with four smaller counters and a
> selector
> > > > > depending on the carry out of the previous stages but it only got me
> to
> > > > > about
> > > > > 180MHz.
> > > > >
> > > > >   Did anyone ever had a similar problem and solved it ?
> > > > >   Unfortunately I'm not familiar with a pipelined implementation,
> I'll
> > > be
> > > > > happy
> > > > > to learn one.
> > > > >
> > > > >   Many thanks,
> > > > >   Erez.

Article: 62946
Subject: Re: Reverse engineering an EDIF file?
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 11 Nov 2003 12:55:12 -0500
Links: << >>  << T >>  << A >>
On Mon, 10 Nov 2003 23:10:39 +0100, Rastislav Struharik wrote:

> Hello,
> 
> I would like to know does anyone knows, is it possible to reverse
> engineer an edif netlist file? I am currently developing an FPGA core.
> I would like to supply an evaluation version of the core, that would
> have all the functionality of the final core, but would operate only
> for a limited period of time. My fear is that there is a way to modify
> the evaluation version edif netlist (find and remove modules that set
> a time limit to the operation of the evaluation version), and thus
> obtain completely functional core. Can something like this be done, or
> am I being paranoid?
> Every help and clarification on this subject is most welcome.
> 
> Thanks in advance,
> Rastislav Struharik

You can convert the edif file into Verilog of VHDL by running the Xilinx
programs edif2ngd followed by an ngd2ver or ngd2vhdl. What you get is gate
level so it's not easy to work with but it's at least minimally human
readable.



Article: 62947
Subject: Re: Layout examples
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 11 Nov 2003 17:57:43 GMT
Links: << >>  << T >>  << A >>
"Filled Vias" are a process that your raw-board vendor may support and are
necessary for in-the-pad vias.  You're still right in that unfilled vias in
the pad act as solder theifs.  Micro-vias (a form of blind via) are even
better at giving exceptionally low impedance without acting as a sloder
theif but the cost and tool support art two things I'd worry about.  Chances
are you'll stick with regular vias and get the spacing particulars
(capacitor pad to via minimum spacing) from your board assembly house or
someone else intimately familiar with the IPC recommendations.

It wouldn't be a good thing to just stick those vias in the pads or a
solder-flow away from the pad to act as a nice drain for the solder.  These
details get lost on those of us who have it ingrained upon us that the
minimum spacing shall never be violated.  Thanks for keeping the details
alive.

"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:bor6c5$je3$1$8300dec7@news.demon.co.uk...
> "John_H" <johnhandwork@mail.com> wrote in message
> news:mt8sb.12$SZ3.1981@news-west.eli.net...
> [...]
> > The "*very* short tracks" is a noteworthy comment as
> > well; it's easy to make a stiff decoupling cap a bit soft by adding a
> little
> > track between the pad and via(s).
>
> Showing my age here....  when I was routinely designing PCBs
> around 8-10 years ago, I was often given a very hard time by
> assembly subcontractors if I put vias inside an SMD pad - they
> used to complain about solder hogging or some such manufacturing
> folklore.  What are the up-to-date design rules for putting vias
> in or very close to a pad?
>
> TIA
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
UK
> Tel: +44 (0)1425 471223                    mail:
jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>
>
>
>



Article: 62948
Subject: Re: Linux and FPGA compatibility
From: sleepymish@hotmail.com (Michelle)
Date: 11 Nov 2003 11:02:21 -0800
Links: << >>  << T >>  << A >>
sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311110741.10ae36dc@posting.google.com>...
> johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0311052351.1f2db0a7@posting.google.com>...
> > sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311050941.3dc9ee2c@posting.google.com>...
> > > Hi, 
> > > 
> > > I'm a newbie to FPGA and Linux world. I have a general question
> > > concerning both.
> > > 
> > > I have a workstation with Linux installed. A Virtex II Pro FPGA Module
> > > is plugged in the backplane of the workstation. I'm wondering if I
> > > need to write a device driver for the FPGA module in order for the
> > > Linux box to recognize the card?
> > > 
> > > I want a software program running on the Linux machine to be able to
> > > poll a few registers on the FPGA module, bascially through memory map.
> > > Is this possible without a device driver?
> > > 
> > > Thanks in advance for all the help. 
> > > 
> > > Michelle
> > 
> > 
> > The better FPGA board makers should include a ready to go PCI device
> > driver. For Windows this would have been something like Numega IIRC,
> > but for Linux I am less sure, most of my old links are long gone
> > (thanks to MS ...).
> > 
> > Who is the board vendor?, check their site for driver support.
> > 
> > John
> > 
> > johnjaksonATusaDOTcom
> 
> Xilinx is the vendor.

By the way, I have a related question....

I believe the "/proc/bus/pci/devices" file in Linux lists all the
devices on the PCI bus. I'm wondering if anyone knows how this file is
updated or maintained? How is this file updated with the devices.? Is
it updated every time the system is turned on or does the system admin
update with the appropriate information?

Thanks!

Article: 62949
Subject: Re: Linux and FPGA compatibility
From: H. Peter Anvin <hpa@zytor.com>
Date: 11 Nov 2003 11:21:44 -0800
Links: << >>  << T >>  << A >>
Followup to:  <2b3db7ca.0311111102.31c51e50@posting.google.com>
By author:    sleepymish@hotmail.com (Michelle)
In newsgroup: comp.arch.fpga
> 
> By the way, I have a related question....
> 
> I believe the "/proc/bus/pci/devices" file in Linux lists all the
> devices on the PCI bus. I'm wondering if anyone knows how this file is
> updated or maintained? How is this file updated with the devices.? Is
> it updated every time the system is turned on or does the system admin
> update with the appropriate information?
> 

Anything in /proc is automatically updated by the kernel.

	-hpa



-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64



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