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 126625

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

Wow, you got some strange answers! (IMHO, natch.) The same old chestnuts 
about PWR and GND planes being used as bypass capacitance. Waste of time. 
The tiny capacitance is no use to you as you have to attach the FPGA to it 
_VIA_ inductance. This is why FPGA companies embed bypass caps in the 
package. BTW, what PWR is on the plane? VCCO for your DDR bank? VCCINT?

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

Good answers you got are, 'use two more layers', 'simulate', 'SI-LIST', and 
'use as few vias as possible'. Oh, and don't cross gaps in planes, but we 
all know that, right?

I'd do something like this:-

sig
gnd
sig
sig
gnd
sig

I'd route the powers on one or two of the internal layers. I'd use copper 
pours and/or little puddles of cu for each supply. I'd use X2Y caps backside 
of the FPGA for bypassing. (Google X2Y FPGA) If a fast signal changes its 
ground reference from one ground plane to another, I'd put a GND via nearby. 
Several fast signals can share a single ground via.

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

HTH. Syms.

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



Article: 126626
Subject: Re: Global Reset using Global Buffer
From: Andrew FPGA <andrew.newsgroup@gmail.com>
Date: Wed, 28 Nov 2007 11:13:55 -0800 (PST)
Links: << >>  << T >>  << A >>
> IMHO the lack of reset circuitry is a serious flaw.

Bold statement :) More likely we don't know or understand their
reasons for not including it. Every new thing added has a cost. I can
guess at some reasons:
-global routing networks are expensive, clearly they are justified for
clocks, but reset?
-this is reconfigurable hardware so following power up the FPGA is put
into a known state following configuration - so is reset really
required?
-Reset can be coded into your design where needed. Providing resets on
the inputs and outputs, and waiting for the pipeline/intermediate
registers to flush gives the appearance of, and has the same effect as
a design wide reset.

Regards
Andrew

Article: 126627
Subject: Re: Global Reset using Global Buffer
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 28 Nov 2007 11:50:02 -0800
Links: << >>  << T >>  << A >>
Andrew FPGA wrote (in response to the inabilty to use global clock nets
to drive FF resets:
> Every new thing added has a cost. I can guess at some reasons:
> -global routing networks are expensive, clearly they are justified for
> clocks, but reset?

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

1)  Additional routing resources within the CLB to allow an existing
    global clock net to drive the FF reset

2)  Additional routing resources within the CLB to allow an existing
    global clock net to drive local lines, which could then be used
    for logic and/or to drive the FF reset

Apparently the Virtex 4 and 5 have done one of these, so the answer
is that the cost isn't too high to preclude doing it in high-end FPGAs.
Maybe the cost is too much for Spartan series FPGAs, or maybe it will
appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts
said we'd get in 2007.  Time's running out, guys!  :-)
    http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkproduct-Asia.html

Article: 126628
Subject: Re: CPU design uses too many slices
From: rickman <gnuarm@gmail.com>
Date: Wed, 28 Nov 2007 11:56:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 10:41 pm, J=FCrgen B=F6hm <jbo...@gmx.net> wrote:
> Jim Granville wrote:
>
> > You could download the Lattice Mico32, and reality check against that,
> > as that is open source.
> > Most FPGAs these days have multiport RAM, so it makes sense to optimise
> > your architecture to use that - in your case for registers, and maybe
> > even for micocode storage.
>
> Thank your for your answer:
>    Indeed I use RAMB16_S36 for microcode-storage, the final design will
> probably need four of them, as the microcode is more than 36 bit wide.
>   The idea from the other posters to change to Virtex FPGAs is currently
> not an option for me, as I really want to develop for the cheaper
> Spartan platform, for which a lot of affordable boards are offered - if
> necessary I will buy a board with the next larger Spartan 3 on it.

If you are trying to fit a given device, then you need to use the full
map and place portions of the tools as well.  Only then will you know
for sure that your design won't fit.  But what part is on your board?
You are using about 75% of available resources.  I can't say for sure
about your design, but ALU logic can be very light if designed
properly.  So the rest of your design may fit easily in the part.

