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 126675

Article: 126675
Subject: Re: lossless compression in hardware: what to do in case of uncompressibility?
From: Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat>
Date: Thu, 29 Nov 2007 09:48:10 -0500
Links: << >>  << T >>  << A >>
On Thu, 29 Nov 2007 15:42:45 +0100, "Denkedran Joe"
<denkedranjoe@googlemail.com> wrote:

>Hi all,
>
>I'm working on a hardware implementation (FPGA) of a lossless compression 
>algorithm for a real-time application. The data will be fed in to the 
>system, will then be compressed on-the-fly and then transmitted further.
>
>The average compression ratio is 3:1, so I'm gonna use some FIFOs of a 
>certain size and start reading data out of the FIFO after a fixed 
>startup-time. The readout rate will be 1/3 of the input data rate The size 
>of the FIFOs is determined by the experimental variance of the mean 
>compression ratio. Nonetheless there are possible circumstances in which no 
>compression can be achieved. Since the overall system does not support 
>variable bitrates a faster transmission is no solution here.
>
>So my idea was to put the question to all of you what to do in case of 
>uncompressibility? Any ideas?
>
>Denkedran Joe 

Given the constraints you have put on the problem, you're kinda left
with reducing the incoming data rate or dropping packets. 

Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Article: 126676
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 29 Nov 2007 06:51:29 -0800
Links: << >>  << T >>  << A >>
On Thu, 29 Nov 2007 09:44:37 -0000, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:

>> The thing to watch out for is signal-signal crosstalk, especially on
>> clock lines. Clocks need especially serious signal integrity treatment
>> these days. And "clocks" includes CCLK!
>
>
>We've been following one of the Micron app notes here, especially wrt
>the clocks. It's a fairly short pt to pt connection so hopefully we
>should be OK.
>
>Thanks,
>
>Nial. 
>

We've found that a lot of cheap surface-mount crystal oscillators have
a combination of sub-ns rise time and weak drive. So if they drive a
few inches or more of trace, their output step can have a plateau
right in the ballpark of Vcc/2, which is like hanging out a welcome
sign for noise. The fpga clock inputs are very fast and have little or
no hysteresis, so a tiny amount of crosstalk noise can result in
multiple clockings on either edge.

CCLK can be a problem, too; we often buffer it with a Tiny Logic
schmitt right at the fpga, especially if it's a shared SPI clock that
goes everywhere.

John


Article: 126677
Subject: Re: lossless compression in hardware: what to do in case of
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 29 Nov 2007 06:58:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 8:42 am, "Denkedran Joe" <denkedran...@googlemail.com>
wrote:
> Hi all,
>
> I'm working on a hardware implementation (FPGA) of a lossless compression
> algorithm for a real-time application. The data will be fed in to the
> system, will then be compressed on-the-fly and then transmitted further.
>
> The average compression ratio is 3:1, so I'm gonna use some FIFOs of a
> certain size and start reading data out of the FIFO after a fixed
> startup-time. The readout rate will be 1/3 of the input data rate The size
> of the FIFOs is determined by the experimental variance of the mean
> compression ratio. Nonetheless there are possible circumstances in which no
> compression can be achieved. Since the overall system does not support
> variable bitrates a faster transmission is no solution here.
>
> So my idea was to put the question to all of you what to do in case of
> uncompressibility? Any ideas?
>
> Denkedran Joe

If the compression must be lossless, and you can not increase the bit
rate, you need to allow for the buffering of the input data to grow in
size to accommodate the worst case.  If you can not build a big enough
FIFO inside the FPGA, add some external memory and use it as a FIFO.


Is the hardware already designed? What are your data rates, and do you
know what the worst case compression is?

Regards,

John McCaskill
www.fastertechnology.com

