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 145300

Article: 145300
Subject: Re: How good are Actel tools
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 5 Feb 2010 01:53:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On 4 Feb., 12:01, whygee <y...@yg.yg> wrote:
> > Can anyone confirm or dispute it the relative quality of Actel tools?
> > Am I mistaken about them?
>
> The Actel tools take a while to get used too,
> like most big SW suites. It's its own world...
> It is not particularly terrible, I can do
> mostly what I want, inside the bounds of reality
> and the target chip's capacity.

For "normal" projects I have the same opinion.

I'm using Actel since nearly 10 years now in a lot of projects for
several technologies.

Actel provides a crippled version of Modelsim like most other tools
(Xilinx,...) I can't say anything about this, as I have access to full
Modelsim.
The synthesis tool provided for free is Synplicity. I would consider
this tool as usable in standard projects and would be surprised if xst
performs better in overall. But Synplify itself as well as in
combination with the libraries of Actel for several technologies may
cause trouble if you need to squeeze the technologie or leave the
"main stream" of hdl coding. Synplicity provides no direct support and
Actel can't provide the needed support in some cases. I remember
several problems which could not be fixed in a reasonable amount of
time by Actel.

The major used tool from Actel is desiger (the P&R+Layout tool). This
tool is quite good if you're used to it and it took me less time to
get the first design done than my experiences with xilinx.
But the manual layout itself is in each technology different (which I
would consider major drawback). I personaly dislike the manual layout
or pinassignment per GUI of ProAsic devices, while the story is
complete different for SX-S.

You may encounter problems when doing large designs on new released
technologies. The windows version is atm only usable in 32-bit OS
which will bite you when doing very large designs.

bye Thomas



Article: 145301
Subject: Re: Board layout for FPGA
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 5 Feb 2010 10:12:46 -0000
Links: << >>  << T >>  << A >>
> Now that I think of it, I suppose I could make the bus connection job
> a little simpler if I take advantage of the fact that RAM is "random
> access," so the address/data line numbers from chip to chip don't
> necessarily have to match up. Then the address/data lines could be
> connected in whatever order is easiest and cleanest, since on the FPGA
> side the data would go in and come out in the desired order either
> way.
> Would this for any reason be a bad design practice?


Cypress don't even define address and data pin numbers for their synchronous
rams (apart from A0 and A1).

Go for it.


Nial 



Article: 145302
Subject: Re: Board layout for FPGA
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 5 Feb 2010 10:15:33 -0000
Links: << >>  << T >>  << A >>
> John,
> I don't think I can get away with only the outer two rows of balls,
> I'll probably need the two inside of that as well-- I was thinking of
> breaking out the outer two on one signal layer and the inner two in
> another, as suggested in the Xilinx app note I saw. It was a tight
> squeeze but they wrote .127mm traces, and .3/.6mm on the vias, which
> is the standard offering of the board house we're using.. it's
> possible to ask for smaller, for an extra chunk of change.

With 1mm ball pitch I use 0.5mm pads, 0.5mm vias with 0.25mm drills.

This is pretty much run of the mill for fab houses and shouldn't
add much to costs.

The first four balls can then be routed out on the top and bottom
layers.

Nial 



Article: 145303
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 05 Feb 2010 11:42:13 +0000
Links: << >>  << T >>  << A >>
On 2/5/2010 5:40 AM, rickman wrote:
>>
>> To the OP, in the absence of micro-vias, I would recommend a 6 layer
>> board. Maybe like this:-
>>
>> signal
>> signal
>> ground
>> ground
>> power/signal
>> signal
>>
>
> Everyone has their own way of doing things, but I would ask, why the
> two ground planes?  I would have a ground plane and a power plane in
> the center with a minimum thickness between them.  The spacing between
> the ground/power plane and the signal plane is not so important.  What
> is important is the characteristic impedance.  The lower the
> impedance, the less it will radiate.  Of course, with thin traces you
> have to have the signal plane to power/ground plane very small to get
> a low impedance.  But if you have wide traces, you can open up the
> plane spacing.  Since the outer layers are on the outside of the
> board, they won't be very close to inside power/ground planes.  BTW,
> you are aware that the power plane is just as effective as the ground
> plane for determining the impedance.
>
> Rick

Hi Rick,