I designed my own 16 bit CPU to have minimal size and it was about 500
LUTs, IIRC.  Like you, most of the logic was from muxes, so I kept
them as small as possible, even to the point of eliminating some
instructions.  Having an extra, unused select line makes them twice as
large.  BTW, any unused inputs will be optimized out by the tools.  So
if you don't connect the select input or data inputs, that logic will
not be generated.

Article: 126629
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "David Spencer" <davidmspencer@verizon.net>
Date: Wed, 28 Nov 2007 20:58:52 GMT
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fikd12$uf7$1@aioe.org...
> Wow, you got some strange answers! (IMHO, natch.) The same old chestnuts 
> about PWR and GND planes being used as bypass capacitance. Waste of time. 
> The tiny capacitance is no use to you as you have to attach the FPGA to it 
> _VIA_ inductance. This is why FPGA companies embed bypass caps in the 
> package. BTW, what PWR is on the plane? VCCO for your DDR bank? VCCINT?
>

I disagree, as does most of the research done into the subject. The use of 
buried capacitance, typically by having adjacent power and ground planes 
separated by as small a distance as possible (2 thou is normal), has been 
shown to be very favorable when compared to discrete decoupling caps because 
although the capacitance is much lower the inductance is very much lower so 
the overall impedence is significantly lower. There is an article about it 
here: http://www.ddmconsulting.com/Design_Guides/bcguide.pdf

The requirement for discrete capacitors on the BGA substrate itself is a 
different matter. That is to compensate for the inductance of the BGA ball 
and tracking and is necessary regardless of how the board level decoupling 
is implemented. 



Article: 126630
Subject: Quartus memory init file
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 29 Nov 2007 08:55:20 +1100
Links: << >>  << T >>  << A >>
Hi,

I've instantiated some quartus memory in VHDL using the init_file generic
to specify an intel hex file. This works great for 8-bit wide memory.

However, I can't work out how to initialise 16- or 32-bit wide memory
using this method!?!

Has anyone done it before?
Any tips would be greatly appreciated!

TIA
Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 126631
Subject: Re: FPGA Editor (9.2.03i) under Linux x86_64
From: rickman <gnuarm@gmail.com>
Date: Wed, 28 Nov 2007 14:06:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 26, 1:05 pm, <steve.l...@xilinx.com> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:d1662618-8529-41c6-a716-d83b5fc791ac@w28g2000hsf.googlegroups.com...> On Nov 20, 6:22 pm, <steve.l...@xilinx.com> wrote:
> >> A substantial amount of work is required for each appication when we
> >> move away from Wind/U. We have decided not to do that for FPGA
> >> Editor. Instead, we are creating a new application that is a combination
> >> of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be
> >> available in 11.1 (March 2009).
>
> >> Steve
>
> > I read that correctly as a year and a half from now, right?
>
> Yes. We plan to keep FPGA Editor around for a while so if there are
> issues, let us know. Hopefully the issue that started this thread is
> solved by the answer record provided.
>  That seems like a loooooong way off.  I remember once being told that
> > supporting partial reconfigurationon the Spartan devices was a few
> > months off and that Xilinx was committed to it.
>
> I don't remember a commitement on Spartan support. We have it working
> internally, but it's a very difficult flow and not something we are
> prepared to support. The big difference between Spartan and Virtex is
> that Spartan glitches when reconfigured. That means you need to isolate
> partial regions including IO, and static routes cannot cross parial
> regions. We are commited to Partial Reconfig for Virtex.

I dug around and found that the Xilinx web site seems to contradict
itself in regards to support for partial reconfiguration for Spartan 3
parts.  Although the "PlanAhead" web page lists several lines of
Spartan 3 parts as being supported by the PlanAhead software, I found
these comments in the "PlanAhead Software as a Platform for Partial
Reconfiguration" web page.

