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 145425

Article: 145425
Subject: Re: using an FPGA to emulate a vintage computer
From: oksid <oksid@bluewin.ch>
Date: Tue, 09 Feb 2010 08:27:38 +0100
Links: << >>  << T >>  << A >>
Jecel wrote:
> I try to keep a reasonably updated list of such projects at
>
> http://www.merlintec.com:8080/hardware/31

The commodore 64 clone "C-one" which is in your list is interesting.
It has been implemented in an ASIC and has been sold as a commercial 
product.
http://en.wikipedia.org/wiki/C64_Direct-to-TV



Article: 145426
Subject: Re: Progrmming a flash connected to a Stratix II GX
From: Alan Fitch <alan.fitch@spamtrap.com>
Date: Tue, 09 Feb 2010 10:02:13 +0000
Links: << >>  << T >>  << A >>
jfh wrote:
> Hi;
> 
> We are trying to program a CFI Flash (Numonyx TE28F320J3D75) using the
> flash programmer of Quartus II/EDS  9.1. We followed the instructions
> given in the User's Guide (from february 2010 !), and the programmer
> is reading the CFI table correctly, but when it comes to actual
> programming, it stops at 0%, with the following message :
> "
> Program failed
> Error code : 4 in .....nios2flashprogrammer.exe ....
> "
> In parallel, we have been running read and write tests on the flash
> and they are passing.
> Thus we suspect that something may be wrong with the flash
> programmer... would you have any idea of what we need to check and
> what we can do to have a bit more visibility of what's going on  ?
> 
> Best regards,
> 
> JF

If you've tried all the advice in section 3 (--debug, flash override 
file etc), perhaps you should follow the last sentence :-)

"If you find a CFI-compliant device that does not work with the Nios II 
Flash
Programmer, please report it to Altera Technical Support."

regards
Alan


-- 
Alan Fitch
Senior Consultant

Doulos  Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223		Email: alan.fitch@doulos.com	
Fax:  +44 (0)1425 471573		http://www.doulos.com

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

This message may contain personal views which are not the views of 
Doulos, unless specifically stated.

Article: 145427
Subject: Re: Xilinx ISE 11.1 crash - Visual Studio error
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Tue, 09 Feb 2010 10:54:34 +0000
Links: << >>  << T >>  << A >>
Daku <dakupoto@gmail.com> writes:

> Could some Xilinx ISE guru provide some hints for my problem ? I am
> trying to synthesize a simple 4K RAM block with Xilinx ISE. About half-
> way through execution, I get an error message, inside a Visual Studio
> dialog box, stating that xst.exe ( the Xilinx synthesis executable)
> has encountered a problem and would I like to debug ? The Xilinx ISE
> is running

Can you try synthesizing a much smaller RAM (say 128 words?)

Can you post your code?  

What does the synthesis logfile say?

You haven't given us much to go on! 

Cheers,
Martin

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

Article: 145428
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 09 Feb 2010 12:18:30 +0000
Links: << >>  << T >>  << A >>
On 2/8/2010 5:14 AM, rickman wrote:
> On Feb 6, 7:37 pm, Symon<symon_bre...@hotmail.com>  wrote:
>> On 2/6/2010 5:38 PM, rickman wrote:
>>
>>> I keep asking you if you have done any real analysis or measurements
>>> of what you are stating?
>>
>>   >
>>
>> Well, this was the first time you asked IIRC, but thank you for doing
>> so. The answer is "For sure". I've used Hyperlynx and Spice on my
>> boards. I guess you have also, or else you would not be able to post
>> your opinions without worrying you might giving someone a bum steer.
>
> So are you going to share the results of these simulations on the vias
> you are talking about?
>
>
Sure Rick, let's go through it together with some cheap tools (free!) 
from t'internet. OK, you can get a nice copy of Spice from here. maybe 
you already have it.

http://www.linear.com/designtools/software/

At the bottom of this post you will find a model of a PCB with a power 
plane bypass. I've used lumped components to model it. If you 
cut'n'paste the text into an editor and save it as 'planes.asc' or 
somesuch, you should be able to load it into the simulator you downloaded.

So, if you look at the model, here's what each bit does.


V1   DC power supply.
L3   Big inductor to represent the PDS supply impedance.
C2,  R2, L4 model a 0402 1uF bypass capacitor. L4 includes the vias.
C4   Models the power plane bypass. No parasitics on this baby!
L1   Models the power via and ball from the plane to the FPGA die.
C3, R3, L5 model the bypass capacitor on the FPGA BGA package.
R1, C1, V2 model a IOB switching with 500ps rise time. Rout=20,Cpin=10p
L2   Models the ground via from the PCB plane to the FPGA die.

BTW, you can find models of bypass capacitors here:-
http://www.murata.com/products/design_support/mcsil/index.html

Signals are:-

PCB_PWR is the power on the PCB
FPGA_PWR is the power on the BGA package.
FPGA_GND is the ground on the BGA package.
Vout is used to show when the switching happens.

(1) If you press the little 'running man' button, a simulation window 
will appear. You can now click on nets in the schematic. I clicked on 
FPGA_PWR, FPGA_GND, Vout and PCB_PWR. I also clicked on Windows -> tile 
vertically to give a nicer picture. Whatever, let's call this experiment 1.

OK, we see the power on the BGA is quite well behaved as expected. 60mv 
of overshoot and ground bounce.

(2) So, what happens if we remove the bypass made from the power plane 
being next to the ground plane, and instead use a ground plane near the 
surface? If you make the schematic the active window by clicking in it, 
then click the scissors symbol, then click on C4, that's got rid of the 
power bypassing. If we right click on L2 and change it to 0.5n, (N.B. 
don't forget the 'n'!) that's the same as moving the ground plane near 
to the surface, as the via inductance is reduced by this much. Call this 
experiment 2.

Here we see a little difference. The power overshoot is now a bit 
bigger, maybe 110mV. The ground bounce is less, about 30mV.

(3) If we add another bypass capacitor, using the copy feature (next to 
the scissors!) to copy L4, R2 and C2, we can do experiment 3.

Here we see smaller overshoot, maybe 100mV, showing that if a few bypass 
capacitors are added we would get back the performance of a 'plane built 
capacitor'.

(4) Let's go back to the original design. If you press F9 enough times 
you'll undo any changes. Try deleting the 'on BGA' bypass capacitor C3. 
experiment 4.

You will now see much bigger overshoots and ground bounce. That's why 
the FPGA manufacturers put bypassing on the BGA.

(5) OK, back to the original design again with F9. Let's try this. Let's 
say we only have a small board, a few square inches, and the plane 
capacitance is only 200pF. Right click on C4 and change it to 200p. 
Experiment 5.

Here we see the potential danger of using a power plane derived 
bypassing system. The high-Q power plane is resonanting with L1, the via 
and ball inductance to start an oscillation. With ordinary bypass 
capacitors only, this doesn't happen as the caps have far less Q. If you 
remove the 'on-bga' bypassing, C3, you'll see this effect get even worse.


I hope this crude model has given you some insight into why I choose to 
eschew the power plane bypassing idea in the middle of the board, and 
use ground planes near the surface instead.

1) From experiment 2 we can have less ground bounce by using a ground 
plane very close to the FPGA. The ground is connected to all the FPGA 
supplies, not just the Vcco we are simulating here, so is most 
important. Any ground bounce affects the whole device, core, DCMs, PLLs, 
everything. Any rises in Vcco overshoot from losing the power plane can 
be mitigated with more bypass caps as shown in experiment 3.

