«

Dear Sir or Madam,

when you look at the linked site you see the simulation plots
(functional simulation) of the SRAM controller
which I am designing for the SRAM CY7C1399B.
There are shown the sram_address, sram_data and the control signals
Oe_bar, Cs_bar, We_bar
for writing to a location and reading from this location later.
But when trying to read from that location the data bus is in
undefined state ('U').
The reasons could be:
1. writing to that address was not done correctly so that the written
data is corrupted.
2. reading is not done correctly
Where could be the problem?
I would be very thankful for some useful hint..
Andrés Vázquez

p.s. Do the changed timing constants in CY7C199.vhd take affect when
doing a functional simulation ?

PLOTS --->
http://mitglied.lycos.de/vazquez78/

On 1 Mar 2004 06:58:43 -0800, (ALuPin) wrote:

[SRAM controller doesn't work correctly]

>The reasons could be:
>1. writing to that address was not done correctly

Yes. You can't be serious - you have left nWE and nCS permanently
asserted whilst changing your write data and address. Please go
back to the SRAM data sheet and understand what is meant by
"address setup time", "address hold time", "write data setup
time", "write data hold time".

> so that the written data is corrupted.

Your write controller is completely broken. On the
timing diagram you showed us, no write cycle was
ever performed.

In general it is almost impossible to do a SRAM write in
only one clock cycle, if you are using an FPGA as the
controller.

>2. reading is not done correctly

Less important. Reading an asynchronous SRAM is easy - it's just
a combinational component. You got UUUUUUUU from each location
because you have never performed a valid write to any location.

>p.s. Do the changed timing constants in CY7C199.vhd take affect when
>doing a functional simulation ?

Yes; you can easily see in your read waveforms that the SRAM
shows a delay between nOE deassertion and the RAM's output
buffers going into tri-state.

You are beginning to learn why people prefer synchronous RAMs
these days.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley <> wrote in message news:<>. ..
> On 1 Mar 2004 06:58:43 -0800, (ALuPin) wrote:
>
> [SRAM controller doesn't work correctly]

> Yes. You can't be serious - you have left nWE and nCS permanently
> asserted whilst changing your write data and address. Please go
> back to the SRAM data sheet and understand what is meant by
> "address setup time", "address hold time", "write data setup
> time", "write data hold time".
>
> > so that the written data is corrupted.
>
> Your write controller is completely broken. On the
> timing diagram you showed us, no write cycle was
> ever performed.
>
> In general it is almost impossible to do a SRAM write in
> only one clock cycle, if you are using an FPGA as the
> controller.

I have attached the SRAM data sheet from IDT at
http://mitglied.lycos.de/vazquez78/
As I can see the "address setup time" is specified with 0 ns,
the "address hold time" with 0 ns,
the "write data setup time" with 6 ns,
the "write data hold time" with 0 ns.
So I ask myself where the problem occurs
(SRAM part 71V256SA10, I am using in the FPGA a 100MHz write clock)

I would appreciate clearing.

Thank you in advance.

Best regards
Andrés Vázquez
G&D

ALuPin a écrit:

> I have attached the SRAM data sheet from IDT at
> http://mitglied.lycos.de/vazquez78/
> As I can see the "address setup time" is specified with 0 ns,
> the "address hold time" with 0 ns,
> the "write data setup time" with 6 ns,
> the "write data hold time" with 0 ns.
> So I ask myself where the problem occurs

Hi
SRAM writes occur on /WE rising edges (or /CS rising edges if /WE is low)
Since you keep /WE low, nothing ever happens.

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

Nicolas Matringe <> wrote in message news:<>...

> Hi
> SRAM writes occur on /WE rising edges (or /CS rising edges if /WE is low)
> Since you keep /WE low, nothing ever happens.


Hi,
I have changed my controller by inserting one extra state in which
n_we is deasserted. (Please go to
http://mitglied.lycos.de/vazquez78/ to view
the new plots).
But when trying to read the location I still get undefined data ...
What does still go wrong?

Rgds

Andrés Vázquez

On 2 Mar 2004 07:07:14 -0800, (ALuPin) wrote:

>I have changed my controller by inserting one extra state in which
>n_we is deasserted. (Please go to
>http://mitglied.lycos.de/vazquez78/ to view
>the new plots).
>But when trying to read the location I still get undefined data ...

You are not being a good professional paranoid engineer!

Before going any further, please make one more modification:
Keep the writing data asserted and stable until AFTER
you take n_WE back to '1', so that there is plenty of data
hold time after the rising edge of n_WE.

If this works, you will have some clues about how to re-
implement the controller.

If it doesn't work, then something else is going wrong.
You may find it's useful to probe the internal signals
of the Cypress SRAM model to get a better idea of what's
happening.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

i faced the similar situation when i worked on it...infact the solution is
simple...you have to keep the data bus in "Z" state, whenever you are
expecting data from SDRAM. it will then work properly....

hope this will solve yoru problem...

Dk

"deep" <> wrote in message news:< alkaboutprogramming.com>...
> i faced the similar situation when i worked on it...infact the solution is
> simple...you have to keep the data bus in "Z" state, whenever you are
> expecting data from SDRAM. it will then work properly....
>
> hope this will solve yoru problem...
>
> Dk

Hi,

you say "SDRAM" ? So you mean SDRAM or SRAM ?

Rgds

AV