"Partial reconfiguration is supported in both the Virtex and Spartan(tm)
families. In this article, we will focus on implementing the partial
reconfiguration methodology as it applies to Virtex-II and Virtex-II
Pro FPGAs."

So they really do shy away from describing in any way, partial
reconfiguration for Spartan devices.  I guess I will stick with my
original belief that, for all practical purposes, in contradiction to
what the Xilinx web site says, partial reconfiguration is not
supported on Spartan devices.... still.

BTW, if you would like to see where I was told, more than once, that
Xilinx was committed to supporting partial reconfiguration on the
Spartan 3 parts, I can forward the emails to you.


Article: 126632
Subject: Re: CPU design uses too many slices
From: Jon Elson <elson@wustl.edu>
Date: Wed, 28 Nov 2007 16:13:36 -0600
Links: << >>  << T >>  << A >>


Jürgen Böhm wrote:
> Jon Elson wrote:
> 
>>
>>Yes, wide adders use a lot of LUTs.  Multiplexers use up LUTs too.  A
>>single 4-input LUT could form a single bit of a 2-input mux, wasting one
>>input.  If you need more inputs, then you have to combine several LUTs
>>to perform one bit's worth of multiplexer.
>>
> 
> 
> Currently I have predominantly three (5bit select) x (32bit data size)
> muxes with 16 alternatives select actually used (I overdimensioned the
> muxes, as I did not exactly knew before having written the microcode,
> how many inputs would be necessary). Are these muxes realized by
> cascaded LUTs, and does your above remark imply, that a 5-stages-deep
> chain of LUTs (1 stage for every select bit) will be used?
I think it probably does a little better than that.  Really, it breaks
it down into basic boolean equations, and then minimizes them.  So, it may
make much more efficient use than what you describe above, and it 
probably gets better the more inputs you have.  I think three LUTs can 
do a 4-input MUX, you can almost do it with 2 but are one input short.
If you had 5 separate select inputs (like if you were originally 
designing for 5 tri-state drivers on a bus) that might be less efficient 
than using a 3-bit binary address for the MUX.  But, if a binary address 
is decoded somewhere in your logic to the 5 select lines, that will all 
fall out in the logic minimization.

Jon


Article: 126633
Subject: Re: CPU design uses too many slices
From: Jon Elson <elson@wustl.edu>
Date: Wed, 28 Nov 2007 16:15:53 -0600
Links: << >>  << T >>  << A >>


Jürgen Böhm wrote:
>    Indeed I use RAMB16_S36 for microcode-storage, the final design will
> probably need four of them, as the microcode is more than 36 bit wide.
>   The idea from the other posters to change to Virtex FPGAs is currently
> not an option for me, as I really want to develop for the cheaper
> Spartan platform, for which a lot of affordable boards are offered - if
> necessary I will buy a board with the next larger Spartan 3 on it.
Yup, the low-cost Spartan was my choice for some designs, too, as I really
had no need for the special structures that the Virtex features.

Jon


Article: 126634
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: Jon Elson <elson@wustl.edu>
Date: Wed, 28 Nov 2007 16:24:33 -0600
Links: << >>  << T >>  << A >>


Nial Stewart wrote:
> Hopefully some of you guys who have gone through this can
> comment...
> 
> We're doing our first board with a couple of DDRs and have a
> query with ground plane coupling when routing the signals out
> of the FPGA.
> 
> We're hoping to get away with a 6 layer board so the stack is..
> 
> sig1
> GND
> sig2
> sig3
> PWR
> sig4
> 
I've had good results with :
sig1
sig2
GND
PWR
sig3
sig4

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

Jon


Article: 126635
Subject: Re: CPU design uses too many slices
From: Eric Smith <eric@brouhaha.com>
Date: Wed, 28 Nov 2007 14:33:30 -0800
Links: << >>  << T >>  << A >>
Jürgen Böhm wrote:
>    Indeed I use RAMB16_S36 for microcode-storage, the final design will
> probably need four of them, as the microcode is more than 36 bit wide.