Article: 126678
Subject: Re: lossless compression in hardware: what to do in case of
From: CBFalconer <cbfalconer@yahoo.com>
Date: Thu, 29 Nov 2007 10:16:43 -0500
Links: << >>  << T >>  << A >>
Denkedran Joe wrote:
> 
> I'm working on a hardware implementation (FPGA) of a lossless
> compression algorithm for a real-time application. The data will
> be fed in to the system, will then be compressed on-the-fly and
> then transmitted further.
> 
> The average compression ratio is 3:1, so I'm gonna use some FIFOs
> of a certain size and start reading data out of the FIFO after a
> fixed startup-time. The readout rate will be 1/3 of the input
> data rate The size of the FIFOs is determined by the experimental
> variance of the mean compression ratio. Nonetheless there are
> possible circumstances in which no compression can be achieved.
> Since the overall system does not support variable bitrates a
> faster transmission is no solution here.
> 
> So my idea was to put the question to all of you what to do in
> case of uncompressibility? Any ideas?

Bigger buffers.  Smarter algos.

-- 
 Chuck F (cbfalconer at maineline dot net)
   <http://cbfalconer.home.att.net>
   Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com


Article: 126679
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "David Spencer" <davidmspencer@verizon.net>
Date: Thu, 29 Nov 2007 15:36:04 GMT
Links: << >>  << T >>  << A >>
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:5r7esrF12d91kU1@mid.individual.net...
>> I would never split a plane except as a last resort (unless you can 
>> sandwich it between two solid planes - I often use a four layer GND, 
>> split power, split power, GND sandwich in the middle of 16-20 layer 
>> boards), because of the issues with traces crossing the split.
>
> As you say below signals can use the PWR plane as a 'pseudo gnd'.
>
> By using this stack are you not loosing the ability to route two internal
> signal layers adjacent to the GND planes, and the additional use of the
> PWR planes as pseudo grounds?
>
> Nial.
>
No, because everything is referenced to ground. My favorite stackups are:

12-layer    S, G, S, S, G, P, P, G, S, S, G, S
14-layer microvia    S, S, G, S, S, G, P, P, G, S, S, G, S, S
18-layer    S, G, S, S, G, S, S, G, P, P, G, S, S, G, S, S, G, S
20-layer microvia    S, S, G, S, S, G, S, S, G, P, P, G, S, S, G, S, S, G, 
S, S

S = Signal, G = Ground, P = Power.
Microvias are laser-drilled vias going from the outside down just one 
layer - makes double-sided fan-out on high density boards much easier.

The advantages of these stackups are:
1. All signal layers are referenced to a real ground plane.
2. For normal board thicknesses (1.6 - 2.5 mm) it is easy to get 50-ohm 
single-ended and 100-ohm differential impedance on the inner signal layers 
with 4 mil track and gap (the outers give you about 42 ohms with 5 mil 
traces).
3. You can use ZBC cores on the innermost power stack up achieve buried 
capacitance decoupling.
4. You can split the power planes as much as you like without having to 
worry about signal integrity, because the splits are caged.
5. You can adjust the thickness of the board by changing the prepreg between 
the two power layers without having any real effect on the electrical 
characteristics.

The possible disadvantages are:
1. The via length down to the power planes will be longer than had the 
planes been closer to the surface, but this is unlikely to cause a problem.
2. The board cost in increased somewhat over a six or eight layer one, but 
not by as much as you might think.



Article: 126680
Subject: EDK IPIF development workflow
From: Anton Kowalski <AntonKowalski@gmail.com>
Date: Thu, 29 Nov 2007 07:38:18 -0800 (PST)
Links: << >>  << T >>  << A >>
I am new to EDK (but not ISE) and have some questions about the
workflow for developing a custom IPIF peripheral.

The documentation implies that the peripheral is re-imported into EDK
once it's development is *complete*. But what if one wants to work
iteratively? That is, I would like to start with a stubbed-out design
(the one provided in user_logic.vhd) and add to it incrementally,
debugging and testing the peripheral from the processor along the way.
Is there a simple way to do this? Or does one have to re-import the
design every time a internal structural change is made? (The external
specification will remain the same.)

Thanks,
Anton

Article: 126681
Subject: Re: Cascaded DCMs with variable phase shift (Xilinx)
From: austin <austin@xilinx.com>
Date: Thu, 29 Nov 2007 07:46:28 -0800
Links: << >>  << T >>  << A >>
chesi,

I am looking into this now.

My concern is that feeding a phase shifted clock out of one DCM into
another that is set to multiply by ten (10) may not work (I never
simulated that case).  Not sure what the second DCM will do while the
input clock is changing phase (it might lose lock).

