From: John McCaskill on
On Dec 21, 5:42 am, Antti <antti.luk...(a)googlemail.com> wrote:
> On Dec 21, 1:29 pm, "maxascent" <maxasc...(a)yahoo.co.uk> wrote:
>
> > >On Dec 21, 12:32=A0pm, "maxascent" <maxasc...(a)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        
>
> 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


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
From: Antti on
On Dec 21, 3:21 pm, John McCaskill <jhmccask...(a)gmail.com> wrote:
> On Dec 21, 5:42 am, Antti <antti.luk...(a)googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 1:29 pm, "maxascent" <maxasc...(a)yahoo.co.uk> wrote:
>
> > > >On Dec 21, 12:32=A0pm, "maxascent" <maxasc...(a)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        
>
> > 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
>
> 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 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






From: Ed McGettigan on
On Dec 21, 3:01 am, Antti <antti.luk...(a)googlemail.com> wrote:
> On Dec 21, 12:56 pm, Symon <symon_bre...(a)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.
From: Antti on
On Dec 21, 7:20 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote:
> On Dec 21, 3:01 am, Antti <antti.luk...(a)googlemail.com> wrote:
>
>
>
>
>
> > On Dec 21, 12:56 pm, Symon <symon_bre...(a)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







From: Peter Alfke on
On Dec 21, 9:30 am, Antti <antti.luk...(a)googlemail.com> wrote:
> On Dec 21, 7:20 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote:
>
>
>
>
>
> > On Dec 21, 3:01 am, Antti <antti.luk...(a)googlemail.com> wrote:
>
> > > On Dec 21, 12:56 pm, Symon <symon_bre...(a)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