In my designs, and perhaps yours too, the power plane, such as it is, is 
useless as a reference plane for the simple reason that it's chopped up 
into many different pours for all the different voltages. I don't think 
you are suggesting a separate layer for each separate voltage? So, there 
will be slots in the plane, and every time a fast signal passes across 
this slot, you'll get the thing radiating as a good slot antenna does! 
You could add a bunch of bypass caps to bridge between the planes, but 
there's rarely space for this with a dense BGA design. For sure, if your 
planes are close together in the middle of your stack, this problem is 
small, but then you need wider surface traces to get the impedance you 
require.
So, I recommend multiple ground planes close to all your signals. A 
thick core in the centre of the board to make up the correct thickness. 
Then you can simply forget about any slot issues. Like you say, this 
lets you keep the traces thin and with a lower characteristic impedance, 
which is normally what you want when routing BGA FPGAs. The two ground 
planes should be well bonded with vias, so there isn't a problem when a 
signal goes through a via and passes from being referred to one ground 
plane to the other.

I reject the notion of placing a power plane and a ground plane close 
together in the middle of the board to get the benefit of the 
inter-plane capacitance for bypassing reasons. Don't get me wrong, it 
won't hurt, but IMO the amount of capacitance gained is tiny, and even 
though it is a very high Q capacitor, getting the power to the die is 
stymied by the inductance of the vias and BGA balls that are part of the 
PDS. If your power plane is in the middle of the board, the signal path 
of these vias are longer. You don't care about the supply stiffness on 
your plane, it's on the die that counts. If you graunch off the metal 
cover of an FPGA you'll see that the manufacturer has already had to add 
bypass caps on the BGA substrate for this very reason. Furthermore, if 
you have a PCB ground plane close to the surface and hence close to the 
FPGA, the cavity between the PCB ground plane and the ground plane in 
the FPGA is smaller, reducing the inductance of the vias and BGA balls 
and so reducing stuff like ground bounce.
So, IMO, the disadvantages of having the planes further from your 
signals and components more than outweigh the tiny gain in bypass 
capacitance you gain.

I say better is to put your bypass caps as close as possible to the 
FPGA, and maybe use puddles of copper close to the ground planes to 
maximise the via and capacitor utilization. Here's an article showing 
what I mean. Fig. 2.

http://www.x2y.com/bypass/mount/backside_cap.pdf

Whatever, YMMV, and I'm sure your designs work just fine. It's hard to 
cock it up, but I contend that the dual ground plane design I suggest 
above is nigh on impossible to go wrong with from an SI point of view, 
even if you have absolutely no clue what you're doing. That's why I use it!

Cheers, Syms.


Article: 145304
Subject: Re: Board layout for FPGA
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 05 Feb 2010 11:48:56 +0000
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> BTW, you are aware that the power plane is just as effective as the
> ground plane for determining the impedance.

Yes, but the OP needs to be aware that care can be required when
switching your signal trace from one layer to another. When you switch
to a layer which references the other supply rail, then the return
current has to also switch layers.  If the way it has to do that is
via a decoupling cap a long way away then the current loop can be
quite large.  

I got Henry Ott's new book just this morning, and he has some
discussion on p630...  If you use Amazon's "search in this book"
feature from here:

http://www.amazon.co.uk/Electromagnetic-Compatibility-Engineering-Henry-Ott/dp/0470189304/

and search for "Changing Reference Planes", you can see pp 630-631.

To the OP - ...and then buy it :)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 145305
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 05 Feb 2010 13:45:55 +0000
Links: << >>  << T >>  << A >>
On 2/5/2010 11:48 AM, Martin Thompson wrote:
> rickman<gnuarm@gmail.com>  writes:
>
>> BTW, you are aware that the power plane is just as effective as the
>> ground plane for determining the impedance.
>
> Yes, but the OP needs to be aware that care can be required when
> switching your signal trace from one layer to another. When you switch
> to a layer which references the other supply rail, then the return
> current has to also switch layers.  If the way it has to do that is
> via a decoupling cap a long way away then the current loop can be
> quite large.
>
> I got Henry Ott's new book just this morning, and he has some
> discussion on p630...  If you use Amazon's "search in this book"
> feature from here:
>
> http://www.amazon.co.uk/Electromagnetic-Compatibility-Engineering-Henry-Ott/dp/0470189304/
>
> and search for "Changing Reference Planes", you can see pp 630-631.
>
> To the OP - ...and then buy it :)
>
> Cheers,
> Martin
>
Hi Martin,

