Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
I am trying to be brief not arrogant ... please forgive me if you feel it is in bad format.
############
Basic components of FIFO: Memory, Read Pointer and Write pointer
Read pointer : decrement on every read
Write pointer : Increment on every read.
############
Power basics : Most power consumption takes place in Flip flops when there is a value change
############
Basic operation in FIFO : increment/decrement Rd/ Wr Pointer and access the memory.
############
Property of grey code : Only one bit value change when incremented.
############
So if you implement the rd pointer and wr pointer in grey code it can save you power.
Hi,
The reason for changing 1 bit at a time is not just reducing time constraints, it is also to simplify error correction problems.
E.g compare increasing from '00111' -> '01000' with using Gray code '00111' -> '01111'.
If any error occurs, it would be immediately seen EXCEPT when '00111' -> '00110' or using grey code '00111' -> '00110' (decreasing state).
Since only 1 bit changes at a time, for Gray code, the chance for an error to happen (due to timing issues) could be considered lower.
Also, an error can also be easily detected using Gray code to check if 2 bits change instead, thus making error correction designs simpler.
Whether we really need to translate to binary I think depends on the design. It doesn't seem necessary to me if only the machine has to read/write data to it.
Hey pennsia,
Ok this may seem contridictory but then welcome Design world!
Q. Why do you need grey2bin and bin2grey in the design.
A. Most memory array follow a simple binary addressing scheme. i.e. Memory locations are addressed by binary and not grey code. so if you want to "neatly" store in your memory that is you want to store 3 data say 0x1,0x2,0x3 into the first three locations then you start by storing 0x1 into 0x0000 location, then incr addr to 0x0001 and store 0x2 and so on.
So what's the contradiction here...if you use grey2bin and bin2grey to convert your writer pointer back to seq. memory address for you RAM and bin2grey to convert the binary number to you read pointer. You end up wasting a lot of gates that are now going through a lot of transistions lossing power!
Yeah its much better power wise to keep the memory "jumbled" that is '00111' -> '01111' that is the memory locations b/w 0'b00111 to 0'b01111 will have junk data. But if you do decide to do this implementation it is very difficult nay.. nightware debugging errors if they occur in your design
I doubt you can save a lot of power with gray code logic. Most logic designers designing FIFOs do NOT even consider saving power.
You use gray code counters in asynchronous FIFO design where the write pointer is in a different clock domain than the read pointer, AND, when the pointers are multi-bit. This is to correctly detect full and empty conditions.
Hi,
As the binary counter is incremented from say from 011 then there will some intermediate states, as the read pointer is synchronized with write clock and if during these intermediate transitions the count gets captured then you will have wrong flag condition.
And we use g2b and counter because you cannot directly add 1 to gray count, it will result in wrong gray count. Therefore you convert to binary, increment and convert back to gray.
usually the read and write pointer is compared combo to generate full or empty condition and the flag will be passed to read/write clock domain.
In this process if you are using binary counter to compare the read and write pointer there is a chance of formation of glitch because in binary counter all the bits will toggle if it is incremented from final value to 0(i.e say u r using 4 bit counter then frm 1111 to 0000). This can be founded oly during gate level simulation. But in the gray the value formation of glitch is having less possibilities.
so in comparision usually we will use gray counter.
For easier debugging we are using binary counter instead of gray.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.