But what is the FIFO width? How much extra space is needed if going to a 64 word memory?Let me clarify more.
I need an asynchronous FIFO to store data and it should be minimum of depth 33. Even an asynchronous FIFO of depth 34 will solve my problem, but I cannot even waste area by increasing the depth to 34. So definitely I want depth of 33 to save area. Hope it clarifies the requirements.
Code VHDL - [expand] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 signal real_write_ptr : unsigned(5 downto 0); -- used range = 0-32 signal real_read_ptr : unsigned(5 downto 0); -- used range = 0-32 signal virtual_write_ptr : unsigned(5 downto 0); -- used range = 0-63 signal virtual_read_pointer_1 : unsigned(5 downto 0); -- used range = 0-63, for empty detection signal virtual_read_pointer_2 : unsigned(5 downto 0); -- used range = 0-63, for full detection -- write pointer handling (in a write clock process) -- increment write pointers if real_write_ptr = 32 then real_write_ptr <= (others => '0'); -- wrap from 32 to 0 else real_write_ptr <= real_write_ptr + 1; end if; virtual_write_ptr <= virtual_write_ptr + 1; -- reset real_write_ptr : <= (others => '0'); -- used range = 0-32, initial value = 0 virtual_write_ptr <= (others => '0'); -- used range = 0-63, initial value = 0 -- read pointer handling (in a read clock process) -- increment read pointers if real_read_ptr = 32 then real_read_ptr <= (others => '0'); -- wrap from 32 to 0 else real_read_ptr <= real_read_ptr + 1; end if; virtual_read_ptr_1 <= virtual_read_ptr_1 + 1; virtual_read_ptr_2 <= virtual_read_ptr_2 + 1; -- reset real_read_ptr <= (others => '0'); -- used range = 0-32, initial value = 0 virtual_read_pointer_1 <= (others => '0'); -- used range = 0-63, initial value = 0, for empty detection virtual_read_pointer_2 <= to_unsigned(33, 6); -- used range = 0-63, initial value = 33, for full detection -- The wanted empty/full conditions empty <= '1' when virtual_write_ptr_read_domain = virtual_read_ptr_1 else '0'; -- write pointer transferred to the read domain full <= '1' when virtual_write_ptr = virtual_read_ptr_2_write_domain else '0'; -- read pointer transferred to the write domain -- The virtual pointers are transferred between clock domains using Gray coding -- The actual read/write operations on the memory use the "real" pointers -- Instead of having a separate signal for read pointer 2, it can be created by subtracting 31 from read pointer 1
Unlike others, I clearly understood that your "odd" FIFO was a FIFO with an odd number (as in not even) of locations and didn't mean you had a non-power of 2 "oddly sized" FIFO. As I've previously mentioned you can't perform gray-code on an odd number of addresses. You could come up with a custom scheme to do so with an even number of addresses.Thread was to design an asynchronous FIFO with odd number of depth. For example to design a FIFO of depth 33 where we do not want to design the asynchronous FIFO of depth 34 and use it for depth 33. We want to save area so that if my requirement was up to depth 33 , we shall design uptown depth 33 only and not at all uptown depth 34 as we want to save area and not to loose area for an extra 34th location. Hope it clarifies the question in the thread.
Target is not to design an asynchronous FIFO of depth 34 and then derive an asynchronous FIFO of depth 33 as it waste the area for the 34th location.
But having a depth of 34 when 33 is really used in the design, is "no cardinal sin", IF YOUR FIFO WIDTH IS NOT SIGNIFICANTLY LARGE. But then you have REPEATEDLY failed to provide us info on the FIFO width. In a design team your manager will not pull you up for for the "one extra depth"!I need an asynchronous FIFO to store data and it should be minimum of depth 33. Even an asynchronous FIFO of depth 34 will solve my problem, but I cannot even waste area by increasing the depth to 34. So definitely I want depth of 33 to save area.
Did you read the *last paragraph* of my last comment? Do you have anything to say about it?Please review my comments and provide feedback.
Wrong!!!The specification for the problem along with the clarification is sufficient and does not need to include the width of the FIFO.
I wonder if you considered the added register hack or the rolling buffer using a larger RAM the elegant approach ;-)ads-ee sketched an elegant way to design it. So you have two options: use less effective none gray code method for pointer synchronisation, or a combination of power-of-two sized DCFIFO and "odd" sized SDFIFO, respectively single register.
I'm not sure what the limitations on RAM sizes in an ASIC are (haven't worked on ASICs for decades), but is going from say a 33 deep RAM to a 64 deep RAM going to be such a huge die real estate problem? Besides that if you really need to optimize the size it is almost always better to cascade a FIFO with another FIFO.
The point I was making is that they wouldn't be able to get any savings by having a RAM that is 33 vs 64 as I thought the underlying RAM would always be 64. Also how much of a die real estate impact would there be between adding logic for the extra 33rd entry vs using a larger RAM for the FIFO.most SRAM compilers will generate the same block whether you want 33 or 64. In this specific case of 33, it would be a good idea to let the RAM handle 32 elements and the 33rd you do with logic. The wr/rd/full/empty pointer logic is nearly identical anyway.
agreed, shrinking from 64 to 33 can have zero impact depending on how the compiler behaves.The point I was making is that they wouldn't be able to get any savings by having a RAM that is 33 vs 64 as I thought the underlying RAM would always be 64. Also how much of a die real estate impact would there be between adding logic for the extra 33rd entry vs using a larger RAM for the FIFO.
Which I why I mentioned in post #29 using logic to create the 33rd element of such a FIFO.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?