2) The manufacturers put bypassing on the device for a reason, as we see 
from experiment 4, and this is highly effective.

3) Power plane bypassing systems can give rise to nasty unexpected 
resonances unless they are designed very carefully as shown in 
experiment 5. Using crappy Q bypass capacitors instead precludes this 
from ever being a problem.

I'd appreciate your critique.

Thanks, Syms.


Model planes.asc  :-

Version 4
SHEET 1 880 680
WIRE -144 -224 -192 -224
WIRE -16 -224 -64 -224
WIRE 128 -224 -16 -224
WIRE 272 -224 128 -224
WIRE 336 -224 272 -224
WIRE 336 -192 336 -224
WIRE -16 -128 -16 -224
WIRE 336 -96 336 -112
WIRE 528 -96 336 -96
WIRE 560 -96 528 -96
WIRE 336 -80 336 -96
WIRE 336 -80 224 -80
WIRE 336 -64 336 -80
WIRE 224 -48 224 -80
WIRE -16 16 -16 -48
WIRE 128 48 128 -224
WIRE 224 48 224 32
WIRE 336 48 336 16
WIRE -192 80 -192 -224
WIRE 336 128 336 112
WIRE 528 128 336 128
WIRE 560 128 528 128
WIRE 224 144 224 128
WIRE 336 144 336 128
WIRE -16 176 -16 96
WIRE 224 256 224 208
WIRE 336 256 336 224
WIRE 336 256 224 256
WIRE 336 288 336 256
WIRE 528 288 336 288
WIRE 560 288 528 288
WIRE 336 320 336 288
WIRE -192 432 -192 160
WIRE -16 432 -16 240
WIRE -16 432 -192 432
WIRE 128 432 128 112
WIRE 128 432 -16 432
WIRE 256 432 128 432
WIRE 336 432 336 400
WIRE 336 432 256 432
WIRE 256 464 256 432
FLAG 256 464 0
FLAG 528 -96 FPGA_PWR
FLAG 528 288 FPGA_GND
FLAG 528 128 Vout
FLAG 272 -224 PCB_PWR
SYMBOL ind 320 -208 R0
SYMATTR InstName L1
SYMATTR Value 1n
SYMBOL ind 320 304 R0
SYMATTR InstName L2
SYMATTR Value 1n
SYMBOL voltage -192 64 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value 3.3
SYMBOL voltage 336 128 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V2
SYMATTR Value PULSE(0 3.3 0 0.5n 0.5n 9.5n 20n)
SYMBOL cap 320 48 R0
SYMATTR InstName C1
SYMATTR Value 10p
SYMBOL res 320 -80 R0
SYMATTR InstName R1
SYMATTR Value 20
SYMBOL ind -48 -240 R90
WINDOW 0 5 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName L3
SYMATTR Value 10
SYMBOL cap -32 176 R0
SYMATTR InstName C2
SYMATTR Value 1
SYMBOL res -32 0 R0
SYMATTR InstName R2
SYMATTR Value 0.25
SYMBOL cap 208 144 R0
SYMATTR InstName C3
SYMATTR Value 10n
SYMBOL ind 208 -64 R0
SYMATTR InstName L5
SYMATTR Value 0.7n
SYMBOL cap 112 48 R0
SYMATTR InstName C4
SYMATTR Value 1n
SYMBOL ind -32 -144 R0
SYMATTR InstName L4
SYMATTR Value 0.7n
SYMBOL res 208 32 R0
SYMATTR InstName R3
SYMATTR Value 0.25
TEXT -312 -72 Left 0 !.tran 50n









Article: 145429
Subject: Running BMD design on a 64 bit machine
From: Usama <usama817@gmail.com>
Date: Tue, 9 Feb 2010 05:26:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

i have implemented a BMD design using xapp1052. it is running
successfully on a 32 bit machine. but when i run it on a 64 bit
machine i am facing a problem

the problem is that when i set  the register DCSR0 bit 1 and try to
read it a blue screen appears with the message "HARDWARE FAILURE" .
but on the 32 bit machine this is functioning properly.

Please help me if anyone has any idea regarding this issue.

Thanks

Regards,
Usama Bin Aslam

Article: 145430
Subject: Re: Board layout for FPGA
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.gmail.com>
Date: Tue, 09 Feb 2010 07:26:41 -0600
Links: << >>  << T >>  << A >>
<big snip>

>
>3) Power plane bypassing systems can give rise to nasty unexpected 
>resonances unless they are designed very carefully as shown in 
>experiment 5. Using crappy Q bypass capacitors instead precludes this 
>from ever being a problem.
>
>I'd appreciate your critique.
>
>Thanks, Syms.
>

<snip>

So, are X7R 'crappy' enough Q, or would Y5U be worse/better?
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145431
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 09 Feb 2010 14:10:59 +0000
Links: << >>  << T >>  << A >>
On 2/9/2010 1:26 PM, RCIngham wrote:
> <big snip>
>
>>
>> 3) Power plane bypassing systems can give rise to nasty unexpected
>> resonances unless they are designed very carefully as shown in
>> experiment 5. Using crappy Q bypass capacitors instead precludes this
>>from ever being a problem.
>>
>> I'd appreciate your critique.
>>
>> Thanks, Syms.
>>
>
> <snip>
>
> So, are X7R 'crappy' enough Q, or would Y5U be worse/better?
> 	
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

Hi,
Off the top of my head, I wouldn't know. Perhaps have a look with this 
tool that I referenced, Murata's S-parameter and impedance library.

http://www.murata.com/products/design_support/mcsil/index.html

Off the top of my head I don't think Y5U have any worse Q than other 
ceramics. They do have terrible temperature issues though. They also 
lose capacitance all you put more DC voltage onto them.

Please report back!

Thanks, Symon.

Article: 145432
Subject: Re: using an FPGA to emulate a vintage computer
From: Philipp Hachtmann <hachti@hachti.de>
Date: Tue, 09 Feb 2010 16:23:39 +0100
Links: << >>  << T >>  << A >>
Eric Chomko wrote:
> Has anyone created a copy machine of an old system using an FPGA? I
Yes, pdp8 :-)

But no front panel yet. Just a CPU with BRAM memory and teletype. Passed the CPU maindecs.



-- 
---
http://pdp8.hachti.de

Article: 145433
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Tue, 09 Feb 2010 17:36:07 +0100
Links: << >>  << T >>  << A >>
Hi Brian,

thanks for a lot of useful pointers! See my responses below.

Brian Davis wrote:
> FWIW another of my favorite Impact 10.1 settings is
>  Edit->Preferences->Configuration Preferences->
>  Startup Clock->Automatic Correction
I think that's the default in ISE11 now, as it should be.

