Sign in

username:

password:



Not a member?

Search fpga-cpu



Search tips

Subscribe to fpga-cpu



fpga-cpu by Keywords

Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Ads

Discussion Groups

Discussion Groups | FPGA-CPU | Questions re: SRAM

This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).

Questions re: SRAM - rtstofer - Oct 22 14:15:00 2004



I have been looking at a couple of datasheets for the SRAM I am
using: First, on the Spartan 3 Starter Board is
http://www.issi.com/pdf/61LV25616AL.pdf and second, on the BurchED
SRAM board is
http://www.cypress.com/cfuploads/img/products/7c1019bv33.pdf where
the actual part is the 1018.

There must be something subtle that I am missing because I don't see
any issue with reading or writing in a single cycle. Now, the
reason I suspect I misunderstand is that there are several scenarios
for each operation.

In my case, with the Cypress part and the T80 core, I apply the
address constantly. For a write I turn the FPGA data output on
holding the SRAM CE off. The WE signal is set up early depending on
whether the CPU is requesting read or write and this keeps the SRAM
output buffers tristated. During the last half of the clock I
strobe the SRAM CE. In the case of a read I tristate the FPGA
buffers. During the last half of the clock I strobe the CE turning
on the SRAM output buffers. In some ways this is convoluted by the
fact that OE is not brought out as a separate signal from the board
but it turns out to not be necessary.

MEMRD_n <= RD_n or MREQ_n; -- cpu wants to read memory
MEMWR_n <= WR_n or MREQ_n; -- cpu wants to write memory
SRAM_CE_n_i <= '0' when ( (Clk = '0') and (MREQ_n = '0') ) else '1';
SRAM_CE_n <= SRAM_CE_n_i;
SRAM_A(15 downto 0) <= A(15 downto 0); -- always follows the A bus
SRAM_WE_LB_n <= MEMWR_n; -- I only use the lower 8 bits
SRAM_WE_UB_n <= '1'; -- not used
SRAM_D <= D when MEMWR_n = '0' else "ZZZZZZZZ"; -- tristate inferred

Now, this seems to work ok but I am somewhat concerned because I
have seen other references to multi-cycle timings.

WebPACK whines about gating the Clk for SRAM CE but I have been
ignoring that. All of the above signals are combinatorial; they are
not in a process.

Any chance I am doing this properly?
Thanks
Richard




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )


Re: Questions re: SRAM - Arius - Rick Collins - Oct 22 17:46:00 2004

At 03:15 PM 10/22/2004, you wrote:
>I have been looking at a couple of datasheets for the SRAM I am
>using: First, on the Spartan 3 Starter Board is
>http://www.issi.com/pdf/61LV25616AL.pdf and second, on the BurchED
>SRAM board is
>http://www.cypress.com/cfuploads/img/products/7c1019bv33.pdf where
>the actual part is the 1018.
>
>There must be something subtle that I am missing because I don't see
>any issue with reading or writing in a single cycle. Now, the
>reason I suspect I misunderstand is that there are several scenarios
>for each operation.

Certainly, you can do operations in a single clock cycle, but I thought you
were having problems with the speed of your circuit. Using the OE will
help you speed up the circuit. >In my case, with the Cypress part and the T80 core, I apply the
>address constantly. For a write I turn the FPGA data output on
>holding the SRAM CE off. The WE signal is set up early depending on
>whether the CPU is requesting read or write and this keeps the SRAM
>output buffers tristated. During the last half of the clock I
>strobe the SRAM CE. In the case of a read I tristate the FPGA
>buffers. During the last half of the clock I strobe the CE turning
>on the SRAM output buffers. In some ways this is convoluted by the
>fact that OE is not brought out as a separate signal from the board
>but it turns out to not be necessary.
>
>MEMRD_n <= RD_n or MREQ_n; -- cpu wants to read memory
>MEMWR_n <= WR_n or MREQ_n; -- cpu wants to write memory
>SRAM_CE_n_i <= '0' when ( (Clk = '0') and (MREQ_n = '0') ) else '1';
>SRAM_CE_n <= SRAM_CE_n_i;
>SRAM_A(15 downto 0) <= A(15 downto 0); -- always follows the A bus
>SRAM_WE_LB_n <= MEMWR_n; -- I only use the lower 8 bits
>SRAM_WE_UB_n <= '1'; -- not used
>SRAM_D <= D when MEMWR_n = '0' else "ZZZZZZZZ"; -- tristate inferred
>
>Now, this seems to work ok but I am somewhat concerned because I
>have seen other references to multi-cycle timings.
>
>WebPACK whines about gating the Clk for SRAM CE but I have been
>ignoring that. All of the above signals are combinatorial; they are
>not in a process.
>
>Any chance I am doing this properly?