I am presuming that your problem is not with the second DCM, but with
the first one?  It does not perform the negative phase shifts between 20
and 28 counts?

At 27 MHz, that is a 37 ns period, so each count is 27,000/256 =~ 105
ps.  Given that there is a finite number of delay taps, I believe the
lower frequency limit is 19 MHz, there should be no reason you are
running out of taps (and the status register would indicate overflow or
underflow, and you would lose lock).

I will discuss this, and post again.

Austin

Article: 126682
Subject: Re: lossless compression in hardware: what to do in case of uncompressibility?
From: "Denkedran Joe" <denkedranjoe@googlemail.com>
Date: Thu, 29 Nov 2007 16:59:24 +0100
Links: << >>  << T >>  << A >>
"CBFalconer" <cbfalconer@yahoo.com> wrote:
>
> Bigger buffers.  Smarter algos.
>

Ah okay, now that's why I'm here! Let's discuss some ideas of smarter algos! 



Article: 126683
Subject: Re: EDK IPIF development workflow
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 29 Nov 2007 08:28:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 9:38 am, Anton Kowalski <AntonKowal...@gmail.com> wrote:
> I am new to EDK (but not ISE) and have some questions about the
> workflow for developing a custom IPIF peripheral.
>
> The documentation implies that the peripheral is re-imported into EDK
> once it's development is *complete*. But what if one wants to work
> iteratively? That is, I would like to start with a stubbed-out design
> (the one provided in user_logic.vhd) and add to it incrementally,
> debugging and testing the peripheral from the processor along the way.
> Is there a simple way to do this? Or does one have to re-import the
> design every time a internal structural change is made? (The external
> specification will remain the same.)
>
> Thanks,
> Anton

In the MPD file for your peripheral, add the line:

OPTION CORE_STATE = DEVELOPMENT

This will cause EDK to not cache the synthesis results for your
peripheral.  For simulation, I just use the clean option, then
regenerate the simulation files if I change the peripheral.  If you
are not changing the data files (MPD, TCL, etc), you do not need to
rescan the repository.

If you are creating your own peripheral in EDK, you will want to read
the "Platform Specification Format Reference Manual" located at $EDK/
doc/psf_rm.pdf

Regards,

John McCaskill
www.fastertechnology.com



Article: 126684
Subject: Re: lossless compression in hardware: what to do in case of uncompressibility?
From: MikeShepherd564@btinternet.com
Date: Thu, 29 Nov 2007 16:33:47 +0000
Links: << >>  << T >>  << A >>
>> Bigger buffers.  Smarter algos

>Ah okay, now that's why I'm here! Let's discuss some ideas of smarter algos! 

Let's not.

Instead, start here and study for a few weeks, then get back to us:

http://en.wikipedia.org/wiki/Lossless_data_compression

Article: 126685
Subject: Re: Asynchronous FIFO and almost empty - bug?
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 29 Nov 2007 08:35:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 3:46 am, "heinerl...@googlemail.com"
<heinerl...@googlemail.com> wrote:
> Hi,
>
> we are using an asynchronous FIFO to bridge two clock domains. Both
> domains have "the same" clock speed but different clock oscillators.
>
> We shift data phits in the FIFO which always form a data packet. In
> between a packet data is shifted in continously without a break.
> Breaks (no shift in) are only allowed in between packets.
> On the output side of the FIFO we need a steady data stream during a
> data packet. The packet may not be interrupted. As the input side may
> be slower we start shift-out data if at least two data phits are in
> the FIFO. As the 2 clocks have almost the same frequency this
> guarantees that we never have a buffer underflow.
>
> The problem we found is that the almost empty flag is only asserted if
> the FIFO is beeing emptied and not if it is beeing filled. So if the
> FIFO was empty and we get a shift in the almost empty is not asserted
> although we set the treshold to one. Is this a bug?
Which FPGA family, which type of FIFO controller, and also what clock
rate?
Peter Alfke, Xilinx Applications>


> We tried to solve that problem by generating a delay-empty signal at
> the output which guarantees that if the FIFO was emtpy and than
> receives a shift in we still wait another cycle so we get another
> shift in to avoid underflow.
>
> This solution however does not solve the problem if the FIFO exactly
> had one entry when starting to shift out a packet. In this case
> neither delayed-empty nor almost empty is asserted, hence we get an
> underflow.
>
> Why isn't the almost empty signal asserted every time there is a
> single packet in the FIFO? Ideas?


