From: Sebastien Bourdeauducq on 18 Jun 2010 10:43 Hi, I am trying to use this FIFO design in a Spartan6: http://www.asic-world.com/examples/verilog/asyn_fifo.html Doing so makes Xst emit a shrill warning (Xst:3002) because a latch construct does not play well with the Spartan6 architecture, as it has both an asynchronous set and reset. And as the warning says, the circuit is still built but results in poor timing. The construct in question is: always @ (Set_Status, Rst_Status, Clear_in) //D Latch w/ Asynchronous Clear & Preset. if (Rst_Status | Clear_in) Status = 0; //Going 'Empty'. else if (Set_Status) Status = 1; //Going 'Full'. To fix the warning and improve timing, I have replaced it with: wire Clear_Status = Rst_Status | Clear_in; always @(posedge Clear_Status, posedge Set_Status) if (Clear_Status) Status <= 1'b0; else Status <= 1'b1; Would this design still work without metastability problems? I guess the answer to this question is probably in the article "Asynchronous FIFO in Virtex-II FPGAs" by Peter Alfke, but I cannot find it anywhere for download. Thanks, Sébastien PS. I do not want to use CORE Generator FIFOs.
From: Gabor on 18 Jun 2010 11:05 On Jun 18, 10:43 am, Sebastien Bourdeauducq <sebastien.bourdeaud...(a)gmail.com> wrote: > Hi, > > I am trying to use this FIFO design in a Spartan6:http://www.asic-world.com/examples/verilog/asyn_fifo.html > > Doing so makes Xst emit a shrill warning (Xst:3002) because a latch > construct does not play well with the Spartan6 architecture, as it has > both an asynchronous set and reset. And as the warning says, the > circuit is still built but results in poor timing. > > The construct in question is: > always @ (Set_Status, Rst_Status, Clear_in) //D Latch w/ Asynchronous > Clear & Preset. > if (Rst_Status | Clear_in) > Status = 0; //Going 'Empty'. > else if (Set_Status) > Status = 1; //Going 'Full'. > > To fix the warning and improve timing, I have replaced it with: > wire Clear_Status = Rst_Status | Clear_in; > always @(posedge Clear_Status, posedge Set_Status) > if (Clear_Status) > Status <= 1'b0; > else > Status <= 1'b1; > > Would this design still work without metastability problems? > > I guess the answer to this question is probably in the article > "Asynchronous FIFO in Virtex-II FPGAs" by Peter Alfke, but I cannot > find it anywhere for download. > > Thanks, > Sébastien > PS. I do not want to use CORE Generator FIFOs. The new version of the code does not do the same thing as the original. The difference is in what happens if both clear and set are active and you release the clear input. In that case the original code would set the output high, the new version would stay low, since it requires a rising edge of the set. If that particular case never happens, then you should be able to use the new code. Regards, Gabor
From: Uwe Bonnes on 18 Jun 2010 11:16 Sebastien Bourdeauducq <sebastien.bourdeauducq(a)gmail.com> wrote: > Hi, > I am trying to use this FIFO design in a Spartan6: > http://www.asic-world.com/examples/verilog/asyn_fifo.html > Doing so makes Xst emit a shrill warning (Xst:3002) because a latch > construct does not play well with the Spartan6 architecture, as it has > both an asynchronous set and reset. And as the warning says, the > circuit is still built but results in poor timing. .... > I guess the answer to this question is probably in the article > "Asynchronous FIFO in Virtex-II FPGAs" by Peter Alfke, but I cannot > find it anywhere for download. I use the "generic_fifo" from opencores. The "generic ram" needed by the module I replaced with straight XST synthesizable RAM code. generic_fifo also supplies an indication of the filling degree, so throttling when transfering blocks of data gest simple. I use the fifo to transfer blocks of data with about 16 MByte/sec via an FT2232H. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
From: Oscar Almer on 22 Jun 2010 14:17 On Fri, 18 Jun 2010 07:43:04 -0700 (PDT) Sebastien Bourdeauducq <sebastien.bourdeauducq(a)gmail.com> wrote: > Hi, > > I am trying to use this FIFO design in a Spartan6: > http://www.asic-world.com/examples/verilog/asyn_fifo.html > > Doing so makes Xst emit a shrill warning (Xst:3002) because a latch > construct does not play well with the Spartan6 architecture, as it has > both an asynchronous set and reset. And as the warning says, the > circuit is still built but results in poor timing. > > The construct in question is: > always @ (Set_Status, Rst_Status, Clear_in) //D Latch w/ Asynchronous > Clear & Preset. > if (Rst_Status | Clear_in) > Status = 0; //Going 'Empty'. > else if (Set_Status) > Status = 1; //Going 'Full'. > > To fix the warning and improve timing, I have replaced it with: > wire Clear_Status = Rst_Status | Clear_in; > always @(posedge Clear_Status, posedge Set_Status) > if (Clear_Status) > Status <= 1'b0; > else > Status <= 1'b1; > > Would this design still work without metastability problems? > > I guess the answer to this question is probably in the article > "Asynchronous FIFO in Virtex-II FPGAs" by Peter Alfke, but I cannot > find it anywhere for download. > > Thanks, > Sébastien > PS. I do not want to use CORE Generator FIFOs. I played with this code a while ago, and had the same trouble. Additionally, I was never able to convince myself that the design(s) were in fact without timing problems. This was some concern, as the decoupling of processor clock from I/O system clocks were dependant on getting working async FIFOs. After a while I started manually instantiating FIFO(36|36_72) blocks instead, as they have the async capability built-in. I even wrote some wrappers to make this instantiation slightly nicer, and in particular, to make them wider then 72 bits when necessary. For me this works just fine, and I haven't had a problem with FIFOs since. When you say you do not want to use CORE generator FIFO's, do you mean you want to avoid using the hard BRAM-based FIFO's, or do you want to avoid CORE Generator? //Oscar
|
Pages: 1 Prev: Programming the Actel Smartfusion Eval Kit in Linux Next: Xilinx Timing Constraings |