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 126650

Article: 126650
Subject: Cascaded DCMs with variable phase shift (Xilinx)
From: chesi <cesteban75@gmail.com>
Date: Thu, 29 Nov 2007 00:10:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all,

I'm using a Spartan-3 XC3S400 with cascaded DCMs.
1st DCM is configured as variable phase shift with 27MHz clock from an
external VCXO in CLKIN. It is fedback (1X) from CLK0 through an IOB
(run out of BUFG). This IOB's output feeds second DCM's CLKIN. First
DCM's CLKFX output is also used for other tasks (multiplied by 4).
2nd DCM  simply uses CLK0 and CLKFX (multiplied by 10) outputs with
BUFG for both of them and the proper feedback 1X from CLK0.
Attributes for both DCMs:
      FACTORY_JF            =3D> X"8080"
      STARTUP_WAIT       =3D> FALSE

This structure above is instantiated twice, so I use the 4 DCM of my
FPGA. Both instantiations are identical.

The result of this is that one instantiation works perfectly, but the
other one not. This one successes to set most phase-shift values, but
fails just to set negative phase-shifts (PSINCDEC=3D0) in the range
between 20 and 28 (nr. of pulses of PSCLK while PSEN is high). The
rest of the phase-shifts are achieved OK. When it fails the DCM's lock
and status bits do not indicate any error situation but ALL the clocks
generated within the FPGA from the VCXO start to move their edges of
the clock pulses pretty much (even clocks not generated by DCM).

I reset DCMs as Xilinx advises (waiting the lock of the 1st DCM to
reset the second one). Has any of you experienced some similar
behaviour?

Regards,
C=E9sar

Article: 126651
Subject: Re: area group constraint problem (more detailed)
From: "L. Schreiber" <l.s.rockfan@web.de>
Date: Thu, 29 Nov 2007 09:31:43 +0100
Links: << >>  << T >>  << A >>
> But now I'm getting an error (while implementation stage - don't know 
> exactly at the moment).

Ok, the error occured while translation in implementation phase.

> I can't post the exact error message at the moment, but it will be given 
> later if it's necessary.

Here is the exact error message from the translation report:

Reading NGO file "/home/schrl/ise/virtex2p/reconf_rs232/top.ngc" ...

Applying constraints in "top.ucf" to the design...
ERROR:NgdBuild:753 - "top.ucf" Line 27: Could not find instance(s) 
stat_r' in the design.  To suppress this error specify the correct 
instance name or remove the constraint.


I'm trying these first suggestions from M. Hicks and MH.

thx

Article: 126652
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 29 Nov 2007 00:33:13 -0800 (PST)
Links: << >>  << T >>  << A >>
Nial

I would expect from our experience that the DDR could be routed in 3
layers assuming you are attaching to a FPGA and a sensible pinout is
chosen. Our product Tarfessock1 achieves the connection of a DDR2 chip
in principally 2 layers with a couple of straggler signals on a 3rd
layer. If this product was a less compoonent dense product we
certainly would do it all in the 2 layers.

Taking that as a starting point you could use one of your tracking
layers as a localised ground layer using a polygon fill and you can
have a fairly good electrical setup for high speed signals. We use
some of the recomendations in Xilinx XAPP693 for layer structure and
never had an issue.We don't use all the recomendations of this
applications note as they are impractical to achieve on a cost
sensitive board.

Signal integrity tools are a nice toy but they are only as good as the
information fed into them. There are generally also expensive although
you can argue that against the cost of a failed board. Even if you
know your pcb manufacturer at this point, and the materials they use
specifically, then at best things like the dielectric constants and
layer spacing vary a lot over product batches unless you pay a lot to
get boards made to an exact specification and get them tested with
resultant yield drop and cost implications. I doubt that any PC
motherboard manufactures ever do that and they make an awful lot of
boards. Those boards also tend to be 4 layers or sometimes 6 layers.

John Adair
Enterpoint Ltd. - Home of Darnaw1. The PGA FPGA solution.

On 28 Nov, 10:06, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> Hopefully some of you guys who have gone through this can
> comment...
>
> We're doing our first board with a couple of DDRs and have a
> query with ground plane coupling when routing the signals out
> of the FPGA.
>
> We're hoping to get away with a 6 layer board so the stack is..
>
> sig1
> GND
> sig2
> sig3
> PWR
> sig4
>
> Any signals that're routed from the FPBA ball to sig4 won't have
> the same good GND return paths to the FPGA that those coming out
> on sig1/sig2 will have.
>
> We're aiming to run the interface at ~2* 120MHz.
>
> We don't have any simulation tools so are having to design using best
> practice.
>
> We can place a GND island in on the PWR layer under the FPGA/DDR
> with plenty of vias stitching it up to the 'real' GND plane, but
> this will make the PWR routing more difficult.
>
> Does this matter, will the difference in GND coupling be a problem?
>
> Some of the app notes we've read suggest that the track impedance
> isn't too much of a problem.
>
> Thanks for any pointers,
>
> Nial