Article: 126686
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "David Spencer" <davidmspencer@verizon.net>
Date: Thu, 29 Nov 2007 16:41:30 GMT
Links: << >>  << T >>  << A >>

"Didi" <diditgi@gmail.com> wrote in message 
news:0fb44a5a-ceba-4643-87ad-4ea2f1ed60f2@a39g2000pre.googlegroups.com...
>
> Again, 120 MHz is nearly DC nowadays. You don't need any
> fancy SI tools to do it.
>
> Dimiter
>
>
It's not the frequency that matters, but rather the edge rate. It is the 
behavior of the edges that are altered by the characteristics of a 
transmission line. The frequency just indicates how often such edges occur. 
This is why many older designs fail when a manufacturer introduces a faster, 
die-shrunk, version of a part. Although the application is using the part in 
the same way, the unavoidable change in edge rate can break a previously 
working board. 



Article: 126687
Subject: Re: lossless compression in hardware: what to do in case of
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 29 Nov 2007 08:48:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 6:42 am, "Denkedran Joe" <denkedran...@googlemail.com>
wrote:
> Hi all,
>
> I'm working on a hardware implementation (FPGA) of a lossless compression
> algorithm for a real-time application. The data will be fed in to the
> system, will then be compressed on-the-fly and then transmitted further.
>
> The average compression ratio is 3:1, so I'm gonna use some FIFOs of a
> certain size and start reading data out of the FIFO after a fixed
> startup-time. The readout rate will be 1/3 of the input data rate The size
> of the FIFOs is determined by the experimental variance of the mean
> compression ratio. Nonetheless there are possible circumstances in which no
> compression can be achieved. Since the overall system does not support
> variable bitrates a faster transmission is no solution here.
>
> So my idea was to put the question to all of you what to do in case of
> uncompressibility? Any ideas?
>
> Denkedran Joe

You cannot solve your problem losslessly.  You must guarantee your
image is in a state that will guarantee compressibility or your stream
will occasionally require more bandwidth than is available; you'd need
infinite FIFOs to cover worst-case situations.

You MUST have a lossy fallback OR supply enough bandwidth to
accommodate uncompressed data as a fallback.  Variable bit-rate multi-
channel systems can borrow bandwidth from each other since -
statistically - all channels do not experience poor compression at
once unless they're all transmitting similarly uncompressible images.

If your video is dynamic in movement and in color for a length of
time, your stream will exceed your channel bandwidth.  If you have
very large (disk based?) FIFOs, you can drop video for a short time
and pick back up when the compressed stream is better behaved and you
can receive continuous video again.  You will not be able to recover
the delay that you introduced from the compression on the receive side
unless you skip some received video (which is lossy) or speed up the
playback.  Can you deal with a fixed delay of seconds or minutes once
you've experienced a period of poor compression?

No lossless compression scheme can compress everything.  You can only
have better compression schemes that will fail less often or present a
fallback: lossy compression or variable bit rates.

There are no finite alternatives; it's one of the basic principles of
compression.  There are no smarter algos, just better compression
schemes that fail less often.

- John_H

Article: 126688
Subject: Re: FPGA not in boundary scan
From: Mike <Mike@yahoo.co.uk>
Date: Thu, 29 Nov 2007 16:52:43 +0000
Links: << >>  << T >>  << A >>

> Are you using Impact?  Chipscope?  Synplicity's Identify?  If you have 
> anything else that does JTAG, get a second opinion.
> 
> Help us help you - please specify what board and what software.

Oh I wish someone of you could help me a out a little bit ;). Anyway
I installed ISE 7.1 and the drivers for the ADM-XRC-II board on another
machine. I connected and installed the MultiLinx cable to the board and
used Impact to get the devices in the boundary scan. Again I can just 
see the Xilinx xc9572xl CPLD in the boundary scan. According to section 
6.3 of the ADM-XRC-II manual, the FPGA (VirtexII) and CPLD are on the 
same JTAG chain, so both should be visible in the software:
http://www.alphadata.co.uk/pdf/ADM-XRC-II%20User%20Manual.pdf

