Uses of Gray code in digital design

"Hal Murray" <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote in message 
news:2q-dnXHQf72ryHXbnZ2dnUVZ_tninZ2d@megapath.net...
>
> 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


Hal,

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.


Nial.

On Sep 13, 10:02 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> "Hal Murray" <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote in message
>
> news:2q-dnXHQf72ryHXbnZ2dnUVZ_tninZ2d@megapath.net...
>
>
>
> > 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
>
> Hal,
>
> 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.
>
> Nial.

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...
1. Setup address
2. Enable write and put out data to be written
3. Disable write
4. Allow address and data to do whatever.

KJ

>The general sequence of events to write to async SRAM is...
>1. Setup address

Wait address setup time

>2. Enable write and put out data to be written

Wait max of
  data setup time
  min write pulse width

>3. Disable write

Wait address/data hold time

>4. Allow address and data to do whatever.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.

>> How about
>>  1: change address
>>  2: wait for address to settle and data hold time
>>  3: write new data

>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 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.

On Sep 13, 10:02 pm, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> "Hal Murray" <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote in message
>
> news:2q-dnXHQf72ryHXbnZ2dnUVZ_tninZ2d@megapath.net...
>
>
>
> > 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)
>

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.

> 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?

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
www.nialstewartdevelopments.co.uk

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:5kuvpsF5kqemU1@mid.individual.net...
>> 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?
>
> 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....
>
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

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=6&f=G&l=50&co1=AND&d=PTXT&s1=Jennings.INNM.&s2=Unisys.ASNM.&OS=IN/Jennings+AND+AN/Unisys&RS=IN/Jennings+AND+AN/Unisys

>
> 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.
>
Agreed, you'd probably have to get some more info from the SRAM suppliers to 
see if it would really work.

KJ