Please help, Xilinx FIFO problem!
in [FPGA]
|
From: John_H on 22 Dec 2009 08:14 On Dec 22, 8:06 am, John_H <newsgr...(a)johnhandwork.com> wrote: > On Dec 22, 12:00 am, Antti <antti.luk...(a)googlemail.com> wrote: > > > > > On Dec 22, 6:40 am, John_H <newsgr...(a)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 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.
From: Antti on 22 Dec 2009 08:20 On Dec 22, 3:06 pm, John_H <newsgr...(a)johnhandwork.com> wrote: > On Dec 22, 12:00 am, Antti <antti.luk...(a)googlemail.com> wrote: > > > > > > > On Dec 22, 6:40 am, John_H <newsgr...(a)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 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
From: John_H on 22 Dec 2009 08:55 On Dec 22, 8:20 am, Antti <antti.luk...(a)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
From: Antti on 22 Dec 2009 10:24 On Dec 22, 3:55 pm, John_H <newsgr...(a)johnhandwork.com> wrote: > On Dec 22, 8:20 am, Antti <antti.luk...(a)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- 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
From: Nico Coesel on 22 Dec 2009 10:38
Antti <antti.lukats(a)googlemail.com> wrote: >On Dec 22, 3:55=A0pm, John_H <newsgr...(a)johnhandwork.com> wrote: >> On Dec 22, 8:20=A0am, Antti <antti.luk...(a)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!" -------------------------------------------------------------- |