You can use a single BRAM as a 72-bit wide single-ported RAM, if you only
need half the "depth".  For instance, normally the maximum width of a
Spartan 3 BRAM would be 512x36, but you can combine the two ports to get
256x72.

Obviously if you need greater depth or dual-port this won't help you.

Eric

Article: 126636
Subject: Re: Quartus memory init file
From: MikeShepherd564@btinternet.com
Date: Wed, 28 Nov 2007 23:13:21 +0000
Links: << >>  << T >>  << A >>
>I've instantiated some quartus memory in VHDL using the init_file generic
>to specify an intel hex file. This works great for 8-bit wide memory.
>
>However, I can't work out how to initialise 16- or 32-bit wide memory
>using this method!?!



Here is an example of a .MIF (not Intel hex) file which initialises
36-bit wide memory:


Width         = 36;
Address_radix = Hex;
Data_radix    = Hex;

% Character shapes %
Content
BEGIN
0000 :  000000000;
0001 :  000000000;
0002 :  000000000;
  :
  :  (bulk of this file omitted)
  :
01F6 :  0600C00C0;
01F7 :  380000000;
01F8 :  0000001E2;
01F9 :  37623C000;
01FA :  000000000;
01FB :  000000000;
01FC :  000000000;
01FD :  000000000;
01FE :  000000000;
01FF :  000000000;
END;

Article: 126637
Subject: Re: Quartus memory init file
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 29 Nov 2007 11:07:02 +1100
Links: << >>  << T >>  << A >>
MikeShepherd564@btinternet.com wrote:

> Here is an example of a .MIF (not Intel hex) file which initialises
> 36-bit wide memory:

Thanks Mike, but I want to use intel hex, not MIF, mainly because the
intel hex can be used for both synthesis and simulation in ModelSim.

I think I've found the answer anyway. For now I create an 8-bit wide intel
hex file, then open the hex file in Quartus and use the memory size wizard
to change it to 32 bits, then re-save the file. I'm yet to confirm it
produces the results I expect, but at least it builds now...

Since I use my own utility to create intel hex files in the first place,
I'll simply modify it to produce the same output as Quartus...

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 126638
Subject: Re: What's the difference for VHDL code between simulation and synthesis?
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 29 Nov 2007 00:28:42 GMT
Links: << >>  << T >>  << A >>

"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote in 
message 
news:78b49268-a7ec-409c-b5c0-c61003164231@n20g2000hsh.googlegroups.com...
> On Nov 27, 9:43 pm, fl <rxjw...@gmail.com> wrote:
> - Code that's just _not_ syntesizable :
>
> process
> begin
> wait until reset='0';
> wait for 3 ns;
> sig <= '1';
> end process;
>
The only reason the above code could be considered 'just _not_ syntesizable' 
is because the behaviour of 'sig' prior to getting to where it is assigned 
has not been defined and is a design error that one would fix while still in 
simulation.

But given that code, if the synthesizer wants to assume that 'sig' defaults 
to 1 then it would synthesize to 'sig' always being '1'.  If instead it 
assumed that 'sig' defaults to '0' then it is again synthesizable with an 
inverter and a 3 ns delay line.  If market pressure causes the FPGA 
suppliers to start adding delay lines to their parts then the above code can 
be targeted to one of those devices, if not it can still be implemented with 
commercially availabe parts so it is not 'just _not_ syntesizable' it's just 
not supported by FPGA software at this time....but there are a whole slew of 
things that are not supported, and those are typically 
bugs/limitations/whatever with the software that result in web cases to the 
support lines when I run across them.  The end result of that is they 
improve their tool.  Things like delay lines would be added as functional 
blocks when (if) there is sufficient market demand for that function.

> - Code that may / may not be (i.e. if the synthesizer was smart, he
> could do it ... but it might not be )
>
> a <= b / c;
>
Again, an example not of unsynthesizable code but of perfectly valid and 
synthesizable code that a particular supplier may not support for their own 
various reasons.

> VHDL is a hardware description language. Meaning that you should _not_
> use it to describe what you want the hardware to do. But you should
> use it to describe the hardware you want built.
I want the tools to figure out the proper bitstream that needs to be loaded 
into a part so that a vast array of RAM look up tables, transistors and flip 
flops inside that device will implement what I want it to do.  In order to 
do that I describe functionally what I want the hardware to do, I definitely 
do not describe the hardware that I want built (i.e. the look up table 
contents, transistor on/off states, etc....and I doubt I'm alone in that 
regard).

KJ 



Article: 126639
Subject: Re: Xilinx XChecker cable supported until which version?
From: Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m>
Date: Wed, 28 Nov 2007 17:18:00 -0800
Links: << >>  << T >>  << A >>
xchecker was obsoleted in release 4.1i

The last software version that supported xchecker was release 3.3i 
(about 8 years ago)

Florian wrote:
> Hi
> 
> I have Xilinx ISE 7.1 and wanted to use the Xilinx XChecker cable to 
> connect to the JTAG interface. Unfortuantely this does not work when I 
> use autoconnect. When I try to manually configure the connection I cant
> choose the XChecker cable. Is this not supported any more with ISE 7.1?
> 
> Cheers!

Article: 126640
Subject: Re: I/O short circuit protection?
From: posedge52@yahoo.com
Date: Wed, 28 Nov 2007 18:14:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 28, 3:16 pm, John_H <newsgr...@johnhandwork.com> wrote:
> posedg...@yahoo.com wrote:

> Are you designing a board with a production run of three that you'll be
> assembling with the toaster-oven technique?
>
> If you're using a professional assembly house, there is post-assembly
> testing that will test for shorts.  If you have a production run too
> small for a bed-of-nails tester, there are still flying-lead
> manufacturing defect analyzers that can check your board for shorts.
>
> Why design in "protection" that limits your signal characteristics when
> all you're protecting from is manufacturing faults?  If you were cycling
> connecting the FPGA in and out of a connector over and over to varying
> equipment, I could understand some concern.  But for soldered-on chips?

It's for a test setup, where I will test different fpga <-> device
setups. No production run at all, not even a prototype one.
I have bought a 100 ohm series resistor net package. Which will limit
any shorts to 33mA. And I think the rise times will be ok with this. t
= RC = 100*10pF (worst case Sp3E) = 1ns. The sp3e datasheet says max
100mA, I hope this will protect the fpga for those minutes it takes to
test the setup.


Article: 126641
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: Didi <diditgi@gmail.com>
Date: Wed, 28 Nov 2007 18:33:26 -0800 (PST)
Links: << >>  << T >>  << A >>
> We're aiming to run the interface at ~2* 120MHz.

I understand that as 120 MHz clock, 240 MHz data rate
during bursts.
Recently I had a similar case - processor (not FPGA),
which is in a 256 ball FPGA, 133 MHz clock/266 MHz data burst
rate.
 However, I was much more conservatiive with my stackup.
Instead of your

> sig1
> GND
> sig2
> sig3
> PWR
> sig4

I did 6 layers as well, but my stackup is:

signal
GND
PWR
PWR
GND
signal

Worked the first time, actually see the prototype
(very first one assembled, design for an external customer)
board here:

http://tgi-sci.com/y2demo/PICT3007sc.JPG .

The two DDRAMs (x16 each) are close to the board centre, easy
to spot.

Here is the bare board in some better detail:

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

The board is routed at 6 mil most of the time which goes
down to somewhat over 4 mil for the worst case angular
ring and for traces between BGA pads (3 traces between a
pair of 1.27mm spaced pads/vias.
 Have used these rules on other boards as well, have never
failed me. Routing takes somewhat more head scratching (or is
it hear teraing... :-) ), but has always been doable.
 Now what do I do with a 0.8mm BGA (soon to be routed here,
never done so far) is yet to be seen... :-)

