sram

[Richard Damon]

On 8/11/17 3:04 AM, rickman wrote:

Richard Damon wrote on 8/11/2017 12:09 AM:
On 8/10/17 10:39 PM, rickman wrote:
Allan Herriman wrote on 8/10/2017 2:02 AM:
On Wed, 09 Aug 2017 22:33:40 -0400, rickman wrote:

brimdavis@gmail.com wrote on 8/8/2017 8:37 PM:
KJ wrote:

It's even easier than that to synchronously control a standard async
SRAM.
Simply connect WE to the clock and hold OE active all the time
except
for cycles where you want to write something new into the SRAM.

As has been explained to you in detail by several other posters, your
method is not 'easier' with modern FPGA's and SRAMs.

The simplest way to get a high speed clock {gated or not} off the
chip,
coincident with other registered I/O signals, is to use the dual-edge
IOB flip-flops as I suggested.

The DDR technique I mentioned would run synchronous single-cycle read
or write cycles at 50 MHz on a Spartan-3 Starter kit with an
(IIRC) 10
ns SRAM, 66 MHz if using a duty-cycle-skewed clock to meet the WE
pulse
width requirements.

Another advantage of the 'forwarding' method is that one can use the
internal FPGA clock resources for clock multiply/divides etc.
without
needing to also manage the board-level low-skew clock distribution
needed by your method.

I can't say I follow what you are proposing. How do you get the clock
out of the FPGA with a defined time relationship to the signals
clocked
through the IOB? Is this done with feedback from the output clock
using
the internal clocking circuits?


About a decade back, mainstream FPGAs gained greatly expanded IOB
clocking abilities to support DDR RAM (and other interfaces such as
RGMII).
In particular, one can forward a clock out of an FPGA pin phase aligned
with data on other pins. You can also use one of the internal PLLs to
generate phase shifted clocks, and thus have a phase shift on the pins
between two data signals or between the clock and the data signals.

This can be done without needing feedback from the pins.


You should try reading a datasheet occasionally - they can be very
informative.
Just in case someone has blocked Google where you are: here's an
example:
https://www.xilinx.com/support/documentation/user_guides/ug571-ultrascale-

selectio.pdf

Thank you for the link to the 356 page document. No, I have not
researched how every brand of FPGA implements DDR interfaces mostly
because I have not designed a DDR memory interface in an FPGA. I did
look
at the document and didn't find info on how the timing delays through
the
IOB might be synchronized with the output clock.

So how exactly does the tight alignment of a clock exiting a Xilinx FPGA
maintain alignment with data exiting the FPGA over time and differential
temperature? What will the timing relationship be and how tightly
can it
be maintained?

Just waving your hands and saying things can be aligned doesn't explain
how it works. This is a discussion. If you aren't interested in
discussing, then please don't bother to reply.


Thinking about it, YES, FPGAs normally have a few pins that can be
configured as dedicated clock drivers, and it will generally be
guaranteed
that if those pins are driving out a global clock, then any other pin
with
output clocked by that clock will change so as to have a known hold time
(over specified operating conditions). This being the way to run a
typical
synchronous interface.

Since this method requires the WE signal to be the clock, you need to
find a
part that has either a write mask signal, or perhaps is multi-ported
so this
port could be dedicated to writes and another port could be used to read
what is needed (the original part for this thread wouldn't be usable with
this method).

I'm not sure you read the full thread. The method for generating the WE
signal is to use the two DDR FFs to drive a one level during one half of
the clock and to drive the write signal during the other half of the
clock. I misspoke above when I called it a "clock". The *other* method
involved using the actual clock as WE and gating it with the OE signal
which won't work on all async RAMs.

So with the DDR method *all* of the signals will exit the chip with a
nominal zero timing delay relative to each other. This is literally the
edge of the async RAM spec. So you need to have some delays on the
other signals relative to the WE to allow for variation in timing of
individual outputs. It seems the method suggested is to drive the CS
and WE signals hard and lighten the drive on the other outputs.

This is a method that is not relying on any guaranteed spec from the
FPGA maker. This method uses trace capacitance to create delta t =
delta v * c / i to speed or slow the rising edge of the various
outputs. This relies on over compensating the FPGA spec by means that
depend on details of the board layout. It reminds me of the early days
of generating timing signals for DRAM with logic delays.

Yeah, you might get it to work, but the layout will need to be treated
with care and respect even more so than an impedance controlled trace.
It will need to be characterized over temperature and voltage and you
will have to design in enough margin to allow for process variations.

Driving them all with DDR signals isn't putting you at the edge of the
spec, but only at the edge of the spec assuming everything is matched
nominal no-skew. Since we KNOW that output matching is not perfect, and
we don't have a manufacture guaranteed bias (a guarantee that if any
output if faster, it will be this one), we are starting outside the
guaranteed specs. Yes, you can pull some tricks to try and get back into
spec and establish a bit of margin, but this puts the design over into
the realms of 'black arts', and best avoided if possible.

 

[Brian Davis]

On Saturday, August 12, 2017 at 12:18:59 PM UTC-4, Richard Damon wrote:

Since we KNOW that output matching is not perfect

Both you and rickman seem to be missing the entire point
of my original post; i.e. you wrote earlier:

4) Discrete Pulse generation logic, have logic on
the board with delay lines to generate the write pulse
so that WE will pulse low shortly after the address
is stable, and comes back high shortly before the
address might change again.

