I hope my plea will not be seen as usual "please help me" request. I
do my (home)work, I try hard but sometimes there come up problems that
seem very hard to solve, with the current problem, well if there is no
solution to that, then I wonder how come it has been ever been
possible to use Xilinx FIFO's with problem at all? So the problem:

Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPTY
flags present.

signals at input correct, as expected (checked with ChipScope)
signals at output:
- double value
- missing 1, 2 or 3 values
- FIFO will read out random number of OLD entries, this could be 4
values, or 50% of the FIFO old values

I can select BRAM or FIFO16 implementation in Coregen, it doesnt
change the problem

Virtex-4, ISE 10.1SP3

Please help me, if anyone has some good suggestion (except use Altera
advice), I am getting really desperate. To the extent that when i
friend called my yesterday, then after my "hello", his first response
was: "Are you dead?". I had to explain that i am not.

Antti

> Virtex-4, FIFOs

I thought I read there was a bug in those...

On Dec 21, 11:40=A0am, Jon Beniston <j...@beniston.com> wrote:
> > Virtex-4, FIFOs
>
> I thought I read there was a bug in those...

Well there is a bug in the V4 FIFO16 hard-fifo, but Coregen says that
it DOES APPLY PATCH to fix it.

So I assumed that the FIFO's generated by Coregen do actually work,
but it seems i was wrong :(

Antti

Why dont you just write your own fifo? It shouldnt take that long and at
least you would know it was 100% ok.

Jon	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

On Dec 21, 12:07=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Why dont you just write your own fifo? It shouldnt take that long and at
> least you would know it was 100% ok.
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0

Yeah, that advice I have myself ready :) well, I would most likely not
use FIFO
but make dual port RAM instead. Thing is that the system works, the
firmware
works, except that "small Xilinx FIFO problem" .. so if there is at
all chance
to FIX Xilinx FIFO and to make it WORK then it would made the system
work
without the need of rewriting HDL or C code

Antti

Well once you have written and tested your own fifo then you would have it
for any other project. It seems like you have wasted a lot of time already
trying to fix the Xilinx version so I dont see that you have anything to
loose by creating your own.

Jon	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Antti wrote:
> 
> Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPTY
> flags present.
> 
> signals at input correct, as expected (checked with ChipScope)
> signals at output:
> - double value
> - missing 1, 2 or 3 values
> - FIFO will read out random number of OLD entries, this could be 4
> values, or 50% of the FIFO old values
> 
I know you will have read this.


Can you think of any reason why the Xilinx work-around wouldn't work 
because of your specific implementation? It seems to have different 
work-arounds depending on whether the read clock is faster or slower 
than the write clock. Do your clocks change frequency?

Are you sure your clocks don't have any glitches? The reset also? 
Power's OK? Is your office made of Cobalt 60?

HTH., Syms.

On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> Antti wrote:
>
> > Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPTY
> > flags present.
>
> > signals at input correct, as expected (checked with ChipScope)
> > signals at output:
> > - double value
> > - missing 1, 2 or 3 values
> > - FIFO will read out random number of OLD entries, this could be 4
> > values, or 50% of the FIFO old values
>
> I know you will have read this.
>
> Can you think of any reason why the Xilinx work-around wouldn't work
> because of your specific implementation? It seems to have different
> work-arounds depending on whether the read clock is faster or slower
> than the write clock. Do your clocks change frequency?
>
> Are you sure your clocks don't have any glitches? The reset also?
> Power's OK? Is your office made of Cobalt 60?
>
> HTH., Syms.

1) I entered the clock figures in FIFO16 implementationm, but the
error also happens with BRAM based FIFO that do not need workarounds
2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write,
one is PLB clock 62.5MHz read
3) Power OK? Well the problem happens at 2 different sites, hm yes it
could be still be power problem

4) My office is not of Cobalt 60, ... and its cold here too

Antti

On Dec 21, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Well once you have written and tested your own fifo then you would have i=
t
> for any other project. It seems like you have wasted a lot of time alread=
y
> trying to fix the Xilinx version so I dont see that you have anything to
> loose by creating your own.
>
> Jon =A0 =A0 =A0 =A0
>
If you REALLY need todo something else, when your time is at absolute
premium
And if the system working (except occasional errors about 2 of fiber
packets are corrupt)
Then you do not go replacing Xilinx validated FIFO solutions with your
own, if there are other options.

If 2 completly different FIFO implementations both have same error?
you think 3rd one would instantly work? Could be, yes.

Antti

>On Dec 21, 12:32=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>> Well once you have written and tested your own fifo then you would have
i=
>t
>> for any other project. It seems like you have wasted a lot of time
alread=
>y
>> trying to fix the Xilinx version so I dont see that you have anything
to
>> loose by creating your own.
>>
>> Jon =A0 =A0 =A0 =A0
>>
>If you REALLY need todo something else, when your time is at absolute
>premium
>And if the system working (except occasional errors about 2 of fiber
>packets are corrupt)
>Then you do not go replacing Xilinx validated FIFO solutions with your
>own, if there are other options.
>
>If 2 completly different FIFO implementations both have same error?
>you think 3rd one would instantly work? Could be, yes.
>
>Antti
>
>

In my opinion people tend to use coregen far too often. Looking through
some of Xilinx code it is awfull. I went down the route of writing my own
fifos not because I had a problem with Xilinx fifos but because I believe a
fifo written by myself is a lot more flexible and simulates faster than the
Xilinx version. I also know to as good a degree as I can test that it will
work 100%.
I dont really think you can say that their fifos have been validated 100%
if they have to release patches for them.

Jon	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> >> Well once you have written and tested your own fifo then you would hav=
e
> i=3D
> >t
> >> for any other project. It seems like you have wasted a lot of time
> alread=3D
> >y
> >> trying to fix the Xilinx version so I dont see that you have anything
> to
> >> loose by creating your own.
>
> >> Jon =3DA0 =3DA0 =3DA0 =3DA0
>
> >If you REALLY need todo something else, when your time is at absolute
> >premium
> >And if the system working (except occasional errors about 2 of fiber
> >packets are corrupt)
> >Then you do not go replacing Xilinx validated FIFO solutions with your
> >own, if there are other options.
>
> >If 2 completly different FIFO implementations both have same error?
> >you think 3rd one would instantly work? Could be, yes.
>
> >Antti
>
> In my opinion people tend to use coregen far too often. Looking through
> some of Xilinx code it is awfull. I went down the route of writing my own
> fifos not because I had a problem with Xilinx fifos but because I believe=
 a
> fifo written by myself is a lot more flexible and simulates faster than t=
he
> Xilinx version. I also know to as good a degree as I can test that it wil=
l
> work 100%.
> I dont really think you can say that their fifos have been validated 100%
> if they have to release patches for them.
>
> Jon =A0 =A0 =A0 =A0
>
Dear Jon,

I do not feel to be in health right now to write this fifo, so here is
the deal:

  component mgt_fifo
    port (
      din    : in  std_logic_vector(8 downto 0);
      rd_clk : in  std_logic;
      rd_en  : in  std_logic;
      rst    : in  std_logic;
      wr_clk : in  std_logic;
      wr_en  : in  std_logic;
      dout   : out std_logic_vector(8 downto 0);
      empty  : out std_logic;
      full   : out std_logic);
  end component;

if you can write fifo that i can "drop in" and the Xilinx FIFO error
is gone,
then i will stand up, go to postal office and send you 1000 EUR by
western union.
If 1000 EUR is not enough, name your price, i will consider it.
there is no price on the health of our family


condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay.

Antti

Antti wrote:
> 
> 1) I entered the clock figures in FIFO16 implementationm, but the
> error also happens with BRAM based FIFO that do not need workarounds
> 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write,
> one is PLB clock 62.5MHz read
> 3) Power OK? Well the problem happens at 2 different sites, hm yes it
> could be still be power problem
> 
> 4) My office is not of Cobalt 60, ... and its cold here too
> 
> Antti
> 
Whoops, looks like this link didn't make it with my post, sorry.

http://www.xilinx.com/support/answers/22462.htm

But you've read that already of course.

Does temperature make any difference to its operation?

Syms.

Antti

I have an async fifo that I can give you but it is in Verilog as I dont use
VHDL.

Jon
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Hi Antti


You may want to check the sources of the async FIFOs included in the FSL IP core (inside the EDK HW IP folder).

Also I dont want any money. It's not like I am giving you a USB 3.0 core
:)

Jon	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

On Dec 21, 5:42=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>
> > >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> > >> Well once you have written and tested your own fifo then you would h=
ave
> > i=3D
> > >t
> > >> for any other project. It seems like you have wasted a lot of time
> > alread=3D
> > >y
> > >> trying to fix the Xilinx version so I dont see that you have anythin=
g
> > to
> > >> loose by creating your own.
>
> > >> Jon =3DA0 =3DA0 =3DA0 =3DA0
>
> > >If you REALLY need todo something else, when your time is at absolute
> > >premium
> > >And if the system working (except occasional errors about 2 of fiber
> > >packets are corrupt)
> > >Then you do not go replacing Xilinx validated FIFO solutions with your
> > >own, if there are other options.
>
> > >If 2 completly different FIFO implementations both have same error?
> > >you think 3rd one would instantly work? Could be, yes.
>
> > >Antti
>
> > In my opinion people tend to use coregen far too often. Looking through
> > some of Xilinx code it is awfull. I went down the route of writing my o=
wn
> > fifos not because I had a problem with Xilinx fifos but because I belie=
ve a
> > fifo written by myself is a lot more flexible and simulates faster than=
 the
> > Xilinx version. I also know to as good a degree as I can test that it w=
ill
> > work 100%.
> > I dont really think you can say that their fifos have been validated 10=
0%
> > if they have to release patches for them.
>
> > Jon =A0 =A0 =A0 =A0
>
> Dear Jon,
>
> I do not feel to be in health right now to write this fifo, so here is
> the deal:
>
> =A0 component mgt_fifo
> =A0 =A0 port (
> =A0 =A0 =A0 din =A0 =A0: in =A0std_logic_vector(8 downto 0);
> =A0 =A0 =A0 rd_clk : in =A0std_logic;
> =A0 =A0 =A0 rd_en =A0: in =A0std_logic;
> =A0 =A0 =A0 rst =A0 =A0: in =A0std_logic;
> =A0 =A0 =A0 wr_clk : in =A0std_logic;
> =A0 =A0 =A0 wr_en =A0: in =A0std_logic;
> =A0 =A0 =A0 dout =A0 : out std_logic_vector(8 downto 0);
> =A0 =A0 =A0 empty =A0: out std_logic;
> =A0 =A0 =A0 full =A0 : out std_logic);
> =A0 end component;
>
> if you can write fifo that i can "drop in" and the Xilinx FIFO error
> is gone,
> then i will stand up, go to postal office and send you 1000 EUR by
> western union.
> If 1000 EUR is not enough, name your price, i will consider it.
> there is no price on the health of our family
>
> condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay.
>
> Antti


Hello Antti,

If you want to try a different implementation of a FIFO, you can get
the one that the FSL bus uses out of the EDK pcores directory at C:
\Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
\vhdl.

There are multiple implementations, including an async BRAM based one
that has the same ports as you list above, except that it uses exist
instead of empty on the read port.

That said, I don't expect a third implementation to work instantly
when the previous two implementations had the same error.  This FIFO
has the full source to it, so it is straight forward to see how it
works, and add ChipScope to observe what is happening around the time
of the error.

If you have not used it before, FPGA editor has the ability to find a
ChipScope ILA core, and change what is connected to it. That can make
it much quicker to follow the trail of clues since you avoid having to
go through a full place and route every time you want to look at
something different.

Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
mention that the 125 MHz is the recovered clock from the MGT, but
there are other options.  When we did our GigE interface, we used a
125 MHz clock from the MGT, but it was not the recovered clock, but
the local MGT PLL.  This let us use the same 125 MHz clock for all
four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
phase aligned with the 125 MHz clock.

Regards,

John McCaskill
www.FasterTechnology.com

On Dec 21, 3:21=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:
> On Dec 21, 5:42=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>
> > > >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> > > >> Well once you have written and tested your own fifo then you would=
 have
> > > i=3D
> > > >t
> > > >> for any other project. It seems like you have wasted a lot of time
> > > alread=3D
> > > >y
> > > >> trying to fix the Xilinx version so I dont see that you have anyth=
ing
> > > to
> > > >> loose by creating your own.
>
> > > >> Jon =3DA0 =3DA0 =3DA0 =3DA0
>
> > > >If you REALLY need todo something else, when your time is at absolut=
e
> > > >premium
> > > >And if the system working (except occasional errors about 2 of fiber
> > > >packets are corrupt)
> > > >Then you do not go replacing Xilinx validated FIFO solutions with yo=
ur
> > > >own, if there are other options.
>
> > > >If 2 completly different FIFO implementations both have same error?
> > > >you think 3rd one would instantly work? Could be, yes.
>
> > > >Antti
>
> > > In my opinion people tend to use coregen far too often. Looking throu=
gh
> > > some of Xilinx code it is awfull. I went down the route of writing my=
 own
> > > fifos not because I had a problem with Xilinx fifos but because I bel=
ieve a
> > > fifo written by myself is a lot more flexible and simulates faster th=
an the
> > > Xilinx version. I also know to as good a degree as I can test that it=
 will
> > > work 100%.
> > > I dont really think you can say that their fifos have been validated =
100%
> > > if they have to release patches for them.
>
> > > Jon =A0 =A0 =A0 =A0
>
> > Dear Jon,
>
> > I do not feel to be in health right now to write this fifo, so here is
> > the deal:
>
> > =A0 component mgt_fifo
> > =A0 =A0 port (
> > =A0 =A0 =A0 din =A0 =A0: in =A0std_logic_vector(8 downto 0);
> > =A0 =A0 =A0 rd_clk : in =A0std_logic;
> > =A0 =A0 =A0 rd_en =A0: in =A0std_logic;
> > =A0 =A0 =A0 rst =A0 =A0: in =A0std_logic;
> > =A0 =A0 =A0 wr_clk : in =A0std_logic;
> > =A0 =A0 =A0 wr_en =A0: in =A0std_logic;
> > =A0 =A0 =A0 dout =A0 : out std_logic_vector(8 downto 0);
> > =A0 =A0 =A0 empty =A0: out std_logic;
> > =A0 =A0 =A0 full =A0 : out std_logic);
> > =A0 end component;
>
> > if you can write fifo that i can "drop in" and the Xilinx FIFO error
> > is gone,
> > then i will stand up, go to postal office and send you 1000 EUR by
> > western union.
> > If 1000 EUR is not enough, name your price, i will consider it.
> > there is no price on the health of our family
>
> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay.
>
> > Antti
>
> Hello Antti,
>
> If you want to try a different implementation of a FIFO, you can get
> the one that the FSL bus uses out of the EDK pcores directory at C:
> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
> \vhdl.
>
> There are multiple implementations, including an async BRAM based one
> that has the same ports as you list above, except that it uses exist
> instead of empty on the read port.
>
> That said, I don't expect a third implementation to work instantly
> when the previous two implementations had the same error. =A0This FIFO
> has the full source to it, so it is straight forward to see how it
> works, and add ChipScope to observe what is happening around the time
> of the error.
>
> If you have not used it before, FPGA editor has the ability to find a
> ChipScope ILA core, and change what is connected to it. That can make
> it much quicker to follow the trail of clues since you avoid having to
> go through a full place and route every time you want to look at
> something different.
>
> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
> mention that the 125 MHz is the recovered clock from the MGT, but
> there are other options. =A0When we did our GigE interface, we used a
> 125 MHz clock from the MGT, but it was not the recovered clock, but
> the local MGT PLL. =A0This let us use the same 125 MHz clock for all
> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
> phase aligned with the 125 MHz clock.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

