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 20000

Article: 20000
Subject: Re: Transmeta CM & Conf. Comp?
From: Ray Andraka <randraka@ids.net>
Date: Sat, 22 Jan 2000 06:28:35 GMT
Links: << >>  << T >>  << A >>
If I read this right, you want to run X86 code on an FPGA, along with
the FPU.  Don't go there, you'll be really dissapointed with the
performance.  A common misconception about configurable computing in
FPGAs is that the computer implemented in the FPGA is like a common
CPU.  Sure, you can do that, but it ain't gonna touch the performance of
the dedicated CPU chip.

Where FPGAs get their power is the ability to become a custom processor
highly optimized for the task at hand.  If you were going to do nothing
but hammer nails all day, you would spend your money on the best hammer
you could get, not on the mechanics tool chest full of all kinds of
tools, half of which you haven't a clue what they're for.  You'd be
really good at banging in nails, but the hammer wouldn't help too much
for repairing cars.  On the otherhand, if one day you were hammering,
and the next you were fixing cars, if you could trade the hammer for the
wrenches you need you might be able to get away with not buying both.

It is similar with FPGA processors.  For example, if I need to add a
whole bunch of numbers, A CPU would be pretty much stuck with adding one
or two at a time to eventually end up with the sum.  You can't do too
much more than that with the CPU, because you have a very limited amount
of adder resources.  In an FPGA, you have alot of uncommitted gates, so
when we need to do that adding, we just use more gates to do the
additions in parallel if we need to do it fast.

mu0lia0ni@my-deja.com wrote:

> Hi, I have an idea about combining Configurable
> computers/CPU / Processor modules based on FPGA
> with the new Transmeta's CODE MORPHING software.
> If succesful,  the Intel X86 programs can run
> on the configurable computer.
> Is this possible? What is your comments/opinion?
> Is there any problem with Floating Point operation
> on FPGA based configurable computers?
> What is the typical setup delay?
> Regards
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 20001
Subject: Re: Assignment of pins for thousand+ pin packages
From: Phil Hays <Spampostmaster@sprynet.com>
Date: Fri, 21 Jan 2000 23:46:07 -0800
Links: << >>  << T >>  << A >>
Paul Walker wrote:

PW> Get the acrobat version of the data book and device-specific pin tables;
PW> Extract the text of the table into the clipboard;

This suggestion is a good starting point for text/script pinouts for some
device/package combinations,  thank you.  When I tried this on one specific
table, I couldn't copy the text.  I will complain to the guilty party before
mentioning a name here.  

Why don't the vendors just supply a plain text version of pinout tables?


PW> Does anyone else understand why it is the .pcf format that the tools
PW> produce an example of (in the .pad file) rather than the .ucf format?

There is a pin2ucf.exe program in M2.1i that you might want to try.

 
Andreas Doering wrote:

AD> Therefore, I propose (and used) a modification of 2)
AD> 4) Generate a constraint file with a script (perl or whatever).

Scripts can help a lot with the regular parts of the pinout.  Another good
suggestion, thank you.  

It is just not as easy when multiple types of IO levels are used.  Yes, I guess
that a script could be written that checked the Vref and Vcco of the bank for
each pin.


-- 
Phil Hays
Article: 20002
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: krw@attglobal.net (Keith R. Williams)
Date: 22 Jan 2000 17:04:58 GMT
Links: << >>  << T >>  << A >>
On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein" 
<mbillens@one.net> wrote:

> All,
> 
> I've not seen (or cannot find) an appropriate appnote or reference design
> for laying down these fine pitch BGA parts (say FG256 for example)  There
> doesn't seem to be a lot of room between BGA solder pads (0.400 millimeters
> nominal) to route out or drop vias of any substantial size...  I can route
> out two rows around the whole part with very little trouble, but I think I
> have to dogbone anything further inside the part.  How are you folks here
> doing it?

When I switched FPGA manufacturers (at gun-point :-|) I went from
a BG560 to a FG680 to make things a little easier (it didn't). My
choices were either a 3mil line width to get two out traces per 
channel or another plane and 5mil traces and one per channel. 
Since I needed a 50 ohm environment and this widget is a "cost is
no object" type of deal, I chose another plane (actually two - 
one for another power plane to keep 50 ohms). I have a total of 
ten planes (5p, 5S).

----
  Keith


Article: 20003
Subject: Re: Transmeta CM & Conf. Comp?
From: Tim Tyler <tt@cryogen.com>
Date: Sat, 22 Jan 2000 18:37:53 GMT
Links: << >>  << T >>  << A >>
mu0lia0ni@my-deja.com wrote:

: Hi, I have an idea about combining Configurable
: computers/CPU / Processor modules based on FPGA
: with the new Transmeta's CODE MORPHING software.
: If succesful,  the Intel X86 programs can run
: on the configurable computer.
: Is this possible? [...]

I believe Star Bridge Systems claim to be able to perform programmable
logic-based x86 emulation: http://www.starbridgesystems.com/

They use ``Synthesized Hyper-Specificity Specificity Processors(TM)''
- according to their marketing department.

Quite why anyone would want to emulate an x86 in programmable logic
appears obscure today.  An FPGA solution will probably do several of:
be more expensive, run much slower, consume more power and get hotter
than the real thing.

Transmeta's "Code Morphing" software targets their own VLIW architecture -
which appears to have very little to do with FPGAs.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Save the whales.  Collect the whole set.
Article: 20004
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: bob_42690@my-deja.com
Date: Sat, 22 Jan 2000 19:54:52 GMT
Links: << >>  << T >>  << A >>
In article <pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost>,
  krw@attglobal.net wrote:
> On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein"
> <mbillens@one.net> wrote:
>
> > All,
> >
> > I've not seen (or cannot find) an appropriate appnote or reference
design
> > for laying down these fine pitch BGA parts (say FG256 for example)
There
> > doesn't seem to be a lot of room between BGA solder pads (0.400
millimeters
> > nominal) to route out or drop vias of any substantial size...  I can
route
> > out two rows around the whole part with very little trouble, but I
think I
> > have to dogbone anything further inside the part.  How are you folks
here
> > doing it?
>
> When I switched FPGA manufacturers (at gun-point :-|) I went from
> a BG560 to a FG680 to make things a little easier (it didn't). My
> choices were either a 3mil line width to get two out traces per
> channel or another plane and 5mil traces and one per channel.
> Since I needed a 50 ohm environment and this widget is a "cost is
> no object" type of deal, I chose another plane (actually two -
> one for another power plane to keep 50 ohms). I have a total of
> ten planes (5p, 5S).
>
> ----
>   Keith
>
>

According to the High-Speed Digital Design book by Howard Johnson and
Martin Graham, if faced with adding another plane, a ground plane is a
better choice than another power plane.  It minimizes the jump of return
currents through bypass capacitors as the signal traverses it's
different routing layers (Section 5.8.6)


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20005
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Sat, 22 Jan 2000 14:48:42 -0800
Links: << >>  << T >>  << A >>
On Sat, 22 Jan 2000 19:54:52 GMT, bob_42690@my-deja.com wrote:

|In article <pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost>,
|  krw@attglobal.net wrote:
|> On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein"
|> <mbillens@one.net> wrote:
|>
|> > All,
|> >
|> > I've not seen (or cannot find) an appropriate appnote or reference
|design
|> > for laying down these fine pitch BGA parts (say FG256 for example)
|There
|> > doesn't seem to be a lot of room between BGA solder pads (0.400
|millimeters
|> > nominal) to route out or drop vias of any substantial size...  I can
|route
|> > out two rows around the whole part with very little trouble, but I
|think I
|> > have to dogbone anything further inside the part.  How are you folks
|here
|> > doing it?
|>
|> When I switched FPGA manufacturers (at gun-point :-|) I went from
|> a BG560 to a FG680 to make things a little easier (it didn't). My
|> choices were either a 3mil line width to get two out traces per
|> channel or another plane and 5mil traces and one per channel.
|> Since I needed a 50 ohm environment and this widget is a "cost is
|> no object" type of deal, I chose another plane (actually two -
|> one for another power plane to keep 50 ohms). I have a total of
|> ten planes (5p, 5S).
|>
|> ----
|>   Keith
|>
|>
|
|According to the High-Speed Digital Design book by Howard Johnson and
|Martin Graham, if faced with adding another plane, a ground plane is a
|better choice than another power plane.  It minimizes the jump of return
|currents through bypass capacitors as the signal traverses it's
|different routing layers (Section 5.8.6)
|
|
|Sent via Deja.com http://www.deja.com/
|Before you buy.

Bob,

I don't believe this. The planes themselves have so much mutual
capacitance that the bypass caps don't matter... a plane's a plane.

I usually run a test trace on my multilayer boards, starting at a tiny
surfmount coax connector layout, zigzagging through all the layers,
computed to be constant 50 ohms, and ending with a 50 ohm 0805
resistor. I then TDR the trace to see how we're doing. Even with no
parts loaded (bare board, no caps) the 'return plane' distinction is
invisible.

Johnson's book is roughly 2/3 good stuff and 1/3 nonsense;  the
obvious problem is figuring out which is which.

John

Article: 20006
Subject: Cypress programming information for old 370i devices.
From: "Ing. Salvatore Di Fazio" <salvodf@tiscalinet.it>
Date: Sun, 23 Jan 2000 00:43:12 +0100
Links: << >>  << T >>  << A >>
I am searching Cypress programming information for old 370 devices.
Who can help me?

            Thank you very much.

Article: 20007
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: krw@attglobal.net (Keith R. Williams)
Date: 23 Jan 2000 03:01:46 GMT
Links: << >>  << T >>  << A >>
On Thu, 1 Jan 1970 02:59:59, John Larkin 
<jjlarkin@highlandSnipSniptechnology.com> wrote:

> On Sat, 22 Jan 2000 19:54:52 GMT, bob_42690@my-deja.com wrote:
> 
> |In article <pLMYl5dhX7hK-pn2-qfE65ylclhD2@localhost>,
> |  krw@attglobal.net wrote:
> |> On Sun, 19 Jan 3900 04:04:17, "Matt Billenstein"
> |> <mbillens@one.net> wrote:
> |>
> |> > All,
> |> >
> |> > I've not seen (or cannot find) an appropriate appnote or reference
> |design
> |> > for laying down these fine pitch BGA parts (say FG256 for example)
> |There
> |> > doesn't seem to be a lot of room between BGA solder pads (0.400
> |millimeters
> |> > nominal) to route out or drop vias of any substantial size...  I can
> |route
> |> > out two rows around the whole part with very little trouble, but I
> |think I
> |> > have to dogbone anything further inside the part.  How are you folks
> |here
> |> > doing it?
> |>
> |> When I switched FPGA manufacturers (at gun-point :-|) I went from
> |> a BG560 to a FG680 to make things a little easier (it didn't). My
> |> choices were either a 3mil line width to get two out traces per
> |> channel or another plane and 5mil traces and one per channel.
> |> Since I needed a 50 ohm environment and this widget is a "cost is
> |> no object" type of deal, I chose another plane (actually two -
> |> one for another power plane to keep 50 ohms). I have a total of
> |> ten planes (5p, 5S).
> |>
> |> ----
> |>   Keith
> |>
> |>
> |
> |According to the High-Speed Digital Design book by Howard Johnson and
> |Martin Graham, if faced with adding another plane, a ground plane is a
> |better choice than another power plane.  It minimizes the jump of return
> |currents through bypass capacitors as the signal traverses it's
> |different routing layers (Section 5.8.6)
> |
> |
> |Sent via Deja.com http://www.deja.com/
> |Before you buy.
> 
> Bob,
> 
> I don't believe this. The planes themselves have so much mutual
> capacitance that the bypass caps don't matter... a plane's a plane.

I totally agree. Planes are planes. In any case, my offsetting 
factor is that I converted a split 5V/3.3V plane into two 
contiguous planes, at least under the high-speed stuff.  A good 
portion of the board is regulators, so I went with maximum 
surface metal for whatever the PowerFETS tabs were connected.