>  If your normal method of configuration works fine, I wouldn't
> worry too much about curable JTAG issues like that.
The thing is that I'm using configuration via SPI flash on this board. I
 was planning to use indirect SPI programming for initial flashing, but
it doesn't work. iMPACT downloads the JTAG->SPI-core-bitfile and then
just quits with "Programming failed", without giving any more detail.

I suspect this is because the loading of the JTAG->SPI-core fails
because of the issue I'm having on this board. If the bitfile shipped
with iMPACT wasn't created with the DONE_cyle:6-setting, it won't work
on this board.

Fortunately, I have a dedicated SPI programming connector on the board
as well, so I can use that for flashing. Loading the FPGA through SPI
works fine.

>  I've seen that same sort of problem on a multi-chip V5
> DONE cascade with Impact 10.1:
>  http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a291d5c38abbd3c
Only one V5 on this board.

> -------------
> 
> Random debug thoughts:
> 
> Configuration mode
>  - are the chip mode pins set to JTAG, or another boot mode?
>  - does changing the mode pins to JTAG affect the problem?
Mode pins are set to SPI, but changing to JTAG or master serial makes no
difference.

> External DONE timing/levels
>  - what value of pullup do you have on DONE pin?
Originally I had the 300 Ohms Xilinx has in their application notes, but
I've tried different values up to 10k without success.

>  - are you using the "drive DONE" bitgen option?
Nope, I'll try that tomorrow. But of course I can't change it for the
JTAG->SPI bitfile shipped with iMPACT. Or is there a way to manipulate
settings like that in an existing bitfile? Theoretically this should be
possible by changing some bits and recalculating the CRC, but is this
documented somewhere?

>  - have you tried the 'internal done pipe' bitgen option?
Yes, no change.

>  - what does the DONE risetime look like on the board?
>  - what happpens if you lower the JTAG clock rate?
No change.

>  - is your DONE LED buffered? ( I've seen some boards with
>    DONE LED hookups that load down the external DONE signal )
I don't have it buffered, but I have a transistor hooked up to it to
light up a LED when donfiguration is done.

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Article: 145434
Subject: SoC benchmarks
From: Vivek Menon <vivek.menon79@gmail.com>
Date: Tue, 9 Feb 2010 09:00:50 -0800 (PST)
Links: << >>  << T >>  << A >>
I am looking for SoC benchmarks such as VOPD, FFT, MPEG4 for
performance evaluation on FPGAs.

Article: 145435
Subject: Re: Xilinx ISE 11.1 crash - Visual Studio error
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 9 Feb 2010 09:04:01 -0800
Links: << >>  << T >>  << A >>
On Mon, 8 Feb 2010 21:04:49 -0800 (PST)
Daku <dakupoto@gmail.com> wrote:

> Could some Xilinx ISE guru provide some hints for my problem ? I am
> trying to synthesize a simple 4K RAM block with Xilinx ISE. About
> half- way through execution, I get an error message, inside a Visual
> Studio dialog box, stating that xst.exe ( the Xilinx synthesis
> executable) has encountered a problem and would I like to debug ? The
> Xilinx ISE is running
> on a XP machine.
> Any hints, suggestions would be of immense help.

The entire 11.x tool chain has been, in my experience, an unmitigated
disaster.  You might could try upgrading to the latest version, 11.4.
There's a chance it'll fix your problem.  Then again, there's a chance
that it will create a new, unrelated problem, too.  But at least if the
problem is moving around you can claim you've got movement on the
problem.

Xilinx tells me that 12.1 will be better, come April.  Now if only all
_my_ customers were willing to sit around and wait for two extra
months.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 145436
Subject: Re: Xilinx ISE 11.1 crash - Visual Studio error
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 09 Feb 2010 09:19:20 -0800
Links: << >>  << T >>  << A >>
Rob Gaddi wrote:

> The entire 11.x tool chain has been, in my experience, an unmitigated
> disaster.  You might could try upgrading to the latest version, 11.4.
> There's a chance it'll fix your problem. 

I've had good luck with 10.1.

        -- Mike Treseler

Article: 145437
Subject: Re: Xilinx ISE 11.1 crash - Visual Studio error
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 9 Feb 2010 09:29:47 -0800
Links: << >>  << T >>  << A >>
On Tue, 09 Feb 2010 09:19:20 -0800
Mike Treseler <mtreseler@gmail.com> wrote:

> Rob Gaddi wrote:
> 
> > The entire 11.x tool chain has been, in my experience, an
> > unmitigated disaster.  You might could try upgrading to the latest
> > version, 11.4. There's a chance it'll fix your problem. 
> 
> I've had good luck with 10.1.
> 
>         -- Mike Treseler

So did I, right up until I started a Spartan 6 design.  Thus began my
life as a tool fighter rather than a logic designer.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 145438
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 9 Feb 2010 09:31:30 -0800 (PST)
Links: << >>  << T >>  << A >>
This is becoming a very informative discussion.  I have not tried to
analyze a complex power distribution system (PDS).  Most of the
devices I build have modest PDS needs.

You didn't go into enough detail on how you picked the values you
used.  I do not typically use 1 uF caps as decoupling caps.  I use
either 100 nF or 10 nF or a combination of the two.  I see you used a
10 nF cap on the IC.  You list the Murata tool as the source of the
capacitor parameters, but the values you use for ESR seem very high.
With that tool a GRM188R71H103KA01 in the 0603 package gives a series
inductance of 0.58 nH and a series resistance of 0.094 at 100 MHz.
This frequency is above the self resonant frequency of about 65 MHz,
but the impedance is still only 0.23 ohms, same as at about 42 MHz.

You also did not include any of the parasitic effects of how the
capacitors connect to their substrate.  In the case of the board
mounted caps, they will have vias connecting them to the power
planes.  In the case of the caps inside the package, they will also
have mounting parasitic effects, even if there are no vias.

But none of that really matters.  Your circuit is a very poor
representation of the real world.  That is why it is so important to
verify results with real world measurements.  Your circuit has several
problems.  The first is that you only apply a single decoupling
capacitor to the board!  I may be an advocate of using fewer
decoupling capacitors, but I think one is pushing the envelope a bit
much.  If you gave a reference to finding a value for the inductance
of the connection between the power plane and the chip die, it must
have been in an earlier post.

But most importantly, I am very sure that your model for how the
transients are generated is wrong.  You show the current path as being
from the FPGA power plane directly through the output series
resistance and back to the FPGA ground.  I am pretty sure that none of
the traces on the board (the source of the capacitive load on the
output) directly connect to the FPGA ground.  You need to put that
connection to the board ground, and even then through another package
lead.  The model of using a signal generator to provide current surges
may not be so good as well.  This results in currents being drawn
between the two FPGA planes.  Perhaps I am reading incorrectly that
the Vout is an I/O pin and you are only trying to model internal
switching transients.  The real issue that causes ground bounce (the
thing you seem to be most concerned about) is the current required to
charge and discharge the board trace and component pin on the other
end of that trace.  This current will by necessity pass through the
two inductors (L1, L2) and will create a lot of bounce that is not
mitigated by the on chip capacitor(s).