Hi

I have tried all 3 variants possible with coregen,
all 3 have similar errors

and no, the clocks are not divided version, the 125MHz comes from
master over fiber
the master could be 100 hops away, the 62.5mhz is derived from local
oscillator

so the frequencier are very close but not synchron

Antti
who has to give up, at least for a while :(
good advice still welcome, if there is any hope or idea how to fix the
issue
and yes it could be power supply issue at the end of the day also

On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
>
>
>
>
> > Antti wrote:
>
> > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPT=
Y
> > > flags present.
>
> > > signals at input correct, as expected (checked with ChipScope)
> > > signals at output:
> > > - double value
> > > - missing 1, 2 or 3 values
> > > - FIFO will read out random number of OLD entries, this could be 4
> > > values, or 50% of the FIFO old values
>
> > I know you will have read this.
>
> > Can you think of any reason why the Xilinx work-around wouldn't work
> > because of your specific implementation? It seems to have different
> > work-arounds depending on whether the read clock is faster or slower
> > than the write clock. Do your clocks change frequency?
>
> > Are you sure your clocks don't have any glitches? The reset also?
> > Power's OK? Is your office made of Cobalt 60?
>
> > HTH., Syms.
>
> 1) I entered the clock figures in FIFO16 implementationm, but the
> error also happens with BRAM based FIFO that do not need workarounds
> 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write,
> one is PLB clock 62.5MHz read
> 3) Power OK? Well the problem happens at 2 different sites, hm yes it
> could be still be power problem
>
> 4) My office is not of Cobalt 60, ... and its cold here too
>
> Antti- Hide quoted text -
>
> - Show quoted text -

Are you sure that this is a FIFO issue and not something else?  Some
things to think about.

1) The recovered clock from the MGT is a bit noisy as it moves as the
CDR moves.  Why are you using this instead of the REFCLK source?

2) It seems like you have a PLB core that is reading from the FIFO,
could the problem be in this?

Ed McGettigan
--
Xilinx Inc.

On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > > Antti wrote:
>
> > > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL EM=
PTY
> > > > flags present.
>
> > > > signals at input correct, as expected (checked with ChipScope)
> > > > signals at output:
> > > > - double value
> > > > - missing 1, 2 or 3 values
> > > > - FIFO will read out random number of OLD entries, this could be 4
> > > > values, or 50% of the FIFO old values
>
> > > I know you will have read this.
>
> > > Can you think of any reason why the Xilinx work-around wouldn't work
> > > because of your specific implementation? It seems to have different
> > > work-arounds depending on whether the read clock is faster or slower
> > > than the write clock. Do your clocks change frequency?
>
> > > Are you sure your clocks don't have any glitches? The reset also?
> > > Power's OK? Is your office made of Cobalt 60?
>
> > > HTH., Syms.
>
> > 1) I entered the clock figures in FIFO16 implementationm, but the
> > error also happens with BRAM based FIFO that do not need workarounds
> > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write,
> > one is PLB clock 62.5MHz read
> > 3) Power OK? Well the problem happens at 2 different sites, hm yes it
> > could be still be power problem
>
> > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > Antti- Hide quoted text -
>
> > - Show quoted text -
>
> Are you sure that this is a FIFO issue and not something else? =A0Some
> things to think about.
>
> 1) The recovered clock from the MGT is a bit noisy as it moves as the
> CDR moves. =A0Why are you using this instead of the REFCLK source?
>
> 2) It seems like you have a PLB core that is reading from the FIFO,
> could the problem be in this?
>
> Ed McGettigan
> --
> Xilinx Inc.

Well the MGT datapath and clock system is not done by me, and the guy
says it is OK all the way it is connected.

yes, It is very unlikely to belive that all THREE types of coregen
FIFO's fail with about same symptoms, but in all
3 cased Chipscope sees correct data into fifo, and trash coming out

the system can span up to 100 boards, all synced to master unit, the
local refclk is not fully sync to the clock of
the master unit, so I see no way to use this clock to syncronise the
fifo?

Antti
PS I just received a attempt to collect the reward, by using non
xilinx FIFO implementation, i let you all know
the test results

On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > > > Antti wrote:
>
> > > > > Xilinx Coregen FIFO, dual clock, most options disable, only FULL =
EMPTY
> > > > > flags present.
>
> > > > > signals at input correct, as expected (checked with ChipScope)
> > > > > signals at output:
> > > > > - double value
> > > > > - missing 1, 2 or 3 values
> > > > > - FIFO will read out random number of OLD entries, this could be =
4
> > > > > values, or 50% of the FIFO old values
>
> > > > I know you will have read this.
>
> > > > Can you think of any reason why the Xilinx work-around wouldn't wor=
k
> > > > because of your specific implementation? It seems to have different
> > > > work-arounds depending on whether the read clock is faster or slowe=
r
> > > > than the write clock. Do your clocks change frequency?
>
> > > > Are you sure your clocks don't have any glitches? The reset also?
> > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > HTH., Syms.
>
> > > 1) I entered the clock figures in FIFO16 implementationm, but the
> > > error also happens with BRAM based FIFO that do not need workarounds
> > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write=
,
> > > one is PLB clock 62.5MHz read
> > > 3) Power OK? Well the problem happens at 2 different sites, hm yes it
> > > could be still be power problem
>
> > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > Antti- Hide quoted text -
>
> > > - Show quoted text -
>
> > Are you sure that this is a FIFO issue and not something else? =A0Some
> > things to think about.
>
> > 1) The recovered clock from the MGT is a bit noisy as it moves as the
> > CDR moves. =A0Why are you using this instead of the REFCLK source?
>
> > 2) It seems like you have a PLB core that is reading from the FIFO,
> > could the problem be in this?
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Well the MGT datapath and clock system is not done by me, and the guy
> says it is OK all the way it is connected.
>
> yes, It is very unlikely to belive that all THREE types of coregen
> FIFO's fail with about same symptoms, but in all
> 3 cased Chipscope sees correct data into fifo, and trash coming out
>
> the system can span up to 100 boards, all synced to master unit, the
> local refclk is not fully sync to the clock of
> the master unit, so I see no way to use this clock to syncronise the
> fifo?
>
> Antti
> PS I just received a attempt to collect the reward, by using non
> xilinx FIFO implementation, i let you all know
> the test results

Antti
If I remember right (I am no longer at Xilinx) the FIFO is NOT
designed for unequal data width of write and read. (Reason: possible
ambiguity of Full and EMPTY)
Since you use two clocks that are roughly 2:1 in frequency, I hope
that you do not try to have double width on one of the ports.
The FIFO must have the same width on both ports. You must design the
width conversion outside the FIFO. That little circuit will be
synchronous and thus quite simple.
Peter Alfke

On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > > > > Antti wrote:
>
> > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only FUL=
L EMPTY
> > > > > > flags present.
>
> > > > > > signals at input correct, as expected (checked with ChipScope)
> > > > > > signals at output:
> > > > > > - double value
> > > > > > - missing 1, 2 or 3 values
> > > > > > - FIFO will read out random number of OLD entries, this could b=
e 4
> > > > > > values, or 50% of the FIFO old values
>
> > > > > I know you will have read this.
>
> > > > > Can you think of any reason why the Xilinx work-around wouldn't w=
ork
> > > > > because of your specific implementation? It seems to have differe=
nt
> > > > > work-arounds depending on whether the read clock is faster or slo=
wer
> > > > > than the write clock. Do your clocks change frequency?
>
> > > > > Are you sure your clocks don't have any glitches? The reset also?
> > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > HTH., Syms.
>
> > > > 1) I entered the clock figures in FIFO16 implementationm, but the
> > > > error also happens with BRAM based FIFO that do not need workaround=
s
> > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz wri=
te,
> > > > one is PLB clock 62.5MHz read
> > > > 3) Power OK? Well the problem happens at 2 different sites, hm yes =
it
> > > > could be still be power problem
>
> > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > Antti- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Are you sure that this is a FIFO issue and not something else? =A0Som=
e
> > > things to think about.
>
> > > 1) The recovered clock from the MGT is a bit noisy as it moves as the
> > > CDR moves. =A0Why are you using this instead of the REFCLK source?
>
> > > 2) It seems like you have a PLB core that is reading from the FIFO,
> > > could the problem be in this?
>
> > > Ed McGettigan
> > > --
> > > Xilinx Inc.
>
> > Well the MGT datapath and clock system is not done by me, and the guy
> > says it is OK all the way it is connected.
>
> > yes, It is very unlikely to belive that all THREE types of coregen
> > FIFO's fail with about same symptoms, but in all
> > 3 cased Chipscope sees correct data into fifo, and trash coming out
>
> > the system can span up to 100 boards, all synced to master unit, the
> > local refclk is not fully sync to the clock of
> > the master unit, so I see no way to use this clock to syncronise the
> > fifo?
>
> > Antti
> > PS I just received a attempt to collect the reward, by using non
> > xilinx FIFO implementation, i let you all know
> > the test results
>
> Antti
> If I remember right (I am no longer at Xilinx) the FIFO is NOT
> designed for unequal data width of write and read. (Reason: possible
> ambiguity of Full and EMPTY)
> Since you use two clocks that are roughly 2:1 in frequency, I hope
> that you do not try to have double width on one of the ports.
> The FIFO must have the same width on both ports. You must design the
> width conversion outside the FIFO. That little circuit will be
> synchronous and thus quite simple.
> Peter Alfke

well the FIFO is 9b in 9b out so it should work?
at least this is what i hoped...

we did not suspect the FIFO as problem at first
so spent LOT of time looking for the problem AROUND the FIFOS
but.. at least based on what i can see from CS snapshots on fifo
inputs and outputs, the only explanation i have is that the FIFO
are just goind mad,

of course one option is that its me doing, but i have someone
who is in better shape looking over the code as well, and he
sees no issues there either. I know the FIFOs should work
so there must be some explanation, but so far failing to see it.

Antti
PS thank you Peter for the response

On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
>
>
> > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > > > > > Antti wrote:
>
> > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only F=
ULL EMPTY
> > > > > > > flags present.
>
> > > > > > > signals at input correct, as expected (checked with ChipScope=
)
> > > > > > > signals at output:
> > > > > > > - double value
> > > > > > > - missing 1, 2 or 3 values
> > > > > > > - FIFO will read out random number of OLD entries, this could=
 be 4
> > > > > > > values, or 50% of the FIFO old values
>
> > > > > > I know you will have read this.
>
> > > > > > Can you think of any reason why the Xilinx work-around wouldn't=
 work
> > > > > > because of your specific implementation? It seems to have diffe=
rent
> > > > > > work-arounds depending on whether the read clock is faster or s=
lower
> > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > Are you sure your clocks don't have any glitches? The reset als=
o?
> > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > HTH., Syms.
>
> > > > > 1) I entered the clock figures in FIFO16 implementationm, but the
> > > > > error also happens with BRAM based FIFO that do not need workarou=
nds
> > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz w=
rite,
> > > > > one is PLB clock 62.5MHz read
> > > > > 3) Power OK? Well the problem happens at 2 different sites, hm ye=
s it
> > > > > could be still be power problem
>
> > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > Antti- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > > Are you sure that this is a FIFO issue and not something else? =A0S=
ome
> > > > things to think about.
>
> > > > 1) The recovered clock from the MGT is a bit noisy as it moves as t=
he
> > > > CDR moves. =A0Why are you using this instead of the REFCLK source?
>
> > > > 2) It seems like you have a PLB core that is reading from the FIFO,
> > > > could the problem be in this?
>
> > > > Ed McGettigan
> > > > --
> > > > Xilinx Inc.
>
> > > Well the MGT datapath and clock system is not done by me, and the guy
> > > says it is OK all the way it is connected.
>
> > > yes, It is very unlikely to belive that all THREE types of coregen
> > > FIFO's fail with about same symptoms, but in all
> > > 3 cased Chipscope sees correct data into fifo, and trash coming out
>
> > > the system can span up to 100 boards, all synced to master unit, the
> > > local refclk is not fully sync to the clock of
> > > the master unit, so I see no way to use this clock to syncronise the
> > > fifo?
>
> > > Antti
> > > PS I just received a attempt to collect the reward, by using non
> > > xilinx FIFO implementation, i let you all know
> > > the test results
>
> > Antti
> > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > designed for unequal data width of write and read. (Reason: possible
> > ambiguity of Full and EMPTY)
> > Since you use two clocks that are roughly 2:1 in frequency, I hope
> > that you do not try to have double width on one of the ports.
> > The FIFO must have the same width on both ports. You must design the
> > width conversion outside the FIFO. That little circuit will be
> > synchronous and thus quite simple.
> > Peter Alfke
>
> well the FIFO is 9b in 9b out so it should work?
> at least this is what i hoped...
>
> we did not suspect the FIFO as problem at first
> so spent LOT of time looking for the problem AROUND the FIFOS
> but.. at least based on what i can see from CS snapshots on fifo
> inputs and outputs, the only explanation i have is that the FIFO
> are just goind mad,
>
> of course one option is that its me doing, but i have someone
> who is in better shape looking over the code as well, and he
> sees no issues there either. I know the FIFOs should work
> so there must be some explanation, but so far failing to see it.
>
> Antti
> PS thank you Peter for the response

OK, Antti,
so you have the same port width, but one clock is about twice as fast
as the other.
How do you stop the 125 MHz write clock from filling up the FIFO,
since you read at only 62 MHz ?
I hope you are not gating the clock, but rather run it continuously
and use WE to stop the writing.
Yes, many of these suggestions are well below your level, but stupid
problems need stupid investigations.
Cheers
Peter

On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrot=
e:
>
> > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > > > > > > Antti wrote:
>
> > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, only=
 FULL EMPTY
> > > > > > > > flags present.
>
> > > > > > > > signals at input correct, as expected (checked with ChipSco=
pe)
> > > > > > > > signals at output:
> > > > > > > > - double value
> > > > > > > > - missing 1, 2 or 3 values
> > > > > > > > - FIFO will read out random number of OLD entries, this cou=
ld be 4
> > > > > > > > values, or 50% of the FIFO old values
>
> > > > > > > I know you will have read this.
>
> > > > > > > Can you think of any reason why the Xilinx work-around wouldn=
't work
> > > > > > > because of your specific implementation? It seems to have dif=
ferent
> > > > > > > work-arounds depending on whether the read clock is faster or=
 slower
> > > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > > Are you sure your clocks don't have any glitches? The reset a=
lso?
> > > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > > HTH., Syms.
>
> > > > > > 1) I entered the clock figures in FIFO16 implementationm, but t=
he
> > > > > > error also happens with BRAM based FIFO that do not need workar=
ounds
> > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz=
 write,
> > > > > > one is PLB clock 62.5MHz read
> > > > > > 3) Power OK? Well the problem happens at 2 different sites, hm =
yes it
> > > > > > could be still be power problem
>
> > > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > > Antti- Hide quoted text -
>
> > > > > > - Show quoted text -
>
> > > > > Are you sure that this is a FIFO issue and not something else? =
=A0Some
> > > > > things to think about.
>
> > > > > 1) The recovered clock from the MGT is a bit noisy as it moves as=
 the
> > > > > CDR moves. =A0Why are you using this instead of the REFCLK source=
?
>
> > > > > 2) It seems like you have a PLB core that is reading from the FIF=
O,
> > > > > could the problem be in this?
>
> > > > > Ed McGettigan
> > > > > --
> > > > > Xilinx Inc.
>
> > > > Well the MGT datapath and clock system is not done by me, and the g=
uy
> > > > says it is OK all the way it is connected.
>
> > > > yes, It is very unlikely to belive that all THREE types of coregen
> > > > FIFO's fail with about same symptoms, but in all
> > > > 3 cased Chipscope sees correct data into fifo, and trash coming out
>
> > > > the system can span up to 100 boards, all synced to master unit, th=
e
> > > > local refclk is not fully sync to the clock of
> > > > the master unit, so I see no way to use this clock to syncronise th=
e
> > > > fifo?
>
> > > > Antti
> > > > PS I just received a attempt to collect the reward, by using non
> > > > xilinx FIFO implementation, i let you all know
> > > > the test results
>
> > > Antti
> > > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > > designed for unequal data width of write and read. (Reason: possible
> > > ambiguity of Full and EMPTY)
> > > Since you use two clocks that are roughly 2:1 in frequency, I hope
> > > that you do not try to have double width on one of the ports.
> > > The FIFO must have the same width on both ports. You must design the
> > > width conversion outside the FIFO. That little circuit will be
> > > synchronous and thus quite simple.
> > > Peter Alfke
>
> > well the FIFO is 9b in 9b out so it should work?
> > at least this is what i hoped...
>
> > we did not suspect the FIFO as problem at first
> > so spent LOT of time looking for the problem AROUND the FIFOS
> > but.. at least based on what i can see from CS snapshots on fifo
> > inputs and outputs, the only explanation i have is that the FIFO
> > are just goind mad,
>
> > of course one option is that its me doing, but i have someone
> > who is in better shape looking over the code as well, and he
> > sees no issues there either. I know the FIFOs should work
> > so there must be some explanation, but so far failing to see it.
>
> > Antti
> > PS thank you Peter for the response
>
> OK, Antti,
> so you have the same port width, but one clock is about twice as fast
> as the other.
> How do you stop the 125 MHz write clock from filling up the FIFO,
> since you read at only 62 MHz ?
> I hope you are not gating the clock, but rather run it continuously
> and use WE to stop the writing.
> Yes, many of these suggestions are well below your level, but stupid
> problems need stupid investigations.
> Cheers
> Peter

I am level below ground right now the project is just driving me nuts.
slowly.
To work for months, and end up with Xilinx saying:
The man who could have helped you, left Xilinx last friday. Your
situation is unsupportable.
Well we got out of that situation.
To end up in the new ones.

The FIFO is never over filled by design.
The fiber link is 99% IDLE sending usually only short 10byte packets
over the link.

For tesing I generate 10 byte pakets with MOUSE so 1 per second so
there is no doubt
the FIFO is never near full at all.

Last results:
- ALL 3 types of Xilinx FIFO's same style of errors, about same error
rate
- VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
LESS errors then Xilinx implementation, but still all different types
of error did occour: missing values, and FIFO outputtin large junk of
OLD values, that is read pointer changing by some random value

again, I did not design the MGT clocking and the overall MGT
subsystem, the people who did are either unreachable or unable to
provide any help beyound saying that the implementation (connection of
the FIFO) is done properly. It is also what I have figured out so far,
but.. well somewhere must be problem.

Antti

On Dec 21, 7:17=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> I hope my plea will not be seen as usual "please help me" request. I
> do my (home)work, I try hard but sometimes there come up problems that
> seem very hard to solve, with the current problem, well if there is no
> solution to that, then I wonder how come it has been ever been
> possible to use Xilinx FIFO's with problem at all? So the problem:
>
> Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPTY
> flags present.
>
> signals at input correct, as expected (checked with ChipScope)
> signals at output:
> - double value
> - missing 1, 2 or 3 values
> - FIFO will read out random number of OLD entries, this could be 4
> values, or 50% of the FIFO old values
>
> I can select BRAM or FIFO16 implementation in Coregen, it doesnt
> change the problem
>
> Virtex-4, ISE 10.1SP3
>
> Please help me, if anyone has some good suggestion (except use Altera
> advice), I am getting really desperate. To the extent that when i
> friend called my yesterday, then after my "hello", his first response
> was: "Are you dead?". I had to explain that i am not.
>
> Antti

I'm not sure if this is related but i had a similar problem when using
the FSL v2.11.a core in EDK 10.1 SP3.  In my case it was set up in
synchronous mode.  The problem was lost data whenever there was a
simultaneous read and write at the same time when there was exactly 1
word of data in the FIFO.  It was fixed in v2.11.b of the core in EDK
11.  Perphaps there is something similar happening in the coregen
FIFO.

Cheers
Adam

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

>On Dec 21, 3:21=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:
>> On Dec 21, 5:42=A0am, Antti <antti.luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>> > On Dec 21, 1:29=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>>
>> > > >On Dec 21, 12:32=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>> > > >> Well once you have written and tested your own fifo then you would=
> have
>> > > i=3D
>> > > >t
>> > > >> for any other project. It seems like you have wasted a lot of time
>> > > alread=3D
>> > > >y
>> > > >> trying to fix the Xilinx version so I dont see that you have anyth=
>ing
>> > > to
>> > > >> loose by creating your own.
>>
>> > > >> Jon =3DA0 =3DA0 =3DA0 =3DA0
>>
>> > > >If you REALLY need todo something else, when your time is at absolut=
>e
>> > > >premium
>> > > >And if the system working (except occasional errors about 2 of fiber
>> > > >packets are corrupt)
>> > > >Then you do not go replacing Xilinx validated FIFO solutions with yo=
>ur
>> > > >own, if there are other options.
>>
>> > > >If 2 completly different FIFO implementations both have same error?
>> > > >you think 3rd one would instantly work? Could be, yes.
>>
>> > > >Antti
>>
>> > > In my opinion people tend to use coregen far too often. Looking throu=
>gh
>> > > some of Xilinx code it is awfull. I went down the route of writing my=
> own
>> > > fifos not because I had a problem with Xilinx fifos but because I bel=
>ieve a
>> > > fifo written by myself is a lot more flexible and simulates faster th=
>an the
>> > > Xilinx version. I also know to as good a degree as I can test that it=
> will
>> > > work 100%.
>> > > I dont really think you can say that their fifos have been validated =
>100%
>> > > if they have to release patches for them.
>>
>> > > Jon =A0 =A0 =A0 =A0
>>
>> > Dear Jon,
>>
>> > I do not feel to be in health right now to write this fifo, so here is
>> > the deal:
>>
>> > =A0 component mgt_fifo
>> > =A0 =A0 port (
>> > =A0 =A0 =A0 din =A0 =A0: in =A0std_logic_vector(8 downto 0);
>> > =A0 =A0 =A0 rd_clk : in =A0std_logic;
>> > =A0 =A0 =A0 rd_en =A0: in =A0std_logic;
>> > =A0 =A0 =A0 rst =A0 =A0: in =A0std_logic;
>> > =A0 =A0 =A0 wr_clk : in =A0std_logic;
>> > =A0 =A0 =A0 wr_en =A0: in =A0std_logic;
>> > =A0 =A0 =A0 dout =A0 : out std_logic_vector(8 downto 0);
>> > =A0 =A0 =A0 empty =A0: out std_logic;
>> > =A0 =A0 =A0 full =A0 : out std_logic);
>> > =A0 end component;
>>
>> > if you can write fifo that i can "drop in" and the Xilinx FIFO error
>> > is gone,
>> > then i will stand up, go to postal office and send you 1000 EUR by
>> > western union.
>> > If 1000 EUR is not enough, name your price, i will consider it.
>> > there is no price on the health of our family
>>
>> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay.
>>
>> > Antti
>>
>> Hello Antti,
>>
>> If you want to try a different implementation of a FIFO, you can get
>> the one that the FSL bus uses out of the EDK pcores directory at C:
>> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
>> \vhdl.
>>
>> There are multiple implementations, including an async BRAM based one
>> that has the same ports as you list above, except that it uses exist
>> instead of empty on the read port.
>>
>> That said, I don't expect a third implementation to work instantly
>> when the previous two implementations had the same error. =A0This FIFO
>> has the full source to it, so it is straight forward to see how it
>> works, and add ChipScope to observe what is happening around the time
>> of the error.
>>
>> If you have not used it before, FPGA editor has the ability to find a
>> ChipScope ILA core, and change what is connected to it. That can make
>> it much quicker to follow the trail of clues since you avoid having to
>> go through a full place and route every time you want to look at
>> something different.
>>
>> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
>> mention that the 125 MHz is the recovered clock from the MGT, but
>> there are other options. =A0When we did our GigE interface, we used a
>> 125 MHz clock from the MGT, but it was not the recovered clock, but
>> the local MGT PLL. =A0This let us use the same 125 MHz clock for all
>> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
>> phase aligned with the 125 MHz clock.
>>
>> Regards,
>>
>> John McCaskillwww.FasterTechnology.com
>
>Hi
>
>I have tried all 3 variants possible with coregen,
>all 3 have similar errors
>
>and no, the clocks are not divided version, the 125MHz comes from
>master over fiber
>the master could be 100 hops away, the 62.5mhz is derived from local
>oscillator
>
>so the frequencier are very close but not synchron
>
>Antti
>who has to give up, at least for a while :(
>good advice still welcome, if there is any hope or idea how to fix the
>issue
>and yes it could be power supply issue at the end of the day also

I always write my own fifo's to keep things simple. I keep a write
pointer, read pointer and number of elements counter in the domain
with the highest clock frequency. I don't cross the clock domain
inside the fifo instead I create an interface which does the clock
domain crossing. I also use an early full signal (say max. elements -X
depending on the expected latency). This allows for fast FIFO's (no
cray code counters) with very little logic.

The control logic looks like this:

if read then read_ptr++;
if write then write_ptr++;
if (read=true and write=false) num_elements--;
if (write=true and read=false) num_elements++;

if (num_elements>=(MAX_ELEMENTS-X)) full=true; else full=false;
if (num_elements==0) empty=true;

The external logic should prohibit itself from reading/writing fifo
when its empty or full.

Besides: could your problem be a timing constraint problem? Did you
specify the amount of time signals may travel from one clock domain to
the other? The Xilinx tools are not doing this automatically!

-- 
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 21, 11:29=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> Antti <antti.luk...@googlemail.com> wrote:
> >On Dec 21, 3:21=3DA0pm, John McCaskill <jhmccask...@gmail.com> wrote:
> >> On Dec 21, 5:42=3DA0am, Antti <antti.luk...@googlemail.com> wrote:
>
> >> > On Dec 21, 1:29=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>
> >> > > >On Dec 21, 12:32=3D3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wr=
ote:
> >> > > >> Well once you have written and tested your own fifo then you wo=
uld=3D
> > have
> >> > > i=3D3D
> >> > > >t
> >> > > >> for any other project. It seems like you have wasted a lot of t=
ime
> >> > > alread=3D3D
> >> > > >y
> >> > > >> trying to fix the Xilinx version so I dont see that you have an=
yth=3D
> >ing
> >> > > to
> >> > > >> loose by creating your own.
>
> >> > > >> Jon =3D3DA0 =3D3DA0 =3D3DA0 =3D3DA0
>
> >> > > >If you REALLY need todo something else, when your time is at abso=
lut=3D
> >e
> >> > > >premium
> >> > > >And if the system working (except occasional errors about 2 of fi=
ber
> >> > > >packets are corrupt)
> >> > > >Then you do not go replacing Xilinx validated FIFO solutions with=
 yo=3D
> >ur
> >> > > >own, if there are other options.
>
> >> > > >If 2 completly different FIFO implementations both have same erro=
r?
> >> > > >you think 3rd one would instantly work? Could be, yes.
>
> >> > > >Antti
>
> >> > > In my opinion people tend to use coregen far too often. Looking th=
rou=3D
> >gh
> >> > > some of Xilinx code it is awfull. I went down the route of writing=
 my=3D
> > own
> >> > > fifos not because I had a problem with Xilinx fifos but because I =
bel=3D
> >ieve a
> >> > > fifo written by myself is a lot more flexible and simulates faster=
 th=3D
> >an the
> >> > > Xilinx version. I also know to as good a degree as I can test that=
 it=3D
> > will
> >> > > work 100%.
> >> > > I dont really think you can say that their fifos have been validat=
ed =3D
> >100%
> >> > > if they have to release patches for them.
>
> >> > > Jon =3DA0 =3DA0 =3DA0 =3DA0
>
> >> > Dear Jon,
>
> >> > I do not feel to be in health right now to write this fifo, so here =
is
> >> > the deal:
>
> >> > =3DA0 component mgt_fifo
> >> > =3DA0 =3DA0 port (
> >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 downto=
 0);