It would appear Mr. Ott agrees that multiple ground planes with a big 
centre core are a good idea, even on a four layer board. Fig. 16-15. He 
must be a smart guy!! ;-)

Also, Fig. 16-16 he specifically says that

signal
signal
ground
power
signal
signal

is _not_ recommended.


Looks like he would do

signal
ground
signal
signal
ground
signal

with a thick centre core and routed powers. This way the internal signal 
layers are shielded. I tend to agree. The ssggss stack I suggested 
because I almost always use laser drilled micro-vias on my boards, so I 
need two signal layers on the outside. Also, my enclosures do the EMC 
shielding. With standard vias, sgssgs is probably better.

Cheers, Syms.


Article: 145306
Subject: Re: How good are Actel tools
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Feb 2010 06:44:18 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 4:53=A0am, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> On 4 Feb., 12:01, whygee <y...@yg.yg> wrote:
>
> > > Can anyone confirm or dispute it the relative quality of Actel tools?
> > > Am I mistaken about them?
>
> > The Actel tools take a while to get used too,
> > like most big SW suites. It's its own world...
> > It is not particularly terrible, I can do
> > mostly what I want, inside the bounds of reality
> > and the target chip's capacity.
>
> For "normal" projects I have the same opinion.
>
> I'm using Actel since nearly 10 years now in a lot of projects for
> several technologies.
>
> Actel provides a crippled version of Modelsim like most other tools
> (Xilinx,...) I can't say anything about this, as I have access to full
> Modelsim.
> The synthesis tool provided for free is Synplicity. I would consider
> this tool as usable in standard projects and would be surprised if xst
> performs better in overall. But Synplify itself as well as in
> combination with the libraries of Actel for several technologies may
> cause trouble if you need to squeeze the technologie or leave the
> "main stream" of hdl coding. Synplicity provides no direct support and
> Actel can't provide the needed support in some cases. I remember
> several problems which could not be fixed in a reasonable amount of
> time by Actel.
>
> The major used tool from Actel is desiger (the P&R+Layout tool). This
> tool is quite good if you're used to it and it took me less time to
> get the first design done than my experiences with xilinx.
> But the manual layout itself is in each technology different (which I
> would consider major drawback). I personaly dislike the manual layout
> or pinassignment per GUI of ProAsic devices, while the story is
> complete different for SX-S.
>
> You may encounter problems when doing large designs on new released
> technologies. The windows version is atm only usable in 32-bit OS
> which will bite you when doing very large designs.
>
> bye Thomas

"atm only"?  Is that a typo?  It seems to read ok if the "atm" is left
out entirely.

Rick

Article: 145307
Subject: Re: How good are Actel tools
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 05 Feb 2010 14:54:22 +0000
Links: << >>  << T >>  << A >>
On Fri, 5 Feb 2010 06:44:18 -0800 (PST), rickman wrote:

>"atm only"?  Is that a typo?  It seems to read ok if the "atm" is left
>out entirely.

atm ~= "at the moment" ?
-- 
Jonathan Bromley

Article: 145308
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Feb 2010 06:55:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 5:15=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > John,
> > I don't think I can get away with only the outer two rows of balls,
> > I'll probably need the two inside of that as well-- I was thinking of
> > breaking out the outer two on one signal layer and the inner two in
> > another, as suggested in the Xilinx app note I saw. It was a tight
> > squeeze but they wrote .127mm traces, and .3/.6mm on the vias, which
> > is the standard offering of the board house we're using.. it's
> > possible to ask for smaller, for an extra chunk of change.
>
> With 1mm ball pitch I use 0.5mm pads, 0.5mm vias with 0.25mm drills.
>
> This is pretty much run of the mill for fab houses and shouldn't
> add much to costs.

0.25 mm drill is 10 mil.  I have had fab houses say they can't do 10
mil.  One in particular applied a "standard" rule of +- 3 mil
tolerance and used a 13 mil drill without telling me.  Of course,
without saying any names, I don't use Sunstone anymore.  ;^)  (They
also had a >20% Xout rate on that run and had to do a second run to
get me the last panel, not that I would ever bad mouth them...)