Even if you are looking at the internal switching noise of the IC, you
need to model the *entire* PDS, not just one pin or one capacitor at a
time.  You also need to pick appropriate values for the various
components and include all parasitic effects.  If you can't do all of
that, or even if you can, a simulation doesn't mean squat if it isn't
complete.  The only way to know if it is complete for something as
complex as this is to take measurements of a real design.

Rick


On Feb 9, 7:18 am, Symon <symon_bre...@hotmail.com> wrote:
> On 2/8/2010 5:14 AM, rickman wrote:
>
> > On Feb 6, 7:37 pm, Symon<symon_bre...@hotmail.com>  wrote:
> >> On 2/6/2010 5:38 PM, rickman wrote:
>
> >>> I keep asking you if you have done any real analysis or measurements
> >>> of what you are stating?
>
> >> Well, this was the first time you asked IIRC, but thank you for doing
> >> so. The answer is "For sure". I've used Hyperlynx and Spice on my
> >> boards. I guess you have also, or else you would not be able to post
> >> your opinions without worrying you might giving someone a bum steer.
>
> > So are you going to share the results of these simulations on the vias
> > you are talking about?
>
> Sure Rick, let's go through it together with some cheap tools (free!)
> from t'internet. OK, you can get a nice copy of Spice from here. maybe
> you already have it.
>
> http://www.linear.com/designtools/software/
>
> At the bottom of this post you will find a model of a PCB with a power
> plane bypass. I've used lumped components to model it. If you
> cut'n'paste the text into an editor and save it as 'planes.asc' or
> somesuch, you should be able to load it into the simulator you downloaded=
.
>
> So, if you look at the model, here's what each bit does.
>
> V1   DC power supply.
> L3   Big inductor to represent the PDS supply impedance.
> C2,  R2, L4 model a 0402 1uF bypass capacitor. L4 includes the vias.
> C4   Models the power plane bypass. No parasitics on this baby!
> L1   Models the power via and ball from the plane to the FPGA die.
> C3, R3, L5 model the bypass capacitor on the FPGA BGA package.
> R1, C1, V2 model a IOB switching with 500ps rise time. Rout=3D20,Cpin=3D1=
0p
> L2   Models the ground via from the PCB plane to the FPGA die.
>
> BTW, you can find models of bypass capacitors here:-http://www.murata.com=
/products/design_support/mcsil/index.html
>
> Signals are:-
>
> PCB_PWR is the power on the PCB
> FPGA_PWR is the power on the BGA package.
> FPGA_GND is the ground on the BGA package.
> Vout is used to show when the switching happens.
>
> (1) If you press the little 'running man' button, a simulation window
> will appear. You can now click on nets in the schematic. I clicked on
> FPGA_PWR, FPGA_GND, Vout and PCB_PWR. I also clicked on Windows -> tile
> vertically to give a nicer picture. Whatever, let's call this experiment =
1.
>
> OK, we see the power on the BGA is quite well behaved as expected. 60mv
> of overshoot and ground bounce.
>
> (2) So, what happens if we remove the bypass made from the power plane
> being next to the ground plane, and instead use a ground plane near the
> surface? If you make the schematic the active window by clicking in it,
> then click the scissors symbol, then click on C4, that's got rid of the
> power bypassing. If we right click on L2 and change it to 0.5n, (N.B.
> don't forget the 'n'!) that's the same as moving the ground plane near
> to the surface, as the via inductance is reduced by this much. Call this
> experiment 2.
>
> Here we see a little difference. The power overshoot is now a bit
> bigger, maybe 110mV. The ground bounce is less, about 30mV.
>
> (3) If we add another bypass capacitor, using the copy feature (next to
> the scissors!) to copy L4, R2 and C2, we can do experiment 3.
>
> Here we see smaller overshoot, maybe 100mV, showing that if a few bypass
> capacitors are added we would get back the performance of a 'plane built
> capacitor'.
>
> (4) Let's go back to the original design. If you press F9 enough times
> you'll undo any changes. Try deleting the 'on BGA' bypass capacitor C3.
> experiment 4.
>
> You will now see much bigger overshoots and ground bounce. That's why
> the FPGA manufacturers put bypassing on the BGA.
>
> (5) OK, back to the original design again with F9. Let's try this. Let's
> say we only have a small board, a few square inches, and the plane
> capacitance is only 200pF. Right click on C4 and change it to 200p.
> Experiment 5.
>
> Here we see the potential danger of using a power plane derived
> bypassing system. The high-Q power plane is resonanting with L1, the via
> and ball inductance to start an oscillation. With ordinary bypass
> capacitors only, this doesn't happen as the caps have far less Q. If you
> remove the 'on-bga' bypassing, C3, you'll see this effect get even worse.
>
> I hope this crude model has given you some insight into why I choose to
> eschew the power plane bypassing idea in the middle of the board, and
> use ground planes near the surface instead.
>
> 1) From experiment 2 we can have less ground bounce by using a ground
> plane very close to the FPGA. The ground is connected to all the FPGA
> supplies, not just the Vcco we are simulating here, so is most
> important. Any ground bounce affects the whole device, core, DCMs, PLLs,
> everything. Any rises in Vcco overshoot from losing the power plane can
> be mitigated with more bypass caps as shown in experiment 3.
>
> 2) The manufacturers put bypassing on the device for a reason, as we see
> from experiment 4, and this is highly effective.
>
> 3) Power plane bypassing systems can give rise to nasty unexpected
> resonances unless they are designed very carefully as shown in
> experiment 5. Using crappy Q bypass capacitors instead precludes this
> from ever being a problem.
>
> I'd appreciate your critique.
>
> Thanks, Syms.
>
> Model planes.asc  :-
>
> Version 4
> SHEET 1 880 680
> WIRE -144 -224 -192 -224
> WIRE -16 -224 -64 -224
> WIRE 128 -224 -16 -224
> WIRE 272 -224 128 -224
> WIRE 336 -224 272 -224
> WIRE 336 -192 336 -224
> WIRE -16 -128 -16 -224
> WIRE 336 -96 336 -112
> WIRE 528 -96 336 -96
> WIRE 560 -96 528 -96
> WIRE 336 -80 336 -96
> WIRE 336 -80 224 -80
> WIRE 336 -64 336 -80
> WIRE 224 -48 224 -80
> WIRE -16 16 -16 -48
> WIRE 128 48 128 -224
> WIRE 224 48 224 32
> WIRE 336 48 336 16
> WIRE -192 80 -192 -224
> WIRE 336 128 336 112
> WIRE 528 128 336 128
> WIRE 560 128 528 128
> WIRE 224 144 224 128
> WIRE 336 144 336 128
> WIRE -16 176 -16 96
> WIRE 224 256 224 208
> WIRE 336 256 336 224
> WIRE 336 256 224 256
> WIRE 336 288 336 256
> WIRE 528 288 336 288
> WIRE 560 288 528 288
> WIRE 336 320 336 288
> WIRE -192 432 -192 160
> WIRE -16 432 -16 240
> WIRE -16 432 -192 432
> WIRE 128 432 128 112
> WIRE 128 432 -16 432
> WIRE 256 432 128 432
> WIRE 336 432 336 400
> WIRE 336 432 256 432
> WIRE 256 464 256 432
> FLAG 256 464 0
> FLAG 528 -96 FPGA_PWR
> FLAG 528 288 FPGA_GND
> FLAG 528 128 Vout
> FLAG 272 -224 PCB_PWR
> SYMBOL ind 320 -208 R0
> SYMATTR InstName L1
> SYMATTR Value 1n
> SYMBOL ind 320 304 R0
> SYMATTR InstName L2
> SYMATTR Value 1n
> SYMBOL voltage -192 64 R0
> WINDOW 123 0 0 Left 0
> WINDOW 39 0 0 Left 0
> SYMATTR InstName V1
> SYMATTR Value 3.3
> SYMBOL voltage 336 128 R0
> WINDOW 123 0 0 Left 0
> WINDOW 39 0 0 Left 0
> SYMATTR InstName V2
> SYMATTR Value PULSE(0 3.3 0 0.5n 0.5n 9.5n 20n)
> SYMBOL cap 320 48 R0
> SYMATTR InstName C1
> SYMATTR Value 10p
> SYMBOL res 320 -80 R0
> SYMATTR InstName R1
> SYMATTR Value 20
> SYMBOL ind -48 -240 R90
> WINDOW 0 5 56 VBottom 0
> WINDOW 3 32 56 VTop 0
> SYMATTR InstName L3
> SYMATTR Value 10=B5
> SYMBOL cap -32 176 R0
> SYMATTR InstName C2
> SYMATTR Value 1=B5
> SYMBOL res -32 0 R0
> SYMATTR InstName R2
> SYMATTR Value 0.25
> SYMBOL cap 208 144 R0
> SYMATTR InstName C3
> SYMATTR Value 10n
> SYMBOL ind 208 -64 R0
> SYMATTR InstName L5
> SYMATTR Value 0.7n
> SYMBOL cap 112 48 R0
> SYMATTR InstName C4
> SYMATTR Value 1n
> SYMBOL ind -32 -144 R0
> SYMATTR InstName L4
> SYMATTR Value 0.7n
> SYMBOL res 208 32 R0
> SYMATTR InstName R3
> SYMATTR Value 0.25
> TEXT -312 -72 Left 0 !.tran 50n