At these low speeds, buying signal integrity tools/consultants
will be a sheer waste. You need neither (although ask that on
the SI list and you will be overwhelmed by suggestions to
buy all things imaginable... make sure to ignore such advice,
the SI tool writers and SI consultants are pretty active on that
list).
Buy a tool by the usual criterion, that is, only if you know
exactly what you want the tool to do for you and if you
understand how it will do it.
 Buying a software blindly expecting it to solve your problems
will typically result in more, not less problems. Which does
not mean most people nowadays are not doing exactly that,
of course :-).

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

Dimiter

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

http://www.tgi-sci.com
------------------------------------------------------

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


Article: 126642
Subject: Re: FPGA not in boundary scan
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 29 Nov 2007 02:41:29 GMT
Links: << >>  << T >>  << A >>
Mike wrote:
> Hi
> 
> I am using Impact and Xilinx Multilinx cable to communicate to my FPGA 
> board. I was able that the connection to the board is established, but
> somehow I just see a CPLD instead of a Virtex II FPGA board. Anyone an 
> idea how to have access to the FPGA that is hosted on the board?
> 
> Cheers

Connect your cable to the JTAG chain that the FPGA is hooked up to.

You couldn't be much more vague.  Whether it's a development board or 
your own board, you should be able to find schematics.  These schematics 
may show the JTAG pins of the FPGA (TDI, TDO, TCLK, TRST or similar 
names) either unconnected or connected to a specific JTAG connector or 
JTAG chain.  If you can identify which chain, you're on your way.  If 
you are connected to the correct chain and you don't see the device, 
there's something wrong on the application side (not configuring things 
properly?) rather than the hardware side.

- John_H

Article: 126643
Subject: Re: Quartus memory init file
From: John Rible <news@sandpipers.com>
Date: Wed, 28 Nov 2007 18:41:33 -0800
Links: << >>  << T >>  << A >>
Mark McDougall wrote:
> MikeShepherd564@btinternet.com wrote:
> 
>> Here is an example of a .MIF (not Intel hex) file which initialises
>> 36-bit wide memory:
> 
> Thanks Mike, but I want to use intel hex, not MIF, mainly because the
> intel hex can be used for both synthesis and simulation in ModelSim.
> 
> I think I've found the answer anyway. For now I create an 8-bit wide intel
> hex file, then open the hex file in Quartus and use the memory size wizard
> to change it to 32 bits, then re-save the file. I'm yet to confirm it
> produces the results I expect, but at least it builds now...
> 
> Since I use my own utility to create intel hex files in the first place,
> I'll simply modify it to produce the same output as Quartus...
> 
> Regards,
> 
Mark-

I've used 8-, 16-, 24-, and 32-bit wide Intel hex files with Quartus. 
The general format is (spaces for readability--not in file):
	- -- ----  --  ~~  --  --  --
	: nn addr  00  **  cs <cr><lf>	\ data records 
	: 00 0000  01      ff <cr><lf>	\ end record
	- -- ----  --  ~~  --  --  --
where 
nn     = number of data bytes in memory word
addr   = 16-bit memory address
00, 01 = record type
**     = nn data bytes
cs     = 100h - (byte.sum mod 256)

The tools will complain if you don't initialize more OR less than the full memory.

-John


Article: 126644
Subject: ISE WARNING Xst:647
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 29 Nov 2007 14:36:06 +1100
Links: << >>  << T >>  << A >>
Hi,

I have a design that works fine in Quartus.

In the process of porting it to ISE, I'm getting a series of these
warnings and can't for the life of me work out why...

An example:
WARNING:Xst:647 - Input <vblank> is never used.

But it clearly _is_ being used!?! Same for all the other signals that it's
complaining about.

Normally I'd suspect a missing clock but that doesn't appear to be the
case. (For the record the clock for this process isn't actually meeting
all timing constraints at the moment.)

Any tips would be appreciated - it's driving me (more) insane!
Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 126645
Subject: Re: Quartus memory init file
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 29 Nov 2007 14:41:34 +1100
Links: << >>  << T >>  << A >>
John Rible wrote:

> I've used 8-, 16-, 24-, and 32-bit wide Intel hex files with Quartus.
> The general format is (spaces for readability--not in file):
>     - -- ----  --  ~~  --  --  --
>     : nn addr  00  **  cs <cr><lf>    \ data records     : 00 0000 
> 01      ff <cr><lf>    \ end record
>     - -- ----  --  ~~  --  --  --
> where nn     = number of data bytes in memory word
> addr   = 16-bit memory address
> 00, 01 = record type
> **     = nn data bytes
> cs     = 100h - (byte.sum mod 256)
> 
> The tools will complain if you don't initialize more OR less than the
> full memory.

The format I've been using for 8-bit data is 16 bytes/record. I tried all
sorts of permutations of that for 32-bit wide memory some time back but
never got it to work. In the end I settled for 4x 8-bit memory blocks. Now
it's time to fix it properly.

Using Quartus to re-size my 8-bit intel hex file did the trick. It
basically spat out 1 word/line in the format you specify above.

FYI it does let you initialise *less* than the full block, as long as the
word size is correct...

BTW I wish Xilinx memories were as easy to specify and initialise as
Quartus... I'm porting some projects and it's a real PITA!

Thanks for your assistance!
Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 126646
Subject: Interfacing Cyclone III to 3.3v LVDS devices
From: "liqiyue@gmail.com" <liqiyue@gmail.com>
Date: Wed, 28 Nov 2007 19:46:01 -0800 (PST)
Links: << >>  << T >>  << A >>
How can i interface the cyclone III with 2.5v LVDS to 3.3v LVDS adc &
dac ?

Thanks

Article: 126647
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: Didi <diditgi@gmail.com>
Date: Wed, 28 Nov 2007 20:14:10 -0800 (PST)
Links: << >>  << T >>  << A >>
>  Have used these rules on other boards as well, have never
> failed me. Routing takes somewhat more head scratching (or is
> it hear teraing... :-) )

Sorry for the typos above, it should read
"or is it hair tearing"...

On Nov 29, 4:33 am, Didi <didi...@gmail.com> wrote:
> > We're aiming to run the interface at ~2* 120MHz.
>
> I understand that as 120 MHz clock, 240 MHz data rate
> during bursts.
> Recently I had a similar case - processor (not FPGA),
> which is in a 256 ball FPGA, 133 MHz clock/266 MHz data burst
> rate.
>  However, I was much more conservatiive with my stackup.
> Instead of your
>
> > sig1
> > GND
> > sig2
> > sig3
> > PWR
> > sig4
>
> I did 6 layers as well, but my stackup is:
>
> signal
> GND
> PWR
> PWR
> GND
> signal
>
> Worked the first time, actually see the prototype
> (very first one assembled, design for an external customer)
> board here:
>
> http://tgi-sci.com/y2demo/PICT3007sc.JPG.
>
> The two DDRAMs (x16 each) are close to the board centre, easy
> to spot.
>
> Here is the bare board in some better detail:
>
> http://tgi-sci.com/misc/PICT0605.JPG.
>
> The board is routed at 6 mil most of the time which goes
> down to somewhat over 4 mil for the worst case angular
> ring and for traces between BGA pads (3 traces between a
> pair of 1.27mm spaced pads/vias.
>  Have used these rules on other boards as well, have never
> failed me. Routing takes somewhat more head scratching (or is
> it hear teraing... :-) ), but has always been doable.
>  Now what do I do with a 0.8mm BGA (soon to be routed here,
> never done so far) is yet to be seen... :-)
>
> At these low speeds, buying signal integrity tools/consultants
> will be a sheer waste. You need neither (although ask that on
> the SI list and you will be overwhelmed by suggestions to
> buy all things imaginable... make sure to ignore such advice,
> the SI tool writers and SI consultants are pretty active on that
> list).
> Buy a tool by the usual criterion, that is, only if you know
> exactly what you want the tool to do for you and if you
> understand how it will do it.
>  Buying a software blindly expecting it to solve your problems
> will typically result in more, not less problems. Which does
> not mean most people nowadays are not doing exactly that,
> of course :-).
>
>  Again, 120 MHz is nearly DC nowadays. You don't need any
> fancy SI tools to do it.
>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------
>
> On Nov 28, 12:06 pm, "Nial Stewart"
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > Hopefully some of you guys who have gone through this can
> > comment...
>
> > We're doing our first board with a couple of DDRs and have a
> > query with ground plane coupling when routing the signals out
> > of the FPGA.
>
> > We're hoping to get away with a 6 layer board so the stack is..
>
> > sig1
> > GND
> > sig2
> > sig3
> > PWR
> > sig4
>
> > Any signals that're routed from the FPBA ball to sig4 won't have
> > the same good GND return paths to the FPGA that those coming out
> > on sig1/sig2 will have.
>
> > We're aiming to run the interface at ~2* 120MHz.
>
> > We don't have any simulation tools so are having to design using best
> > practice.
>
> > We can place a GND island in on the PWR layer under the FPGA/DDR
> > with plenty of vias stitching it up to the 'real' GND plane, but
> > this will make the PWR routing more difficult.
>
> > Does this matter, will the difference in GND coupling be a problem?
>
> > Some of the app notes we've read suggest that the track impedance
> > isn't too much of a problem.
>
> > Thanks for any pointers,
>
> > Nial