Any helpful comments are appreciated!

Article: 126689
Subject: Re: FPGA not in boundary scan
From: Mike <Mike@yahoo.co.uk>
Date: Thu, 29 Nov 2007 16:55:04 +0000
Links: << >>  << T >>  << A >>
> 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.  

And yes, I have exactly set up this connections to the FPGA board which 
should be fine but there is still just this one CPLD in my boundary scan!

Article: 126690
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: Didi <diditgi@gmail.com>
Date: Thu, 29 Nov 2007 08:55:40 -0800 (PST)
Links: << >>  << T >>  << A >>
It means "120 MHz clock rate is nearly DC nowadays", I thought
it was obvious from the context.

On Nov 29, 6:41 pm, "David Spencer" <davidmspen...@verizon.net> wrote:
> "Didi" <didi...@gmail.com> wrote in message
>
> news:0fb44a5a-ceba-4643-87ad-4ea2f1ed60f2@a39g2000pre.googlegroups.com...
>
> > Again, 120 MHz is nearly DC nowadays. You don't need any
> > fancy SI tools to do it.
>
> > Dimiter
>
> It's not the frequency that matters, but rather the edge rate. It is the
> behavior of the edges that are altered by the characteristics of a
> transmission line.
> ....

Of course so, I meant "120 MHz clock rate is nearly DC nowadays", I
thought
it was obvious from the context. It applies to the concrete DDRAM case
allright.

Dimiter




Article: 126691
Subject: Re: lossless compression in hardware: what to do in case of uncompressibility?
From: Phil Carmody <thefatphil_demunged@yahoo.co.uk>
Date: 29 Nov 2007 18:57:16 +0200
Links: << >>  << T >>  << A >>
"Denkedran Joe" <denkedranjoe@googlemail.com> writes:
> Hi all,
> 
> I'm working on a hardware implementation (FPGA) of a lossless compression 
> algorithm for a real-time application. The data will be fed in to the 
> system, will then be compressed on-the-fly and then transmitted further.
> 
> The average compression ratio is 3:1, so I'm gonna use some FIFOs of a 
> certain size and start reading data out of the FIFO after a fixed 
> startup-time. The readout rate will be 1/3 of the input data rate The size 
> of the FIFOs is determined by the experimental variance of the mean 
> compression ratio. Nonetheless there are possible circumstances in which no 
> compression can be achieved. Since the overall system does not support 
> variable bitrates a faster transmission is no solution here.
> 
> So my idea was to put the question to all of you what to do in case of 
> uncompressibility? Any ideas?


You will need to specify your data integrity contraints.
If your real-time constraints are soft, then big buffers
will make the problem less common, but not get rid of it
entirely. If you've got hard real time constraints, then 
they won't, as the data will be stale before you've had
a chance to send it. Either way, you must be prepared to 
throw some data away under some situations. The question
then becomes chosing what to throw away, and how to make
sure that the recipient can also cope with the lost data.

However, if you know something about your source data that
general purpose algorithms don't know, then perhaps you
can achieve a guaranteed compression ratio from a bespoke
algorithm. What's in your data?

Phil
-- 
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Article: 126692
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 29 Nov 2007 09:04:04 -0800
Links: << >>  << T >>  << A >>

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:jRy3j.3053$Dt4.871@newssvr19.news.prodigy.net...
>
> "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
> message news:5r7d87F1326q5U1@mid.individual.net...
>>> I disagree, as does most of the research done into the subject. The use 
>>> of buried capacitance, typically by having adjacent power and ground 
>>> planes separated by as small a distance as possible (2 thou is normal), 
>>> has been shown to be very favorable when compared to discrete decoupling 
>>> caps because although the capacitance is much lower the inductance is 
>>> very much lower so the overall impedence is significantly lower. There 
>>> is an article about it here: 
>>> http://www.ddmconsulting.com/Design_Guides/bcguide.pdf
>>
>> David,
>>
>> I too am skeptical about the amount of decoupling that close GND/PWR 
>> plane
>> coupling can provice.
>>
>> In that atricle above they quote 560pF/sq inch. Most BGAs are smaller
>> than that.
>>
>
> It's not so much the capacitance as it is the lowered inductance that the 
> closely spaced planes brings you.  Having a fire hydrant near a burning 
> house doesn't help much if you only have a garden hose to deliver the 
> water. The inductance of the power delivery network is the thing that 
> delivers the power from the source to the load.
>
> KJ
>
Hi KJ,
This is a good analogy. I say the garden hose is between the planes and the 
FPGA. It matters not a jot if the planes had zero impedance, the BGA balls, 
and the vias to them, are the bottleneck that makes the plane capacitance 
moot.
Cheers, Syms. 