> >> > =3DA0 =3DA0 =3DA0 rd_clk : in =3DA0std_logic;
> >> > =3DA0 =3DA0 =3DA0 rd_en =3DA0: in =3DA0std_logic;
> >> > =3DA0 =3DA0 =3DA0 rst =3DA0 =3DA0: in =3DA0std_logic;
> >> > =3DA0 =3DA0 =3DA0 wr_clk : in =3DA0std_logic;
> >> > =3DA0 =3DA0 =3DA0 wr_en =3DA0: in =3DA0std_logic;
> >> > =3DA0 =3DA0 =3DA0 dout =3DA0 : out std_logic_vector(8 downto 0);
> >> > =3DA0 =3DA0 =3DA0 empty =3DA0: out std_logic;
> >> > =3DA0 =3DA0 =3DA0 full =3DA0 : out std_logic);
> >> > =3DA0 end component;
>
> >> > if you can write fifo that i can "drop in" and the Xilinx FIFO error
> >> > is gone,
> >> > then i will stand up, go to postal office and send you 1000 EUR by
> >> > western union.
> >> > If 1000 EUR is not enough, name your price, i will consider it.
> >> > there is no price on the health of our family
>
> >> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay=
..
>
> >> > Antti
>
> >> Hello Antti,
>
> >> If you want to try a different implementation of a FIFO, you can get
> >> the one that the FSL bus uses out of the EDK pcores directory at C:
> >> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
> >> \vhdl.
>
> >> There are multiple implementations, including an async BRAM based one
> >> that has the same ports as you list above, except that it uses exist
> >> instead of empty on the read port.
>
> >> That said, I don't expect a third implementation to work instantly
> >> when the previous two implementations had the same error. =3DA0This FI=
FO
> >> has the full source to it, so it is straight forward to see how it
> >> works, and add ChipScope to observe what is happening around the time
> >> of the error.
>
> >> If you have not used it before, FPGA editor has the ability to find a
> >> ChipScope ILA core, and change what is connected to it. That can make
> >> it much quicker to follow the trail of clues since you avoid having to
> >> go through a full place and route every time you want to look at
> >> something different.
>
> >> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
> >> mention that the 125 MHz is the recovered clock from the MGT, but
> >> there are other options. =3DA0When we did our GigE interface, we used =
a
> >> 125 MHz clock from the MGT, but it was not the recovered clock, but
> >> the local MGT PLL. =3DA0This let us use the same 125 MHz clock for all
> >> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
> >> phase aligned with the 125 MHz clock.
>
> >> Regards,
>
> >> John McCaskillwww.FasterTechnology.com
>
> >Hi
>
> >I have tried all 3 variants possible with coregen,
> >all 3 have similar errors
>
> >and no, the clocks are not divided version, the 125MHz comes from
> >master over fiber
> >the master could be 100 hops away, the 62.5mhz is derived from local
> >oscillator
>
> >so the frequencier are very close but not synchron
>
> >Antti
> >who has to give up, at least for a while :(
> >good advice still welcome, if there is any hope or idea how to fix the
> >issue
> >and yes it could be power supply issue at the end of the day also
>
> I always write my own fifo's to keep things simple. I keep a write
> pointer, read pointer and number of elements counter in the domain
> with the highest clock frequency. I don't cross the clock domain
> inside the fifo instead I create an interface which does the clock
> domain crossing. I also use an early full signal (say max. elements -X
> depending on the expected latency). This allows for fast FIFO's (no
> cray code counters) with very little logic.
>
> The control logic looks like this:
>
> if read then read_ptr++;
> if write then write_ptr++;
> if (read=3Dtrue and write=3Dfalse) num_elements--;
> if (write=3Dtrue and read=3Dfalse) num_elements++;
>
> if (num_elements>=3D(MAX_ELEMENTS-X)) full=3Dtrue; else full=3Dfalse;
> if (num_elements=3D=3D0) empty=3Dtrue;
>
> The external logic should prohibit itself from reading/writing fifo
> when its empty or full.
>
> Besides: could your problem be a timing constraint problem? Did you
> specify the amount of time signals may travel from one clock domain to
> the other? The Xilinx tools are not doing this automatically!
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg=
er hammer!"
> --------------------------------------------------------------

hi

I was already thinking of writing "simplified FIFO" that is would
work under the conditions it is used, the read is done by PPC software
polling so never too often

well the clock domains are fully async, so the clock edges of the read-
write
can have any phase they like

so I assumed if the read and write clock are constrained then it is
enough?

Antti

Antti <antti.lukats@googlemail.com> wrote:
....
> I was already thinking of writing "simplified FIFO" that is would
> work under the conditions it is used, the read is done by PPC software
> polling so never too often

> well the clock domains are fully async, so the clock edges of the read-
> write
> can have any phase they like

> so I assumed if the read and write clock are constrained then it is
> enough?

Did you try Opencore FIFO?

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

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

Antti wrote:
> On Dec 21, 10:21 pm, Peter Alfke <al...@sbcglobal.net> wrote:
>> On Dec 21, 11:58 am, Antti <antti.luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>>> On Dec 21, 9:50 pm, Peter Alfke <al...@sbcglobal.net> wrote:
>>>> On Dec 21, 9:30 am, Antti <antti.luk...@googlemail.com> wrote:
>>>>> On Dec 21, 7:20 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>>>>>> On Dec 21, 3:01 am, Antti <antti.luk...@googlemail.com> wrote:
>>>>>>> On Dec 21, 12:56 pm, Symon <symon_bre...@hotmail.com> wrote:
>>>>>>>> Antti wrote:
>>>>>>>>> Xilinx Coregen FIFO, dual clock, most options disable, only FULL EMPTY
>>>>>>>>> flags present.
>>>>>>>>> signals at input correct, as expected (checked with ChipScope)
>>>>>>>>> signals at output:
>>>>>>>>> - double value
>>>>>>>>> - missing 1, 2 or 3 values
>>>>>>>>> - FIFO will read out random number of OLD entries, this could be 4
>>>>>>>>> values, or 50% of the FIFO old values
>>>>>>>> I know you will have read this.
>>>>>>>> Can you think of any reason why the Xilinx work-around wouldn't work
>>>>>>>> because of your specific implementation? It seems to have different
>>>>>>>> work-arounds depending on whether the read clock is faster or slower
>>>>>>>> than the write clock. Do your clocks change frequency?
>>>>>>>> Are you sure your clocks don't have any glitches? The reset also?
>>>>>>>> Power's OK? Is your office made of Cobalt 60?
>>>>>>>> HTH., Syms.
>>>>>>> 1) I entered the clock figures in FIFO16 implementationm, but the
>>>>>>> error also happens with BRAM based FIFO that do not need workarounds
>>>>>>> 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125MHz write,
>>>>>>> one is PLB clock 62.5MHz read
>>>>>>> 3) Power OK? Well the problem happens at 2 different sites, hm yes it
>>>>>>> could be still be power problem
>>>>>>> 4) My office is not of Cobalt 60, ... and its cold here too
>>>>>>> Antti- Hide quoted text -
>>>>>>> - Show quoted text -
>>>>>> Are you sure that this is a FIFO issue and not something else?  Some
>>>>>> things to think about.
>>>>>> 1) The recovered clock from the MGT is a bit noisy as it moves as the
>>>>>> CDR moves.  Why are you using this instead of the REFCLK source?
>>>>>> 2) It seems like you have a PLB core that is reading from the FIFO,
>>>>>> could the problem be in this?
>>>>>> Ed McGettigan
>>>>>> --
>>>>>> Xilinx Inc.
>>>>> Well the MGT datapath and clock system is not done by me, and the guy
>>>>> says it is OK all the way it is connected.
>>>>> yes, It is very unlikely to belive that all THREE types of coregen
>>>>> FIFO's fail with about same symptoms, but in all
>>>>> 3 cased Chipscope sees correct data into fifo, and trash coming out
>>>>> the system can span up to 100 boards, all synced to master unit, the
>>>>> local refclk is not fully sync to the clock of
>>>>> the master unit, so I see no way to use this clock to syncronise the
>>>>> fifo?
>>>>> Antti
>>>>> PS I just received a attempt to collect the reward, by using non
>>>>> xilinx FIFO implementation, i let you all know
>>>>> the test results
>>>> Antti
>>>> If I remember right (I am no longer at Xilinx) the FIFO is NOT
>>>> designed for unequal data width of write and read. (Reason: possible
>>>> ambiguity of Full and EMPTY)
>>>> Since you use two clocks that are roughly 2:1 in frequency, I hope
>>>> that you do not try to have double width on one of the ports.
>>>> The FIFO must have the same width on both ports. You must design the
>>>> width conversion outside the FIFO. That little circuit will be
>>>> synchronous and thus quite simple.
>>>> Peter Alfke
>>> well the FIFO is 9b in 9b out so it should work?
>>> at least this is what i hoped...
>>> we did not suspect the FIFO as problem at first
>>> so spent LOT of time looking for the problem AROUND the FIFOS
>>> but.. at least based on what i can see from CS snapshots on fifo
>>> inputs and outputs, the only explanation i have is that the FIFO
>>> are just goind mad,
>>> of course one option is that its me doing, but i have someone
>>> who is in better shape looking over the code as well, and he
>>> sees no issues there either. I know the FIFOs should work
>>> so there must be some explanation, but so far failing to see it.
>>> Antti
>>> PS thank you Peter for the response
>> OK, Antti,
>> so you have the same port width, but one clock is about twice as fast
>> as the other.
>> How do you stop the 125 MHz write clock from filling up the FIFO,
>> since you read at only 62 MHz ?
>> I hope you are not gating the clock, but rather run it continuously
>> and use WE to stop the writing.
>> Yes, many of these suggestions are well below your level, but stupid
>> problems need stupid investigations.
>> Cheers
>> Peter
> 
> I am level below ground right now the project is just driving me nuts.
> slowly.
> To work for months, and end up with Xilinx saying:
> The man who could have helped you, left Xilinx last friday. Your
> situation is unsupportable.
> Well we got out of that situation.
> To end up in the new ones.
> 
> The FIFO is never over filled by design.
> The fiber link is 99% IDLE sending usually only short 10byte packets
> over the link.
> 
> For tesing I generate 10 byte pakets with MOUSE so 1 per second so
> there is no doubt
> the FIFO is never near full at all.
> 
> Last results:
> - ALL 3 types of Xilinx FIFO's same style of errors, about same error
> rate
Looking at UG175 The document says that you should hold WR and RD in the 
inactive state whilst resetting the device. The number of reset clock 
cycles needed for each condition is documented.

UG175 is here:- 
www.xilinx.com/support/documentation/ip.../fifo_generator_ug175.pdf

> - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
> LESS errors then Xilinx implementation, but still all different types
> of error did occour: missing values, and FIFO outputtin large junk of
> OLD values, that is read pointer changing by some random value

This implies the fault is not the fifo but what is driving it. Can you 
route the signals to a port and monitor the port with a scope?

Does this occur on the bench and in the simulator?

I am still learning design so if I'm teaching you to suck eggs you have 
my apologies. Andy
> 
> again, I did not design the MGT clocking and the overall MGT
> subsystem, the people who did are either unreachable or unable to
> provide any help beyound saying that the implementation (connection of
> the FIFO) is done properly. It is also what I have figured out so far,
> but.. well somewhere must be problem.
> 
> Antti

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

>On Dec 21, 11:29=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> Antti <antti.luk...@googlemail.com> wrote:
>> >On Dec 21, 3:21=3DA0pm, John McCaskill <jhmccask...@gmail.com> wrote:
>> >> On Dec 21, 5:42=3DA0am, Antti <antti.luk...@googlemail.com> wrote:
>>
>> >> > On Dec 21, 1:29=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>>
>> >> > > >On Dec 21, 12:32=3D3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wr=
>ote:
>> >> > > >> Well once you have written and tested your own fifo then you wo=
>uld=3D
>> > have
>> >> > > i=3D3D
>> >> > > >t
>> >> > > >> for any other project. It seems like you have wasted a lot of t=
>ime
>> >> > > alread=3D3D
>> >> > > >y
>> >> > > >> trying to fix the Xilinx version so I dont see that you have an=
>yth=3D
>> >ing
>> >> > > to
>> >> > > >> loose by creating your own.
>>
>> >> > > >> Jon =3D3DA0 =3D3DA0 =3D3DA0 =3D3DA0
>>
>> >> > > >If you REALLY need todo something else, when your time is at abso=
>lut=3D
>> >e
>> >> > > >premium
>> >> > > >And if the system working (except occasional errors about 2 of fi=
>ber
>> >> > > >packets are corrupt)
>> >> > > >Then you do not go replacing Xilinx validated FIFO solutions with=
> yo=3D
>> >ur
>> >> > > >own, if there are other options.
>>
>> >> > > >If 2 completly different FIFO implementations both have same erro=
>r?
>> >> > > >you think 3rd one would instantly work? Could be, yes.
>>
>> >> > > >Antti
>>
>> >> > > In my opinion people tend to use coregen far too often. Looking th=
>rou=3D
>> >gh
>> >> > > some of Xilinx code it is awfull. I went down the route of writing=
> my=3D
>> > own
>> >> > > fifos not because I had a problem with Xilinx fifos but because I =
>bel=3D
>> >ieve a
>> >> > > fifo written by myself is a lot more flexible and simulates faster=
> th=3D
>> >an the
>> >> > > Xilinx version. I also know to as good a degree as I can test that=
> it=3D
>> > will
>> >> > > work 100%.
>> >> > > I dont really think you can say that their fifos have been validat=
>ed =3D
>> >100%
>> >> > > if they have to release patches for them.
>>
>> >> > > Jon =3DA0 =3DA0 =3DA0 =3DA0
>>
>> >> > Dear Jon,
>>
>> >> > I do not feel to be in health right now to write this fifo, so here =
>is
>> >> > the deal:
>>
>> >> > =3DA0 component mgt_fifo
>> >> > =3DA0 =3DA0 port (
>> >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 downto=
> 0);
>> >> > =3DA0 =3DA0 =3DA0 rd_clk : in =3DA0std_logic;
>> >> > =3DA0 =3DA0 =3DA0 rd_en =3DA0: in =3DA0std_logic;
>> >> > =3DA0 =3DA0 =3DA0 rst =3DA0 =3DA0: in =3DA0std_logic;
>> >> > =3DA0 =3DA0 =3DA0 wr_clk : in =3DA0std_logic;
>> >> > =3DA0 =3DA0 =3DA0 wr_en =3DA0: in =3DA0std_logic;
>> >> > =3DA0 =3DA0 =3DA0 dout =3DA0 : out std_logic_vector(8 downto 0);
>> >> > =3DA0 =3DA0 =3DA0 empty =3DA0: out std_logic;
>> >> > =3DA0 =3DA0 =3DA0 full =3DA0 : out std_logic);
>> >> > =3DA0 end component;
>>
>> >> > if you can write fifo that i can "drop in" and the Xilinx FIFO error
>> >> > is gone,
>> >> > then i will stand up, go to postal office and send you 1000 EUR by
>> >> > western union.
>> >> > If 1000 EUR is not enough, name your price, i will consider it.
>> >> > there is no price on the health of our family
>>
>> >> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no pay=
>.
>>
>> >> > Antti
>>
>> >> Hello Antti,
>>
>> >> If you want to try a different implementation of a FIFO, you can get
>> >> the one that the FSL bus uses out of the EDK pcores directory at C:
>> >> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
>> >> \vhdl.
>>
>> >> There are multiple implementations, including an async BRAM based one
>> >> that has the same ports as you list above, except that it uses exist
>> >> instead of empty on the read port.
>>
>> >> That said, I don't expect a third implementation to work instantly
>> >> when the previous two implementations had the same error. =3DA0This FI=
>FO
>> >> has the full source to it, so it is straight forward to see how it
>> >> works, and add ChipScope to observe what is happening around the time
>> >> of the error.
>>
>> >> If you have not used it before, FPGA editor has the ability to find a
>> >> ChipScope ILA core, and change what is connected to it. That can make
>> >> it much quicker to follow the trail of clues since you avoid having to
>> >> go through a full place and route every time you want to look at
>> >> something different.
>>
>> >> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
>> >> mention that the 125 MHz is the recovered clock from the MGT, but
>> >> there are other options. =3DA0When we did our GigE interface, we used =
>a
>> >> 125 MHz clock from the MGT, but it was not the recovered clock, but
>> >> the local MGT PLL. =3DA0This let us use the same 125 MHz clock for all
>> >> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
>> >> phase aligned with the 125 MHz clock.
>>
>> >> Regards,
>>
>> >> John McCaskillwww.FasterTechnology.com
>>
>> >Hi
>>
>> >I have tried all 3 variants possible with coregen,
>> >all 3 have similar errors
>>
>> >and no, the clocks are not divided version, the 125MHz comes from
>> >master over fiber
>> >the master could be 100 hops away, the 62.5mhz is derived from local
>> >oscillator
>>
>> >so the frequencier are very close but not synchron
>>
>> >Antti
>> >who has to give up, at least for a while :(
>> >good advice still welcome, if there is any hope or idea how to fix the
>> >issue
>> >and yes it could be power supply issue at the end of the day also
>>
>> I always write my own fifo's to keep things simple. I keep a write
>> pointer, read pointer and number of elements counter in the domain
>> with the highest clock frequency. I don't cross the clock domain
>> inside the fifo instead I create an interface which does the clock
>> domain crossing. I also use an early full signal (say max. elements -X
>> depending on the expected latency). This allows for fast FIFO's (no
>> cray code counters) with very little logic.
>>
>> The control logic looks like this:
>>
>> if read then read_ptr++;
>> if write then write_ptr++;
>> if (read=3Dtrue and write=3Dfalse) num_elements--;
>> if (write=3Dtrue and read=3Dfalse) num_elements++;
>>
>> if (num_elements>=3D(MAX_ELEMENTS-X)) full=3Dtrue; else full=3Dfalse;
>> if (num_elements=3D=3D0) empty=3Dtrue;
>>
>> The external logic should prohibit itself from reading/writing fifo
>> when its empty or full.
>>
>> Besides: could your problem be a timing constraint problem? Did you
>> specify the amount of time signals may travel from one clock domain to
>> the other? The Xilinx tools are not doing this automatically!
>>
>
>hi
>
>I was already thinking of writing "simplified FIFO" that is would
>work under the conditions it is used, the read is done by PPC software
>polling so never too often
>
>well the clock domains are fully async, so the clock edges of the read-
>write
>can have any phase they like
>
>so I assumed if the read and write clock are constrained then it is
>enough?

