Please help, Xilinx FIFO problem!

On Dec 22, 3:06=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Dec 22, 12:00=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > Sometimes the simpler things can get in the way of complex issues.
>
> > > Are you certain your read enable and write enables are showing up
> > > relative to the correct data?
> > > It seems some people expect the read enable to indicate the valid dat=
a
> > > is being removed from the FIFO while others believe the read enable
> > > should produce valid data on the following clock.
>
> > > Double check where the documentation says the valid data should be
> > > relative to the enable pulse especially for the read, but check the
> > > write as well.
> > > ___
>
> > > How deep do you want your FIFO?
> > > Is latency an issue?
> > > Do you want rd_en to indicate you're taking valid data or that the
> > > next clock is valid?
> > > You want wr_en to be present in the same clock cycle as the din,
> > > right?
>
> > > Long time no post (partly because I miss having a real newsreader),
> > > - John_H
>
> > Hi John,
>
> > 1 the FIFO is supposed to be SIMPLEST possible MGT receiver, FIFO
> > wr_en is active when the incoming char is not IDLE.
> > 2 Latency is absolutly NO issue, PPC is pulling the data extremly slow
> > anyway :(
> > 3 rd_en almost do not care, well currently it is wrong, 1 clock too
> > late so PPC doesnt pull the last value from fifo (it is pulled when
> > new data comes in), but this minor issue does really not explain the
> > error where the fifo reads out out half of the old values
>
> > Antti
>
> If the rd_en is one cycle off, the data during that cycle is
> undefined.
>
> If the rd_en is active for two cycles, the data extracted will be
> precisely one cycle off for the rd_en pulses after the first.
>
> The specific FIFO implementation may provide what looks like valid
> data - or not - during the first of those consecutive rd_en pulses.
>
> I would *love* to know how much data is "good" versus "bad" with the
> rd_en realigned.
>
> - John_H

John,

just LAST value remains in the FIFO nothing else wrong, this really
is not an issue the system, the data corruption is NEVER wrong values.

1) double value
2) 1, 2, 3 missing values
3) rd addr ptr restart at random

So ALL data what comes is good in that sense its data that has been
pushed it. its just duplicates, missing or long repeats of old data.

whatever the read enable is clock early or late it can not be cause
the cause of the problem. I can also call it design feature if you so
want. We read the data, and pop next one. Ok, its little buggy feature
but several big companies call serious bugs a feature.

Antti

On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
> John,
>
> just LAST value remains in the FIFO nothing else wrong, this really
> is not an issue the system, the data corruption is NEVER wrong values.
>
> 1) double value
> 2) 1, 2, 3 missing values
> 3) rd addr ptr restart at random
>
> So ALL data what comes is good in that sense its data that has been
> pushed it. its just duplicates, missing or long repeats of old data.
>
> whatever the read enable is clock early or late it can not be cause
> the cause of the problem. I can also call it design feature if you so
> want. We read the data, and pop next one. Ok, its little buggy feature
> but several big companies call serious bugs a feature.
>
> Antti

If you haven't gotten the FIFO working yet, I'd love to bring up my
VHDL coding with a FIFO to help you out within the next several
hours.  You gave the port declarations but I didn't see your needed
FIFO depth.  And is valid data the clock after the rd_en acceptable?

It's good for me to get into VHDL and it sounds like you could use a
little Christmas cheer.  I've done Verilog FIFOs in the past with rock-
solid results.  Full asynch support, read past empty can generate an
"invalid read" flag but not upset the later operation (for an absurd
method of "clearing out a FIFO" for instance) while write past full
will be entirely gated out with an error flag the following clock.

- John_H

On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > John,
>
> > just LAST value remains in the FIFO nothing else wrong, this really
> > is not an issue the system, the data corruption is NEVER wrong values.
>
> > 1) double value
> > 2) 1, 2, 3 missing values
> > 3) rd addr ptr restart at random
>
> > So ALL data what comes is good in that sense its data that has been
> > pushed it. its just duplicates, missing or long repeats of old data.
>
> > whatever the read enable is clock early or late it can not be cause
> > the cause of the problem. I can also call it design feature if you so
> > want. We read the data, and pop next one. Ok, its little buggy feature
> > but several big companies call serious bugs a feature.
>
> > Antti
>
> If you haven't gotten the FIFO working yet, I'd love to bring up my
> VHDL coding with a FIFO to help you out within the next several
> hours. =A0You gave the port declarations but I didn't see your needed
> FIFO depth. =A0And is valid data the clock after the rd_en acceptable?
>
> It's good for me to get into VHDL and it sounds like you could use a
> little Christmas cheer. =A0I've done Verilog FIFOs in the past with rock-
> solid results. =A0Full asynch support, read past empty can generate an
> "invalid read" flag but not upset the later operation (for an absurd
> method of "clearing out a FIFO" for instance) while write past full
> will be entirely gated out with an error flag the following clock.
>
> - John_H- Hide quoted text -
>
> - Show quoted text -