Article: 126693
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 29 Nov 2007 09:11:12 -0800
Links: << >>  << T >>  << A >>
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:5r7gc7F12nc8dU1@mid.individual.net...
>
> Looking at the complexity/density/performance of a typical PC motherboard
> I'm still impressed at the price they knock them out for.
>
Hi Nial,
I doubt they press the 'autoroute' button on their PCB CAD tool!
Cheers, Syms. 



Article: 126694
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 29 Nov 2007 09:16:13 -0800
Links: << >>  << T >>  << A >>
"David Spencer" <davidmspencer@verizon.net> wrote in message 
news:_YB3j.26538$XT.7448@trnddc01...
>
> It's not the frequency that matters, but rather the edge rate. It is the 
> behavior of the edges that are altered by the characteristics of a 
> transmission line. The frequency just indicates how often such edges 
> occur. This is why many older designs fail when a manufacturer introduces 
> a faster, die-shrunk, version of a part. Although the application is using 
> the part in the same way, the unavoidable change in edge rate can break a 
> previously working board.
>
Hi David,
To be technically correct (the best kind of correct!) it's not the edge 
rate, but the rise time. :-) I'm sure that's what you meant, I'm just being 
pedantic...
HTH, Syms. 



Article: 126695
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: "David Spencer" <davidmspencer@verizon.net>
Date: Thu, 29 Nov 2007 17:25:24 GMT
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fims50$arc$1@aioe.org...
> Hi David,
> To be technically correct (the best kind of correct!) it's not the edge 
> rate, but the rise time. :-) I'm sure that's what you meant, I'm just 
> being pedantic...
> HTH, Syms.
>
Or "fall time". ;)