IIRC there is some constraint that ignores the clock but only
specifies the delays in the paths. Thats what you want with unrelated
clocks. I just can't find it in the ISE7.1 docs and I don't have a
newer version installed at this moment.

IMHO for some reason a counter gets messed up. This probably means
there is more then one signal crossing the clock domain boundary or
the signal crossing the boundary isn't synchronised with the domain
before using it.

-- 
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 21, 1:12=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
>
>
> > On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wr=
ote:
>
> > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote=
:
>
> > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote=
:
>
> > > > > > > > Antti wrote:
>
> > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, on=
ly FULL EMPTY
> > > > > > > > > flags present.
>
> > > > > > > > > signals at input correct, as expected (checked with ChipS=
cope)
> > > > > > > > > signals at output:
> > > > > > > > > - double value
> > > > > > > > > - missing 1, 2 or 3 values
> > > > > > > > > - FIFO will read out random number of OLD entries, this c=
ould be 4
> > > > > > > > > values, or 50% of the FIFO old values
>
> > > > > > > > I know you will have read this.
>
> > > > > > > > Can you think of any reason why the Xilinx work-around woul=
dn't work
> > > > > > > > because of your specific implementation? It seems to have d=
ifferent
> > > > > > > > work-arounds depending on whether the read clock is faster =
or slower
> > > > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > > > Are you sure your clocks don't have any glitches? The reset=
 also?
> > > > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > > > HTH., Syms.
>
> > > > > > > 1) I entered the clock figures in FIFO16 implementationm, but=
 the
> > > > > > > error also happens with BRAM based FIFO that do not need work=
arounds
> > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125M=
Hz write,
> > > > > > > one is PLB clock 62.5MHz read
> > > > > > > 3) Power OK? Well the problem happens at 2 different sites, h=
m yes it
> > > > > > > could be still be power problem
>
> > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > > > Antti- Hide quoted text -
>
> > > > > > > - Show quoted text -
>
> > > > > > Are you sure that this is a FIFO issue and not something else? =
=A0Some
> > > > > > things to think about.
>
> > > > > > 1) The recovered clock from the MGT is a bit noisy as it moves =
as the
> > > > > > CDR moves. =A0Why are you using this instead of the REFCLK sour=
ce?
>
> > > > > > 2) It seems like you have a PLB core that is reading from the F=
IFO,
> > > > > > could the problem be in this?
>
> > > > > > Ed McGettigan
> > > > > > --
> > > > > > Xilinx Inc.
>
> > > > > Well the MGT datapath and clock system is not done by me, and the=
 guy
> > > > > says it is OK all the way it is connected.
>
> > > > > yes, It is very unlikely to belive that all THREE types of corege=
n
> > > > > FIFO's fail with about same symptoms, but in all
> > > > > 3 cased Chipscope sees correct data into fifo, and trash coming o=
ut
>
> > > > > the system can span up to 100 boards, all synced to master unit, =
the
> > > > > local refclk is not fully sync to the clock of
> > > > > the master unit, so I see no way to use this clock to syncronise =
the
> > > > > fifo?
>
> > > > > Antti
> > > > > PS I just received a attempt to collect the reward, by using non
> > > > > xilinx FIFO implementation, i let you all know
> > > > > the test results
>
> > > > Antti
> > > > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > > > designed for unequal data width of write and read. (Reason: possibl=
e
> > > > ambiguity of Full and EMPTY)
> > > > Since you use two clocks that are roughly 2:1 in frequency, I hope
> > > > that you do not try to have double width on one of the ports.
> > > > The FIFO must have the same width on both ports. You must design th=
e
> > > > width conversion outside the FIFO. That little circuit will be
> > > > synchronous and thus quite simple.
> > > > Peter Alfke
>
> > > well the FIFO is 9b in 9b out so it should work?
> > > at least this is what i hoped...
>
> > > we did not suspect the FIFO as problem at first
> > > so spent LOT of time looking for the problem AROUND the FIFOS
> > > but.. at least based on what i can see from CS snapshots on fifo
> > > inputs and outputs, the only explanation i have is that the FIFO
> > > are just goind mad,
>
> > > of course one option is that its me doing, but i have someone
> > > who is in better shape looking over the code as well, and he
> > > sees no issues there either. I know the FIFOs should work
> > > so there must be some explanation, but so far failing to see it.
>
> > > Antti
> > > PS thank you Peter for the response
>
> > OK, Antti,
> > so you have the same port width, but one clock is about twice as fast
> > as the other.
> > How do you stop the 125 MHz write clock from filling up the FIFO,
> > since you read at only 62 MHz ?
> > I hope you are not gating the clock, but rather run it continuously
> > and use WE to stop the writing.
> > Yes, many of these suggestions are well below your level, but stupid
> > problems need stupid investigations.
> > Cheers
> > Peter
>
> I am level below ground right now the project is just driving me nuts.
> slowly.
> To work for months, and end up with Xilinx saying:
> The man who could have helped you, left Xilinx last friday. Your
> situation is unsupportable.
> Well we got out of that situation.
> To end up in the new ones.
>
> The FIFO is never over filled by design.
> The fiber link is 99% IDLE sending usually only short 10byte packets
> over the link.
>
> For tesing I generate 10 byte pakets with MOUSE so 1 per second so
> there is no doubt
> the FIFO is never near full at all.
>
> Last results:
> - ALL 3 types of Xilinx FIFO's same style of errors, about same error
> rate
> - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
> LESS errors then Xilinx implementation, but still all different types
> of error did occour: missing values, and FIFO outputtin large junk of
> OLD values, that is read pointer changing by some random value
>
> again, I did not design the MGT clocking and the overall MGT
> subsystem, the people who did are either unreachable or unable to
> provide any help beyound saying that the implementation (connection of
> the FIFO) is done properly. It is also what I have figured out so far,
> but.. well somewhere must be problem.
>
> Antti

Antti, my very simple question:
Do the two clocks (125 and 62 MHz) run continuously? They should, or
more precisely: THEY MUST, and all speed control is to be done by WE
and RE.
I am sure that's covered in the User Guide.
Peter

On Dec 21, 1:12=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
>
>
> > On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wr=
ote:
>
> > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote=
:
>
> > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote=
:
>
> > > > > > > > Antti wrote:
>
> > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, on=
ly FULL EMPTY
> > > > > > > > > flags present.
>
> > > > > > > > > signals at input correct, as expected (checked with ChipS=
cope)
> > > > > > > > > signals at output:
> > > > > > > > > - double value
> > > > > > > > > - missing 1, 2 or 3 values
> > > > > > > > > - FIFO will read out random number of OLD entries, this c=
ould be 4
> > > > > > > > > values, or 50% of the FIFO old values
>
> > > > > > > > I know you will have read this.
>
> > > > > > > > Can you think of any reason why the Xilinx work-around woul=
dn't work
> > > > > > > > because of your specific implementation? It seems to have d=
ifferent
> > > > > > > > work-arounds depending on whether the read clock is faster =
or slower
> > > > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > > > Are you sure your clocks don't have any glitches? The reset=
 also?
> > > > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > > > HTH., Syms.
>
> > > > > > > 1) I entered the clock figures in FIFO16 implementationm, but=
 the
> > > > > > > error also happens with BRAM based FIFO that do not need work=
arounds
> > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125M=
Hz write,
> > > > > > > one is PLB clock 62.5MHz read
> > > > > > > 3) Power OK? Well the problem happens at 2 different sites, h=
m yes it
> > > > > > > could be still be power problem
>
> > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > > > Antti- Hide quoted text -
>
> > > > > > > - Show quoted text -
>
> > > > > > Are you sure that this is a FIFO issue and not something else? =
=A0Some
> > > > > > things to think about.
>
> > > > > > 1) The recovered clock from the MGT is a bit noisy as it moves =
as the
> > > > > > CDR moves. =A0Why are you using this instead of the REFCLK sour=
ce?
>
> > > > > > 2) It seems like you have a PLB core that is reading from the F=
IFO,
> > > > > > could the problem be in this?
>
> > > > > > Ed McGettigan
> > > > > > --
> > > > > > Xilinx Inc.
>
> > > > > Well the MGT datapath and clock system is not done by me, and the=
 guy
> > > > > says it is OK all the way it is connected.
>
> > > > > yes, It is very unlikely to belive that all THREE types of corege=
n
> > > > > FIFO's fail with about same symptoms, but in all
> > > > > 3 cased Chipscope sees correct data into fifo, and trash coming o=
ut
>
> > > > > the system can span up to 100 boards, all synced to master unit, =
the
> > > > > local refclk is not fully sync to the clock of
> > > > > the master unit, so I see no way to use this clock to syncronise =
the
> > > > > fifo?
>
> > > > > Antti
> > > > > PS I just received a attempt to collect the reward, by using non
> > > > > xilinx FIFO implementation, i let you all know
> > > > > the test results
>
> > > > Antti
> > > > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > > > designed for unequal data width of write and read. (Reason: possibl=
e
> > > > ambiguity of Full and EMPTY)
> > > > Since you use two clocks that are roughly 2:1 in frequency, I hope
> > > > that you do not try to have double width on one of the ports.
> > > > The FIFO must have the same width on both ports. You must design th=
e
> > > > width conversion outside the FIFO. That little circuit will be
> > > > synchronous and thus quite simple.
> > > > Peter Alfke
>
> > > well the FIFO is 9b in 9b out so it should work?
> > > at least this is what i hoped...
>
> > > we did not suspect the FIFO as problem at first
> > > so spent LOT of time looking for the problem AROUND the FIFOS
> > > but.. at least based on what i can see from CS snapshots on fifo
> > > inputs and outputs, the only explanation i have is that the FIFO
> > > are just goind mad,
>
> > > of course one option is that its me doing, but i have someone
> > > who is in better shape looking over the code as well, and he
> > > sees no issues there either. I know the FIFOs should work
> > > so there must be some explanation, but so far failing to see it.
>
> > > Antti
> > > PS thank you Peter for the response
>
> > OK, Antti,
> > so you have the same port width, but one clock is about twice as fast
> > as the other.
> > How do you stop the 125 MHz write clock from filling up the FIFO,
> > since you read at only 62 MHz ?
> > I hope you are not gating the clock, but rather run it continuously
> > and use WE to stop the writing.
> > Yes, many of these suggestions are well below your level, but stupid
> > problems need stupid investigations.
> > Cheers
> > Peter
>
> I am level below ground right now the project is just driving me nuts.
> slowly.
> To work for months, and end up with Xilinx saying:
> The man who could have helped you, left Xilinx last friday. Your
> situation is unsupportable.
> Well we got out of that situation.
> To end up in the new ones.
>
> The FIFO is never over filled by design.
> The fiber link is 99% IDLE sending usually only short 10byte packets
> over the link.
>
> For tesing I generate 10 byte pakets with MOUSE so 1 per second so
> there is no doubt
> the FIFO is never near full at all.
>
> Last results:
> - ALL 3 types of Xilinx FIFO's same style of errors, about same error
> rate
> - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
> LESS errors then Xilinx implementation, but still all different types
> of error did occour: missing values, and FIFO outputtin large junk of
> OLD values, that is read pointer changing by some random value
>
> again, I did not design the MGT clocking and the overall MGT
> subsystem, the people who did are either unreachable or unable to
> provide any help beyound saying that the implementation (connection of
> the FIFO) is done properly. It is also what I have figured out so far,
> but.. well somewhere must be problem.
>
> Antti- Hide quoted text -
>
> - Show quoted text -

Since you can't get further on the MGT clocking circuit topology, what
about the 62.5 MHz read clock?  How is this generated?  It sounds like
it could be glitching.

In one of your other posts, you had mention that ChipScope had shown
that the write data was correct and that the read data wasn't.  Did
you have two separate ILA cores with the 125 MHz and 62.5 MHz clocks
when you did this testing?

Ed McGettigan
--
Xilinx Inc

On Dec 21, 4:43=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 11:29=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>
>
>
> > Antti <antti.luk...@googlemail.com> wrote:
> > >On Dec 21, 3:21=3DA0pm, John McCaskill <jhmccask...@gmail.com> wrote:
> > >> On Dec 21, 5:42=3DA0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > >> > On Dec 21, 1:29=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>
> > >> > > >On Dec 21, 12:32=3D3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> =
wrote:
> > >> > > >> Well once you have written and tested your own fifo then you =
would=3D
> > > have
> > >> > > i=3D3D
> > >> > > >t
> > >> > > >> for any other project. It seems like you have wasted a lot of=
 time