Hi John,

I have only spare minute, please do not shoote me - when I reported
all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
tested
i replaced the un-unused FIFO

I will retest and report results.
what does look like valid result is that replacing one of 2 similar
FIFOs the unused one, made the other one have 10 times less error

have to give kids e-lectronics class this instant!
Antti

Antti <antti.lukats@googlemail.com> wrote:

>On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>> On Dec 22, 8:20=A0am, Antti <antti.luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>> > John,
>>
>> > just LAST value remains in the FIFO nothing else wrong, this really
>> > is not an issue the system, the data corruption is NEVER wrong values.
>>
>> > 1) double value
>> > 2) 1, 2, 3 missing values
>> > 3) rd addr ptr restart at random
>>
>> > So ALL data what comes is good in that sense its data that has been
>> > pushed it. its just duplicates, missing or long repeats of old data.
>>
>> > whatever the read enable is clock early or late it can not be cause
>> > the cause of the problem. I can also call it design feature if you so
>> > want. We read the data, and pop next one. Ok, its little buggy feature
>> > but several big companies call serious bugs a feature.
>>
>> > Antti
>>
>> If you haven't gotten the FIFO working yet, I'd love to bring up my
>> VHDL coding with a FIFO to help you out within the next several
>> hours. =A0You gave the port declarations but I didn't see your needed
>> FIFO depth. =A0And is valid data the clock after the rd_en acceptable?
>>
>> It's good for me to get into VHDL and it sounds like you could use a
>> little Christmas cheer. =A0I've done Verilog FIFOs in the past with rock-
>> solid results. =A0Full asynch support, read past empty can generate an
>> "invalid read" flag but not upset the later operation (for an absurd
>> method of "clearing out a FIFO" for instance) while write past full
>> will be entirely gated out with an error flag the following clock.
>>
>> - John_H- Hide quoted text -
>>
>> - Show quoted text -
>
>Hi John,
>
>I have only spare minute, please do not shoote me - when I reported
>all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
>tested
>i replaced the un-unused FIFO
>
>I will retest and report results.
>what does look like valid result is that replacing one of 2 similar
>FIFOs the unused one, made the other one have 10 times less error

Does this mean that changing the design had effects in other unaltered
places? If yes, then you definitely have a clock-boundary crossing
problem.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

On Dec 22, 9:24=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 22, 3:55=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>

<snip>

>
> Hi John,
>
> I have only spare minute, please do not shoote me - when I reported
> all 4 FIFOs not working it was wrong, the non-xilinx fifo is not
> tested
> i replaced the un-unused FIFO
>
> I will retest and report results.
> what does look like valid result is that replacing one of 2 similar
> FIFOs the unused one, made the other one have 10 times less error
>
> have to give kids e-lectronics class this instant!
> Antti

Since your change did not change the functionality of what you tested,
but changed the timing due to going through place and route again,
this sure sounds like it could be a timing problem to me.

I am sure that you have already checked that static path analysis
stated that all of your constraints were met, so generate a custom
timing report and have it list the unconstrained paths.

If something that matters is unconstrained, you are susceptible to
strange behavior from the design. Since the symptoms are appearing at
a FIFO, I would pay special attention to signals crossing between the
clock domains. You mention that the FPGA is about 80% full. If you
meant 80% of LUTs and FFs, you are getting into the region that the
place and route tools are having to work hard to meet timing
constraints. If something is unconstrained,  it could be getting
really poor placement and timing with respect to what it really needs.

Regards,

John McCaskill
www.FasterTechnology.com