The lower limit for the lower end board houses (in terms of costs not
quality) tends to be around 15 mil.  I don't think you can do any of
these BGAs using 15 mil vias, so the truly low end houses are likely
out anyway.  It is important to choose a *good* fab house.  I have
found quality to vary a *lot*.

Rick

Article: 145309
Subject: Re: Board layout for FPGA
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 5 Feb 2010 15:58:13 -0000
Links: << >>  << T >>  << A >>
> The lower limit for the lower end board houses (in terms of costs not
> quality) tends to be around 15 mil.  I don't think you can do any of
> these BGAs using 15 mil vias, so the truly low end houses are likely
> out anyway.  It is important to choose a *good* fab house.  I have
> found quality to vary a *lot*.


Aye, I'd assumed a 'proper' board house, not a pile em high outfit like
PCB pool etc (although I've always had good results using pcb pool for lower
tech boards).


Nial. 



Article: 145310
Subject: ISPLever, devlist command
From: "jbj" <jbjacques2003@yahoo.fr>
Date: Fri, 05 Feb 2010 10:03:47 -0600
Links: << >>  << T >>  << A >>
Hello,

i use ISPLever 7.1 - 8.0, but I have a major trouble : 

When I try to launch devlist -l command in the ISPLever console, the result
is empty.

BUT this command should return the list of all the devices supported by the
tool.

Do someone know this issue?
Do somenone know how to fix it ? 

Thanks.

Best regards

JB

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145311
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Feb 2010 08:08:47 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 8:45 am, Symon <symon_bre...@hotmail.com> wrote:
> On 2/5/2010 11:48 AM, Martin Thompson wrote:
>
> > rickman<gnu...@gmail.com>  writes:
>
> >> BTW, you are aware that the power plane is just as effective as the
> >> ground plane for determining the impedance.
>
> > Yes, but the OP needs to be aware that care can be required when
> > switching your signal trace from one layer to another. When you switch
> > to a layer which references the other supply rail, then the return
> > current has to also switch layers.  If the way it has to do that is
> > via a decoupling cap a long way away then the current loop can be
> > quite large.
>
> > I got Henry Ott's new book just this morning, and he has some
> > discussion on p630...  If you use Amazon's "search in this book"
> > feature from here:
>
> >http://www.amazon.co.uk/Electromagnetic-Compatibility-Engineering-Hen...
>
> > and search for "Changing Reference Planes", you can see pp 630-631.
>
> > To the OP - ...and then buy it :)
>
> > Cheers,
> > Martin
>
> Hi Martin,
>
> It would appear Mr. Ott agrees that multiple ground planes with a big
> centre core are a good idea, even on a four layer board. Fig. 16-15. He
> must be a smart guy!! ;-)
>
> Also, Fig. 16-16 he specifically says that
>
> signal
> signal
> ground
> power
> signal
> signal
>
> is _not_ recommended.
>
> Looks like he would do
>
> signal
> ground
> signal
> signal
> ground
> signal
>
> with a thick centre core and routed powers. This way the internal signal
> layers are shielded. I tend to agree. The ssggss stack I suggested
> because I almost always use laser drilled micro-vias on my boards, so I
> need two signal layers on the outside. Also, my enclosures do the EMC
> shielding. With standard vias, sgssgs is probably better.
>
> Cheers, Syms.

In reply to both of your posts, I will say that there is a *lot* of
misinformation out there.  There is *NO* one way to stack up PCBs.  I
once took a class in "High Speed Digital Design" with Lee Ritchey.
Some "experts" in the field will explain the theory behind what they
say.  Lee Ritchey not only gives the theory, he also shows detail
simulations and even builds test boards to verify that what he is
saying is how it works in the real world.  That impressed me
greatly.

As to the return current having to "jump" between layers being a
problem, if you use the ssgpss stackup and have the power and ground
very close rather than widely spaced, the capacitive coupling allows
the signal to switch between them without issue.  In fact, when
splitting a plane for multiple power sections, the return current will
switch from one power plane, to the ground plane and back to the next
power plane as if they were all one plane.  This is because of the
capacitive coupling between layers.  Of course this only works for the
highest frequency components of the signals, but that's all we really
care about, no?