Article: 126653
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 08:51:51 -0000
Links: << >>  << T >>  << A >>
> Nial,
> Get a Signal Integrity Tool.
> The money you spend on that is recovered by NOT having to respin your
> pcb and first assembly run ONE TIME.
> For something that has guaranteed payback, for the cost of a respin in
> materials alone (does not even include your time, the pcb designer's
> time, your cost of lost opportunity being late to market...) why do
> people choose to suffer?


Thanks for the constructive suggestions Austin, in reply to...

> Are you a masochist?  Do you enjoy pain?  Or are you a sadist?  Do you
> enjoy causing pain to others?

..I'm tempted to say "Yes, I have used Xilinx devices in the past".

But that's just me being cheeky.


> I suppose if I wanted revenge on a horrible boss, I would just follow
> their directions, but what is the fun in that?  Go work for someone who
> has a brain.

I am the boss.

It's easy enough to spout off when you've all the resources of Xilinx
behind you, the situation in a small (2 man) company is a bit different.

In the UK we generally pay the same price in GBP that you guys pay
in dollars for tools. That makes them twice the price, not so cheap.

We'd then be starting the (presmably long if they're any good) learning
curve to produce useful results for something that we're possibly
only going to be doing once in a blue moon. I doubt we'd be getting
any results defore Christmas.

As others have said this is an almost run of the mill routing/termination
problem, I'm confident we'll get it right with a bit of thought.


Nial.




Article: 126654
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 08:57:26 -0000
Links: << >>  << T >>  << A >>
> I disagree, as does most of the research done into the subject. The use of buried capacitance, 
> typically by having adjacent power and ground planes separated by as small a distance as possible 
> (2 thou is normal), has been shown to be very favorable when compared to discrete decoupling caps 
> because although the capacitance is much lower the inductance is very much lower so the overall 
> impedence is significantly lower. There is an article about it here: 
> http://www.ddmconsulting.com/Design_Guides/bcguide.pdf

David,

I too am skeptical about the amount of decoupling that close GND/PWR plane
coupling can provice.

In that atricle above they quote 560pF/sq inch. Most BGAs are smaller
than that.

The article suggests that this sort of capacitance is useful for 'random'
logic where there's little synchronisation between gates drawing power.

We're using FPGAs that tend to be largely synchronous.


Page 24 says...

> Memory ICís: Memory ICís generally are assembled in synchronous arrays.
> When these arrays are clocked, a large amount of switching current is required to
> drive the output interfaces and charge the internal memory arrayís. These
> devices require a large amount of high speed current which is larger than BC
> layers can provide. Additional discrete decoupling capacitors will be required.


?

I think I'll rely on my decouplers, the X2Y devices Symon pointed out (again)
seem useful.


Nial. 



Article: 126655
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:07:57 -0000
Links: << >>  << T >>  << A >>
Hi Symon,

I was hoping you'd stick your oar in!

> Also, 16-20 layer boards? I guess it'll work, but I'm glad I'm not paying for it.

Indeed, this is self funded so I'd like ot keep costs down where possible
(with the proviso things should work).

> Good answers you got are, 'use two more layers'

8 Layers is the brute force answer to the problem. It should definitely
work, but it would be good to find a more elegant solution to the problem.

> , 'simulate', 'SI-LIST', and 'use as few vias as possible'. Oh, and don't cross gaps in planes, 
> but we all know that, right?

To use a Belfast expression

"Do you think I came up the Lagan in a bubble?".

No (adjacent) plane splits will be crossed.

> I'd do something like this:-
>
> sig
> gnd
> sig
> sig
> gnd
> sig
>
> I'd route the powers on one or two of the internal layers. I'd use copper pours and/or little 
> puddles of cu for each supply.

I think you've said before that you've got away with routing power in like
this with no problems.

> I'd use X2Y caps backside of the FPGA for bypassing. (Google X2Y FPGA)

They look good, and as they're available from Digikey they might be a goer.

The downside is that we're currently using 0402's with round pads on the back
of the board so they fit neatly just at the PWR/GND pins.

The X2Ys would have to be round the edges, but it could be worth adding a
few in.

> If a fast signal changes its ground reference from one ground plane to another, I'd put a GND via 
> nearby. Several fast signals can share a single ground via.

The idea was to create a localised GND plane on the PWR layer with vias to
the 'real' GND layer and a matching linking via beside any point at which
a trace goes from the bottom layer to top layer.

> Austin's right, if you're a beginner you should certainly use a simulator. Maybe you can borrow 
> one from somewhere? Any universities nearby? However, the 'two ground planes' design makes it 
> considerably harder to get it wrong, especially at 120MHz.

But as others have said, 120MHz is almost DC these days!

> p.s. You did search back through CAF for previous threads, right? ;-)

Oh aye, there wasn't too much about routing to DDRs specifically but as
usual all advice was conflicting as here!

:-)

Thansk,

Nial.





Article: 126656
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:25:30 -0000
Links: << >>  << T >>  << A >>
> I would never split a plane except as a last resort (unless you can sandwich it between two solid 
> planes - I often use a four layer GND, split power, split power, GND sandwich in the middle of 
> 16-20 layer boards), because of the issues with traces crossing the split.

As you say below signals can use the PWR plane as a 'pseudo gnd'.

By using this stack are you not loosing the ability to route two internal
signal layers adjacent to the GND planes, and the additional use of the
PWR planes as pseudo grounds?


> If you must stick to six layers then you need to make the power plane look like a ground plane by 
> ensuring that there are adequate decoupling capacitors spread uniformly across the board, such 
> that no point on the board is more than some short distance from a capacitor. The AC return 
> current can flow along the power plane and through the capacitor to ground. Of course, you want to 
> reduce the inductance so use 0402 or 0603 parts with vias very close to the pads.

That's a thought. The bank of the FPGA driving the DDR and the device itself
are on the same unbroken power plane. There's also plenty of decoupling
round both devices so we might be OK.


Nial. 



Article: 126657
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:29:39 -0000
Links: << >>  << T >>  << A >>
> I've had good results with :
> sig1
> sig2
> GND
> PWR
> sig3
> sig4

Are you not missing out on one layer closely coupling to the GND
and using the PWR as a pseudo GND like this?


> If you really need to, you can make the traces on sig1 and sig4 a little wider to keep the 
> impedance near the right value.  Keeping GND and PWR planes close together helps.  If sig1 and 
> sig2 are orthogonal, and same
> for sig3 and sig4, there should be minimal crosstalk.  I have not done a
> DDR memory, but signal integrity is signal integrity.

Indeed.


Nial. 



Article: 126658
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:37:15 -0000
Links: << >>  << T >>  << A >>
> I did 6 layers as well, but my stackup is:
>
> signal
> GND
> PWR
> PWR
> GND
> signal

>:-0

That's not very routing efficient.

> Worked the first time, actually see the prototype
> (very first one assembled, design for an external customer)
> board here:
> http://tgi-sci.com/y2demo/PICT3007sc.JPG .
> The two DDRAMs (x16 each) are close to the board centre, easy
> to spot.
> Here is the bare board in some better detail:
> http://tgi-sci.com/misc/PICT0605.JPG .
> The board is routed at 6 mil most of the time which goes
> down to somewhat over 4 mil for the worst case angular
> ring and for traces between BGA pads (3 traces between a
> pair of 1.27mm spaced pads/vias.
> Have used these rules on other boards as well, have never
> failed me. Routing takes somewhat more head scratching (or is
> it hear teraing... :-) ), but has always been doable.
> Now what do I do with a 0.8mm BGA (soon to be routed here,
> never done so far) is yet to be seen... :-)

Thanks for this info.

We've been working from a Micron app note which suggests 8 mil
min clearances between data lines.

On the other hand this is a short point to point connection so
we can probably get away with a lot more than others with more
onerous topologies.

> At these low speeds, buying signal integrity tools/consultants
> will be a sheer waste. You need neither (although ask that on
> the SI list and you will be overwhelmed by suggestions to
> buy all things imaginable... make sure to ignore such advice,
> the SI tool writers and SI consultants are pretty active on that
> list).

Thanks for an alternative viewpoint.

> Again, 120 MHz is nearly DC nowadays. You don't need any
> fancy SI tools to do it.

Hopefully.



Nial. 



Article: 126659
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:42:37 -0000
Links: << >>  << T >>  << A >>
> Power and ground are not going to be forming a very good capacitor to
> supply power so you're making a big compromise right there, it won't
> be a really low inductance pathway to deliver power to the parts on
> the board.