The point I was trying to make (and which I'm still not sure Didi fully got) 
was that if a device is designed such that its outputs can operate at, say, 
200 MHz, then running that device at 1 MHz will not generally magically 
improve the signal integrity. 



Article: 126696
Subject: Re: Asynchronous FIFO and almost empty - bug?
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 29 Nov 2007 09:26:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 3:46 am, "heinerl...@googlemail.com"
<heinerl...@googlemail.com> wrote:
> Hi,
>
> we are using an asynchronous FIFO to bridge two clock domains. Both
> domains have "the same" clock speed but different clock oscillators.
>
> We shift data phits in the FIFO which always form a data packet. In
> between a packet data is shifted in continously without a break.
> Breaks (no shift in) are only allowed in between packets.
> On the output side of the FIFO we need a steady data stream during a
> data packet. The packet may not be interrupted. As the input side may
> be slower we start shift-out data if at least two data phits are in
> the FIFO. As the 2 clocks have almost the same frequency this
> guarantees that we never have a buffer underflow.
>
> The problem we found is that the almost empty flag is only asserted if
> the FIFO is beeing emptied and not if it is beeing filled. So if the
> FIFO was empty and we get a shift in the almost empty is not asserted
> although we set the treshold to one. Is this a bug?
 In a synchronous (single-clock) FIFO, flag control is very simple,
done by a synchronous state machine.
With asynchronous (unrelated clocks) operation, flag control is very
complex, if metastable posssibilities must also be considered.
Almost Empty is generally considered a warning flag that can have a
one-count ambiguity.
Empty is the most important flag, and its rising edge is not allowed
to have any uncertainty. The trailing edge of EMPTY, however, often
has an additional delay, so as to avoid metastability.
My advice: trust the rising edge of the Empty flag, expect its falling
edge to have an additional pipeline delay,  and treat the Almost Empty
flag just as a warning.
Peter Alfke


> We tried to solve that problem by generating a delay-empty signal at
> the output which guarantees that if the FIFO was emtpy and than
> receives a shift in we still wait another cycle so we get another
> shift in to avoid underflow.
>
> This solution however does not solve the problem if the FIFO exactly
> had one entry when starting to shift out a packet. In this case
> neither delayed-empty nor almost empty is asserted, hence we get an
> underflow.
>
> Why isn't the almost empty signal asserted every time there is a
> single packet in the FIFO? Ideas?


Article: 126697
Subject: Re: Global Reset using Global Buffer
From: Rgamer <rgamer1981@gmail.com>
Date: Thu, 29 Nov 2007 09:54:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 12:41 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1...@gmail.com>
> wrote:
>
> >I understood. And thanks for all for the replies.
>
> >So, I can't use a global line for reset and like all Xilinx guys say,
> >I shouldn't use it.
> >IMHO the lack of reset circuitry is a serious flaw.
> >I have a global enable too, that must get everypart of the design.
> >Again, no way to use it as global. This is even a more serious flaw,
> >since enable is the best design pratice regarding FPGAs.
>
> >I think I'll have to prey that PAR meet my timing constraints, as they
> >are somewhat tight... Does anyone have a better idea than using low
> >skew lines?
>
> If you control your design from some central state machine, add several
> states between the "reset" state and the central despatcher state (e.g.
> "idle" where you wait for inputs to react to and depatch to states that
> do the work).
>
> That guarantees that nothing else in your design will be active for
> those several cycles; therefore reset to anything OUTSIDE these states
> can be constrained as a multicycle path.
>
> - Brian

I thought another solution for either global reset and global enable:
I kept the global buffer, since it has more strength (greater fanout)
and I added the attribute for low skew lines. That should do a good
job.

Regards,

Article: 126698
Subject: Re: Gnd plane coupling with DDR routing from FPGA <-> DDR?
From: Didi <diditgi@gmail.com>
Date: Thu, 29 Nov 2007 10:34:58 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 7:25 pm, "David Spencer" <davidmspen...@verizon.net> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
> The point I was trying to make (and which I'm still not sure Didi fully got)
> was that if a device is designed such that its outputs can operate at, say,
> 200 MHz, then running that device at 1 MHz will not generally magically
> improve the signal integrity.

I got the point you made with your first post. In goes into details
I explicitly did not want to go into, because one does not need to
do it in this case, this is the essence of my point.
It can be detailed as "at 120 MHz DDR clock frequency edges
and generally related parts on the market are nearly as easy to use as
if
they were DC nowadays".
 I expected the "nowadays", put in context with
the links to some board photos I provided, to make the point obvious
enough.
Clearly you do have to treat transmission lines as such,
but no extra effort except keeping in mind you are doing that is
necessary.
 I hope my point is now clear enough :-).

BTW, how many persons do you know who have designed boards of
comparable complexity/density/speed to those I showed in the thread
who would have a problem getting the point you made (which says
it is not the frequency but the timing relationships which matter,
put in a more general way)? .... :-) :-)

Dimiter

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

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

In fact the denser board - http://tgi-sci.com/misc/PICT3084.JPG - is
routed by me 7 years ago, with 100 MHz SDRAMs at the photo.

>
> news:fims50$arc$1@aioe.org...> Hi David,
> > To be technically correct (the best kind of correct!) it's not the edge
> > rate, but the rise time. :-) I'm sure that's what you meant, I'm just
> > being pedantic...
> > HTH, Syms.
>
> Or "fall time". ;)
>
> The point I was trying to make (and which I'm still not sure Didi fully got)
> was that if a device is designed such that its outputs can operate at, say,
> 200 MHz, then running that device at 1 MHz will not generally magically
> improve the signal integrity.


Article: 126699
Subject: Re: FPGA not in boundary scan
From: Mike <Mike@yahoo.co.uk>
Date: Thu, 29 Nov 2007 20:10:21 +0000
Links: << >>  << T >>  << A >>

> And yes, I have exactly set up this connections to the FPGA board which 
> should be fine but there is still just this one CPLD in my boundary scan!

Alright, my mistake. Actually there is another JTAG interface hiden 
between the two boards. With this one it should work.

Sorry for the confusion!



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