Article: 145439
Subject: Spartan-3E Starter Kit reconfiguration problems
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 9 Feb 2010 19:09:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello,

to talk to the SPI flash on the s3e starter kit board, I have some code that
invokes the BSCAN_SPARTAN3 primitive and additional sets and locates
DAC_CS = AMP_CS = SF_CE0 = FPGA_INIT_B = 1 and AD_CONV =0; 

NET "DAC_CS" LOC = "N8" ;
NET "AMP_CS" LOC = "N7" 
NET "AD_CONV" LOC = "P11" ;
NET "SF_CE0" LOC = "D16" ;
NET "FPGA_INIT_B" LOC = "T3";

That way I can talk to the SPI device after loading the bitfile via JTAG.

The first SPI access however often fails.

After an SPI access through that core, a press on the PROG button of the
board still triggers reconfiguration, and the DONE leds still lights up
after a short while, but the inital program scrolling the LCD doesn't
start. It only starts after repowering the whole board.

Any idea on what contention I hit and how I can solve?

Thanks
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 145440
Subject: Re: Board layout for FPGA
From: Symon <symon_brewer@hotmail.com>
Date: Tue, 09 Feb 2010 19:10:22 +0000
Links: << >>  << T >>  << A >>
Allow me to rebut!!

On 2/9/2010 5:31 PM, rickman wrote:
> This is becoming a very informative discussion.  I have not tried to
> analyze a complex power distribution system (PDS).  Most of the
> devices I build have modest PDS needs.

Unfortunately, if you use a FPFA with sub ns rise times, you no longer 
have modest PDS needs. Your preference for a tightly coupled 
power-ground plane bypassing system could lead to hi-frequency 
resonances. You might not have these problems, but it's important to do 
some kind of simulation or calculation to be sure. Remember, the 
frequency of your signals are not the issue, but the rise times are.
>
> You didn't go into enough detail on how you picked the values you
> used.  I do not typically use 1 uF caps as decoupling caps.  I use
> either 100 nF or 10 nF or a combination of the two.  I see you used a
> 10 nF cap on the IC.  You list the Murata tool as the source of the
> capacitor parameters, but the values you use for ESR seem very high.
> With that tool a GRM188R71H103KA01 in the 0603 package gives a series
> inductance of 0.58 nH and a series resistance of 0.094 at 100 MHz.
> This frequency is above the self resonant frequency of about 65 MHz,
> but the impedance is still only 0.23 ohms, same as at about 42 MHz.

You have the model, I hereby release it to you to butcher in whatever 
way you choose!
>
> You also did not include any of the parasitic effects of how the
> capacitors connect to their substrate.  In the case of the board
> mounted caps, they will have vias connecting them to the power
> planes.  In the case of the caps inside the package, they will also
> have mounting parasitic effects, even if there are no vias.
 >
I guess you missed "L4 includes the vias"? I modeled the vias by lumping 
them into L4. Likewise L5 includes the 'on BGA' inductance.
>
> But none of that really matters.  Your circuit is a very poor
> representation of the real world.

I can't believe you would slag off my beautifully created design!

> That is why it is so important to
> verify results with real world measurements.  Your circuit has several
> problems.  The first is that you only apply a single decoupling
> capacitor to the board!  I may be an advocate of using fewer
> decoupling capacitors, but I think one is pushing the envelope a bit
> much.  If you gave a reference to finding a value for the inductance
> of the connection between the power plane and the chip die, it must
> have been in an earlier post.

Right, as I said it's a crude model, but surely you see it demonstrates 
the point. I used one bypass cap, but I also used only one IOB, one BGA 
bypass cap, and one ground and power via on the device. This model is to 
show qualitative differences, and what general effects our design 
decisions have.

> But most importantly, I am very sure that your model for how the
> transients are generated is wrong.  You show the current path as being
> from the FPGA power plane directly through the output series
> resistance and back to the FPGA ground.  I am pretty sure that none of
> the traces on the board (the source of the capacitive load on the
> output) directly connect to the FPGA ground.

Right back at you Rick, you are wrong! Look at the datasheet for a 
modern Xilinx FPGA. I'm looking at DS312, Spartan3E. Look for Cin. That 
10pF is there, ON THE DIE, because of the IOB's output FETs. This Spice 
model is a IOB switching without any attached signal. When the output 
switches, a 10pF capacitor has to be charged or discharged from the 
FPGA's PDS through the 20ohms or so output resistance. The model is just 
fine.

>  You need to put that
> connection to the board ground, and even then through another package
> lead.  The model of using a signal generator to provide current surges
> may not be so good as well.  This results in currents being drawn
> between the two FPGA planes.  Perhaps I am reading incorrectly that
> the Vout is an I/O pin and you are only trying to model internal
> switching transients.  The real issue that causes ground bounce (the
> thing you seem to be most concerned about) is the current required to
> charge and discharge the board trace and component pin on the other
> end of that trace.

Not with FPGAs. The Cin is so high, the effect of the rest of the trace 
isn't necessary to show my point.

>  This current will by necessity pass through the
> two inductors (L1, L2) and will create a lot of bounce that is not
> mitigated by the on chip capacitor(s).
>
> Even if you are looking at the internal switching noise of the IC, you
> need to model the *entire* PDS, not just one pin or one capacitor at a
> time.  You also need to pick appropriate values for the various
> components and include all parasitic effects.  If you can't do all of
> that, or even if you can, a simulation doesn't mean squat if it isn't
> complete.

I must disagree here also. I think the model does give some insights 
into the issues that can arise. I'm not looking for accurate numbers, 
just qualitative comparisons between different methodologies.

> The only way to know if it is complete for something as
> complex as this is to take measurements of a real design.
>
> Rick
>
>

People can and do simulate entire PDS systems, sometimes using expensive 
CAD software like HSPICE or even HFSS  or ADS.


Anyway, I've finished with this thread. I hope people reading it will 
take away that simulation is cheap and easy and can give good insights, 
even with a simplistic model. I hope I've scared a few people with 
'power plane resonance' (google it!). I hope I've persuaded a few to 
route/pour their powers because you don't stand to gain much from 
tightly coupled planes, indeed you can have nasty problems from them, 
aside from the logistics of having many power supplies in a modern FPGA 
design. I hope I've persuaded a few to use more ground planes instead of 
power planes, and use their ground planes near to the surface and near 
their signal traces as it's harder to go wrong with this set up. Oh, and 
I hope that now you've downloaded the simulator, you'll get a lot of 
good use from it Rick. I hope you'll play around with some of the things 
you posted and see what effects they have. There's a mailing list for 
LTSpice, which is easy to find, that is useful for advice.

Cheers, Syms.






Article: 145441
Subject: Re: Board layout for FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 9 Feb 2010 20:15:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
Symon <symon_brewer@hotmail.com> wrote:
(snip)

> Sure Rick, let's go through it together with some cheap tools (free!) 
> from t'internet. OK, you can get a nice copy of Spice from here. maybe 
> you already have it.
 
> http://www.linear.com/designtools/software/
 
> At the bottom of this post you will find a model of a PCB with a power 
> plane bypass. I've used lumped components to model it. If you 
> cut'n'paste the text into an editor and save it as 'planes.asc' or 
> somesuch, you should be able to load it into the simulator you downloaded.

(really big snip)

I think you really need a model of the radial transmission line,
which I don't see (but could have missed).

See the papers I mentioned in previous posts.

-- glen

Article: 145442
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: ghelbig <ghelbig@lycos.com>
Date: Tue, 9 Feb 2010 13:38:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 9, 8:36=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote:
> Hi Brian,
>
> thanks for a lot of useful pointers! See my responses below.
>
> Brian Davis wrote:
> > FWIW another of my favorite Impact 10.1 settings is
> > =A0Edit->Preferences->Configuration Preferences->
> > =A0Startup Clock->Automatic Correction
>
> I think that's the default in ISE11 now, as it should be.
>
> > =A0If your normal method of configuration works fine, I wouldn't
> > worry too much about curable JTAG issues like that.
>
> The thing is that I'm using configuration via SPI flash on this board. I
> =A0was planning to use indirect SPI programming for initial flashing, but
> it doesn't work. iMPACT downloads the JTAG->SPI-core-bitfile and then
> just quits with "Programming failed", without giving any more detail.
>
> I suspect this is because the loading of the JTAG->SPI-core fails
> because of the issue I'm having on this board. If the bitfile shipped
> with iMPACT wasn't created with the DONE_cyle:6-setting, it won't work
> on this board.
>
> Fortunately, I have a dedicated SPI programming connector on the board
> as well, so I can use that for flashing. Loading the FPGA through SPI
> works fine.
>
> > =A0I've seen that same sort of problem on a multi-chip V5
> > DONE cascade with Impact 10.1:
> > =A0http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a29=
1...
>
> Only one V5 on this board.
>
> > -------------
>
> > Random debug thoughts:
>
> > Configuration mode
> > =A0- are the chip mode pins set to JTAG, or another boot mode?
> > =A0- does changing the mode pins to JTAG affect the problem?
>
> Mode pins are set to SPI, but changing to JTAG or master serial makes no
> difference.
>
> > External DONE timing/levels
> > =A0- what value of pullup do you have on DONE pin?
>
> Originally I had the 300 Ohms Xilinx has in their application notes, but
> I've tried different values up to 10k without success.
>
> > =A0- are you using the "drive DONE" bitgen option?
>
> Nope, I'll try that tomorrow. But of course I can't change it for the
> JTAG->SPI bitfile shipped with iMPACT. Or is there a way to manipulate
> settings like that in an existing bitfile? Theoretically this should be
> possible by changing some bits and recalculating the CRC, but is this
> documented somewhere?
>
> > =A0- have you tried the 'internal done pipe' bitgen option?
>
> Yes, no change.
>
> > =A0- what does the DONE risetime look like on the board?
> > =A0- what happpens if you lower the JTAG clock rate?
>
> No change.
>
> > =A0- is your DONE LED buffered? ( I've seen some boards with
> > =A0 =A0DONE LED hookups that load down the external DONE signal )
>
> I don't have it buffered, but I have a transistor hooked up to it to
> light up a LED when donfiguration is done.
>
> cu,
> Sean
>
> --
> Replace "MONTH" with the three-letter abbreviation of the current month
> and the two-digit code for the current year (simple, eh?).

FWIW:  I spent 3 days debugging an isse (see: "XST is driving me
crazy" in this usenet group) that was resolved by adding one more
clock to the startup stream.

In my configuration, done would go high and all of the combitorial
logic would word, but none of the sequential logic would work.

One more (extra) CCLK, and everythig went working.

G.

Article: 145443
Subject: Re: using an FPGA to emulate a vintage computer
From: Charles Richmond <frizzle@tx.rr.com>
Date: Tue, 09 Feb 2010 17:21:47 -0600
Links: << >>  << T >>  << A >>
Jecel wrote:
> On Feb 8, 7:05 am, Gregory Estrade wrote:
>> You can add those too :
>> http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued
>> http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga
>> http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga
>>
>> Someday, I will set up a dedicated page for all these projects :)
> 
> Great! This subject really needs a whole wiki to itself rather than
> just a page at a hard to remember address. This is on my "to do" list,
> but it will be a while before I get to it.
> 
> -- Jecel