-------+  +-------> Return Current
=======|  |======== Power Planes
       |  |
       +--+
=================== Ground Plane

The ascii art may not come out too well depending on your browser or
newreader, but I hope you get the idea.

I couldn't view the pages in Ott's book so I can't respond to that.
The one point I most learned from Lee Ritchey's course is that you
should never take any expert's opinion as fact.  Many experts make
mistakes and a number of things look good on paper while the real
world works differently.  Only trust an expert opinion if it is backed
up by reliable proof.  How does Ott "prove" his analysis, or is it
just a paper analysis?

Rick

Article: 145312
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Feb 2010 09:56:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 6:42 am, Symon <symon_bre...@hotmail.com> wrote:
> On 2/5/2010 5:40 AM, rickman wrote:
>
> >> To the OP, in the absence of micro-vias, I would recommend a 6 layer
> >> board. Maybe like this:-
>
> >> signal
> >> signal
> >> ground
> >> ground
> >> power/signal
> >> signal
>
> > Everyone has their own way of doing things, but I would ask, why the
> > two ground planes?  I would have a ground plane and a power plane in
> > the center with a minimum thickness between them.  The spacing between
> > the ground/power plane and the signal plane is not so important.  What
> > is important is the characteristic impedance.  The lower the
> > impedance, the less it will radiate.  Of course, with thin traces you
> > have to have the signal plane to power/ground plane very small to get
> > a low impedance.  But if you have wide traces, you can open up the
> > plane spacing.  Since the outer layers are on the outside of the
> > board, they won't be very close to inside power/ground planes.  BTW,
> > you are aware that the power plane is just as effective as the ground
> > plane for determining the impedance.
>
> > Rick
>
> Hi Rick,
>
> In my designs, and perhaps yours too, the power plane, such as it is, is
> useless as a reference plane for the simple reason that it's chopped up
> into many different pours for all the different voltages. I don't think
> you are suggesting a separate layer for each separate voltage? So, there
> will be slots in the plane, and every time a fast signal passes across
> this slot, you'll get the thing radiating as a good slot antenna does!
> You could add a bunch of bypass caps to bridge between the planes, but
> there's rarely space for this with a dense BGA design. For sure, if your
> planes are close together in the middle of your stack, this problem is
> small, but then you need wider surface traces to get the impedance you
> require.
> So, I recommend multiple ground planes close to all your signals. A
> thick core in the centre of the board to make up the correct thickness.
> Then you can simply forget about any slot issues. Like you say, this
> lets you keep the traces thin and with a lower characteristic impedance,
> which is normally what you want when routing BGA FPGAs. The two ground
> planes should be well bonded with vias, so there isn't a problem when a
> signal goes through a via and passes from being referred to one ground
> plane to the other.

Below, you talk about the connecting of the power and ground plane by
spacing to be of little value and yet propose that vias are adequate
to couple multiple ground planes.  I find that interesting.  For a
signal passing between layers the return current would have a long
path to reach a via and back.


> I reject the notion of placing a power plane and a ground plane close
> together in the middle of the board to get the benefit of the
> inter-plane capacitance for bypassing reasons. Don't get me wrong, it
> won't hurt, but IMO the amount of capacitance gained is tiny, and even
> though it is a very high Q capacitor, getting the power to the die is
> stymied by the inductance of the vias and BGA balls that are part of the
> PDS. If your power plane is in the middle of the board, the signal path
> of these vias are longer. You don't care about the supply stiffness on
> your plane, it's on the die that counts. If you graunch off the metal
> cover of an FPGA you'll see that the manufacturer has already had to add
> bypass caps on the BGA substrate for this very reason. Furthermore, if
> you have a PCB ground plane close to the surface and hence close to the
> FPGA, the cavity between the PCB ground plane and the ground plane in
> the FPGA is smaller, reducing the inductance of the vias and BGA balls
> and so reducing stuff like ground bounce.
> So, IMO, the disadvantages of having the planes further from your
> signals and components more than outweigh the tiny gain in bypass
> capacitance you gain.

I'm a bit unclear on what you are saying.  You are suggesting that the
impedance of the vias is enough that you should put the planes as
close as possible to the component surface, but then you recommend
putting the decoupling caps on the back side much further away from
the component with longer vias.