Article: 126648
Subject: Re: An error occured while using Dual Port Block Memory
From: RAI <spygame81@gmail.com>
Date: Wed, 28 Nov 2007 20:32:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 21, 4:55 am, Joseph Samson <u...@not.my.company> wrote:
> spygam...@gmail.com wrote:
> > Hi!
>
> > I am using Dual Port Block Memory in Virtex-II, V8.2. During
> > simulation in Modelsim, i have encountered an error that reports to me
> > is:
>
> > $recovery(posedge clk B: .... ps, posedge clk A &&&
> > collision_posa_posb: ... ns, 1ns);
>
> > How can i cater this issue and how can i remove this error in my
> > simulation???
>
> What have you tried and and why didn't it work?
>
> Here's what I did:
>
> 1. Google "verilog $recovery"
>
> 2. Read the first citation
> <http://toolbox.xilinx.com/docsan/xilinx5/data/docs/sim/sim0066_10.html>
>
> ---
> Joe Samson
> Pixel Velocity

hi sir!

thnx for your anticipation...........i am using dual port memory to
receive data from camera and pass it onto DSP..........and during
simulation in ModelSim there is an error like:

# ** Error :C:/Xilinx/Verilog/mti_se/XilinxCoreLib_ver/
XilinxCoreLib_ver_source.v(27060):$recovery(posedge clk B: .... ps,
posedge clk A &&& collision_posa_posb: ... ns, 1ns);
# Time ... ps Iteration : 2 Instance/tb/dsp_inst0/memory_dp_inst0/inst

and thats error repeated after every some time period delay and
remained at the end of simulation...........plz guide me how can i get
through from this error???

Regards


Article: 126649
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 28 Nov 2007 22:16:26 -0800
Links: << >>  << T >>  << A >>
On Wed, 28 Nov 2007 10:06:22 -0000, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:

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

As Jon suggests, putting power and ground adjacent is generally a bit
better.

But either stackup will work fine. As long as the power plane (or its
split pours) is pretty well bypassed to ground, the signals can't tell
the difference between them or ground as the "return" plane. If power
and ground are adjacent layers, the increased plane-plane capacitance
keeps them a bit more equipotential at very high frequencies.

Don't worry about signals crossing small slits on a split power plane;
that is simply not an issue in real life. You can barely resolve
crossings like that on a 20 GHz TDR... it's down in the wiggles caused
by the fiberglass weave.

We've done pretty hairy stuff with Xilinx bga's on 6 layers, with no
signal integrity problems.

The thing to watch out for is signal-signal crosstalk, especially on
clock lines. Clocks need especially serious signal integrity treatment
these days. And "clocks" includes CCLK!

I suppose I could post some layer pics...


John






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