Continue to Site

Welcome to EDAboard.com

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.

why FIFO design using grey code?

Status
Not open for further replies.

pennsia

Junior Member level 1
Joined
May 27, 2009
Messages
16
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,391
fifo design

Can anyone explain the reason for grey code used in FIFO deisng? Thx a lot.
 

grey code

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.
 

gray code fifo

I see. So the only reason to use grey code is to save the times of flipping. But we do need grey2bin and bin2grey both in real FIFO design, right?
 

fifo design

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.
 

fifo code

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

Good luck with your implementation.
 

tryey gray code

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.

You can read more at https://en.wikipedia.org/wiki/Gray_code

- Hung
 

fifo memory wikipedia

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.


Thanks,
Niks
 

pennsia

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.
 

fifo message hindi

grey code can help to reduce meta-stability issue!
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top