You are doing what is called a CE controlled write. This will work just
fine. Likewise your CE controlled read will work as well. But you are
limiting your clock speed by the CE pulse. Assuming you are using the
Cypress CY7C1018BV33-15VC, on a read the data will not be output until 15
ns after the CE is low. Since this is half the clock, your clock speed is
33 MHz max, not counting the setup time on the FPGA inputs. If you use the
OE gated with the clock, you can get data 7 ns later so your clock can run
at up to 67 MHz, ignoring the other delays.

The concern on a write is that the data and address must remain stable
until the CE or WE are high. Since they are coming from the same clock
this is a race condition. In fact, the CE you are using is gated with the
clock, so it will be delayed and your data/address can change before the WE
goes high.

My async ram designs typically change the CE along with the address, if
needed. The OE is used if I have to be concerned with bus contention and
the WE is clocked on the opposite edge of the clock so that the
data/address is stable well before and after the WE changes. If you have
no other devices on the bus, you *can* use the single WE signal ignoring CE
and OE, but you can have some bus contention for a moment when WE goes high.

One last thought, if a bus is otherwise tristate, a driver being released
does not mean the bus goes invalid. Typically the bus is high-Z and will
hold a given value for microsecs or more. So if you turn off your data bus
drivers with the WE signal, your bus contention issue can be minimal or
none. Notice that they spec a 3 ns minimum output enable on WE going high.
Rick Collins
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX




(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Questions re: SRAM - rtstofer - Oct 22 18:56:00 2004



Rick,

Thanks for the input. I may not go back and fix the T80 with
Cypress configuration. I am a little burned out on that project -
it is done.

For the Spartan 3 I have been looking at the internal frequency
syntesizer. The crystal is fixed at 50 MHz which is an acceptable
clock rate for the P4 (I should live so long...) so if I can
generate, internally, a 200 MHz signal I can do the bus turn-around
in the 1st quarter and have the last 3 quarters of a CPU clock for
access. Plus I have access to the OE signal - it is not available
on the BurchED SRAM card.

Again, thanks. Now, I have to study that datasheet - all 17 pages!

Richard

--- In , Arius - Rick Collins
<dsprelated@a...> wrote:
> At 03:15 PM 10/22/2004, you wrote: >
> >I have been looking at a couple of datasheets for the SRAM I am
> >using: First, on the Spartan 3 Starter Board is
> >http://www.issi.com/pdf/61LV25616AL.pdf and second, on the BurchED
> >SRAM board is
> >http://www.cypress.com/cfuploads/img/products/7c1019bv33.pdf where
> >the actual part is the 1018.
> >
> >There must be something subtle that I am missing because I don't
see
> >any issue with reading or writing in a single cycle. Now, the
> >reason I suspect I misunderstand is that there are several
scenarios
> >for each operation.
>
> Certainly, you can do operations in a single clock cycle, but I
thought you
> were having problems with the speed of your circuit. Using the OE
will
> help you speed up the circuit. > >In my case, with the Cypress part and the T80 core, I apply the
> >address constantly. For a write I turn the FPGA data output on
> >holding the SRAM CE off. The WE signal is set up early depending
on
> >whether the CPU is requesting read or write and this keeps the
SRAM
> >output buffers tristated. During the last half of the clock I
> >strobe the SRAM CE. In the case of a read I tristate the FPGA
> >buffers. During the last half of the clock I strobe the CE
turning
> >on the SRAM output buffers. In some ways this is convoluted by
the
> >fact that OE is not brought out as a separate signal from the
board
> >but it turns out to not be necessary.
> >
> >MEMRD_n <= RD_n or MREQ_n; -- cpu wants to read memory
> >MEMWR_n <= WR_n or MREQ_n; -- cpu wants to write memory
> >SRAM_CE_n_i <= '0' when ( (Clk = '0') and (MREQ_n = '0') )
else '1';
> >SRAM_CE_n <= SRAM_CE_n_i;
> >SRAM_A(15 downto 0) <= A(15 downto 0); -- always follows the A bus
> >SRAM_WE_LB_n <= MEMWR_n; -- I only use the lower 8 bits
> >SRAM_WE_UB_n <= '1'; -- not used
> >SRAM_D <= D when MEMWR_n = '0' else "ZZZZZZZZ"; -- tristate
inferred
> >
> >Now, this seems to work ok but I am somewhat concerned because I
> >have seen other references to multi-cycle timings.
> >
> >WebPACK whines about gating the Clk for SRAM CE but I have been
> >ignoring that. All of the above signals are combinatorial; they
are
> >not in a process.
> >
> >Any chance I am doing this properly?
>
> You are doing what is called a CE controlled write. This will
work just
> fine. Likewise your CE controlled read will work as well. But
you are
> limiting your clock speed by the CE pulse. Assuming you are using
the
> Cypress CY7C1018BV33-15VC, on a read the data will not be output
until 15
> ns after the CE is low. Since this is half the clock, your clock
speed is
> 33 MHz max, not counting the setup time on the FPGA inputs. If
you use the
> OE gated with the clock, you can get data 7 ns later so your clock
can run
> at up to 67 MHz, ignoring the other delays.
>
> The concern on a write is that the data and address must remain
stable
> until the CE or WE are high. Since they are coming from the same
clock
> this is a race condition. In fact, the CE you are using is gated
with the
> clock, so it will be delayed and your data/address can change
before the WE
> goes high.
>
> My async ram designs typically change the CE along with the
address, if
> needed. The OE is used if I have to be concerned with bus
contention and
> the WE is clocked on the opposite edge of the clock so that the
> data/address is stable well before and after the WE changes. If
you have
> no other devices on the bus, you *can* use the single WE signal
ignoring CE
> and OE, but you can have some bus contention for a moment when WE
goes high.
>
> One last thought, if a bus is otherwise tristate, a driver being
released
> does not mean the bus goes invalid. Typically the bus is high-Z
and will
> hold a given value for microsecs or more. So if you turn off your
data bus
> drivers with the WE signal, your bus contention issue can be
minimal or
> none. Notice that they spec a 3 ns minimum output enable on WE
going high. >
> Rick Collins
>
> rick.collins@a...
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Questions re: SRAM - Brian Davis - Oct 26 20:15:00 2004


>
> WebPACK whines about gating the Clk for SRAM CE but I have been
> ignoring that. All of the above signals are combinatorial; they
> are not in a process. The easiest way to fix a gated output clock problem in
a Spartan3 is to use the DDR output registers to produce
your CE; since the DDR outputs are clocked by the same
clock tree as are the output address/data registers, the
skew problem with the locally routed clock goes away.

looks something like this:

WE_CLK_GATE : OFDDRRSE
port map
(
Q => ram_we_out_l,

C0 => clk_0,
C1 => clk_180,

D0 => '1',
D1 => ram_we_l
);

The rising edge clock on C0 always spits out a '1', the
falling edge clock on C1 either a '1' or '0' based upon
the internal we.

If you're using a DCM, generate the 0/180 degree clocks
with that, otherwise use a logical inversion at the top
level and the tools will (usually) invert the clock
in the IOB.

I'd also recommend starting with the output drivers for
all the address and data lines set to SLOW, low drive strength,
and use a SLOW CE/WE output with the drive set slightly higher.
( because the eval board shared address/data/ctl lines might
be routed as an unterminated hairball net )

Brian






(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Re: Questions re: SRAM - rtstofer - Oct 26 20:42:00 2004



Brian,

I going to try this tomorrow. It looks pretty clean.
Thanks!

Richard

--- In , "Brian Davis" <brimdavis@a...> wrote:
>
> >
> > WebPACK whines about gating the Clk for SRAM CE but I have been
> > ignoring that. All of the above signals are combinatorial; they
> > are not in a process.
> >
>
> The easiest way to fix a gated output clock problem in
> a Spartan3 is to use the DDR output registers to produce
> your CE; since the DDR outputs are clocked by the same
> clock tree as are the output address/data registers, the
> skew problem with the locally routed clock goes away.
>
> looks something like this:
>
> WE_CLK_GATE : OFDDRRSE
> port map
> (
> Q => ram_we_out_l,
>
> C0 => clk_0,
> C1 => clk_180,
>
> D0 => '1',
> D1 => ram_we_l
> );
>
> The rising edge clock on C0 always spits out a '1', the
> falling edge clock on C1 either a '1' or '0' based upon
> the internal we.
>
> If you're using a DCM, generate the 0/180 degree clocks
> with that, otherwise use a logical inversion at the top
> level and the tools will (usually) invert the clock
> in the IOB.
>
> I'd also recommend starting with the output drivers for
> all the address and data lines set to SLOW, low drive strength,
> and use a SLOW CE/WE output with the drive set slightly higher.
> ( because the eval board shared address/data/ctl lines might
> be routed as an unterminated hairball net )
>
> Brian





(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )