It's even better - with the Gray code, you don't need the FF synchronisation at all, as long as you are stepping up or down through the codes (it's a different matter for step machines that jump steps). The point is that whenever you look at the code as it passes from one value to the next, it is either in the old state or in the new state - there is nothing in between. With a binary counter, you could see intermediary stages as different bits toggle with different delays. Synchronisation FF's have nothing to do with it.
It gets murkier when you have to allow for finite routing delays, and in the newest FPGAs routing delays can be significant.
Yes, Johnson counters can be useful, and can decode glitch-free as well as Gray counters. The simpler D-FF structure of Johnson counters means they can often count faster than other counters. - but they need more registers for a given modulus, so it's a trade-off.
IMHO I'd be very wary of this statement (and would be interested to hear how others see it). I remember looking at metastability tests on flip-flops many years ago and there are two issues here:
1) Catching / not catching a state change
2) Lengthening of the FF switching time when set-up/hold times are not met
Particularily with 2), the tests I observed back then showed a factor of three to five times against the specified switching time when set-up/hold times are met. The higher the capacitive load on the FF the worse it got.
So, if you have your two gray counters (one being asynchronous) and feed them to a comparator which then goes to a Full/Empty flag FF, the timing of the path asynch_gray_counter -> comparator -> full_or_empty_ff will not be what your timing analysis said if you actually hit the meta-stability window. If you are running at max speed, this may well mean that the set-up/hold times on the full/empty FF input are not met, effectively meaning that the output of this FF now becomes meta-stable.
IMHO, the advantage of the Gray-coding is that you are guaranteed not to observe any intermediate switching states (i.e. point 1 above is addressed) but I would still synchronise the output to be sure that metastability is not just propogated down the line and eventually causing problems at some unexpected circuit node.
That's what I wrote, though for a large counter, you don't want to exclusively use unary, because it will require too much space. A combination of unary code at the byte level with a gray code addressing scheme works quite nicely.
I think you also need something like: 1.5: Wait for new address to settle
Gray code makes sure you only write something to either the old address or the new address. You also have to make sure that the new data doesn't get written to the old address. (or probably worse, part of the new data gets written on top of the old data)
How about 1: change address 2: wait for address to settle and data hold time 3: write new data
--
These are my opinions, not necessarily my employer's. I hate spam.
Agreed - if you are looking at the gray-coded values from a different clock domain, then the signals are asynchronous and must be treated as such (with meta-stability handling as required). Someone also pointed out that your binary-to-gray coder may also be subject to glitches which could pass through to the output - it must be designed carefully. All in all, I'd prefer to let the development tools produce things like FIFOs - they are going to be smaller, faster and safer than if I tried to hand code them myself. But it's nice to know how they work.
If you were using an FPGA to do this you could clock the address out on the rising edge of the clock, the data out on the falling edge. If setup and hold times were met this would get you one write per clock.
I'm assuming from all this, that we're talking about interfacing to async memory. If so, then what you suggest will possibly fail timing because of a race condition between the write strobe going inactive and the address starting to change. So just exactly when would you be strobing the write signal itself? In order to do as you say the write pulse would need to be some time after the rising edge (after address settle max) but prior to or roughly coincident with the rising edge of the next clock (i.e. prior to address change min). It can be done, but from your post it seems like you're suggesting it would all be done simply with flops and run at the clock rate that clocks the flops at one write per clock....or am I missing something here?
The general sequence of events to write to async SRAM is...
I think that would work, but the RAM only gets a half cycle to do the write so you probably need a faster RAM. (or a slower cycle time on the FPGA)
As always, check the fine print in the data sheet. With something like this, check again. (Or better yet, get somebody else to double check your work, not just the arithmetic, but the reading of the data sheet.)
--
These are my opinions, not necessarily my employer's. I hate spam.
It depends on the application of course. When I first encountered this technique it was on a video sampling hardware. As such it didn't matter much if the intended data happened to appear one pixel to the left. I guess back then memory was fast but logic was slow especially since in that specific case it was a bunch of 74xx TTL logic chips.
You wouldn't, if you'd read the thread you'd have seen that the write strobe is being held active and the (grey coded) address change is being used to action the write....
Addr X ADR1 X ADR2 X ADR3 X ADR4 X
Data X D1 X D2 X D3 X D4 X
I've never tried this in anger because no sram data sheet that I could find had any information on whether this mechanism would work, it was just an idea on how to stream data into an external SRAM faster.
Nial.
---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 516 8883
32/12 Hardengreen Business Park Fax: +44 131 663 8771 Dalkeith, Midlothian EH22 3NX
"Nial Stewart" wrote in message news: snipped-for-privacy@mid.individual.net...
I read the thread but admit I did forgot the point about always writing to the SRAM. For 'every clock cycle' read/write to SRAMs applications, I like the following
formatting link
Agreed, you'd probably have to get some more info from the SRAM suppliers to see if it would really work.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.