"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'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
Reply by Nial Stewart●September 14, 20072007-09-14
> 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
Reply by sleb...@yahoo.com●September 14, 20072007-09-14
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.
Reply by Hal Murray●September 13, 20072007-09-13
>> 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.
Reply by Hal Murray●September 13, 20072007-09-13
>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.
Reply by KJ●September 13, 20072007-09-13
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
Reply by Nial Stewart●September 13, 20072007-09-13
"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.
> David Brown wrote:
>
>> 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).
>
> 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.
>
> Regards,
> Charles
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.
mvh.,
David
Reply by Hal Murray●September 12, 20072007-09-12
>glitches. The typical write operation is:
>
>1. change address.
I think you also need something like:
1.5: Wait for new address to settle
>2. toggle write signal to write data.
>Gray code avoids glitches in a different way. It avoids glitches by
>ensuring that only a single bit changes when the address change. This
>allows us to do everything in a single clock cycle:
>
>(write signal is always set)
>1. change address and write data.
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.