"I have discovered a truly wonderful proof of this, but the margin
  is too narrow to hold it."     -- Pierre de Fermat

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Article: 145444
Subject: Re: using an FPGA to emulate a vintage computer
From: Charles Richmond <frizzle@tx.rr.com>
Date: Tue, 09 Feb 2010 17:26:34 -0600
Links: << >>  << T >>  << A >>
Charlie Gibbs wrote:
> In article <1bd40ftplw.fsf@snowball.wb.pfeifferfamily.net>,
> pfeiffer@cs.nmsu.edu (Joe Pfeiffer) writes:
> 
>> Al Kossow <aek@bitsavers.org> writes:
>>
>>> Reviving early computing dinosaurs from the surviving DNA is
>>> difficult.
>> That's a line that deserves to be put above the entrance to a
>> computer museum.
> 
> "It's a Unix system!  I know this!"  -- Jurassic Park
> 

http://www.youtube.com/watch?v=dFUlAQZB9Ng

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Article: 145445
Subject: Re: using an FPGA to emulate a vintage computer
From: Walter Bushell <proto@panix.com>
Date: Tue, 09 Feb 2010 18:39:25 -0500
Links: << >>  << T >>  << A >>
In article <hksqmd$arq$1@news.eternal-september.org>,
 Charles Richmond <frizzle@tx.rr.com> wrote:

> Jecel wrote:
> > On Feb 8, 7:05 am, Gregory Estrade wrote:
> >> You can add those too :
> >> http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued
> >> http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga
> >> http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga
> >>
> >> Someday, I will set up a dedicated page for all these projects :)
> > 
> > Great! This subject really needs a whole wiki to itself rather than
> > just a page at a hard to remember address. This is on my "to do" list,
> > but it will be a while before I get to it.
> > 
> > -- Jecel
> 
> "I have discovered a truly wonderful proof of this, but the margin
>   is too narrow to hold it."     -- Pierre de Fermat

If only someone had provided him with some butter.

-- 
 A computer without Microsoft is like a chocolate cake without mustard.

Article: 145446
Subject: To get higher clock frequencies at output using propagation delays.
From: "Pallavi" <pallavi_mp@n_o_s_p_a_m.rediffmail.com>
Date: Tue, 09 Feb 2010 20:11:02 -0600
Links: << >>  << T >>  << A >>
Hi,

I'm implementing this project where I've to generate higher output clk
frequencies using DCM module. I have used a counter for delay generator,
for propagation delays(Pls suggest if there is any other method). I have
also instantiated the DCM module with an input freq of 50MHz and an output
frequency of 320 MHz. I dont know how to write the test bench for this(or
how to connect the DCM logic to the propagation delays to get higher output
clock frequencies). I'm new to this technology and would highly appreciate
if anyone could help me with this. 
the instantiation template is:
dcm1 instance_name (
    .CLKIN_IN(CLKIN_IN), 
    .RST_IN(RST_IN), 
    .CLKFX_OUT(CLKFX_OUT), 
    .CLKIN_IBUFG_OUT(CLKIN_IBUFG_OUT), 
    .CLK0_OUT(CLK0_OUT), 
    .LOCKED_OUT(LOCKED_OUT)
    );
and the counter logic is:
module Counter(Clock, Direction, Count_Out);
    input Clock;
    input Direction;
	 output [3:0] Count_Out;
    reg [3:0] count_int = 0;
   always @(posedge Clock)
      if (Direction)
         count_int <= count_int + 1;
      else
         count_int <= count_int - 1;
			
	assign Count_Out = count_int;		
endmodule



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

Article: 145447
Subject: Re: DONE_cycle:6 setting neccessary in bitgen
From: Brian Davis <brimdavis@aol.com>
Date: Tue, 9 Feb 2010 18:45:41 -0800 (PST)
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
>
>> External DONE timing/levels
>>  - what value of pullup do you have on DONE pin?
>
> Originally I had the 300 Ohms Xilinx has in their application notes,
> but I've tried different values up to 10k without success.
>
 Values lower than 300 ( down to maybe(?) 100 ohms ) would help
if DONE is rising too slow, although 330 should be fine with
just one FPGA.

 What do you measure on the actual board for risetime and
high/low voltage levels on the DONE pin ?

>
>>  - is your DONE LED buffered? ( I've seen some boards with
>>    DONE LED hookups that load down the external DONE signal )
>
> I don't have it buffered, but I have a transistor hooked up to
> it to light up a LED when donfiguration is done.
>
 Transistors normally fall within my definition of 'buffer' :)

 Unless a hypothetical assembly house stuffed, say, a 1.2 ohm
(1R2) where a one Kohm (102) NPN base resistor was supposed
to go, lighting the DONE LED just fine but clamping the DONE
voltage seen at the FPGA pin to one VBE drop such that the
FPGA thinks DONE never went high.

>
> The thing is that I'm using configuration via SPI flash on
> this board. I was planning to use indirect SPI programming
> for initial flashing, but it doesn't work. iMPACT downloads
> the JTAG->SPI-core-bitfile and then just quits with
> "Programming failed", without giving any more detail.
>

 IIRC I'd get a 'Programming Failed' error box after the
'downloading core' stage was reported in the 10.1 log
window, if DONE didn't go high on the board.

 Not sure it'll help any, but here's another post of SPI
related stuff from previous application note trawls:
 http://groups.google.com/group/comp.arch.fpga/msg/797303edfd4e7cac

>
> I suspect this is because the loading of the JTAG->SPI-core
> fails because of the issue I'm having on this board. If the
> bitfile shipped with iMPACT wasn't created with the DONE_cyle:6
> setting, it won't work on this board.
>
<snip>
>
> But of course I can't change it for the JTAG->SPI bitfile
> shipped with iMPACT.
>
 It is a major nuisance that Xilinx doesn't provide the JTAG-SPI
core for iMPACT in either source or black-box synthesizable form.

 This forces customers to reinvent the indirect SPI FLASH wheel.

 If you ever need to do this, I'd suggest starting with either the
Ken Chapman Picoblaze flash example (S3E) or the Avnet V5 SPI
flash eval board example, which demonstrates the V5 logic needed
to do user access to the internal configuration logic.

 Also of note, command line 10.1 PROMGEN has an undocumented-in-
the-manuals " -spi " option that will let you generate an .mcs
file for SPI proms with the proper bit order.

 This is quite helpful, for instance, when iMPACT 10.1 crashes
and burns each time you try to define a multiboot, multi-FPGA
daisy chain SPI PROM from within the iMPACT GUI.

Brian

Article: 145448
Subject: Stratix FPGA board up for grabs for cheap.
From: Alexander <kallisti05@gmail.com>
Date: Tue, 9 Feb 2010 18:48:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello!

Sorry to spam, but this is for a very limited audience. I just placed
my crazy expensive Stratix FPGA development board on E-Bay for cheap
if anyone is interested.

Ebay Item: 200437929577

http://cgi.ebay.com/Stratix-FPGA-PCI-X-or-PCI-Development-Board_W0QQitemZ200437929577QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item2eab081669

Thanks!
 -- Alex

Article: 145449
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 9 Feb 2010 20:28:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 9, 2:10=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> Allow me to rebut!!
>
> On 2/9/2010 5:31 PM, rickman wrote:
>
> > This is becoming a very informative discussion. =A0I have not tried to
> > analyze a complex power distribution system (PDS). =A0Most of the
> > devices I build have modest PDS needs.
>
> Unfortunately, if you use a FPFA with sub ns rise times, you no longer
> have modest PDS needs. Your preference for a tightly coupled
> power-ground plane bypassing system could lead to hi-frequency
> resonances. You might not have these problems, but it's important to do
> some kind of simulation or calculation to be sure. Remember, the
> frequency of your signals are not the issue, but the rise times are.