I do have split planes because some devices require different 
voltages (can't fit any more planes into .062"), but I burried 
them between two other solid planes. I don't believe any 
high-speed line crosses any discontinuity in planes and all 
high-speed lines are 50ohm.  The outer two (signal) planes are 
reserved for house-keeping, BGA pads, and metal for heatsinking. 
There are no critical nets on the surface (I may regret this). 
The real critical nets never see a via, except at the BGAs. 
They're wired on a single plane each (three planes). I should 
know if this works in a couple of weeks.  

Actually, I already know of two flaws, one in the impedance of 
differential PECL/LVPECL clocks (the nets were set up to 50ohm, 
but differentially they're more like 40), and another really dumb
mistake (reused an "address" line).

> I usually run a test trace on my multilayer boards, starting at a tiny
> surfmount coax connector layout, zigzagging through all the layers,
> computed to be constant 50 ohms, and ending with a 50 ohm 0805
> resistor. I then TDR the trace to see how we're doing. Even with no
> parts loaded (bare board, no caps) the 'return plane' distinction is
> invisible.

What do you see at the vias?  This is very interesting. I 
threatened to break the layout person's legs if he switched 
planes on a critical net.  The clocks are routed inbetween planes
- never to surface, except at the BGA's Vias.

> Johnson's book is roughly 2/3 good stuff and 1/3 nonsense;  the
> obvious problem is figuring out which is which.

Yikes!  That's what life is about! ...well maybe in different 
proportions. ;-)

----
  Keith



Article: 20008
Subject: Re: Biphase mark decoder
From: edick@hotmail.com (Richard Erlacher)
Date: Sun, 23 Jan 2000 04:09:31 GMT
Links: << >>  << T >>  << A >>



On Fri, 21 Jan 2000 13:21:07 +0800, "Sherdyn" <sherdyn@yahoo.com>
wrote:

>But how am I going to know the clk frequency? One of the feature of this
>design is that it should be able to support 4 different frequencies. (in the
>range 400us - 500 us period)
>
>Sherdyn
>
>Kelly Hall <khall@pacbell.net> wrote in message
>news:5aRh4.83$oj1.7843@nnrp3-w.snfc21.pbi.net...
>> On Fri, 21 Jan 2000 10:42:59 +0800, Sherdyn <sherdyn@yahoo.com> wrote:
>> >Can someone tell me how I can extract a clock embedded in a serial stream
>> >which is biphase mark coded? I have only a single input stream to FPGA
>and
>> >need to extract some bits within a frame of 90 bits (assuming I have an
>> >independent clock which is running 2 times or more). The only thing I
>know
>> >is I would be able to do that with a Digital PLL but do not exactly sure
>> >what it is.
>>
>> As I recall, you should have a 32x clock.  Sample on counts 7 and 23.
>> If the two samples are the same, the data is a 1, else a 0.  You can
>> use different clock periods, but be test to test interoperability.
>>
>> Kelly
>
Well . . . what ARE the four frequencies?  Thee must be a spec
somewhere.  While you're checking what is wanted here, perhaps you can
find out precisely what the modulation (coding) scheme is.  It may
well be BIPHASE-L (Manchester) from which clock extraction is quite
straightforward.  There should also be a specification for a sync word
from which you can extract framing.  In any case, the DPLL I'd propose
is quite simple and requires at least four flipflops and perhaps a
fifth as transient memory for the incoming data pulse.  The incoming
data./clock pulse can only be used once in each 8-count window.  It's
up to you to see that it never extends beyond the count window within
which it occurs.  

If you'd like your DPLL to work well, you really need a 16x clock,
else you'll not be happy with the jitter on your clock.  You can then
wait for the arrival of a data pulse, using a 4-bit counter which
skips head a count if the data pulse occurs during the first three
counts (0,1,2,8,9,A), does nothing but count if it occurs during the
middle  counts (3,4,B,C),  and is disabled for one count, essentially
retarding the counter by one count, if the pulse occurs during the
last 3 counts of each 8-count cycle  (5,6,7,D,E,F).  Take your output
from the MSB of the 4-bit counter.  This scheme should lock in four
bit periods of the counter, provided that the data rate is within 5%
of 1/16th the driver clock.   The output clock will jitter at most
6.25%.  

Dick


Article: 20009
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Sat, 22 Jan 2000 20:42:10 -0800
Links: << >>  << T >>  << A >>
On 23 Jan 2000 03:01:46 GMT, krw@attglobal.net (Keith R. Williams)
wrote:


|I totally agree. Planes are planes. In any case, my offsetting 
|factor is that I converted a split 5V/3.3V plane into two 
|contiguous planes, at least under the high-speed stuff.  A good 
|portion of the board is regulators, so I went with maximum 
|surface metal for whatever the PowerFETS tabs were connected.
|
|I do have split planes because some devices require different 
|voltages (can't fit any more planes into .062"), but I burried 
|them between two other solid planes. I don't believe any 
|high-speed line crosses any discontinuity in planes and all 
|high-speed lines are 50ohm.  The outer two (signal) planes are 
|reserved for house-keeping, BGA pads, and metal for heatsinking. 
|There are no critical nets on the surface (I may regret this). 
|The real critical nets never see a via, except at the BGAs. 
|They're wired on a single plane each (three planes). I should 
|know if this works in a couple of weeks.  
|
|Actually, I already know of two flaws, one in the impedance of 
|differential PECL/LVPECL clocks (the nets were set up to 50ohm, 
|but differentially they're more like 40), and another really dumb
|mistake (reused an "address" line).
|

Keith,

40 ohms isn't bad if you were shooting for 50. I use three different
microstrip/stripline calculator programs, and they often disagree by
10% or so.  We do split planes, too (say, an island of 3.3v in a 5v
plane) and don't worry about crossing boundaries.

|
|What do you see at the vias?  This is very interesting. I 
|threatened to break the layout person's legs if he switched 
|planes on a critical net.  The clocks are routed inbetween planes
|- never to surface, except at the BGA's Vias.

If your edges are over 100 ps, vias are invisible, too. Even with a 30
ps resolution TDR, vias are just little bumps. We do EclipsLite all
the time, with tons of vias.

Interestingly, on one board I put a bunch of Hirose coax connector
pads so I could TDR the power planes and the little 3.3v island. As
far as I could tell, a plane behaves like an ideal capacitor of the
expected value. Adding bypass caps - anywhere - then makes it look
like a *bigger* ideal capacitor. If your power and ground planes are
close, all you need is a few scattered bypass caps, but nothing like
one per chip. Some brave souls build BIG digital boards with no bypass
caps at all! (I'm not quite that brave...)

If you solder some SMAs on your board and send it to me, I'll TDR it
and send you snapshots.

John

Article: 20010
Subject: Re: WebFitter???
From: Jamil Khaib <Khatib@ieee.org>
Date: Sun, 23 Jan 2000 13:51:18 +0200
Links: << >>  << T >>  << A >>
you can define the pins in a seperate file "not VHDL" if you do not know how to
define it change the options of the webfitter to download get a file then you
can edit it according to your need

Anthony Ellis - LogicWorks wrote:

> For someone new to Xilinx.
> I am planning to use a XC9572 PLD using the online Web compiler and fitter -
> using  VHDL source code.
> Does anyone know how to embedd my pin allocation details into the VHDL
> source.
>
> Thanks Anthony

Article: 20011
Subject: Re: Transmeta CM & Conf. Comp?
From: timothyc@ribbit.CS.Berkeley.EDU (Tim Callahan )
Date: 23 Jan 2000 19:27:52 GMT
Links: << >>  << T >>  << A >>
In article <For2F5.Ex@bath.ac.uk>, Tim Tyler  <tt@cryogen.com> wrote:
>mu0lia0ni@my-deja.com wrote:
>: Hi, I have an idea about combining Configurable
>: computers/CPU / Processor modules based on FPGA
>: with the new Transmeta's CODE MORPHING software.
>: ...
> ...
>Transmeta's "Code Morphing" software targets their own VLIW architecture -
>which appears to have very little to do with FPGAs.


What VLIWs and FPGAs have in common is that they both
can exploit instruction-level parallelism (ILP).  Because of this,
I've found it very useful to employ VLIW compilation techniques ---
hyperblock formation, predication, speculation, (sw) pipelining ---
in my work in extracting loops from ISO C programs for 
acceleration on a rapidly reconfigurable coprocessor.

As Ray said, you don't want to make the mistake of building
an instruction-based processor using your FPGA, even
if it's VLIW and specialized.  You'd be shackling yourself
with the same limitations of fixed instruction issue bandwidth,
fixed reg file bandwidth, and n^2 complexity in your bypassing network.
And you'd be a lot slower than a hardwired VLIW.

My approach is to use VLIW techniques to extract the dataflow
graph for the loop, exposing the ILP, but then map it
directly---spatially---to hardware.  No reuse of function units,
so each can be optimized for the one operation is executing.  
Often multiple adjacent operations in the DFG can be merged into
a single optimized FPGA module (kind of like compiling to
CISC instructions).

Of course, this fully-specialized approach means that
you must completely reconfigure each time you want to accelerate
a different kernel.  The VLIW-on-top-of-FPGA approach would allow
you to change just the instructions/microcode.  But then your
problem is specializing your configured VLIW processor to
be good at two or more loops, so it probably won't be -great-
at any of them.

So, my philosophy is, use the VLIW compilation/morphing 
techniques, but don't build a VLIW processor on your FPGA.

	-- Tim

------------------------------------------------------------------------
Tim Callahan			  415 Soda Hall, (510) 643-4203
timothyc@cs.Berkeley.EDU	  http://www.cs.berkeley.edu/~timothyc/
------------------------------------------------------------------------
Article: 20012
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: krw@attglobal.net (Keith R. Williams)
Date: 23 Jan 2000 19:38:31 GMT
Links: << >>  << T >>  << A >>
On Thu, 1 Jan 1970 02:59:59, John Larkin 
<jjlarkin@highlandSnipSniptechnology.com> wrote:

> On 23 Jan 2000 03:01:46 GMT, krw@attglobal.net (Keith R. Williams)
> wrote:
> 
> |I do have split planes because some devices require different 
> |voltages (can't fit any more planes into .062"), but I burried 
> |them between two other solid planes. I don't believe any 
> |high-speed line crosses any discontinuity in planes and all 
> |high-speed lines are 50ohm.  The outer two (signal) planes are 
> |reserved for house-keeping, BGA pads, and metal for heatsinking. 
> |There are no critical nets on the surface (I may regret this). 
> |The real critical nets never see a via, except at the BGAs. 
> |They're wired on a single plane each (three planes). I should 
> |know if this works in a couple of weeks.  
> |
> |Actually, I already know of two flaws, one in the impedance of 
> |differential PECL/LVPECL clocks (the nets were set up to 50ohm, 
> |but differentially they're more like 40), and another really dumb
> |mistake (reused an "address" line).
> |
> 
> Keith,
> 
> 40 ohms isn't bad if you were shooting for 50. I use three different
> microstrip/stripline calculator programs, and they often disagree by
> 10% or so.  We do split planes, too (say, an island of 3.3v in a 5v
> plane) and don't worry about crossing boundaries.

I'm not too concerned about the impedance. I'd rather be low than
high here. If it's a problem there are already two rather simple 
solutions available. I think only four (possibly eight) pairs of 
signals are long enough to count as transmission lines. I can 
lower the termination resistors if necessary.  The drivers might 
complain, but this isn't in any way going to be a product. The 
other alternative would be to change the traces slightly.

That's interesting. In the list of no-nos for EMI design is plane
crossings because of the return path. I can see how the plane 
capacitance coupled via the contiguous ground plane would couple 
the return current across but these capacitors are in series, no?
I guess if the capacitance is big enough...

> |What do you see at the vias?  This is very interesting. I 
> |threatened to break the layout person's legs if he switched 
> |planes on a critical net.  The clocks are routed inbetween planes
> |- never to surface, except at the BGA's Vias.
> 
> If your edges are over 100 ps, vias are invisible, too. Even with a 30
> ps resolution TDR, vias are just little bumps. We do EclipsLite all
> the time, with tons of vias.
> 
> Interestingly, on one board I put a bunch of Hirose coax connector
> pads so I could TDR the power planes and the little 3.3v island. As
> far as I could tell, a plane behaves like an ideal capacitor of the
> expected value. Adding bypass caps - anywhere - then makes it look
> like a *bigger* ideal capacitor. If your power and ground planes are
> close, all you need is a few scattered bypass caps, but nothing like
> one per chip. Some brave souls build BIG digital boards with no bypass
> caps at all! (I'm not quite that brave...)

Not this chicken! ;-)  I think I have about 460 capacitors on 
this board. Only a few of them do something interesting, most are
there to ward off evil spirits. Many of them are 470uF for bulk 
decoupling, switcher filters and such. I used the Xilinx 
recommendations (as close as I could reasonably follow them) for 
decoupling the VCCO and VCCint balls (how do you get two caps in 
a 1mm space??). I also have about twelve voltage levels so 460 
isn't all *that weird. There are also a ton of pretty "hot" 
LVCMOS and HSTL drivers with 64 bit busses so simultaneous 
switching is a problem. The ECL stuff is just used for clock 
generation, timing, and distribution. I'm not so concerned about 
it.

I can see how one could get away with less decoupling in ECL, but
CMOS?  That's not somewhere my boss would like me to go. 

> If you solder some SMAs on your board and send it to me, I'll TDR it
> and send you snapshots.

I have access to a TDR. I could do this, but I won't have any 
bare boards. I know the vendor is making extras in case of 
defects. Maybe I can snag one and take a look at it with a TDR.  
I'm also interested in the power supply to the chip this board is
intended to play with.  A TDR is the way to go. 

I'd like to understand how you attach the TDR.  What do you do 
with the planes?  Tie them all to the TDR's ground?  Tie the GND 
plane to the TDR and let the rest float?

This is very interesting.  I'm going to look into this further. 
I'd like to hear other's comments about this subject as well.

----
  Keith
Reply-To: "Sherdyn" <sherdyn@yahoo.com>
Article: 20013
Subject: Re: Biphase mark decoder
From: "Sherdyn" <sherdyn@yahoo.com>
Date: Mon, 24 Jan 2000 09:34:00 +0800
Links: << >>  << T >>  << A >>
First of all, thank you very much to all of you that taking time replying my
mail!!

The four frequencies are 420 us, 450 us, 500 us and 520 us. The module must
be able to auto-detect these frequencies as the bits which need to be
extracted later on are embedded in different locations away from the
synchronization
word. What I intend to do is to generate a clock which is running 8X or 16X
faster
than the detected clock (I have a system clock of 25 MHz). Use this
generated clock to run a counter which is then use as
indicator to sample data at the correct interval. After synchronization on
bit boundary is achieved, I can then synch to synchronization word before
extraction of bits can be performed. My problem is how can I detect these
four frequencies? I'm thinking of using a fast clock to start counting when
the first data transition occur and check the number of count when a second
data transition elapsed ... but, I face the second problem, the data
transition can occur at middle of bit or start of bit.


Richard Erlacher <edick@hotmail.com> wrote in message
news:388a6a41.955324305@mindmeld.idcomm.com...
>
>
>
> On Fri, 21 Jan 2000 13:21:07 +0800, "Sherdyn" <sherdyn@yahoo.com>
> wrote:
>
> >But how am I going to know the clk frequency? One of the feature of this
> >design is that it should be able to support 4 different frequencies. (in
the
> >range 400us - 500 us period)
> >
> >Sherdyn
> >
> >Kelly Hall <khall@pacbell.net> wrote in message
> >news:5aRh4.83$oj1.7843@nnrp3-w.snfc21.pbi.net...
> >> On Fri, 21 Jan 2000 10:42:59 +0800, Sherdyn <sherdyn@yahoo.com> wrote:
> >> >Can someone tell me how I can extract a clock embedded in a serial
stream
> >> >which is biphase mark coded? I have only a single input stream to FPGA
> >and
> >> >need to extract some bits within a frame of 90 bits (assuming I have
an
> >> >independent clock which is running 2 times or more). The only thing I
> >know
> >> >is I would be able to do that with a Digital PLL but do not exactly
sure
> >> >what it is.
> >>
> >> As I recall, you should have a 32x clock.  Sample on counts 7 and 23.
> >> If the two samples are the same, the data is a 1, else a 0.  You can
> >> use different clock periods, but be test to test interoperability.
> >>
> >> Kelly
> >
> Well . . . what ARE the four frequencies?  Thee must be a spec
> somewhere.  While you're checking what is wanted here, perhaps you can
> find out precisely what the modulation (coding) scheme is.  It may
> well be BIPHASE-L (Manchester) from which clock extraction is quite
> straightforward.  There should also be a specification for a sync word
> from which you can extract framing.  In any case, the DPLL I'd propose
> is quite simple and requires at least four flipflops and perhaps a
> fifth as transient memory for the incoming data pulse.  The incoming
> data./clock pulse can only be used once in each 8-count window.  It's
> up to you to see that it never extends beyond the count window within
> which it occurs.
>
> If you'd like your DPLL to work well, you really need a 16x clock,
> else you'll not be happy with the jitter on your clock.  You can then
> wait for the arrival of a data pulse, using a 4-bit counter which
> skips head a count if the data pulse occurs during the first three
> counts (0,1,2,8,9,A), does nothing but count if it occurs during the
> middle  counts (3,4,B,C),  and is disabled for one count, essentially
> retarding the counter by one count, if the pulse occurs during the
> last 3 counts of each 8-count cycle  (5,6,7,D,E,F).  Take your output
> from the MSB of the 4-bit counter.  This scheme should lock in four
> bit periods of the counter, provided that the data rate is within 5%
> of 1/16th the driver clock.   The output clock will jitter at most
> 6.25%.
>
> Dick
>
>




Article: 20014
Subject: Re: Biphase mark decoder
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 24 Jan 2000 02:32:36 GMT
Links: << >>  << T >>  << A >>


Sherdyn wrote:

> The four frequencies are 420 us, 450 us, 500 us and 520 us. The module must
> be able to auto-detect these frequencies as the bits which need to be
> extracted later on are embedded in different locations away from the
> synchronization
> word. What I intend to do is to generate a clock which is running 8X or 16X
> faster
> than the detected clock (I have a system clock of 25 MHz). Use this
> generated clock to run a counter which is then use as
> indicator to sample data at the correct interval. After synchronization on
> bit boundary is achieved, I can then synch to synchronization word before
> extraction of bits can be performed. My problem is how can I detect these
> four frequencies? I'm thinking of using a fast clock to start counting when
> the first data transition occur and check the number of count when a second
> data transition elapsed ... but, I face the second problem, the data
> transition can occur at middle of bit or start of bit.

Just start your 25 MHz counter on any transition, then ignore any transition
while the counter is below about 10,000. Then stop the counter on the next
transition. If you let the counter clear itself at 10,000 ( or thereabouts),
you get relatively small values for the four frequencies ( 500, 1250, 2500,
3000) Look-up tables or a RAM can be used as discriminator with an optimized
guardband. Then you can derive your 16 x clock from you 25 MHz. The
numbers do
not work out perfectly, but you can fix that by alternating between two very
similar clock periods. Should be fairly simple. The enormous difference between
25 MHz and about 2 kHz helps you a lot.

Peter Alfke, Xilinx
Article: 20015
Subject: Re: Virtex Fine Pitch BGA pcb layout
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Sun, 23 Jan 2000 18:58:13 -0800
Links: << >>  << T >>  << A >>

Keith,

Hirose makes some itty bitty surface-mount coax connectors (the H.FL
series) you can buy from Digikey. We often plop a few here and there
on multilayer boards.  The three gnd pins go to vias to the nearest
ground plane, and the center pin goes through a via to whatever we're
interested in: a test trace, a power plane, a power island, stuff like
that. We then solder the connectors onto a bare board, TDR things, and
see how close our theory came to real life. We often find that the PCB
fab houses aren't too religious about the dielectric stackups! It's
good to know this before you populate a mess of boards.

The next time you buy boards, ask for a 'solder sample'. All board
houses make 10-50% extras to make up for yield problems, and don't
usually mind giving rejects or extras away. They'll sometimes punch a
hole on it to ensure it's not usable!

Keep in mind that a 30 ps TDR magnifies trace discontinuities greatly
in most cases. You have to mentally (or mathematically!) lowpass
filter the TDR display to make it consistant with your actual
risetimes.

We usually use four ceramic caps per Xilinx chip, near the corners of
a 3.3 volt island. Seems to work fine.

460 is a LOT of caps! 

John

Article: 20016
Subject: Easy to program PLD
From: Shawn D'Alimonte <sdalimon@www.ee.ryerson.ca>
Date: 24 Jan 2000 05:11:15 GMT
Links: << >>  << T >>  << A >>
I am working on my final project in EE which involves improving a
single board computer used in several classes.  Students usually build
their own board (from a kit) for one class and many use the board in
their projects.  I am hoping to replace the GAL16V8 used for address
decoding with something easier to program.

So far all I have found is Lattice's ispGAL22V10.  I found a schematic
of the programmer cable and can get the software with a free 6 month
license.

I was wondering if anyone has any suggestions.  It should easily
replace a GAL device.  Small size, low cost and ease of soldering (DIP
or PLCC package) are important.  The programmer must be simple and
easy to build and software should be available for free.

Thanks in advance for any suggestions.

-- 
Shawn D'Alimonte - sdalimon@ee.ryerson.ca
"Faster processors are nice, but they are not truly revolutionary. And
   neither are colors." - Jim Collas, Amiga Inc.
Article: 20017
Subject: Re: Easy to program PLD
From: Klaus Falser <kfalser@durst.it>
Date: Mon, 24 Jan 2000 08:19:46 GMT
Links: << >>  << T >>  << A >>
In article <86gmtj$bvg$1@ns2.ryerson.ca>,
  Shawn D'Alimonte <sdalimon@www.ee.ryerson.ca> wrote:
> I am working on my final project in EE which involves improving a
> single board computer used in several classes.  Students usually build
> their own board (from a kit) for one class and many use the board in
> their projects.  I am hoping to replace the GAL16V8 used for address
> decoding with something easier to program.
>
> So far all I have found is Lattice's ispGAL22V10.  I found a schematic
> of the programmer cable and can get the software with a free 6 month
> license.
>
> I was wondering if anyone has any suggestions.  It should easily
> replace a GAL device.  Small size, low cost and ease of soldering (DIP
> or PLCC package) are important.  The programmer must be simple and
> easy to build and software should be available for free.
>
> Thanks in advance for any suggestions.
>
> --
> Shawn D'Alimonte - sdalimon@ee.ryerson.ca
> "Faster processors are nice, but they are not truly revolutionary. And
>    neither are colors." - Jim Collas, Amiga Inc.
>

You could use the smallest Xilinx XC9500 device.
Programming software is free and downloadable from there site (WebPack)
and programming is done through JTAG (6 pins ) form the parellel port
of a PC. The adapter should cost around 50$, but if you want to
build it itself there should be the schematics somewhere on Xilinx's
Web-sites.

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20018
Subject: Re: Indexing functions
From: "Nikolay" <nikolayr@acte.no>
Date: Mon, 24 Jan 2000 13:47:13 +0100
Links: << >>  << T >>  << A >>
It sounds like CAM might be a solution.
If so, Altera's APEX devices has memory blocks that can be configured as
CAM.

-Nikolay

Mark Summerfield <m.summerfield@ieee.org> wrote in message
news:388780C9.80BB528F@ieee.org...
> Andreas Doering wrote:
> > I am interested in the implementation of indexing memory in hardware
> > (custom or FPGA).
> > The problem is the following:
> > say we have inputs a0,a1
> > and a0 (a 5-bit-vector) can have 19 different values and
> >     a1 (also 5-bit) can have 21 different values.
> > We need to address a memory with binary addresses.
> > Hence we could concatenate both vectors and needed 1K memory words.
>
> Have you considered commercially-available content-addressable memory
> (CAM)?  I don't have any experience actually using it myself, but it
> seems to me that it could be used to do what you describe.  A quick
> web search turned up a number of manufacturers, or which Quality
> Semiconductor (www.qualitysemi.com) is just one -- their data sheets
> look pretty comprehensive.
>
> I don't know anything about the cost of such parts, and of course I
> have no idea about the requirements of your application -- this is
> just a thought.
>
> Mark


Article: 20019
Subject: Xilinx programming from a Linux PC
From: Phil Endecott <phil_endecott@spamcop.net>
Date: Mon, 24 Jan 2000 16:13:54 +0000
Links: << >>  << T >>  << A >>
Hi FPGA Experts,

I have a Virtex prototyping board from VCC (www.vcc.com) which I
currently program from an NT PC running the Xilinx alliance tools.  The
problem is that I run all of the other tools (VHDL simulation &
synthesis, place & route) on a Sun; this machine is locked away in a
machine room somewhere, and I have a Linux PC on my desk which I use as
an X-terminal.  I'd like to be able to get rid of the NT PC and plug the
VCC board directly into my Linux box, but I can't find a way to download
the bit file.  What I need is either a utility that will download a bit
file from Linux (I don't need anything like the hardware debugger), or
alternatively a way to make the Sun version of the alliance tools talk
to a serial port that's not on the local machine.  Xilinx support tell
me that neither is possible.

I can't believe that I'm the only person ever to try to do this.  Does
anyone have any experience to share?  If someone knows the protocol
needed to talk to an X-checker or MultiLINX cable I'm happy to write my
own tool.

Thanks in advance,

--Phil.
Article: 20020
Subject: How to access standard sdram ?
From: Thomas Sitt <ThomasSitt@t-online.de>
Date: Mon, 24 Jan 2000 17:23:13 +0100
Links: << >>  << T >>  << A >>
Hello,
I want to use standard sdram ( 64 MByte ) with FPGA.
Is it possible and where are examples to find ?

Greetings
Thomas Sitt

Article: 20021
Subject: Polynomial calculation on FPGA ???
From: "PYD" <pierre-yves.duniau@mors.fr>
Date: Mon, 24 Jan 2000 17:49:15 +0100
Links: << >>  << T >>  << A >>
Does anyone knows how to make polynomial calculation on FPGA ?

Do you have any experience or do you know an homepage which is talking about
???

Best regards,


Article: 20022
Subject: Re: Xilinx vs. other FPGAs manufactrers
From: rob_dickinson@my-deja.com
Date: Mon, 24 Jan 2000 16:56:08 GMT
Links: << >>  << T >>  << A >>
I've spent the last 6 months trying to design 10ka's with asynchronous
fifo's.  The E architecture came out just too late but we probably
would have made up a couple of the months that we "saved" by going with
the A.  If they used the E type EAB from the outset we might have a
different opinion but our next gen stuff is VERTEX all the way.  To be
fair the 10K had some advantages over the XC4000's I just can't quite
put my finger on any.

Does anyone still think that the ALTERA human interface is better?


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 20023
Subject: Re: Xilinx programming from a Linux PC
From: Sigurd Urdahl <sigurdur@naglfar.ifi.uio.no>
Date: 24 Jan 2000 18:14:43 +0100
Links: << >>  << T >>  << A >>
Phil Endecott <phil_endecott@spamcop.net> writes:

> I have a Virtex prototyping board from VCC (www.vcc.com) which I
> currently program from an NT PC running the Xilinx alliance tools.  The
> problem is that I run all of the other tools (VHDL simulation &
> synthesis, place & route) on a Sun; this machine is locked away in a
> machine room somewhere, and I have a Linux PC on my desk which I use as
> an X-terminal.  I'd like to be able to get rid of the NT PC and plug the
> VCC board directly into my Linux box, but I can't find a way to download
> the bit file.  What I need is either a utility that will download a bit
> file from Linux (I don't need anything like the hardware debugger), or
> alternatively a way to make the Sun version of the alliance tools talk
> to a serial port that's not on the local machine.  Xilinx support tell
> me that neither is possible.


What would probably work is to implement a fake serial port on the Sun
box that behaves as a "'fake-serial-interface'->tcp/ip" proxy. Then on
the Linuxbox you just convert back to a serial port. 

I would go looking on <url://freshmeat.net/> and maybe ask in a Unix/
Linux group. On freshmeat I at least found this:

   Serproxy is a multi-threaded proxy program for redirecting network
   socket connections to/from serial ports, in cases where the remote
   end of the serial link doesn't have a TCP/IP stack (eg an embedded
   or microcontroller system). The proxy allows other hosts on the
   network to communicate with the system on the remote end of the
   serial link.

and:

   Sredird is a serial port redirector that is compliant with the RFC
   2217 "Telnet Com Port Control Option" protocol. This protocol lets
   you share a serial port through the network.

These might be suitable with som changes - and they're with free
source code so that shouldn't be impossible:)

Good luck

-sig
-- 
sigurd urdahl
Article: 20024
Subject: Re: How to access standard sdram ?
From: Mike Treseler <tres@tc.fluke.com>
Date: Mon, 24 Jan 2000 09:41:35 -0800
Links: << >>  << T >>  << A >>
Thomas Sitt wrote:
> 
> Hello,
> I want to use standard sdram ( 64 MByte ) with FPGA.
> Is it possible 

Yes. You need to make a state machine to control splitting
and sequencing the address bus into row and column and
applying "strobes" at the proper times.

Synchronous DRAM adds requirements for setting a mode
register and synchronizing the IO.

Skip the fancy modes until you get a single beat
read/write working.

> and where are examples to find ?

http://209.67.241.58/reg/1997/060597/12df_04.htm

     -Mike Treseler


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