Xilinx: XST synchronous FIFO using BRAMs
in [FPGA]
|
Prev: errors during MAP
Next: NIOS II + USB 2.0 host
From: sidney on 4 Jul 2005 19:24 Hi Alvin, > There is one serious flaw in your code: you don't reset the pointers, so > resetting your fifo after some usage will actually bring it in a non-working > state. Why so? I synchronously set only the counter to zero upon reset (this is by design); there is no reason why "cur_address_r" would need to be zero as well upon reset. The location "cur_address_r" points to is immaterial- a FIFO is empty iff cur_num_entries is zero. > In my follow-up post, I'll dump some code (entity + lbram and bram > architectures + package + testbench). It does simulate, but I didn't try to > synthesize it. Feel free to use and improve it (you can dump the fifo count > by using the pointers and sacrificing 1 entry). Thanks a lot, I will test this for sure - but I am still curious to know what goes wrong with my code. Best regards, Sidney
From: sidney on 4 Jul 2005 19:32 > Here's the code. Thanks. I hope this was something you had made already and not something you did specially for me- I'd feel all guilty. :) One small nit: your line: push <= not full and (shift_in = '1'); Couldn't this be replaced by push <= (not full or shift_out = '1') and (shift_in = '1'); This would allow shifting into an already full buffer, iff in the same cycle you are shifting data out. Regards, Sidney
From: Alvin Andries on 4 Jul 2005 19:39 <sidney(a)jigsaw.nl> wrote in message news:1120519464.755269.123880(a)z14g2000cwz.googlegroups.com... > Hi Alvin, > > > There is one serious flaw in your code: you don't reset the pointers, so > > resetting your fifo after some usage will actually bring it in a non-working > > state. > > Why so? I synchronously set only the counter to zero upon reset (this > is by design); there is no reason why "cur_address_r" would need to be > zero as well upon reset. The location "cur_address_r" points to is > immaterial- a FIFO is empty iff cur_num_entries is zero. > > > In my follow-up post, I'll dump some code (entity + lbram and bram > > architectures + package + testbench). It does simulate, but I didn't try to > > synthesize it. Feel free to use and improve it (you can dump the fifo count > > by using the pointers and sacrificing 1 entry). > > Thanks a lot, I will test this for sure - but I am still curious to > know what goes wrong with my code. > > Best regards, Sidney Oops, I was too fast. Normally, I'd create a read and write pointer (because it's faster than what you're doing). In that case, not resetting both would kill the fifo. you're using the number of words for address calculation. This inferes a full adder, which is slower than an increment. Regards, Alvin.
From: Alvin Andries on 4 Jul 2005 19:46 <sidney(a)jigsaw.nl> wrote in message news:1120519944.599307.249010(a)g49g2000cwa.googlegroups.com... > > > Here's the code. > > Thanks. I hope this was something you had made already and not > something you did specially for me- I'd feel all guilty. :) > > One small nit: your line: > > push <= not full and (shift_in = '1'); > > Couldn't this be replaced by > > push <= (not full or shift_out = '1') and (shift_in = '1'); > > This would allow shifting into an already full buffer, iff in the same > cycle you are shifting data out. > > Regards, Sidney > Hi, You could do this. But if you want to use the fifo in a fully handshaking system, you loose an important property! The fifo breaks the combinatorial handshake path and is required to leverage the increased latency in the handshake. In your design, this isn't an issue. It's just a matter of habit. As for the coding: the exercise was usefull to refresh my modelsim knowledge a bit. Regards, Alvin.
From: Peter Alfke on 4 Jul 2005 21:55
Why would an adder be slower than an increment. In Xilinx, I see no difference. It's all a matter of carry propagation ( and it is pretty fast in either case.) Or is this a case of generics and portability? My analogy for generics is Fast Food. Throw a coin whether you go to McDon or to BurgerKing. it's all the same mediocre or below stuff. Same with a design that is fearful of being Xilinx specific. Using only the ingredients that everybody has, means lowering yourself to the lowest common denominator. Have guts and be specific! There is more stuff than Altera ever dreamt of. Sorry, couldn't resist the plug. Peter Alfke |