Yes, I said I have not analyzed a complex PDS myself.  But I have seen
it done by Lee Ritchey with very informative results.  Those results
are the basis of what I have been saying here.


...snip...
> > You also did not include any of the parasitic effects of how the
> > capacitors connect to their substrate. =A0In the case of the board
> > mounted caps, they will have vias connecting them to the power
> > planes. =A0In the case of the caps inside the package, they will also
> > have mounting parasitic effects, even if there are no vias.
>
> =A0>
> I guess you missed "L4 includes the vias"? I modeled the vias by lumping
> them into L4. Likewise L5 includes the 'on BGA' inductance.

Yes, I missed that.  I would like to know where you got your info.
Now that you have me interested in this, I would like to understand
what you have done.


> > But none of that really matters. =A0Your circuit is a very poor
> > representation of the real world.
>
> I can't believe you would slag off my beautifully created design!

Lol!


> > That is why it is so important to
> > verify results with real world measurements. =A0Your circuit has severa=
l
> > problems. =A0The first is that you only apply a single decoupling
> > capacitor to the board! =A0I may be an advocate of using fewer
> > decoupling capacitors, but I think one is pushing the envelope a bit
> > much. =A0If you gave a reference to finding a value for the inductance
> > of the connection between the power plane and the chip die, it must
> > have been in an earlier post.
>
> Right, as I said it's a crude model, but surely you see it demonstrates
> the point. I used one bypass cap, but I also used only one IOB, one BGA
> bypass cap, and one ground and power via on the device. This model is to
> show qualitative differences, and what general effects our design
> decisions have.

Qualitative is not very useful.  Everything has some effect on
everything.  What is important is how *much* of an effect.  There will
always be some ground and power noise.  It is only a problem when it
becomes significant in comparison to the noise margins.  Is that not
true?  By only using one of each item in the design an unrealistic
representation of the circuit you are trying to propose.  Clearly
there are a lot more than 1 board cap and via for each cap on the IC.
If I said the caps on the chip will have *no* effect, I did not mean
that.  I intended to say that they would have no significant effect in
the region of interest.

Also, without understanding how you came up with the values used in
your simulation, I have no way to trust it.


> > But most importantly, I am very sure that your model for how the
> > transients are generated is wrong. =A0You show the current path as bein=
g
> > from the FPGA power plane directly through the output series
> > resistance and back to the FPGA ground. =A0I am pretty sure that none o=
f
> > the traces on the board (the source of the capacitive load on the
> > output) directly connect to the FPGA ground.
>
> Right back at you Rick, you are wrong! Look at the datasheet for a
> modern Xilinx FPGA. I'm looking at DS312, Spartan3E. Look for Cin. That
> 10pF is there, ON THE DIE, because of the IOB's output FETs. This Spice
> model is a IOB switching without any attached signal. When the output
> switches, a 10pF capacitor has to be charged or discharged from the
> FPGA's PDS through the 20ohms or so output resistance. The model is just
> fine.

Why do you say it is "on the die"?  The value of Cin is largely from
the pin itself from what I have learned.  Perhaps I am wrong, but it
makes sense to me that the pin has more capacitance than the
transistor on the die, but I may not be right on that.  How can you
tell this capacitance is of the transistor and not the pin?


> > =A0You need to put that
> > connection to the board ground, and even then through another package
> > lead. =A0The model of using a signal generator to provide current surge=
s
> > may not be so good as well. =A0This results in currents being drawn
> > between the two FPGA planes. =A0Perhaps I am reading incorrectly that
> > the Vout is an I/O pin and you are only trying to model internal
> > switching transients. =A0The real issue that causes ground bounce (the
> > thing you seem to be most concerned about) is the current required to
> > charge and discharge the board trace and component pin on the other
> > end of that trace.
>
> Not with FPGAs. The Cin is so high, the effect of the rest of the trace
> isn't necessary to show my point.

I'm not at all clear on that.  The capacitance of the trace is very
significant.  If you said the trace and other IC pins shouldn't be
modeled as a lumped capacitance, I would agree that might be
significant, but to say it is not important at all is not obvious
without something to support that.


> > =A0This current will by necessity pass through the
> > two inductors (L1, L2) and will create a lot of bounce that is not
> > mitigated by the on chip capacitor(s).
>
> > Even if you are looking at the internal switching noise of the IC, you
> > need to model the *entire* PDS, not just one pin or one capacitor at a
> > time. =A0You also need to pick appropriate values for the various
> > components and include all parasitic effects. =A0If you can't do all of
> > that, or even if you can, a simulation doesn't mean squat if it isn't
> > complete.
>
> I must disagree here also. I think the model does give some insights
> into the issues that can arise. I'm not looking for accurate numbers,
> just qualitative comparisons between different methodologies.

Ok, then I agree that there will be some effect from the on chip
caps.  But I don't agree that they are useful in reducing ground
bounce from I/O switching.


> > The only way to know if it is complete for something as
> > complex as this is to take measurements of a real design.
>
> > Rick
>
> People can and do simulate entire PDS systems, sometimes using expensive
> CAD software like HSPICE or even HFSS =A0or ADS.
>
> Anyway, I've finished with this thread. I hope people reading it will
> take away that simulation is cheap and easy and can give good insights,
> even with a simplistic model. I hope I've scared a few people with
> 'power plane resonance' (google it!). I hope I've persuaded a few to
> route/pour their powers because you don't stand to gain much from
> tightly coupled planes, indeed you can have nasty problems from them,
> aside from the logistics of having many power supplies in a modern FPGA
> design. I hope I've persuaded a few to use more ground planes instead of
> power planes, and use their ground planes near to the surface and near
> their signal traces as it's harder to go wrong with this set up. Oh, and
> I hope that now you've downloaded the simulator, you'll get a lot of
> good use from it Rick. I hope you'll play around with some of the things
> you posted and see what effects they have. There's a mailing list for
> LTSpice, which is easy to find, that is useful for advice.
>
> Cheers, Syms.

Yes, I have used this simulator before.  But a simulation is only as
useful as the circuit being simulated.  If you try to simulate a
complex PDS without verifying it with measurement, you have no idea if
your simulation is correct.  I believe the "mailing list" is actually
a Yahoo group which is a *great* place to get excellent support.  I
forget the name of the LT person, but he answers every question he can
with patience and never chids no matter how many times that same
question has been answered.  It would appear that responding to that
group is his full time job at LT!

I will say that the Ritchey course is full of examples of designers
who follow rules of thumb without knowing why or that use an incorrect
analysis without ever verifying it with the real world.  There are
even examples of companies that went out of business because of
designers who did not completely understand why their circuits did not
work correctly.

Maybe I will perform this simulation the way I think it should be
done.  Then we will see if closely coupled power planes are pointless
or not...

Rick



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