As below, I'm not convinced this is a problem.

Good _enough_ supply paths with sufficient local decoupling should do?

> Ideally you'd like to have two more layers, move PWR up to
> be underneath GND and then mirror that on the bottom side (i.e. sig1,
> GND, PWR, sig2, sig3, PWR, GND, sig4).  Whether your 6 layer bites you
> or not will depend entirely on how much switching is going on and how
> demanding the parts are.  I recently consulted on a design that had
> the above type of stackup and the PCB was unable to deliver enough
> 3.3V to the FPGA and would cause it to functionally upset, the board
> failed.

Might it not have been due to bad signal return path integrity or
insufficient grounding?

(I'm not arguing here, just posing the question).


> If you can't spring for si tools, then I'd suggest the following
> resources that you should peruse in besides just this particular
> newsgroup
> 1. "Right the First Time: A Practical Handbook on High Speed PCB
> Design and System Design".  Volumes 1 and 2, by Lee W. Ritchey.  Each
> will set you back about $90USD I think but they are both well worth
> it.  Can be purchased from speedingedge.com (I have no financial or
> other interest in the book or the Speeding Edge company, this is just
> a recommendation for what I've found to be an excellent resource).


Alan (if you're reading this), guess what you're getting for Christmas!


Thanks for the pointers Kevin,


Nial. 



Article: 126660
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:44:37 -0000
Links: << >>  << T >>  << A >>
> The thing to watch out for is signal-signal crosstalk, especially on
> clock lines. Clocks need especially serious signal integrity treatment
> these days. And "clocks" includes CCLK!


We've been following one of the Micron app notes here, especially wrt
the clocks. It's a fairly short pt to pt connection so hopefully we
should be OK.

Thanks,

Nial. 



Article: 126661
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 29 Nov 2007 09:50:45 -0000
Links: << >>  << T >>  << A >>
> I would expect from our experience that the DDR could be routed in 3
> layers assuming you are attaching to a FPGA and a sensible pinout is
> chosen. Our product Tarfessock1 achieves the connection of a DDR2 chip
> in principally 2 layers with a couple of straggler signals on a 3rd
> layer. If this product was a less compoonent dense product we
> certainly would do it all in the 2 layers.

I'm not doing the routing but I think it'll all come out on 3 layers.
We have a few spare pins in the banks we're using so should be able to
shuffle things about.

> Taking that as a starting point you could use one of your tracking
> layers as a localised ground layer using a polygon fill and you can
> have a fairly good electrical setup for high speed signals. We use
> some of the recomendations in Xilinx XAPP693 for layer structure and
> never had an issue.We don't use all the recomendations of this
> applications note as they are impractical to achieve on a cost
> sensitive board.

We'll have a look at that, although I think we've been overly paranoid.
Top and layer 3 are tightly coupled to the GND plane, the bottom layer
should be coupled to the PWR plane if we make sure it's sufficiently
decoupled (as elsewhere in the thread).

> I doubt that any PC
> motherboard manufactures ever do that and they make an awful lot of
> boards. Those boards also tend to be 4 layers or sometimes 6 layers.

Aye, but they are purveyors of magic!

Looking at the complexity/density/performance of a typical PC motherboard
I'm still impressed at the price they knock them out for.

Thanks John.


Nial. 



Article: 126662
Subject: Re: FPGA not in boundary scan
From: Mike <Mike@yahoo.co.uk>
Date: Thu, 29 Nov 2007 09:57:39 +0000
Links: << >>  << T >>  << A >>
   If
> you are connected to the correct chain and you don't see the device, 
> there's something wrong on the application side (not configuring things 
> properly?) rather than the hardware side.
> 
> - John_H

Thanks John, yes the hardware side should be fine, I have correctly 
connected all the pins and as I mentioned I can see one device but
the FPGA is missing. I am using ISE 7.1, probably there are issues with
using the Multilinx cable? Can anyone from the Xilinx guys give an 
answer to that if the Multilinx cable works alright with the 7.1 version?

Article: 126663
Subject: Re: ISE WARNING Xst:647
From: Tricky <Trickyhead@gmail.com>
Date: Thu, 29 Nov 2007 02:50:07 -0800 (PST)
Links: << >>  << T >>  << A >>
Have you checked to see if ISE hasnt optimised the logic connected to
those signals away (like you said, often caused by an unconnected
clock)? Use a post synthesis RTL and Technology veiw to have a look.
Quartus has them, Im sure ISE must have them too.

Article: 126664
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: Didi <diditgi@gmail.com>
Date: Thu, 29 Nov 2007 03:02:30 -0800 (PST)
Links: << >>  << T >>  << A >>
> > I did 6 layers as well, but my stackup is:
>
> > signal
> > GND
> > PWR
> > PWR
> > GND
> > signal
> >:-0
>
> That's not very routing efficient.
>

Well at first sight it is not indeed. But take into account
the fact, that you have no hidden signal layers and related
nightmares for errors to fix on the prototype board there
(which does not save you the nightmares of misconnected
power planes... so far I have had the only the latter,
thankfully never to come true :-) ), then think that at the
6/4 mil rules you can do a lot of things (I forgot to mention
it, I do 0.3 or 0.2mm drilling for vias/BGA pads), and
it becomes a lot more attractive.
Especially if you cannot afford a respin of the prototype
(usually the case with me, and thanfully never needed
one - although typically my second or third revision is 100%
error free).

Actually here is one prototype (recent shot of a 5-6 years
old prototype, the CPU cooler got unstuck and I took the
opportunity):

http://tgi-sci.com/misc/PICT3084.JPG

Routed using the same technique, not much free area left
(especially if you count the 5 SDRAM chips on the bottom,
1 of which - the ECC - is routed but left empty).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/


On Nov 29, 11:37 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I did 6 layers as well, but my stackup is:
>
> > signal
> > GND
> > PWR
> > PWR
> > GND
> > signal
> >:-0
>
> That's not very routing efficient.
>
>
>
> > Worked the first time, actually see the prototype
> > (very first one assembled, design for an external customer)
> > board here:
> >http://tgi-sci.com/y2demo/PICT3007sc.JPG.
> > The two DDRAMs (x16 each) are close to the board centre, easy
> > to spot.
> > Here is the bare board in some better detail:
> >http://tgi-sci.com/misc/PICT0605.JPG.
> > The board is routed at 6 mil most of the time which goes
> > down to somewhat over 4 mil for the worst case angular
> > ring and for traces between BGA pads (3 traces between a
> > pair of 1.27mm spaced pads/vias.
> > Have used these rules on other boards as well, have never
> > failed me. Routing takes somewhat more head scratching (or is
> > it hear teraing... :-) ), but has always been doable.
> > Now what do I do with a 0.8mm BGA (soon to be routed here,
> > never done so far) is yet to be seen... :-)
>
> Thanks for this info.
>
> We've been working from a Micron app note which suggests 8 mil
> min clearances between data lines.
>
> On the other hand this is a short point to point connection so
> we can probably get away with a lot more than others with more
> onerous topologies.
>
> > At these low speeds, buying signal integrity tools/consultants
> > will be a sheer waste. You need neither (although ask that on
> > the SI list and you will be overwhelmed by suggestions to
> > buy all things imaginable... make sure to ignore such advice,
> > the SI tool writers and SI consultants are pretty active on that
> > list).
>
> Thanks for an alternative viewpoint.
>
> > Again, 120 MHz is nearly DC nowadays. You don't need any
> > fancy SI tools to do it.
>
> Hopefully.
>
> Nial.