> I say better is to put your bypass caps as close as possible to the
> FPGA, and maybe use puddles of copper close to the ground planes to
> maximise the via and capacitor utilization. Here's an article showing
> what I mean. Fig. 2.
>
> http://www.x2y.com/bypass/mount/backside_cap.pdf
>
> Whatever, YMMV, and I'm sure your designs work just fine. It's hard to
> cock it up, but I contend that the dual ground plane design I suggest
> above is nigh on impossible to go wrong with from an SI point of view,
> even if you have absolutely no clue what you're doing. That's why I use it!
>
> Cheers, Syms.


Yes, one common element is that most designs apply overkill in the
supply decoupling area.  When an engineer uses a method and it works,
it is like the elephant protection charm... you don't see any
elephants do you, so it must be working!

I would likely not use the offset coupled planes you describe mainly
because it only works well for boards with active components on only
one side.

In Lee Ritchey's class I asked about adding caps to the package to
overcome lead inductance causing ground bounce.  He showed me that the
bounce is caused by the switching currents of driving an external
signal travel in a loop and independent of any capacitance on the
package, still have to travel through the leads of the part (even if
they are only bonding leads).  In fact, there is *nothing* you can do
about the series inductance of pins in a package other than fix the
package.  That is why I seriously doubt that the small added
inductance of 30 mil of a via is significant in any but the highest
speed designs.  But as you say, YMMV.

Rick

Article: 145313
Subject: Re: How good are Actel tools
From: rickman <gnuarm@gmail.com>
Date: Fri, 5 Feb 2010 10:00:59 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 9:54=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 5 Feb 2010 06:44:18 -0800 (PST), rickman wrote:
> >"atm only"? =A0Is that a typo? =A0It seems to read ok if the "atm" is le=
ft
> >out entirely.
>
> atm ~=3D "at the moment" ?
> --
> Jonathan Bromley

PUTMNOAAA*

Rick



*People Use Too Many Non Obvious Abbreviations And Acronyms

Article: 145314
Subject: Re: Matching hadware and software CRC
From: "dlopez" <d@n_o_s_p_a_m.designgame.ca>
Date: Fri, 05 Feb 2010 12:01:27 -0600
Links: << >>  << T >>  << A >>
>I have done the ethernet CRC (CCITT CRC32) and verified that 
>it agreed with what it should do.
>
>-- glen


Thanks, I actually got it to match. 

-need to 'reverse' the individual bytes going in.
-need to 'inverse', then 'reverse' the CRC coming out. 
-do NOT play with the internal feedback work within the CRC calculator.

However, the new problem is that I cannot feed in a data message, followed
by the known good CRC, and get 0! This used to work before I added the
above logic.  

Anyone has an idea?

Diego	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145315
Subject: Re: Simulating Spartan 3A pins in ltspice
From: austin <austin@xilinx.com>
Date: Fri, 5 Feb 2010 10:13:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Pat,

We have encrypted hspice models as shown, mostly only for Virtex
family parts, for "heavy lifting" customers who require them.

Since the devices models belong to Toshiba, IBM, UMC (etc.), these
must be protected (they do not belong to us), so the hspice encrypted
models are what we support.  Period.

IBIS models exist for all families, and parts.  These are per the IBIS
standard, so any tool that works with the IBIS standard should support
these models.  If it doesn't then we need to know (file a webcase so
we can see why it didn't work).

The latest IBIS extension is for the high speed serial IO on newer
parts, also supported per the standard.

xSpice (n, p, x, etc. take your pick) are not supported.  Period.

Austin


Article: 145316
Subject: using an FPGA to emulate a vintage computer
From: Eric Chomko <pne.chomko@comcast.net>
Date: Fri, 5 Feb 2010 10:19:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Has anyone created a copy machine of an old system using an FPGA? I
was wondering if it would be possible to take an entire SWTPC 6800 and
compile the schematics and have it run on an FPGA board.? Wouldn't
even have to be the latest Xylinx product, I suspect.