snip
> > Antti
>
> Since your change did not change the functionality of what you tested,
> but changed the timing due to going through place and route again,
> this sure sounds like it could be a timing problem to me.
>
> I am sure that you have already checked that static path analysis
> stated that all of your constraints were met, so generate a custom
> timing report and have it list the unconstrained paths.
>
> If something that matters is unconstrained, you are susceptible to
> strange behavior from the design. Since the symptoms are appearing at
> a FIFO, I would pay special attention to signals crossing between the
> clock domains. You mention that the FPGA is about 80% full. If you
> meant 80% of LUTs and FFs, you are getting into the region that the
> place and route tools are having to work hard to meet timing
> constraints. If something is unconstrained, =A0it could be getting
> really poor placement and timing with respect to what it really needs.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

not very encouranging, I have had really hard times with Actel devices
where i have witnessed a simple shift register at low as dirt clean
clock
to stop shifting if FPGA utilization did go above say 93% of
versatales.
There was no violations, nothing did show up in post place and route
simulation, just chip was dead. Later i did read about MANUAL
insertion of "inverting" clock tree to adjust the timings. This was
scary!

current design utilization is
Slices 14K 73%
brams 116 80%
DSP 39 80%
GT11 6 50%

the device is slowest speed grade FX40
and there is not a single assembled with higher speed grade, so that
testing is not possible.

i just did clean some snow outside, hm
actually there is no other explanation except XILINX TOOL messup, that
is, the FIFO clocks
are constrained, no violation reported, but tools generate non-working
design.

i will still test the non-xilinx fifo properly for good luck test, but
then its time to redesign
to 8b-32b DPRAM it would have much less logic in 125mhz domain, so
there could be
more hope. Actually first version of that module is ready, but it
needs change of other
HDL code, and change of firmware, so working fifo would be less work
to, well if
fifo would work

thanks for all suggestion, i will continue with testing, and focusing
on timing-hunt
or then remove all fifo from that place

Antti

On Dec 22, 11:32=A0am, Antti <antti.luk...@googlemail.com> wrote:
> snip
>
>
>
> > > Antti
>
> > Since your change did not change the functionality of what you tested,
> > but changed the timing due to going through place and route again,
> > this sure sounds like it could be a timing problem to me.
>
> > I am sure that you have already checked that static path analysis
> > stated that all of your constraints were met, so generate a custom
> > timing report and have it list the unconstrained paths.
>
> > If something that matters is unconstrained, you are susceptible to
> > strange behavior from the design. Since the symptoms are appearing at
> > a FIFO, I would pay special attention to signals crossing between the
> > clock domains. You mention that the FPGA is about 80% full. If you
> > meant 80% of LUTs and FFs, you are getting into the region that the
> > place and route tools are having to work hard to meet timing
> > constraints. If something is unconstrained, =A0it could be getting
> > really poor placement and timing with respect to what it really needs.
>
> > Regards,
>
> > John McCaskillwww.FasterTechnology.com
>
> not very encouranging, I have had really hard times with Actel devices

Not trying to be discouraging Antti, I think you can find and fix this
problem.


> where i have witnessed a simple shift register at low as dirt clean
> clock
> to stop shifting if FPGA utilization did go above say 93% of
> versatales.
> There was no violations, nothing did show up in post place and route
> simulation, just chip was dead. Later i did read about MANUAL
> insertion of "inverting" clock tree to adjust the timings. This was
> scary!
>


If you are using synchronous design techniques, and are treating the
clocks properly by keeping them on the clock networks and only using
the dedicated clocking resources to manipulate them, static path
analysis should make sure that there are either no problems with the
constraints being met no matter how full the chip is, or finding that
there are timing problems.

Where some of the hard to find problems creep in is unconstrained
paths that should be constrained, improperly constrained paths, such
as improper use of multi-cycle and false path constraints, and
improper handling of asynchronous signals and clock domain crossing.
Sometimes the tools can work against you if you are not careful.  If
you have two or three FFs in a series to synchronize a signal, you
don't want to let the tools replicate those registers.


> current design utilization is
> Slices 14K 73%
> brams 116 80%
> DSP 39 80%
> GT11 6 50%
>

Ok, I thought you meant that LUT or FF utilization was at 80%, if it
is not LUTs and FFs that are at 80%, but the BRAMS and DSP blocks that
should not be a problem. Since slices are only at 73%, you have plenty
of LUTs and FFs left and the tools have lots of flexibility to work
with.  By default, the mapper will not put unrelated logic into the
same slice, so it tends to spread it out to give place and route
flexibility.  I have many designs that are at 99% slice utilization
well before I am finished adding stuff to them that place and route
just fine.


> the device is slowest speed grade FX40
> and there is not a single assembled with higher speed grade, so that
> testing is not possible.


If you are having clock domain crossing problems, a faster speed grade
may move the problem around, but is not the real solution.


>
> i just did clean some snow outside, hm
> actually there is no other explanation except XILINX TOOL messup, that
> is, the FIFO clocks
> are constrained, no violation reported, but tools generate non-working
> design.


Hope it is not the tools, that is hard to fix on your own!  I think
there are plenty of other possibilities.  This sounds like a timing
issue to me from what you have described.  You can find it with the
tools you have, it is just one of the more frustrating problems to
deal with.

Look at the unconstrained paths? What do you see?

I don't think the FIFO is the cause of the problem, but it is where it
shows up so put multiple ChipScope ILAs on it to cover the different
clock domains.  While not perfect, you can run the ILAs off of a clock
that is a multiple of the clock domain it is sampling to get some
timing info if you want. Something is going to look wrong here, follow
the trail.  Using the ILA tool in the FPGA editor you should be able
to change which signals the ILA is monitoring and get a new bitstream
to download in a matter of a few minutes since that does not require
you to go through place and route again.  I was doing this the last
few days to see why something that was working in simulation was not
working on the hardware, it is a powerful technique.


>
> i will still test the non-xilinx fifo properly for good luck test, but
> then its time to redesign
> to 8b-32b DPRAM it would have much less logic in 125mhz domain, so
> there could be
> more hope. Actually first version of that module is ready, but it
> needs change of other
> HDL code, and change of firmware, so working fifo would be less work
> to, well if
> fifo would work
>
> thanks for all suggestion, i will continue with testing, and focusing
> on timing-hunt
> or then remove all fifo from that place
>
> Antti



Good luck,

John McCaskill
www.FasterTechnology.com

Antti,

Based on all the symptoms you have described, namely the read side of
the fifo going crazy and getting stale or duplicated data strongly
suggests that the problem is in the recovered clock.

I once worked on a chip where the duty cycle of the recovered clock
can vary widely and that the recovered clock even occasionally have a
stretched cycle where the clock looked like it was missing a cycle.
This was on an actual asic as opposed to an fpga. But the bottom line
was that we had unintentionally assumed that the recovered clock would
always be 50/50 duty cycle and that the recovered clock would never do
strange things like skip a clock.

If at all possible, I suggest you try the following.

1) I assume that you are using the recovered clock directly. If you
are, try running the clock thru an onboard PLL and use the pll
generated clock instead. If this helps your problem then do #2 below.

2) Route the recovered clock back out to a pin and observe it on a
1GHz scope. Configure the scope to trigger on anything less than 40/60
duty cycle.

Good Luck....

On Dec 23 2009, 1:28=A0pm, GLOW <glen.h.l...@gmail.com> wrote:
> Antti,
>
> Based on all the symptoms you have described, namely the read side of
> the fifo going crazy and getting stale or duplicated data strongly
> suggests that the problem is in the recovered clock.
>
> I once worked on a chip where the duty cycle of the recovered clock
> can vary widely and that the recovered clock even occasionally have a
> stretched cycle where the clock looked like it was missing a cycle.
> This was on an actual asic as opposed to an fpga. But the bottom line
> was that we had unintentionally assumed that the recovered clock would
> always be 50/50 duty cycle and that the recovered clock would never do
> strange things like skip a clock.
>
> If at all possible, I suggest you try the following.
>
> 1) I assume that you are using the recovered clock directly. If you
> are, try running the clock thru an onboard PLL and use the pll
> generated clock instead. If this helps your problem then do #2 below.
>
> 2) Route the recovered clock back out to a pin and observe it on a
> 1GHz scope. Configure the scope to trigger on anything less than 40/60
> duty cycle.
>
> Good Luck....

problem fixed!

solution and explanation in the next Brain issue
(I will post short post also after the issue release)

Antti

Antti wrote:
> problem fixed!
yeah !!!

> solution and explanation in the next Brain issue
> (I will post short post also after the issue release)
i'm eagerly waiting :-)

did you solve your website and email issues ?
how can one contact you ?
are your "stamps" still available ?

> Antti
yg

-- 
http://ygdes.com / http://yasep.org