Article: 126665
Subject: Asynchronous FIFO and almost empty - bug?
From: "heinerlitz@googlemail.com" <heinerlitz@googlemail.com>
Date: Thu, 29 Nov 2007 03:46:35 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

we are using an asynchronous FIFO to bridge two clock domains. Both
domains have "the same" clock speed but different clock oscillators.

We shift data phits in the FIFO which always form a data packet. In
between a packet data is shifted in continously without a break.
Breaks (no shift in) are only allowed in between packets.
On the output side of the FIFO we need a steady data stream during a
data packet. The packet may not be interrupted. As the input side may
be slower we start shift-out data if at least two data phits are in
the FIFO. As the 2 clocks have almost the same frequency this
guarantees that we never have a buffer underflow.

The problem we found is that the almost empty flag is only asserted if
the FIFO is beeing emptied and not if it is beeing filled. So if the
FIFO was empty and we get a shift in the almost empty is not asserted
although we set the treshold to one. Is this a bug?

We tried to solve that problem by generating a delay-empty signal at
the output which guarantees that if the FIFO was emtpy and than
receives a shift in we still wait another cycle so we get another
shift in to avoid underflow.

This solution however does not solve the problem if the FIFO exactly
had one entry when starting to shift out a packet. In this case
neither delayed-empty nor almost empty is asserted, hence we get an
underflow.

Why isn't the almost empty signal asserted every time there is a
single packet in the FIFO? Ideas?