Article: 145317
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Gabor <gabor@alacron.com>
Date: Fri, 5 Feb 2010 10:40:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 3:59=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote:
> austin wrote:
> > Sean,
>
> > Do you have the "wait for DCM's to lock before releasing DONE" option
> > set?
>
> Nope. In fact, I'm not even using any DCMs in my test-design. For first
> tests in the lab, I'm just driving some LEDs statically. No clock, no res=
et.
>
> The problem is that in fact "done" IS released, but GTS and GSR aren't
> disabled. It looks like configuration stops in the middle of the startup
> cycle, i.e. after "DONE", but before GTS and GSR are disabled.
>
> But iMPACT claims everything's fine, and configuration was successful.
>
> > Sometimes this gets in the way, as the part is waiting for LOCKED
> > before it even releases GTS, and GSR. =A0Easier is to force the DCM's t=
o
> > reset after DONE goes high by driving reset with a startup signal that
> > you generate.
>
> Hmm, how can the DCMs even lock if GTS is still active, i.e. clock
> inputs are
> still disabled?
>
> > By moving DONE till after GTS, you are getting the DCM's to start
> > up ... or that is my best guess.
>
> What I don't get is that iMPACT claims it's done. Seems to me that it jus=
t
> watches for "DONE", and then stops, even though the startup sequence
> isn't finished yet. If it were waiting for DCMs to lock or something
> else, I'd expect it would get stuck at 99% or stop after a timeout with
> a "failed" message or something.
>
> This just had me stuck for 2 days, measuring ripple on my supply,
> checking my clocks, checking the layout and so on. I probably would've
> sent the board out for x-rays to check for soldering issues next, hadn't
> I by chance run across a colleague in the corridor who had the same
> problem 5 years ago.
>
> cu,
> Sean
>
> --
> Replace "MONTH" with the three-letter abbreviation of the current month
> and the two-digit code for the current year (simple, eh?).

I have seen this exact problem with embedded programming.  The
processor
would stop CCLK (slave serial in this case, but the same idea) as soon
as it saw DONE, but it would only check for DONE starting after the
last bit of the configuration bitstream.  The problem only showed up
for some iterations of the design, because apparently the bitstream
doesn't always end on a byte boundary and the number of extra bits
might or might not be enough to clock the FPGA into the end of the
startup sequence.

Regards,
Gabor

Article: 145318
Subject: Re: Simulating Spartan 3A pins in ltspice
From: Gabor <gabor@alacron.com>
Date: Fri, 5 Feb 2010 10:49:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 1:13=A0pm, austin <aus...@xilinx.com> wrote:
> Pat,
>
> We have encrypted hspice models as shown, mostly only for Virtex
> family parts, for "heavy lifting" customers who require them.
>
> Since the devices models belong to Toshiba, IBM, UMC (etc.), these
> must be protected (they do not belong to us), so the hspice encrypted
> models are what we support. =A0Period.
>
> IBIS models exist for all families, and parts. =A0These are per the IBIS
> standard, so any tool that works with the IBIS standard should support
> these models. =A0If it doesn't then we need to know (file a webcase so
> we can see why it didn't work).
>
> The latest IBIS extension is for the high speed serial IO on newer
> parts, also supported per the standard.
>
> xSpice (n, p, x, etc. take your pick) are not supported. =A0Period.
>
> Austin

A quick Google of "convert IBIS models to spice" brings up quite
a few conversion tools.  Perhaps you could try to run the Spartan
3A IBIS model through a converter?

Article: 145319
Subject: Re: using an FPGA to emulate a vintage computer
From: "(see below)" <yaldnif.w@blueyonder.co.uk>
Date: Fri, 05 Feb 2010 18:51:48 +0000
Links: << >>  << T >>  << A >>
On 05/02/2010 18:19, in article
badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com, "Eric
Chomko" <pne.chomko@comcast.net> wrote:

> Has anyone created a copy machine of an old system using an FPGA? I
> was wondering if it would be possible to take an entire SWTPC 6800 and
> compile the schematics and have it run on an FPGA board.? Wouldn't
> even have to be the latest Xylinx product, I suspect.

I think such a project would valuable, and perhaps even more valuable if it
aimed to recreate a machine of the "heroic" era -- a 7094, an Atlas, or a
KDF9, say. Perhaps even a Stretch.