The built in dual-edge I/O logic on many FPGAs provides
EXACTLY this capability, but with much better PVT tracking.

Although my ancient Spartan-3 example code didn't
explicitly adjust the edge delay with either a DCM/PLL
or IOB delay element (although I did mention DCM duty cycle
tweaks), this is very straightforward to do in many recent
FPGA families.

Yes, you can pull some tricks to try and get
back into spec and establish a bit of margin
but this puts the design over into the realms
of 'black arts'

Relying on characterized minimums to meet hold times
is not a 'black art'; it is the underlying reason why
synchronous digital logic works at all.

I.e. connecting two sections of a 74LS74 in series
at the board level requires that Tplh/Tphl (min) of
the first flip-flop be greater than the hold time of
the next. (And yes, I realize that some logic technologies
require dummy routing or buffers in the datapath to avoid
hold time violations.)

Particularly with a vendor evaluation board like I used
for that 2004 Spartan-3 Starter Kit SRAM example, it is
far more likely that signal integrity problems with the
WE line, rather than buffer delay behavior, causes problems.

-Brian

 

[Richard Damon]

On 8/14/17 6:42 PM, Brian Davis wrote:

On Saturday, August 12, 2017 at 12:18:59 PM UTC-4, Richard Damon wrote:

Since we KNOW that output matching is not perfect


Both you and rickman seem to be missing the entire point
of my original post; i.e. you wrote earlier:

4) Discrete Pulse generation logic, have logic on
the board with delay lines to generate the write pulse
so that WE will pulse low shortly after the address
is stable, and comes back high shortly before the
address might change again.

The built in dual-edge I/O logic on many FPGAs provides
EXACTLY this capability, but with much better PVT tracking.

Although my ancient Spartan-3 example code didn't
explicitly adjust the edge delay with either a DCM/PLL
or IOB delay element (although I did mention DCM duty cycle
tweaks), this is very straightforward to do in many recent
FPGA families.


Yes, you can pull some tricks to try and get
back into spec and establish a bit of margin
but this puts the design over into the realms
of 'black arts'

Relying on characterized minimums to meet hold times
is not a 'black art'; it is the underlying reason why
synchronous digital logic works at all.

I.e. connecting two sections of a 74LS74 in series
at the board level requires that Tplh/Tphl (min) of
the first flip-flop be greater than the hold time of
the next. (And yes, I realize that some logic technologies
require dummy routing or buffers in the datapath to avoid
hold time violations.)

Particularly with a vendor evaluation board like I used
for that 2004 Spartan-3 Starter Kit SRAM example, it is
far more likely that signal integrity problems with the
WE line, rather than buffer delay behavior, causes problems.

-Brian

The 'Black Art' I was referring to was NOT datasheet min/maxs but using
strong/weak drive and bus loading to convert timing that doesn't meet
guaranteed performance (since given two outputs, there will be some
skew, and absent some unusual specification that pin x will always be
faster than pin y, we need to allow that x might be slower than y) into
something that likely 'works'.

 

[Brian Davis]

Richard Damon wrote:

The 'Black Art' I was referring to was NOT datasheet min/maxs
but using strong/weak drive and bus loading to convert timing
that doesn't meet guaranteed performance

As I explained to rickman several posts ago, the Spartan-3
I/O buffer base delay vs. IOSTANDARD/SLEW/DRIVE is fully
characterized and published by Xilinx:

Xilinx characterizes and publishes I/O buffer switching
parameters vs. IOSTANDARD/SLEW/DRIVE settings; this
information is both summarized in the datasheet and used
in generating the timing reports, providing the base delay
of the I/O buffer independent of any external capacitive loading.

If you don't want to rely on a guaranteed minimum delay
between I/O buffer types at the FAST device corner, that's
fine with me, but please stop with the baseless criticism.

-Brian

 

[Richard Damon]

On 8/15/17 5:59 PM, Brian Davis wrote:

Richard Damon wrote:

The 'Black Art' I was referring to was NOT datasheet min/maxs
but using strong/weak drive and bus loading to convert timing
that doesn't meet guaranteed performance

As I explained to rickman several posts ago, the Spartan-3
I/O buffer base delay vs. IOSTANDARD/SLEW/DRIVE is fully
characterized and published by Xilinx:

Looking at the datasheet for the Spartan-3 family, I see no minimum
times published. There is a footnote that minimums can be gotten out of
the timing analyzer. There are maximums fully specified out, including
adders for various cases, allowing you to do some of the analysis early
in the design, but to get minimum timing you need to first get the
program and a license to use it (license may be free, but you need to
give them enough information that they can contact you later asking
about your usage).

Being only available in the program, and not truly "Published" indicates
to me some significant uncertainty in the numbers. Timing reports out of
programs like this tend to be disclaimed to be valid only for THAT
particular design and the particular operating conditions requested. You
need to run the analysis over as many condition combinations they
provide and hope (they never seem to promise it) that the important
factors are at least monotonic between the data points so you can get
real min/maxs.

Xilinx characterizes and publishes I/O buffer switching
parameters vs. IOSTANDARD/SLEW/DRIVE settings; this
information is both summarized in the datasheet and used
in generating the timing reports, providing the base delay
of the I/O buffer independent of any external capacitive loading.


If you don't want to rely on a guaranteed minimum delay
between I/O buffer types at the FAST device corner, that's
fine with me, but please stop with the baseless criticism.

-Brian