Article: 126666
Subject: Re: Global Reset using Global Buffer
From: Rgamer <rgamer1981@gmail.com>
Date: Thu, 29 Nov 2007 04:11:26 -0800 (PST)
Links: << >>  << T >>  << A >>
About Andrew comment "global routing networks are expensive, clearly
they are justified for clocks, but reset?"

Yes, reset! Lets say I have a computational block, that must be
cleared after computaion and I must save older values. I won=B4t
reprogram the FPGA every time.
Or let me say that one can use partial reconfiguration. The other
parts of the system are always allowed to keep an unkown state?
But some will say: "use a sync reset". And I tell: same problem. I
wish it global!

And how about a global enable signal? Or somekind of global control?

I still find that the lack of global lines for logic is even a serious
flaw, worst then the reset one.

Regarding to Erics comments, as follow:

> I don't think anyone was proposing adding additional global nets.  The
> question is how expensive would it be to add either:

Agreed. And even if its expensive, global generic nets would be
useful. Be for reset or not. Like I said, I'd like to use a global
enable too.

> 1)  Additional routing resources within the CLB to allow an existing
>     global clock net to drive the FF reset
>
> 2)  Additional routing resources within the CLB to allow an existing
>     global clock net to drive local lines, which could then be used
>     for logic and/or to drive the FF reset
>
> Apparently the Virtex 4 and 5 have done one of these, so the answer
> is that the cost isn't too high to preclude doing it in high-end FPGAs.
> Maybe the cost is too much for Spartan series FPGAs, or maybe it will
> appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts=

> said we'd get in 2007.  Time's running out, guys!  :-)
>    http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkprodu..=
.

But I=B4m still looking for a FPGA that has global generic nets.


Article: 126667
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 29 Nov 2007 07:59:49 -0500
Links: << >>  << T >>  << A >>

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:5r7fsuF13c7e4U1@mid.individual.net...
>> Power and ground are not going to be forming a very good capacitor to
>> supply power so you're making a big compromise right there, it won't
>> be a really low inductance pathway to deliver power to the parts on
>> the board.
>
> As below, I'm not convinced this is a problem.
>
> Good _enough_ supply paths with sufficient local decoupling should do?
The problem is determining what is 'good enough'.  Putting planes (or even 
the voltage supply puddles and ground plane as Symon suggests) close 
together gets you a very low inductance pathway for delivering the power to 
the part.  What your stackup had is widely separated power and ground which 
is not 'good', but depending on your needs might be 'good enough'.  The 
other suggestion that someone posted to put the power/ground together in the 
middle accomplishes the same thing and saves you two layers at the cost of 
having fewer routing layers directly adjacent to the return plane.  Whether 
that is enough or not depends very much on your particular design.