> > >> > > alread=3D3D
> > >> > > >y
> > >> > > >> trying to fix the Xilinx version so I dont see that you have =
anyth=3D
> > >ing
> > >> > > to
> > >> > > >> loose by creating your own.
>
> > >> > > >> Jon =3D3DA0 =3D3DA0 =3D3DA0 =3D3DA0
>
> > >> > > >If you REALLY need todo something else, when your time is at ab=
solut=3D
> > >e
> > >> > > >premium
> > >> > > >And if the system working (except occasional errors about 2 of =
fiber
> > >> > > >packets are corrupt)
> > >> > > >Then you do not go replacing Xilinx validated FIFO solutions wi=
th yo=3D
> > >ur
> > >> > > >own, if there are other options.
>
> > >> > > >If 2 completly different FIFO implementations both have same er=
ror?
> > >> > > >you think 3rd one would instantly work? Could be, yes.
>
> > >> > > >Antti
>
> > >> > > In my opinion people tend to use coregen far too often. Looking =
throu=3D
> > >gh
> > >> > > some of Xilinx code it is awfull. I went down the route of writi=
ng my=3D
> > > own
> > >> > > fifos not because I had a problem with Xilinx fifos but because =
I bel=3D
> > >ieve a
> > >> > > fifo written by myself is a lot more flexible and simulates fast=
er th=3D
> > >an the
> > >> > > Xilinx version. I also know to as good a degree as I can test th=
at it=3D
> > > will
> > >> > > work 100%.
> > >> > > I dont really think you can say that their fifos have been valid=
ated =3D
> > >100%
> > >> > > if they have to release patches for them.
>
> > >> > > Jon =3DA0 =3DA0 =3DA0 =3DA0
>
> > >> > Dear Jon,
>
> > >> > I do not feel to be in health right now to write this fifo, so her=
e is
> > >> > the deal:
>
> > >> > =3DA0 component mgt_fifo
> > >> > =3DA0 =3DA0 port (
> > >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 down=
to 0);
> > >> > =3DA0 =3DA0 =3DA0 rd_clk : in =3DA0std_logic;
> > >> > =3DA0 =3DA0 =3DA0 rd_en =3DA0: in =3DA0std_logic;
> > >> > =3DA0 =3DA0 =3DA0 rst =3DA0 =3DA0: in =3DA0std_logic;
> > >> > =3DA0 =3DA0 =3DA0 wr_clk : in =3DA0std_logic;
> > >> > =3DA0 =3DA0 =3DA0 wr_en =3DA0: in =3DA0std_logic;
> > >> > =3DA0 =3DA0 =3DA0 dout =3DA0 : out std_logic_vector(8 downto 0);
> > >> > =3DA0 =3DA0 =3DA0 empty =3DA0: out std_logic;
> > >> > =3DA0 =3DA0 =3DA0 full =3DA0 : out std_logic);
> > >> > =3DA0 end component;
>
> > >> > if you can write fifo that i can "drop in" and the Xilinx FIFO err=
or
> > >> > is gone,
> > >> > then i will stand up, go to postal office and send you 1000 EUR by
> > >> > western union.
> > >> > If 1000 EUR is not enough, name your price, i will consider it.
> > >> > there is no price on the health of our family
>
> > >> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no p=
ay.
>
> > >> > Antti
>
> > >> Hello Antti,
>
> > >> If you want to try a different implementation of a FIFO, you can get
> > >> the one that the FSL bus uses out of the EDK pcores directory at C:
> > >> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hdl
> > >> \vhdl.
>
> > >> There are multiple implementations, including an async BRAM based on=
e
> > >> that has the same ports as you list above, except that it uses exist
> > >> instead of empty on the read port.
>
> > >> That said, I don't expect a third implementation to work instantly
> > >> when the previous two implementations had the same error. =3DA0This =
FIFO
> > >> has the full source to it, so it is straight forward to see how it
> > >> works, and add ChipScope to observe what is happening around the tim=
e
> > >> of the error.
>
> > >> If you have not used it before, FPGA editor has the ability to find =
a
> > >> ChipScope ILA core, and change what is connected to it. That can mak=
e
> > >> it much quicker to follow the trail of clues since you avoid having =
to
> > >> go through a full place and route every time you want to look at
> > >> something different.
>
> > >> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
> > >> mention that the 125 MHz is the recovered clock from the MGT, but
> > >> there are other options. =3DA0When we did our GigE interface, we use=
d a
> > >> 125 MHz clock from the MGT, but it was not the recovered clock, but
> > >> the local MGT PLL. =3DA0This let us use the same 125 MHz clock for a=
ll
> > >> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that is
> > >> phase aligned with the 125 MHz clock.
>
> > >> Regards,
>
> > >> John McCaskillwww.FasterTechnology.com
>
> > >Hi
>
> > >I have tried all 3 variants possible with coregen,
> > >all 3 have similar errors
>
> > >and no, the clocks are not divided version, the 125MHz comes from
> > >master over fiber
> > >the master could be 100 hops away, the 62.5mhz is derived from local
> > >oscillator
>
> > >so the frequencier are very close but not synchron
>
> > >Antti
> > >who has to give up, at least for a while :(
> > >good advice still welcome, if there is any hope or idea how to fix the
> > >issue
> > >and yes it could be power supply issue at the end of the day also
>
> > I always write my own fifo's to keep things simple. I keep a write
> > pointer, read pointer and number of elements counter in the domain
> > with the highest clock frequency. I don't cross the clock domain
> > inside the fifo instead I create an interface which does the clock
> > domain crossing. I also use an early full signal (say max. elements -X
> > depending on the expected latency). This allows for fast FIFO's (no
> > cray code counters) with very little logic.
>
> > The control logic looks like this:
>
> > if read then read_ptr++;
> > if write then write_ptr++;
> > if (read=3Dtrue and write=3Dfalse) num_elements--;
> > if (write=3Dtrue and read=3Dfalse) num_elements++;
>
> > if (num_elements>=3D(MAX_ELEMENTS-X)) full=3Dtrue; else full=3Dfalse;
> > if (num_elements=3D=3D0) empty=3Dtrue;
>
> > The external logic should prohibit itself from reading/writing fifo
> > when its empty or full.
>
> > Besides: could your problem be a timing constraint problem? Did you
> > specify the amount of time signals may travel from one clock domain to
> > the other? The Xilinx tools are not doing this automatically!
>
> > --
> > Failure does not prove something is impossible, failure simply
> > indicates you are not using the right tools...
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bi=
gger hammer!"
> > --------------------------------------------------------------
>
> hi
>
> I was already thinking of writing "simplified FIFO" that is would
> work under the conditions it is used, the read is done by PPC software
> polling so never too often
>
> well the clock domains are fully async, so the clock edges of the read-
> write
> can have any phase they like
>
> so I assumed if the read and write clock are constrained then it is
> enough?
>
> Antti

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 data
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

On Dec 22, 1:12=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Dec 21, 1:12=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> =
wrote:
>
> > > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wro=
te:
>
> > > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wro=
te:
>
> > > > > > > > > Antti wrote:
>
> > > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, =
only FULL EMPTY
> > > > > > > > > > flags present.
>
> > > > > > > > > > signals at input correct, as expected (checked with Chi=
pScope)
> > > > > > > > > > signals at output:
> > > > > > > > > > - double value
> > > > > > > > > > - missing 1, 2 or 3 values
> > > > > > > > > > - FIFO will read out random number of OLD entries, this=
 could be 4
> > > > > > > > > > values, or 50% of the FIFO old values
>
> > > > > > > > > I know you will have read this.
>
> > > > > > > > > Can you think of any reason why the Xilinx work-around wo=
uldn't work
> > > > > > > > > because of your specific implementation? It seems to have=
 different
> > > > > > > > > work-arounds depending on whether the read clock is faste=
r or slower
> > > > > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > > > > Are you sure your clocks don't have any glitches? The res=
et also?
> > > > > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > > > > HTH., Syms.
>
> > > > > > > > 1) I entered the clock figures in FIFO16 implementationm, b=
ut the
> > > > > > > > error also happens with BRAM based FIFO that do not need wo=
rkarounds
> > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 12=
5MHz write,
> > > > > > > > one is PLB clock 62.5MHz read
> > > > > > > > 3) Power OK? Well the problem happens at 2 different sites,=
 hm yes it
> > > > > > > > could be still be power problem
>
> > > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > > > > Antti- Hide quoted text -
>
> > > > > > > > - Show quoted text -
>
> > > > > > > Are you sure that this is a FIFO issue and not something else=
? =A0Some
> > > > > > > things to think about.
>
> > > > > > > 1) The recovered clock from the MGT is a bit noisy as it move=
s as the
> > > > > > > CDR moves. =A0Why are you using this instead of the REFCLK so=
urce?
>
> > > > > > > 2) It seems like you have a PLB core that is reading from the=
 FIFO,
> > > > > > > could the problem be in this?
>
> > > > > > > Ed McGettigan
> > > > > > > --
> > > > > > > Xilinx Inc.
>
> > > > > > Well the MGT datapath and clock system is not done by me, and t=
he guy
> > > > > > says it is OK all the way it is connected.
>
> > > > > > yes, It is very unlikely to belive that all THREE types of core=
gen
> > > > > > FIFO's fail with about same symptoms, but in all
> > > > > > 3 cased Chipscope sees correct data into fifo, and trash coming=
 out
>
> > > > > > the system can span up to 100 boards, all synced to master unit=
, the
> > > > > > local refclk is not fully sync to the clock of
> > > > > > the master unit, so I see no way to use this clock to syncronis=
e the
> > > > > > fifo?
>
> > > > > > Antti
> > > > > > PS I just received a attempt to collect the reward, by using no=
n
> > > > > > xilinx FIFO implementation, i let you all know
> > > > > > the test results
>
> > > > > Antti
> > > > > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > > > > designed for unequal data width of write and read. (Reason: possi=
ble
> > > > > ambiguity of Full and EMPTY)
> > > > > Since you use two clocks that are roughly 2:1 in frequency, I hop=
e
> > > > > that you do not try to have double width on one of the ports.
> > > > > The FIFO must have the same width on both ports. You must design =
the
> > > > > width conversion outside the FIFO. That little circuit will be
> > > > > synchronous and thus quite simple.
> > > > > Peter Alfke
>
> > > > well the FIFO is 9b in 9b out so it should work?
> > > > at least this is what i hoped...
>
> > > > we did not suspect the FIFO as problem at first
> > > > so spent LOT of time looking for the problem AROUND the FIFOS
> > > > but.. at least based on what i can see from CS snapshots on fifo
> > > > inputs and outputs, the only explanation i have is that the FIFO
> > > > are just goind mad,
>
> > > > of course one option is that its me doing, but i have someone
> > > > who is in better shape looking over the code as well, and he
> > > > sees no issues there either. I know the FIFOs should work
> > > > so there must be some explanation, but so far failing to see it.
>
> > > > Antti
> > > > PS thank you Peter for the response
>
> > > OK, Antti,
> > > so you have the same port width, but one clock is about twice as fast
> > > as the other.
> > > How do you stop the 125 MHz write clock from filling up the FIFO,
> > > since you read at only 62 MHz ?
> > > I hope you are not gating the clock, but rather run it continuously
> > > and use WE to stop the writing.
> > > Yes, many of these suggestions are well below your level, but stupid
> > > problems need stupid investigations.
> > > Cheers
> > > Peter
>
> > I am level below ground right now the project is just driving me nuts.
> > slowly.
> > To work for months, and end up with Xilinx saying:
> > The man who could have helped you, left Xilinx last friday. Your
> > situation is unsupportable.
> > Well we got out of that situation.
> > To end up in the new ones.
>
> > The FIFO is never over filled by design.
> > The fiber link is 99% IDLE sending usually only short 10byte packets
> > over the link.
>
> > For tesing I generate 10 byte pakets with MOUSE so 1 per second so
> > there is no doubt
> > the FIFO is never near full at all.
>
> > Last results:
> > - ALL 3 types of Xilinx FIFO's same style of errors, about same error
> > rate
> > - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
> > LESS errors then Xilinx implementation, but still all different types
> > of error did occour: missing values, and FIFO outputtin large junk of
> > OLD values, that is read pointer changing by some random value
>
> > again, I did not design the MGT clocking and the overall MGT
> > subsystem, the people who did are either unreachable or unable to
> > provide any help beyound saying that the implementation (connection of
> > the FIFO) is done properly. It is also what I have figured out so far,
> > but.. well somewhere must be problem.
>
> > Antti- Hide quoted text -
>
> > - Show quoted text -
>
> Since you can't get further on the MGT clocking circuit topology, what
> about the 62.5 MHz read clock? =A0How is this generated? =A0It sounds lik=
e
> it could be glitching.
>
> In one of your other posts, you had mention that ChipScope had shown
> that the write data was correct and that the read data wasn't. =A0Did
> you have two separate ILA cores with the 125 MHz and 62.5 MHz clocks
> when you did this testing?
>
> Ed McGettigan
> --
> Xilinx Inc

Peter, Ed, et others

* yes both clock are running all the time

* 125MHz is coming from MGT (recovered clock) there is no gating

* the 62.5mhz clock is PLB clock directly there is no gating

* the 62.5mhz read is generated as edge detect that generates 1 clk
wide pulse on PLB reads

* I used separate ILA cores in different clock domains

* Routing out the 125MHz for external scope would not show the
internal signal same as it is seen by the FIFO module, besides the IOB
characteristics would filter out something and introduce an delay so
the measurement would not be likely to show anything. OTOH the
chipscope inside the FPGA also doesnt tell much about the clock,
except that the data if clocked with the selected clock is latched
properly at the same conditions where FIFO does go crazy.

* The design occupies about 80% of all available resources of Virtex-4
FX40, in order to see the error, I have to start 2 units with GbE to
the first one and fiber link between the two, and send specific
commands to the master unit where the packets are processed by PPC
running custom firmware, that then triggers the condition in the slave
where then the problem can be seen. If anyone says this kind of system
can be simulated with meaningful results I am all ears to know the
setup for this. It doesnt make sense to simulate Xilinx FIFO's they
are almost certain not to exhibit the observed fault behavior.

the possibilities i still see are:

1) one of the clocks has something really "bad" in it, do not even
know what it could be: 1.2Ghz ringing? short bursts of some very high
frequency that do not trigger CS but do trigger FIFO ?
2) Xilinx tools are missing the timing that badly that all 4 type of
fifos inhibit similar error, but parallel connected CS core doesnt?
3) Problem with power supply?
4) Unspecified technical problem?
5) Me needing in sign off from this project to preserve my sanity?

It could be 5, it can be that the problem is there but I constantly
connect CS to some other clock and the FIFO's are one some other clock
that has problem. Well I have asked help, and a fellow engineer has
looked over the clock routing and what he has said is that it is all
OK the way it is right now. Maybe he needs a break as well.

Antti