KDF9 had about 20K transistors, a few K logic transformers, and a comparable
number of diodes; less than 50K devices in total. I imagine this would be
easily accommodated on a modern FPGA. The big question would be whether to
go for functional equivalence, or whether to try to replicate the original
internal structures.

Documentation would be the main challenge for the latter.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk



Article: 145320
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 5 Feb 2010 10:53:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 5, 3:59=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote:
>
> This just had me stuck for 2 days, measuring ripple on my supply,
> checking my clocks, checking the layout and so on. I probably would've
> sent the board out for x-rays to check for soldering issues next, hadn't
> I by chance run across a colleague in the corridor who had the same
> problem 5 years ago.

So did you solve your problem then?  The title suggests the problem
was found.

A system which stops generating a clock once the done pin goes high
still needs a couple more clocks with the default Done=3D4 time
position.  Changing to Done=3D6 got rid of the head scratching many,
many years ago.

Article: 145321
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Schwingen <news-1235297497@discworld.dascon.de>
Date: 5 Feb 2010 19:13:31 GMT
Links: << >>  << T >>  << A >>
["Followup-To:" set to comp.arch.fpga.]
Eric Chomko <pne.chomko@comcast.net> wrote:
> Has anyone created a copy machine of an old system using an FPGA? I
> was wondering if it would be possible to take an entire SWTPC 6800 and
> compile the schematics and have it run on an FPGA board.? Wouldn't
> even have to be the latest Xylinx product, I suspect.

There are several such projects, eg. this Atari ST clone:
http://www.experiment-s.de/en/

so most systems from the 8-bit era should be no problem at all.

cu
Michael


Article: 145322
Subject: Re: Board layout for FPGA
From: Mike Harrison <mike@whitewing.co.uk>
Date: Fri, 05 Feb 2010 19:15:10 +0000
Links: << >>  << T >>  << A >>

>Yes, one common element is that most designs apply overkill in the
>supply decoupling area.  When an engineer uses a method and it works,
>it is like the elephant protection charm... you don't see any
>elephants do you, so it must be working!

Just for amusement, I tried an experiment on a simple FPGA board I designed recently -board has a
Lattice EC3, driving a small TFT LCD from video data in NAND flash.
It's a 2 layer PCB, with about ten 100n decouplers wherever space allowed and a couple of 1u
ceramics on each rail. 
I removed ALL the decouplers apart from a single 1u on each rail to keep the LDOs happy. Board still
worked just fine..... didn't do any noise measurements though....

A few years ago I saw a very amusing talk at London Dorkbot - in an attempt to bring old board games
up to date, James Larson created "Motherboard Operation" - players take it in turns to snip
components from a working, running PC motherboard until it stops working...
This was accompanied by "PC PSU Buckaroo" - players choose and add more and more loads to an old PC
power supply until it fails.... 
 

Article: 145323
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 05 Feb 2010 19:25:15 +0000
Links: << >>  << T >>  << A >>
On 2/5/2010 7:15 PM, Mike Harrison wrote:
> worked just fine..... didn't do any noise measurements though....
>
> A few years ago I saw a very amusing talk at London Dorkbot - in an attempt to bring old board games
> up to date, James Larson created "Motherboard Operation" - players take it in turns to snip
> components from a working, running PC motherboard until it stops working...
>
That's like Muntzing! Named after Madman Muntz. :-)


Article: 145324
Subject: Re: using an FPGA to emulate a vintage computer
From: james <bubba@bud.u>
Date: Fri, 05 Feb 2010 15:10:45 -0500
Links: << >>  << T >>  << A >>
On Fri, 5 Feb 2010 10:19:25 -0800 (PST), Eric Chomko
<pne.chomko@comcast.net> wrote:

|Has anyone created a copy machine of an old system using an FPGA? I
|was wondering if it would be possible to take an entire SWTPC 6800 and
|compile the schematics and have it run on an FPGA board.? Wouldn't
|even have to be the latest Xylinx product, I suspect.


John Kent has done a lot of work using Xilinx chips and synthesizing a
6809 version of the SWTPC onto a chip. 

See his webpage here

http://members.optusnet.com.au/jekent/system09/

There is also a yahoo group that is centered around the Tandy CoCO3 on
a Digilent Spartan 3 starter board with the XC3S1000 chip option. The
yahoo group is known as CoCo3fpga I think. 

james



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