>
>> Ideally you'd like to have two more layers, move PWR up to
>> be underneath GND and then mirror that on the bottom side (i.e. sig1,
>> GND, PWR, sig2, sig3, PWR, GND, sig4).  Whether your 6 layer bites you
>> or not will depend entirely on how much switching is going on and how
>> demanding the parts are.  I recently consulted on a design that had
>> the above type of stackup and the PCB was unable to deliver enough
>> 3.3V to the FPGA and would cause it to functionally upset, the board
>> failed.
>
> Might it not have been due to bad signal return path integrity or
> insufficient grounding?
>
> (I'm not arguing here, just posing the question).
>
No.  In fact to try to prove to the designer that it had to do with anything 
other than power (there was natural skepticism), I programmed the FPGA to 
simply toggle outputs every clock cycle and the failure condition would be 
when the internal phase locked loop lost lock so the only thing the PCB had 
to deliver was core voltage, I/O voltage and a single input clock that went 
into a PLL in the FPGA.  He tried different 'filtering' on the PLL supply 
voltage, we played with I/O drive strengths and limiting certain pins to 
toggling at lower clock rates and it would always fail.  The board only 
functioned somewhat when toggling all but a handful of I/O at a lower clock 
rate (1/4 of the higher speed ones).  When the new board arrived, poof! 
suddenly all I/O could toggle at the full clock rate, could be driven at the 
full I/O current drive strength and not lose lock.  The lowered inductance 
(impedance) in the power delivery network that comes with the better stackup 
was left as the only viable hypothesis for the failure.  If you read 
Ritchey's book, you'll gain a better appreciation for the PCB's role in 
power delivery.  The fundamental flaw that the designer I was working with 
had was treating the stackup as something only to connect all the points 
together and trying to minimize layers for cost reasons and being completely 
lost on what you need for good power delivery.  The inductance/impedance in 
the path from the regulator to each load over the entire frequency range of 
interest is critical.

>
> Thanks for the pointers Kevin,
>
>
You're welcome.  Good luck on your design.  With a bit of thought and 
understanding about what is going on for delivering power and signal 
terminations and image return planes (which you seem to have a basic grasp 
on already) it should all work out just fine.

Kevin Jennings 



Article: 126668
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 29 Nov 2007 08:08:29 -0500
Links: << >>  << T >>  << A >>

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:5r7d87F1326q5U1@mid.individual.net...
>> I disagree, as does most of the research done into the subject. The use 
>> of buried capacitance, typically by having adjacent power and ground 
>> planes separated by as small a distance as possible (2 thou is normal), 
>> has been shown to be very favorable when compared to discrete decoupling 
>> caps because although the capacitance is much lower the inductance is 
>> very much lower so the overall impedence is significantly lower. There is 
>> an article about it here: 
>> http://www.ddmconsulting.com/Design_Guides/bcguide.pdf
>
> David,
>
> I too am skeptical about the amount of decoupling that close GND/PWR plane
> coupling can provice.
>
> In that atricle above they quote 560pF/sq inch. Most BGAs are smaller
> than that.
>

It's not so much the capacitance as it is the lowered inductance that the 
closely spaced planes brings you.  Having a fire hydrant near a burning 
house doesn't help much if you only have a garden hose to deliver the water. 
The inductance of the power delivery network is the thing that delivers the 
power from the source to the load.

KJ 



Article: 126669
Subject: Re: What tools do you use ? Why ?
From: Andy <jonesandy@comcast.net>
Date: Thu, 29 Nov 2007 06:05:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 6:26 pm, "psihode...@googlemail.com"
<psihode...@googlemail.com> wrote:
> Hello all,
> can you please tell us what tools you prefer? Please give some
> arguments, why you like them.
>
> I currently use very intensively Linux shell and GHDL compiler for
> simulations and XST for synthesis.
>
> GHDL is very fast and powerful. You can for example colorize your
> files directly into HTML, call foreign functions (e.g. from C
> library), and many more.
>
> My VHDL projects have typical Linux-way directory tree structure:
> ./bin/ for binaries
> ./include/ for includes
> ./work/ for generated modules
> ./src/ for sources
>
> inside src directory is a Makefile, which is automatically generated
> by GHDL. In order to build a binary, I use "make sim" command. If I
> need to create some additional component in other language (C or
> Python), I use "foreign" declarations in VHDL code and link them using
> GHDL, just like with well-known GCC. For example if you need to verify
> your VGA-Controller Design, you can create a special C-function which
> will create JPG file with the current frame.
>
> For synthesis I use XST from Xilinx ISE. It is very simple to type:
> "make syn; make load" and bitfile will be uploaded into an FPGA. For
> communication with FPGA board, real-time visualization,  and so on,  I
> use small Python scripts.
>
> I use VIM as a text editor. It also helps me to be very productive and
> to work remotely using SSH (e.g. it's nice thing to use VIM on your
> cell phone like Nokia N200 which has Linux onboard).
>
> So, this are my tools:
> GHDL, XST, GNU Tools(make, bintools, bash, libc, etc.), VIM, Python,
> GCC
> and of course Linux itself.
>
> Frankly, only XST is not under Open Source license and it mostly slow-
> downs hole development flow because of XST's bugs and its poor
> performance. All other programs I use are previously compiled using
> optimization flags targeted my server's hardware.
>
> What tools do you prefer? Why ?

NC-VHDL or modelsim, both have top-notch performance, and have
excellent source level debuggers, object "watchers", etc. (which I
tend to use more than waveforms for debugging).

For synthesis, I have been disappointed with XST compared to Symplify-
pro. Synplify covers the language better, and generally gives better
results. It's schematic generation and viewing/filtering are top-
notch, and works at both the "RTL" level (showing  you higher level
objects than primitives) and the technology level, which shows the
luts, flops, etc. at the lowest level. It is also vendor independent,
so you can evaluate other targets very easily.

I've used jGrasp, Ultra-edit, and xemacs with vhdl-mode. I had to
upgrade the UE vhdl syntax description to get it to do a better job on
formatting. JGrasp has excellent formatting, etc. and displays
graphical structural cues in the LH whitespace. However, nothing
compares to the shortcuts, or formatting and beautification
capabilities, of vhdl-mode for xemacs. Getting past some of the
keyboard acrobatics is a pain though. I mostly use xemacs now. Somehow
I can't see being productive writing/editing vhdl on a cell phone...

Andy

Article: 126670
Subject: Drawing timing-diagrams for documentation
From: Sean Durkin <news_nov07@durkin.de>
Date: Thu, 29 Nov 2007 15:18:56 +0100
Links: << >>  << T >>  << A >>
Hi *,

just stumbled across this opensource-thingy and thought it might be
useful to others as well:

http://drawtiming.sourceforge.net/

I've been looking for something just like this...

cu,
Sean

-- 
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Article: 126671
Subject: Re: FPGA not in boundary scan
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 29 Nov 2007 14:23:41 GMT
Links: << >>  << T >>  << A >>
Mike wrote:
>   If
>> you are connected to the correct chain and you don't see the device, 
>> there's something wrong on the application side (not configuring 
>> things properly?) rather than the hardware side.
>>
>> - John_H
> 
> Thanks John, yes the hardware side should be fine, I have correctly 
> connected all the pins and as I mentioned I can see one device but
> the FPGA is missing. I am using ISE 7.1, probably there are issues with
> using the Multilinx cable? Can anyone from the Xilinx guys give an 
> answer to that if the Multilinx cable works alright with the 7.1 version?