On Dec 22, 6:40=A0am, John_H <newsgr...@johnhandwork.com> wrote:
> On Dec 21, 4:43=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 11:29=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>
> > > Antti <antti.luk...@googlemail.com> wrote:
> > > >On Dec 21, 3:21=3DA0pm, John McCaskill <jhmccask...@gmail.com> wrote=
:
> > > >> On Dec 21, 5:42=3DA0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > >> > On Dec 21, 1:29=3DA0pm, "maxascent" <maxasc...@yahoo.co.uk> wrot=
e:
>
> > > >> > > >On Dec 21, 12:32=3D3DA0pm, "maxascent" <maxasc...@yahoo.co.uk=
> wrote:
> > > >> > > >> Well once you have written and tested your own fifo then yo=
u would=3D
> > > > have
> > > >> > > i=3D3D
> > > >> > > >t
> > > >> > > >> for any other project. It seems like you have wasted a lot =
of time
> > > >> > > alread=3D3D
> > > >> > > >y
> > > >> > > >> trying to fix the Xilinx version so I dont see that you hav=
e anyth=3D
> > > >ing
> > > >> > > to
> > > >> > > >> loose by creating your own.
>
> > > >> > > >> Jon =3D3DA0 =3D3DA0 =3D3DA0 =3D3DA0
>
> > > >> > > >If you REALLY need todo something else, when your time is at =
absolut=3D
> > > >e
> > > >> > > >premium
> > > >> > > >And if the system working (except occasional errors about 2 o=
f fiber
> > > >> > > >packets are corrupt)
> > > >> > > >Then you do not go replacing Xilinx validated FIFO solutions =
with yo=3D
> > > >ur
> > > >> > > >own, if there are other options.
>
> > > >> > > >If 2 completly different FIFO implementations both have same =
error?
> > > >> > > >you think 3rd one would instantly work? Could be, yes.
>
> > > >> > > >Antti
>
> > > >> > > In my opinion people tend to use coregen far too often. Lookin=
g throu=3D
> > > >gh
> > > >> > > some of Xilinx code it is awfull. I went down the route of wri=
ting my=3D
> > > > own
> > > >> > > fifos not because I had a problem with Xilinx fifos but becaus=
e I bel=3D
> > > >ieve a
> > > >> > > fifo written by myself is a lot more flexible and simulates fa=
ster th=3D
> > > >an the
> > > >> > > Xilinx version. I also know to as good a degree as I can test =
that it=3D
> > > > will
> > > >> > > work 100%.
> > > >> > > I dont really think you can say that their fifos have been val=
idated =3D
> > > >100%
> > > >> > > if they have to release patches for them.
>
> > > >> > > Jon =3DA0 =3DA0 =3DA0 =3DA0
>
> > > >> > Dear Jon,
>
> > > >> > I do not feel to be in health right now to write this fifo, so h=
ere is
> > > >> > the deal:
>
> > > >> > =3DA0 component mgt_fifo
> > > >> > =3DA0 =3DA0 port (
> > > >> > =3DA0 =3DA0 =3DA0 din =3DA0 =3DA0: in =3DA0std_logic_vector(8 do=
wnto 0);
> > > >> > =3DA0 =3DA0 =3DA0 rd_clk : in =3DA0std_logic;
> > > >> > =3DA0 =3DA0 =3DA0 rd_en =3DA0: in =3DA0std_logic;
> > > >> > =3DA0 =3DA0 =3DA0 rst =3DA0 =3DA0: in =3DA0std_logic;
> > > >> > =3DA0 =3DA0 =3DA0 wr_clk : in =3DA0std_logic;
> > > >> > =3DA0 =3DA0 =3DA0 wr_en =3DA0: in =3DA0std_logic;
> > > >> > =3DA0 =3DA0 =3DA0 dout =3DA0 : out std_logic_vector(8 downto 0);
> > > >> > =3DA0 =3DA0 =3DA0 empty =3DA0: out std_logic;
> > > >> > =3DA0 =3DA0 =3DA0 full =3DA0 : out std_logic);
> > > >> > =3DA0 end component;
>
> > > >> > if you can write fifo that i can "drop in" and the Xilinx FIFO e=
rror
> > > >> > is gone,
> > > >> > then i will stand up, go to postal office and send you 1000 EUR =
by
> > > >> > western union.
> > > >> > If 1000 EUR is not enough, name your price, i will consider it.
> > > >> > there is no price on the health of our family
>
> > > >> > condition is: DROP IN, WORKS, if i need to troubleshoot, then no=
 pay.
>
> > > >> > Antti
>
> > > >> Hello Antti,
>
> > > >> If you want to try a different implementation of a FIFO, you can g=
et
> > > >> the one that the FSL bus uses out of the EDK pcores directory at C=
:
> > > >> \Xilinx\11.1\EDK\hw\XilinxProcessorIPLib\pcores\fsl_v20_v2_11_a\hd=
l
> > > >> \vhdl.
>
> > > >> There are multiple implementations, including an async BRAM based =
one
> > > >> that has the same ports as you list above, except that it uses exi=
st
> > > >> instead of empty on the read port.
>
> > > >> That said, I don't expect a third implementation to work instantly
> > > >> when the previous two implementations had the same error. =3DA0Thi=
s FIFO
> > > >> has the full source to it, so it is straight forward to see how it
> > > >> works, and add ChipScope to observe what is happening around the t=
ime
> > > >> of the error.
>
> > > >> If you have not used it before, FPGA editor has the ability to fin=
d a
> > > >> ChipScope ILA core, and change what is connected to it. That can m=
ake
> > > >> it much quicker to follow the trail of clues since you avoid havin=
g to
> > > >> go through a full place and route every time you want to look at
> > > >> something different.
>
> > > >> Is your 62.5 MHz clock a divided version of the 125 MHz clock? You
> > > >> mention that the 125 MHz is the recovered clock from the MGT, but
> > > >> there are other options. =3DA0When we did our GigE interface, we u=
sed a
> > > >> 125 MHz clock from the MGT, but it was not the recovered clock, bu=
t
> > > >> the local MGT PLL. =3DA0This let us use the same 125 MHz clock for=
 all
> > > >> four GigE interfaces and a PMCD to generate a 62.5 MHz clock that =
is
> > > >> phase aligned with the 125 MHz clock.
>
> > > >> Regards,
>
> > > >> John McCaskillwww.FasterTechnology.com
>
> > > >Hi
>
> > > >I have tried all 3 variants possible with coregen,
> > > >all 3 have similar errors
>
> > > >and no, the clocks are not divided version, the 125MHz comes from
> > > >master over fiber
> > > >the master could be 100 hops away, the 62.5mhz is derived from local
> > > >oscillator
>
> > > >so the frequencier are very close but not synchron
>
> > > >Antti
> > > >who has to give up, at least for a while :(
> > > >good advice still welcome, if there is any hope or idea how to fix t=
he
> > > >issue
> > > >and yes it could be power supply issue at the end of the day also
>
> > > I always write my own fifo's to keep things simple. I keep a write
> > > pointer, read pointer and number of elements counter in the domain
> > > with the highest clock frequency. I don't cross the clock domain
> > > inside the fifo instead I create an interface which does the clock
> > > domain crossing. I also use an early full signal (say max. elements -=
X
> > > depending on the expected latency). This allows for fast FIFO's (no
> > > cray code counters) with very little logic.
>
> > > The control logic looks like this:
>
> > > if read then read_ptr++;
> > > if write then write_ptr++;
> > > if (read=3Dtrue and write=3Dfalse) num_elements--;
> > > if (write=3Dtrue and read=3Dfalse) num_elements++;
>
> > > if (num_elements>=3D(MAX_ELEMENTS-X)) full=3Dtrue; else full=3Dfalse;
> > > if (num_elements=3D=3D0) empty=3Dtrue;
>
> > > The external logic should prohibit itself from reading/writing fifo
> > > when its empty or full.
>
> > > Besides: could your problem be a timing constraint problem? Did you
> > > specify the amount of time signals may travel from one clock domain t=
o
> > > the other? The Xilinx tools are not doing this automatically!
>
> > > --
> > > Failure does not prove something is impossible, failure simply
> > > indicates you are not using the right tools...
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a =
bigger hammer!"
> > > --------------------------------------------------------------
>
> > hi
>
> > I was already thinking of writing "simplified FIFO" that is would
> > work under the conditions it is used, the read is done by PPC software
> > polling so never too often
>
> > well the clock domains are fully async, so the clock edges of the read-
> > write
> > can have any phase they like
>
> > so I assumed if the read and write clock are constrained then it is
> > enough?
>
> > Antti
>
> 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 data
> 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

On Dec 21, 3:12=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
> > On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wr=
ote:
>
> > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wrote=
:
>
> > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wrote=
:
>
> > > > > > > > Antti wrote:
>
> > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, on=
ly FULL EMPTY
> > > > > > > > > flags present.
>
> > > > > > > > > signals at input correct, as expected (checked with ChipS=
cope)
> > > > > > > > > signals at output:
> > > > > > > > > - double value
> > > > > > > > > - missing 1, 2 or 3 values
> > > > > > > > > - FIFO will read out random number of OLD entries, this c=
ould be 4
> > > > > > > > > values, or 50% of the FIFO old values
>
> > > > > > > > I know you will have read this.
>
> > > > > > > > Can you think of any reason why the Xilinx work-around woul=
dn't work
> > > > > > > > because of your specific implementation? It seems to have d=
ifferent
> > > > > > > > work-arounds depending on whether the read clock is faster =
or slower
> > > > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > > > Are you sure your clocks don't have any glitches? The reset=
 also?
> > > > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > > > HTH., Syms.
>
> > > > > > > 1) I entered the clock figures in FIFO16 implementationm, but=
 the
> > > > > > > error also happens with BRAM based FIFO that do not need work=
arounds
> > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 125M=
Hz write,
> > > > > > > one is PLB clock 62.5MHz read
> > > > > > > 3) Power OK? Well the problem happens at 2 different sites, h=
m yes it
> > > > > > > could be still be power problem
>
> > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > > > Antti- Hide quoted text -
>
> > > > > > > - Show quoted text -
>
> > > > > > Are you sure that this is a FIFO issue and not something else? =
=A0Some
> > > > > > things to think about.
>
> > > > > > 1) The recovered clock from the MGT is a bit noisy as it moves =
as the
> > > > > > CDR moves. =A0Why are you using this instead of the REFCLK sour=
ce?
>
> > > > > > 2) It seems like you have a PLB core that is reading from the F=
IFO,
> > > > > > could the problem be in this?
>
> > > > > > Ed McGettigan
> > > > > > --
> > > > > > Xilinx Inc.
>
> > > > > Well the MGT datapath and clock system is not done by me, and the=
 guy
> > > > > says it is OK all the way it is connected.
>
> > > > > yes, It is very unlikely to belive that all THREE types of corege=
n
> > > > > FIFO's fail with about same symptoms, but in all
> > > > > 3 cased Chipscope sees correct data into fifo, and trash coming o=
ut
>
> > > > > the system can span up to 100 boards, all synced to master unit, =
the
> > > > > local refclk is not fully sync to the clock of
> > > > > the master unit, so I see no way to use this clock to syncronise =
the
> > > > > fifo?
>
> > > > > Antti
> > > > > PS I just received a attempt to collect the reward, by using non
> > > > > xilinx FIFO implementation, i let you all know
> > > > > the test results
>
> > > > Antti
> > > > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > > > designed for unequal data width of write and read. (Reason: possibl=
e
> > > > ambiguity of Full and EMPTY)
> > > > Since you use two clocks that are roughly 2:1 in frequency, I hope
> > > > that you do not try to have double width on one of the ports.
> > > > The FIFO must have the same width on both ports. You must design th=
e
> > > > width conversion outside the FIFO. That little circuit will be
> > > > synchronous and thus quite simple.
> > > > Peter Alfke
>
> > > well the FIFO is 9b in 9b out so it should work?
> > > at least this is what i hoped...
>
> > > we did not suspect the FIFO as problem at first
> > > so spent LOT of time looking for the problem AROUND the FIFOS
> > > but.. at least based on what i can see from CS snapshots on fifo
> > > inputs and outputs, the only explanation i have is that the FIFO
> > > are just goind mad,
>
> > > of course one option is that its me doing, but i have someone
> > > who is in better shape looking over the code as well, and he
> > > sees no issues there either. I know the FIFOs should work
> > > so there must be some explanation, but so far failing to see it.
>
> > > Antti
> > > PS thank you Peter for the response
>
> > OK, Antti,
> > so you have the same port width, but one clock is about twice as fast
> > as the other.
> > How do you stop the 125 MHz write clock from filling up the FIFO,
> > since you read at only 62 MHz ?
> > I hope you are not gating the clock, but rather run it continuously
> > and use WE to stop the writing.
> > Yes, many of these suggestions are well below your level, but stupid
> > problems need stupid investigations.
> > Cheers
> > Peter
>
> I am level below ground right now the project is just driving me nuts.
> slowly.
> To work for months, and end up with Xilinx saying:
> The man who could have helped you, left Xilinx last friday. Your
> situation is unsupportable.
> Well we got out of that situation.
> To end up in the new ones.
>
> The FIFO is never over filled by design.
> The fiber link is 99% IDLE sending usually only short 10byte packets
> over the link.
>
> For tesing I generate 10 byte pakets with MOUSE so 1 per second so
> there is no doubt
> the FIFO is never near full at all.
>
> Last results:
> - ALL 3 types of Xilinx FIFO's same style of errors, about same error
> rate
> - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
> LESS errors then Xilinx implementation, but still all different types
> of error did occour: missing values, and FIFO outputtin large junk of
> OLD values, that is read pointer changing by some random value
>
> again, I did not design the MGT clocking and the overall MGT
> subsystem, the people who did are either unreachable or unable to
> provide any help beyound saying that the implementation (connection of
> the FIFO) is done properly. It is also what I have figured out so far,
> but.. well somewhere must be problem.
>
> Antti


Hello Antti,

With four different FIFOs all failing, it is not likely that they are
the source of the problem, just where the symptoms are showing up, as
if you did not already know that.

If you still want suggestions, here are a few.

First, I always consider having an error condition I can trigger on to
be worth its weight in gold and you apparently have one in the FIFO.
Put in ChipScope with multiple ILAs observing one of the FIFOs that
you have source code for.  Use what ever you are currently triggering
on to trigger the other ILAs.  Put one on the write clock domain, and
one on the read clock domain.  Have them look at all of the IOs, as
well as the counters and other logic in the FIFO.  I doubt that you
will find a problem with the FIFO, but something will look wrong and
give you a clue to follow.

Also use separate ILAs to watch the read and write clocks.  I am
always suspicious of IO clocks, I have seen too many problems with
them. If one of those clocks is having a problem, and you are using
that clock as the clock for the ILA, you will not see the clock
problem with that ILA. Since you are using the recovered clock instead
of the reference clock (which you can do, and is how we do it), I
would pay extra attention to it.  Over sample the read and write
clocks by either using one faster clock, or multiple ILAs running on
multiple phases of a faster clock.  On a Virtex-4FX, we have multiple
MGTs/EMACs running GigE.  We use the 125 MHz reference clock instead
of the recovered clock so we only have one 125 MHz clock to deal
with.  We feed it through a PMCD to generate the 62.5 MHz clock so
that they are not asynchronous.   That give us a bit less to have to
deal with.

Do you have access to a digital storage oscilloscope?  If so,  run the
ILA trigger out of the FPGA and use that to trigger the scope. Use it
to look at the clocks and power supplies, and anything else that the
other test turned up.

Use the timing analyzer to look for unconstrained paths. Look for any
cross clock domain buses that have more than a cycle of skew on them.
I have not seen that cause problems yet, but I use from to constraints
to minimize skew to prevent a gray coded bus from having more than a
cycle of skew crossing domains and causing problems.  I don't think it
is a high probability, but your symptoms remind me of the time we
wrote our own FIFO that had different read and write widths and
incremented the Gray code counter by two. That would cause two bits to
change at a time, and eventually that would cause it to fail.

