SRAM controller problems

Discussion in 'VHDL' started by ALuPin, Mar 1, 2004.

  1. ALuPin

    ALuPin Guest

    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/
     
    ALuPin, Mar 1, 2004
    #1
    1. Advertising

  2. 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, Mar 1, 2004
    #2
    1. Advertising

  3. ALuPin

    ALuPin Guest

    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, Mar 2, 2004
    #3
  4. 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, Mar 2, 2004
    #4
  5. ALuPin

    ALuPin Guest

    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
     
    ALuPin, Mar 2, 2004
    #5
  6. 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.
     
    Jonathan Bromley, Mar 2, 2004
    #6
  7. ALuPin

    deep Guest

    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, Apr 15, 2004
    #7
  8. ALuPin

    ALuPin Guest

    "deep" <> wrote in message news:<>...
    > 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
     
    ALuPin, Apr 16, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ALuPin
    Replies:
    3
    Views:
    931
    ALuPin
    Apr 22, 2004
  2. bittor
    Replies:
    0
    Views:
    2,597
    bittor
    Dec 22, 2004
  3. bittor
    Replies:
    2
    Views:
    602
    bittor
    Dec 23, 2004
  4. bat
    Replies:
    0
    Views:
    769
  5. Michael Earls
    Replies:
    3
    Views:
    3,389
    MBUnit
    Mar 24, 2009
Loading...

Share This Page