To see only the CPLD, the FPGA must be IDENTIFIED and put into bypass.

The problem you've identified screams that something is very wrong, not 
simply a matter of the cable.

Are you using Impact?  Chipscope?  Synplicity's Identify?  If you have 
anything else that does JTAG, get a second opinion.

Help us help you - please specify what board and what software.

Article: 126672
Subject: Re: Global Reset using Global Buffer
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 29 Nov 2007 14:41:43 +0000
Links: << >>  << T >>  << A >>
On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1981@gmail.com>
wrote:

>I understood. And thanks for all for the replies.
>
>So, I can't use a global line for reset and like all Xilinx guys say,
>I shouldn't use it.
>IMHO the lack of reset circuitry is a serious flaw.
>I have a global enable too, that must get everypart of the design.
>Again, no way to use it as global. This is even a more serious flaw,
>since enable is the best design pratice regarding FPGAs.
>
>I think I'll have to prey that PAR meet my timing constraints, as they
>are somewhat tight... Does anyone have a better idea than using low
>skew lines?

If you control your design from some central state machine, add several
states between the "reset" state and the central despatcher state (e.g.
"idle" where you wait for inputs to react to and depatch to states that
do the work).

That guarantees that nothing else in your design will be active for
those several cycles; therefore reset to anything OUTSIDE these states
can be constrained as a multicycle path.

- Brian

Article: 126673
Subject: lossless compression in hardware: what to do in case of uncompressibility?
From: "Denkedran Joe" <denkedranjoe@googlemail.com>
Date: Thu, 29 Nov 2007 15:42:45 +0100
Links: << >>  << T >>  << A >>
Hi all,

I'm working on a hardware implementation (FPGA) of a lossless compression 
algorithm for a real-time application. The data will be fed in to the 
system, will then be compressed on-the-fly and then transmitted further.

The average compression ratio is 3:1, so I'm gonna use some FIFOs of a 
certain size and start reading data out of the FIFO after a fixed 
startup-time. The readout rate will be 1/3 of the input data rate The size 
of the FIFOs is determined by the experimental variance of the mean 
compression ratio. Nonetheless there are possible circumstances in which no 
compression can be achieved. Since the overall system does not support 
variable bitrates a faster transmission is no solution here.

So my idea was to put the question to all of you what to do in case of 
uncompressibility? Any ideas?

Denkedran Joe 



Article: 126674
Subject: Hand solder that FPGA on your prototype
From: "Tony Burch" <tony@burched.com.au>
Date: Fri, 30 Nov 2007 01:43:35 +1100
Links: << >>  << T >>  << A >>
Hi all,

I've just finished constructing a new site that has web videos of soldering 
techniques, including how to hand solder quad flat packs. Very handy for 
prototyping.

You can go and get a free membership there, which lets you see 5 videos on 
how to hand solder quad flat packs. Watch me hand solder a Spartan 2E in a 
PQ208 package onto a board:) http://supersolderingsecrets.com/

The upgraded membership covers lots of other soldering techniques such as 
"toaster-oven soldering", "frying pan solder pot soldering", etc., but if 
you just wanted to know how to hand solder that FPGA on your prototype, then 
the free membership reveals all:)

Cheers,

Tony Burch
http://supersolderingsecrets.com/





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search