Good luck, and remember that it it was easy, it would not be called
hardware.

John McCaskill
www.FasterTechnology.com

On Dec 22, 7:02=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Dec 21, 3:12=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 10:21=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On Dec 21, 11:58=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > On Dec 21, 9:50=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > > On Dec 21, 9:30=A0am, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > > > On Dec 21, 7:20=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> =
wrote:
>
> > > > > > > On Dec 21, 3:01=A0am, Antti <antti.luk...@googlemail.com> wro=
te:
>
> > > > > > > > On Dec 21, 12:56=A0pm, Symon <symon_bre...@hotmail.com> wro=
te:
>
> > > > > > > > > Antti wrote:
>
> > > > > > > > > > Xilinx Coregen FIFO, dual clock, most options disable, =
only FULL EMPTY
> > > > > > > > > > flags present.
>
> > > > > > > > > > signals at input correct, as expected (checked with Chi=
pScope)
> > > > > > > > > > signals at output:
> > > > > > > > > > - double value
> > > > > > > > > > - missing 1, 2 or 3 values
> > > > > > > > > > - FIFO will read out random number of OLD entries, this=
 could be 4
> > > > > > > > > > values, or 50% of the FIFO old values
>
> > > > > > > > > I know you will have read this.
>
> > > > > > > > > Can you think of any reason why the Xilinx work-around wo=
uldn't work
> > > > > > > > > because of your specific implementation? It seems to have=
 different
> > > > > > > > > work-arounds depending on whether the read clock is faste=
r or slower
> > > > > > > > > than the write clock. Do your clocks change frequency?
>
> > > > > > > > > Are you sure your clocks don't have any glitches? The res=
et also?
> > > > > > > > > Power's OK? Is your office made of Cobalt 60?
>
> > > > > > > > > HTH., Syms.
>
> > > > > > > > 1) I entered the clock figures in FIFO16 implementationm, b=
ut the
> > > > > > > > error also happens with BRAM based FIFO that do not need wo=
rkarounds
> > > > > > > > 2) Clocks DO NOT CHANGE ever, one is MGT recovered clock 12=
5MHz write,
> > > > > > > > one is PLB clock 62.5MHz read
> > > > > > > > 3) Power OK? Well the problem happens at 2 different sites,=
 hm yes it
> > > > > > > > could be still be power problem
>
> > > > > > > > 4) My office is not of Cobalt 60, ... and its cold here too
>
> > > > > > > > Antti- Hide quoted text -
>
> > > > > > > > - Show quoted text -
>
> > > > > > > Are you sure that this is a FIFO issue and not something else=
? =A0Some
> > > > > > > things to think about.
>
> > > > > > > 1) The recovered clock from the MGT is a bit noisy as it move=
s as the
> > > > > > > CDR moves. =A0Why are you using this instead of the REFCLK so=
urce?
>
> > > > > > > 2) It seems like you have a PLB core that is reading from the=
 FIFO,
> > > > > > > could the problem be in this?
>
> > > > > > > Ed McGettigan
> > > > > > > --
> > > > > > > Xilinx Inc.
>
> > > > > > Well the MGT datapath and clock system is not done by me, and t=
he guy
> > > > > > says it is OK all the way it is connected.
>
> > > > > > yes, It is very unlikely to belive that all THREE types of core=
gen
> > > > > > FIFO's fail with about same symptoms, but in all
> > > > > > 3 cased Chipscope sees correct data into fifo, and trash coming=
 out
>
> > > > > > the system can span up to 100 boards, all synced to master unit=
, the
> > > > > > local refclk is not fully sync to the clock of
> > > > > > the master unit, so I see no way to use this clock to syncronis=
e the
> > > > > > fifo?
>
> > > > > > Antti
> > > > > > PS I just received a attempt to collect the reward, by using no=
n
> > > > > > xilinx FIFO implementation, i let you all know
> > > > > > the test results
>
> > > > > Antti
> > > > > If I remember right (I am no longer at Xilinx) the FIFO is NOT
> > > > > designed for unequal data width of write and read. (Reason: possi=
ble
> > > > > ambiguity of Full and EMPTY)
> > > > > Since you use two clocks that are roughly 2:1 in frequency, I hop=
e
> > > > > that you do not try to have double width on one of the ports.
> > > > > The FIFO must have the same width on both ports. You must design =
the
> > > > > width conversion outside the FIFO. That little circuit will be
> > > > > synchronous and thus quite simple.
> > > > > Peter Alfke
>
> > > > well the FIFO is 9b in 9b out so it should work?
> > > > at least this is what i hoped...
>
> > > > we did not suspect the FIFO as problem at first
> > > > so spent LOT of time looking for the problem AROUND the FIFOS
> > > > but.. at least based on what i can see from CS snapshots on fifo
> > > > inputs and outputs, the only explanation i have is that the FIFO
> > > > are just goind mad,
>
> > > > of course one option is that its me doing, but i have someone
> > > > who is in better shape looking over the code as well, and he
> > > > sees no issues there either. I know the FIFOs should work
> > > > so there must be some explanation, but so far failing to see it.
>
> > > > Antti
> > > > PS thank you Peter for the response
>
> > > OK, Antti,
> > > so you have the same port width, but one clock is about twice as fast
> > > as the other.
> > > How do you stop the 125 MHz write clock from filling up the FIFO,
> > > since you read at only 62 MHz ?
> > > I hope you are not gating the clock, but rather run it continuously
> > > and use WE to stop the writing.
> > > Yes, many of these suggestions are well below your level, but stupid
> > > problems need stupid investigations.
> > > Cheers
> > > Peter
>
> > I am level below ground right now the project is just driving me nuts.
> > slowly.
> > To work for months, and end up with Xilinx saying:
> > The man who could have helped you, left Xilinx last friday. Your
> > situation is unsupportable.
> > Well we got out of that situation.
> > To end up in the new ones.
>
> > The FIFO is never over filled by design.
> > The fiber link is 99% IDLE sending usually only short 10byte packets
> > over the link.
>
> > For tesing I generate 10 byte pakets with MOUSE so 1 per second so
> > there is no doubt
> > the FIFO is never near full at all.
>
> > Last results:
> > - ALL 3 types of Xilinx FIFO's same style of errors, about same error
> > rate
> > - VHDL FIFO send by CAF reader, uses gray counters, about TEN TIMES
> > LESS errors then Xilinx implementation, but still all different types
> > of error did occour: missing values, and FIFO outputtin large junk of
> > OLD values, that is read pointer changing by some random value
>
> > again, I did not design the MGT clocking and the overall MGT
> > subsystem, the people who did are either unreachable or unable to
> > provide any help beyound saying that the implementation (connection of
> > the FIFO) is done properly. It is also what I have figured out so far,
> > but.. well somewhere must be problem.
>
> > Antti
>
> Hello Antti,
>
> With four different FIFOs all failing, it is not likely that they are
> the source of the problem, just where the symptoms are showing up, as
> if you did not already know that.
>
> If you still want suggestions, here are a few.
>
> First, I always consider having an error condition I can trigger on to
> be worth its weight in gold and you apparently have one in the FIFO.
> Put in ChipScope with multiple ILAs observing one of the FIFOs that
> you have source code for. =A0Use what ever you are currently triggering
> on to trigger the other ILAs. =A0Put one on the write clock domain, and
> one on the read clock domain. =A0Have them look at all of the IOs, as
> well as the counters and other logic in the FIFO. =A0I doubt that you
> will find a problem with the FIFO, but something will look wrong and
> give you a clue to follow.
>
> Also use separate ILAs to watch the read and write clocks. =A0I am
> always suspicious of IO clocks, I have seen too many problems with
> them. If one of those clocks is having a problem, and you are using
> that clock as the clock for the ILA, you will not see the clock
> problem with that ILA. Since you are using the recovered clock instead
> of the reference clock (which you can do, and is how we do it), I
> would pay extra attention to it. =A0Over sample the read and write
> clocks by either using one faster clock, or multiple ILAs running on
> multiple phases of a faster clock. =A0On a Virtex-4FX, we have multiple
> MGTs/EMACs running GigE. =A0We use the 125 MHz reference clock instead
> of the recovered clock so we only have one 125 MHz clock to deal
> with. =A0We feed it through a PMCD to generate the 62.5 MHz clock so
> that they are not asynchronous. =A0 That give us a bit less to have to
> deal with.
>
> Do you have access to a digital storage oscilloscope? =A0If so, =A0run th=
e
> ILA trigger out of the FPGA and use that to trigger the scope. Use it
> to look at the clocks and power supplies, and anything else that the
> other test turned up.
>
> Use the timing analyzer to look for unconstrained paths. Look for any
> cross clock domain buses that have more than a cycle of skew on them.
> I have not seen that cause problems yet, but I use from to constraints
> to minimize skew to prevent a gray coded bus from having more than a
> cycle of skew crossing domains and causing problems. =A0I don't think it
> is a high probability, but your symptoms remind me of the time we
> wrote our own FIFO that had different read and write widths and
> incremented the Gray code counter by two. That would cause two bits to
> change at a time, and eventually that would cause it to fail.
>
> Good luck, and remember that it it was easy, it would not be called
> hardware.
>
> John McCaskillwww.FasterTechnology.com

Thank you John,

Antti

Antti <antti.lukats@googlemail.com> wrote:
(big snip)
 
> 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

If the fifo is empty half the time, then half the time you will
be reading the wrong value.  

-- glen

To follow on, here are some of my thoughts:


- I would try to limit the scope of this issue by using a chain of three async identical FIFOs (with the control signals properly forwarded: the point is to make the whole thing transparent, although with increased cycle latency)
  [MGT] ---> [FIFO #1] ---> [FIFO #2] ---> [FIFO #3] --->  [PLB]
    MGT, FIFO #1 (both ports), inbound port of FIFO #2 @ 125 MHz
    Outbound port of FIFO #2, FIFO #3 (both ports), and PLB @ 62.5 MHz
The FIFO #1 and #3 are useless but they may experience the issue you are facing, bringing up interesting facts such as knowing which port is going south.


Also I guess that you already went through the obvious items:

- I would check and re-check __myself__ the clocking scheme inside and outside the FPGA
- Same thing with power-supply
- Check that all I/O pads are LOC'ed (I once had an unconstrained pad due to a typo inside the UCF file, nasty things followed)
- Check that the FIFO reset is performed correctly (all clock stable, FIFO state is idle) and meets the required duration
- A good sleep, cold shower and breakfast are very effective when dealing with though issues !!


-- 
Matthieu Michon <prenom.nom@gmail.com>

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 data
> > 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

On Dec 22, 8:06=A0am, 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

Rereading some stuff, perhaps I wasn't clear:  the data for a read
pulse may be expected by the system the same clock as the read enable
- indicating the design is "taking valid data" from the FIFO on that
clock where rd_en and dout are both valid the same clock cycle - while
the FIFO expects the dout to be valid the clock *after* the rd_en. Or
vice-versa.

It's this "which clock cycle" issue between rd_en and the dout
corresponding to that rd_en that trips up some engineers.

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

Antti wrote:
> website issues in "solving" state yes!
and which email address works ?

> Antti
yg
-- 
http://ygdes.com / http://yasep.org

On Jan 27, 4:24=A0pm, whygee <y...@yg.yg> wrote:
> 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

website issues in "solving" state yes!

first products using Silicon blue stamps are about to be delivered to
the customers
and we have small batch of the SB stamp modules ready as well

Antti

On Jan 27, 5:40=A0pm, whygee <y...@yg.yg> wrote:
> Antti wrote:
> > website issues in "solving" state yes!
>
> and which email address works ?
>
> > Antti
>
> yg
> --http://ygdes.com/http://yasep.org

Antti.Lukats@googlemail.com

always works :) thats why i use it as preffered :)
if i dont reply, please resend, in very rare cases the mails go to
spam
and I delete spam folder without reading (300+ spam mails per day)

Joining in kind of late here--It sounds like you may have a solution
and that's great. But here is some food for thought in case you don't
understand your failure mechanism yet.

It is very interesting to me that the clocks are not derived from same
source, but one is pseudo-multiple of the other (write clock is 2x
faster than read). Just supposing here: Do you make an assumption that
when empty flag goes inactive, you attempt to read multiple pieces of
data from FIFO immediately, because the write side "bursts" multiple
data on consecutive write clocks? I assume that your read bus is twice
as wide as your write bus?

If so, this could be a problem IFF read clock is a tiny bit more
slower than 2x of write clock, due to variant PPM of respective
oscillator frequencies. In other words, I would advise using some type
of partial empty flag to *make sure* there is N amount of words in
FIFO before reading those N words out. Expanding on this idea, can you
(perhaps as a test) add a significant delay from empty flag going
inactive before reading FIFO data just to decouple the read clock
timing from the write clock timing, in case you are currently "racing"
the read out with the write in.

- John Cappello

On Jan 28, 11:38=A0am, jc <jcappe...@optimal-design.com> wrote:
> Joining in kind of late here--It sounds like you may have a solution
> and that's great. But here is some food for thought in case you don't
> understand your failure mechanism yet.
>
> It is very interesting to me that the clocks are not derived from same
> source, but one is pseudo-multiple of the other (write clock is 2x
> faster than read). Just supposing here: Do you make an assumption that
> when empty flag goes inactive, you attempt to read multiple pieces of
> data from FIFO immediately, because the write side "bursts" multiple
> data on consecutive write clocks? I assume that your read bus is twice
> as wide as your write bus?
>
> If so, this could be a problem IFF read clock is a tiny bit more
> slower than 2x of write clock, due to variant PPM of respective
> oscillator frequencies. In other words, I would advise using some type
> of partial empty flag to *make sure* there is N amount of words in
> FIFO before reading those N words out. Expanding on this idea, can you
> (perhaps as a test) add a significant delay from empty flag going
> inactive before reading FIFO data just to decouple the read clock
> timing from the write clock timing, in case you are currently "racing"
> the read out with the write in.
>
> - John Cappello

TEST setup:

PC software that sends commands over GbE-fiber to master board,
Master FPGA board sends a short packet SOP<8 byte>EOP into fiber
Slave FPGA board receives the 8 byte

I PUSHED a key with my hand, and there was never any overflow possible

clocks:
WR clock deriveved from oscillator on the MASTER via the fiber and MGT
using the RECCLK from MGT
RD clock derived from oscillator on the SLAVE

so the clocks are almost "same" or almost 2X except the oscilator
accuracy on master/slave boards.

Antti

I guess I am specifically asking about the precise timing of the
reading of data from the FIFO. How soon does the read side attempt to
read FIFO data after the empty flag goes low? I argue that doing this
too quickly--say, allowing the FIFO empty flag to act as the read
enable also--could cause the problems you are seeing if the 62.5M
clock source frequency is at the higher end of the "+/- PPM" range
while the 125M clock source frequency as at the lower end of its own
PPM range. A safe way to do this would be to either add delay from the
empty going inactive before reading the FIFO, or use some type of
partial empty flag.

This is just an idea and I don't claim that this has to be your
problem. But I've seen this issue arise with ethernet systems where
two boxes attempt to communicate using their own, embedded 125MHz
clock source, but +/-200PPM, I believe.