Prev: Linux capable free/GPL SOFT CPU for XC3S500E?
Next: can't install Centos 5.1 x86_64 and Xilinx ISE 9.2 evaluation
From: Peter Alfke on 30 Nov 2007 10:05 As I wrote, the problem is easy to solve for the synchronous case (identical clocks) but difficult or impossible to solve for the asynchronous case. You wrote synchronous ??? Peter Alfke On Nov 30, 12:44 am, "heinerl...(a)googlemail.com" <heinerl...(a)googlemail.com> wrote: > Hi Peter, > > we are using Virtex4 FX devices. The FIFO runs at 100 MHz and was > generated with coregen 3.5. We just found out that there have been > several modifications regarding the almost empty signal in coregen > 4.2. We'll try that out first. > > Point is we NEED an almost empty signal at threshold == 1 which we can > rely on 100%. If I understand you correctly this is not given with the > Xilinx sync FIFOs so we would have to build our own, right? > > regards, Heiner > > On Nov 29, 5:35 pm, Peter Alfke <al...(a)sbcglobal.net> wrote: > > > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com" > > > <heinerl...(a)googlemail.com> wrote: > > > Hi, > > > > we are using an asynchronous FIFO to bridge two clock domains. Both > > > domains have "the same" clock speed but different clock oscillators. > > > > We shift data phits in the FIFO which always form a data packet. In > > > between a packet data is shifted in continously without a break. > > > Breaks (no shift in) are only allowed in between packets. > > > On the output side of the FIFO we need a steady data stream during a > > > data packet. The packet may not be interrupted. As the input side may > > > be slower we start shift-out data if at least two data phits are in > > > the FIFO. As the 2 clocks have almost the same frequency this > > > guarantees that we never have a buffer underflow. > > > > The problem we found is that the almost empty flag is only asserted if > > > the FIFO is beeing emptied and not if it is beeing filled. So if the > > > FIFO was empty and we get a shift in the almost empty is not asserted > > > although we set the treshold to one. Is this a bug? > > > Which FPGA family, which type of FIFO controller, and also what clock > > rate? > > Peter Alfke, Xilinx Applications> > > > > We tried to solve that problem by generating a delay-empty signal at > > > the output which guarantees that if the FIFO was emtpy and than > > > receives a shift in we still wait another cycle so we get another > > > shift in to avoid underflow. > > > > This solution however does not solve the problem if the FIFO exactly > > > had one entry when starting to shift out a packet. In this case > > > neither delayed-empty nor almost empty is asserted, hence we get an > > > underflow. > > > > Why isn't the almost empty signal asserted every time there is a > > > single packet in the FIFO? Ideas?
From: Peter Alfke on 30 Nov 2007 14:31 On Nov 30, 12:44 am, "heinerl...(a)googlemail.com" <heinerl...(a)googlemail.com> wrote: > Hi Peter, > > we are using Virtex4 FX devices. The FIFO runs at 100 MHz and was > generated with coregen 3.5. We just found out that there have been > several modifications regarding the almost empty signal in coregen > 4.2. We'll try that out first. > > Point is we NEED an almost empty signal at threshold == 1 which we can > rely on 100%. If I understand you correctly this is not given with the > Xilinx sync FIFOs so we would have to build our own, right? > > regards, Heiner > > On Nov 29, 5:35 pm, Peter Alfke <al...(a)sbcglobal.net> wrote: > > > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com" > > > <heinerl...(a)googlemail.com> wrote: > > > Hi, > > > > we are using an asynchronous FIFO to bridge two clock domains. Both > > > domains have "the same" clock speed but different clock oscillators. > > > > We shift data phits in the FIFO which always form a data packet. In > > > between a packet data is shifted in continously without a break. > > > Breaks (no shift in) are only allowed in between packets. > > > On the output side of the FIFO we need a steady data stream during a > > > data packet. The packet may not be interrupted. As the input side may > > > be slower we start shift-out data if at least two data phits are in > > > the FIFO. As the 2 clocks have almost the same frequency this > > > guarantees that we never have a buffer underflow. > > > > The problem we found is that the almost empty flag is only asserted if > > > the FIFO is beeing emptied and not if it is beeing filled. So if the > > > FIFO was empty and we get a shift in the almost empty is not asserted > > > although we set the treshold to one. Is this a bug? > > > Which FPGA family, which type of FIFO controller, and also what clock > > rate? > > Peter Alfke, Xilinx Applications> Heiner, if you have questions about asynchronous FIFOs, just send me an e-mail. English oder Deutsch. But I'll be on vacation starting next Tuesday. Peter Alfke (peter(a)xilinx.com) > > > We tried to solve that problem by generating a delay-empty signal at > > > the output which guarantees that if the FIFO was emtpy and than > > > receives a shift in we still wait another cycle so we get another > > > shift in to avoid underflow. > > > > This solution however does not solve the problem if the FIFO exactly > > > had one entry when starting to shift out a packet. In this case > > > neither delayed-empty nor almost empty is asserted, hence we get an > > > underflow. > > > > Why isn't the almost empty signal asserted every time there is a > > > single packet in the FIFO? Ideas?
From: PatC on 2 Dec 2007 23:53 Peter Alfke wrote: > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com" >> The problem we found is that the almost empty flag is only asserted if >> the FIFO is beeing emptied and not if it is beeing filled. So if the >> FIFO was empty and we get a shift in the almost empty is not asserted >> although we set the treshold to one. Is this a bug? You could use the fifo read count and compare it to 1? The latency may be higher, but it's guarantied there'll be a point there when it asserts. HTH, -P@
From: Peter Alfke on 3 Dec 2007 00:35 On Dec 2, 8:53 pm, PatC <p...(a)patocarr.com> wrote: > Peter Alfke wrote: > > On Nov 29, 3:46 am, "heinerl...(a)googlemail.com" > >> The problem we found is that the almost empty flag is only asserted if > >> the FIFO is beeing emptied and not if it is beeing filled. So if the > >> FIFO was empty and we get a shift in the almost empty is not asserted > >> although we set the treshold to one. Is this a bug? > > You could use the fifo read count and compare it to 1? The latency may > be higher, but it's guarantied there'll be a point there when it asserts. > > HTH, > -P@ In an asynchronous FIFO, the flags must be synchronized to the appropriate clock. The leading edge of Almost Empty is normally generated by the read clock, and it is the read side that usually worries about (Almost) Empty. The trailing edge, however, is generated by the write clock, and (for most purposes) needs re-synchronization to the read clock. That re-synchronization needs an extra clock edge (or two) to avoid metastable confusion. The basic problem is the unknown phase relationship between the two clocks. The edges can be far apart, but also very close to each other, down to fractional picoseconds. But the controller has to provide correct flag outputs. The actual reading and writing is trivial, as long as the RAM is dual-ported. Peter Alfke
From: heinerlitz on 3 Dec 2007 03:20
HI as stated we are using the FIFO in an Asynchronous way. The read and write clock are both 200 MHz but are provided through 2 different oscillators. We are using the almost empty signal onlyin the read clock domain. We are currently implementing a single FF stage located at the output side of the FIFO. If then the FIFO goes empty (and the empty signal behaves correctly) we can be sure to have another datum in the FF stage, equaling almost empty. hope this helps.. regs, Heiner |