Problems with Tristate

Discussion in 'VHDL' started by ALuPin, Nov 18, 2004.

  1. ALuPin

    ALuPin Guest

    Hi,

    I have the following problem:


    My functional simulation system is built up like that: (I use Modelsim 5.8c Altera)

    VHDL SDRAM Controller
    -- Port declaration
    DQ inout : std_logic_vector(15 downto 0)


    VHDL testbench
    -- interconnection declaration
    t_dq : std_logic_vector(15 downto 0);


    SDRAM VHDL model
    -- Port declaration
    DQ : inouot std_logic_vector(15 downto 0);


    In the testbench I connect the modules in the following manner:

    u1: sdram_controller
    port map ( ...
    DQ => t_dq,
    ...
    );

    u2: sdram
    port map ( ..
    DQ => t_dq,
    ..
    );

    In the SDRAM controller I make a concurrent assignment
    where l_we_burst is the enable signal to drive data onto
    the bus and l_data_to_write is the data I want to write into
    the SDRAM:

    DQ <= l_data_to_write when (l_we_burst='1') else (others =>'Z');

    In the testbench I write data to some locations --> I can see the data
    on the bus

    Later I want to read data from SDRAM by asserting readaddress etc.
    When I have a look at the DQ port of the SDRAM and the interconnection
    t_dq I can see the READ DATA.

    But when I have a look at the DQ port of the SDRAM Controller I do
    not see the READ data but "ZZZ..Z". (during READ the signal l_we_burst
    is LOW - the simulation shows)

    Can someone explain to me what goes wrong?

    Rgds
    André
    ALuPin, Nov 18, 2004
    #1
    1. Advertising

  2. ALuPin wrote:

    > VHDL SDRAM Controller
    > -- Port declaration
    > DQ inout : std_logic_vector(15 downto 0)
    >
    >
    > VHDL testbench
    > -- interconnection declaration
    > t_dq : std_logic_vector(15 downto 0);


    This is a signal declaration, right?

    > In the testbench I write data to some locations --> I can see the data
    > on the bus


    Does it make it into the memory array in the sdram model?

    > Later I want to read data from SDRAM by asserting readaddress etc.
    > When I have a look at the DQ port of the SDRAM and the interconnection
    > t_dq I can see the READ DATA.


    That sounds ok.

    > But when I have a look at the DQ port of the SDRAM Controller I do
    > not see the READ data but "ZZZ..Z". (during READ the signal l_we_burst
    > is LOW - the simulation shows)
    >
    > Can someone explain to me what goes wrong?


    What is wrong? You are writing data and reading it
    back to the t_dq bus. What feature is missing?

    -- Mike Treseler
    Mike Treseler, Nov 18, 2004
    #2
    1. Advertising

  3. ALuPin

    ALuPin Guest

    Mike Treseler <> wrote in message news:<>...
    > ALuPin wrote:
    >
    > > VHDL SDRAM Controller
    > > -- Port declaration
    > > DQ inout : std_logic_vector(15 downto 0)
    > >
    > >
    > > VHDL testbench
    > > -- interconnection declaration
    > > t_dq : std_logic_vector(15 downto 0);

    >
    > This is a signal declaration, right?
    >
    > > In the testbench I write data to some locations --> I can see the data
    > > on the bus

    >
    > Does it make it into the memory array in the sdram model?
    >
    > > Later I want to read data from SDRAM by asserting readaddress etc.
    > > When I have a look at the DQ port of the SDRAM and the interconnection
    > > t_dq I can see the READ DATA.

    >
    > That sounds ok.
    >
    > > But when I have a look at the DQ port of the SDRAM Controller I do
    > > not see the READ data but "ZZZ..Z". (during READ the signal l_we_burst
    > > is LOW - the simulation shows)
    > >
    > > Can someone explain to me what goes wrong?

    >
    > What is wrong? You are writing data and reading it
    > back to the t_dq bus. What feature is missing?
    >
    > -- Mike Treseler


    It is missing that I cannot see the READ DATA on the DQ port of my
    SDRAM controller. It stays 'Z'.
    ALuPin, Nov 19, 2004
    #3
  4. ALuPin

    ALuPin Guest

    Please have a look at
    http://mitglied.lycos.de/vazquez78/ -> TRISTATE
    The simulation shows that WRITE DATA appear on DQ and t_dq
    but READ DATA only appear on t_dq.

    Rgds
    André


    > What is wrong? You are writing data and reading it
    > back to the t_dq bus. What feature is missing?
    >
    > -- Mike Treseler
    ALuPin, Nov 19, 2004
    #4
  5. ALuPin wrote:
    > Please have a look at
    > http://mitglied.lycos.de/vazquez78/ -> TRISTATE
    > The simulation shows that WRITE DATA appear on DQ and t_dq
    > but READ DATA only appear on t_dq.


    Hmm. I don't think those ports are wired
    together like you think they are.
    Remember that the controller is driving
    only write data. The read data comes from
    the ram.

    When data does not appear where you expect it,
    the likely culprits are:

    1. A missing wire

    Check signal names, port maps, wave hierarchy.

    2. A missing or disabled assignment.

    Check the processes driving the data.
    Does the proper assignment exist?
    What are the conditions for the assignment?
    Walk through the code.

    3. A more subtle logical error.

    Run the testbench with breakpoints
    on the signal assignments.

    Good luck.

    -- Mike Treseler
    Mike Treseler, Nov 20, 2004
    #5
  6. ALuPin

    ALuPin Guest

    Thank you for your help.

    I have gone through your different points. It seemed everything to be
    ok.

    The following point seems to be the problem:

    I have changed the port name of my controller to "Data_bus" and the
    interconnection in the testbench file to "t_data_bus".
    Now the WRITE and READ data can be seen!

    So Modelsim seems to have problems if there exist modules which
    have the same port names. That seems not to be a general problem but
    in this case it is.

    Kind regards

    André



    Mike Treseler <> wrote in message news:<>...
    > ALuPin wrote:
    > > Please have a look at
    > > http://mitglied.lycos.de/vazquez78/ -> TRISTATE
    > > The simulation shows that WRITE DATA appear on DQ and t_dq
    > > but READ DATA only appear on t_dq.

    >
    > Hmm. I don't think those ports are wired
    > together like you think they are.
    > Remember that the controller is driving
    > only write data. The read data comes from
    > the ram.
    >
    > When data does not appear where you expect it,
    > the likely culprits are:
    >
    > 1. A missing wire
    >
    > Check signal names, port maps, wave hierarchy.
    >
    > 2. A missing or disabled assignment.
    >
    > Check the processes driving the data.
    > Does the proper assignment exist?
    > What are the conditions for the assignment?
    > Walk through the code.
    >
    > 3. A more subtle logical error.
    >
    > Run the testbench with breakpoints
    > on the signal assignments.
    >
    > Good luck.
    >
    > -- Mike Treseler
    ALuPin, Nov 22, 2004
    #6
  7. ALuPin

    ALuPin Guest

    Hi again,

    the problem seems to have been displaced :


    Although now I can see the Write and Read data on the "Data_bus" port of my
    controller I have the following problem:

    I have an output port called "Data_to_sie".

    The following concurrent assignment Data_to_sie <= Data_bus;

    shows in the simulation that only the WRITE data of the "Data_bus" can
    be seen.

    I have made the additional following tries:
    1.
    process(Data_bus)
    begin
    Data_to_sie <= Data_bus;
    end process;

    2.
    process(Clk)
    begin
    if rising_edge(Clk) then
    Data_to_sie <= Data_bus;
    end if;
    end process;

    These descriptions make no difference.

    What the hell is going on ?

    Rgds
    André
    ALuPin, Nov 22, 2004
    #7
  8. ALuPin wrote:
    > Thank you for your help.


    You are welcome.

    > I have changed the port name of my controller to "Data_bus" and the
    > interconnection in the testbench file to "t_data_bus".
    > Now the WRITE and READ data can be seen!


    This would indicate an error in a
    port map using that interconnect.

    > So Modelsim seems to have problems if there exist modules which
    > have the same port names. That seems not to be a general problem but
    > in this case it is.


    More likely it was a port mapping problem.
    VHDL and modelsim really don't care
    what the port names are, as long as
    they are mapped to signals correctly.

    -- Mike Treseler
    Mike Treseler, Nov 22, 2004
    #8
  9. ALuPin wrote:

    > These descriptions make no difference.
    > What the hell is going on ?


    You have an error in your design.
    Read my previous posts.

    Sketch an entity schematic in your noteboook
    and check the port maps one by one.

    -- Mike Treseler
    Mike Treseler, Nov 22, 2004
    #9
  10. ALuPin

    ALuPin Guest

    Mike Treseler <> wrote in message news:<>...
    > ALuPin wrote:
    >
    > > These descriptions make no difference.
    > > What the hell is going on ?

    >
    > You have an error in your design.
    > Read my previous posts.
    >
    > Sketch an entity schematic in your noteboook
    > and check the port maps one by one.
    >
    > -- Mike Treseler


    I have done so.

    I made some changes in the meantime and again I have the first
    problem described: The data on the INOUT port of my controller only
    has a portion of the data on "t_dq" connected to the controller
    and the SDRAM.

    I have zipped the project, the compilation and simulation can
    be started with the file "run.do". Do you want to have a look at it?

    Thank you for your help.

    Rgds
    André
    ALuPin, Nov 23, 2004
    #10
  11. ALuPin wrote:

    > I have done so.


    But you are not done yet.

    It is not always possible to debug
    tough problems in just a few days.

    > I have zipped the project, the compilation and simulation can
    > be started with the file "run.do". Do you want to have a look at it?


    If you really want to, you can dig in and fix it yourself.
    If you want to give up, I suggest that you find a local consultant or
    call in your tool vendors. I have projects of my own to debug.

    -- Mike Treseler
    Mike Treseler, Nov 23, 2004
    #11
  12. ALuPin

    ALuPin Guest

    Mike Treseler <> wrote in message news:<>...
    > ALuPin wrote:
    >
    > > I have done so.

    >
    > But you are not done yet.
    >
    > It is not always possible to debug
    > tough problems in just a few days.


    >
    > > I have zipped the project, the compilation and simulation can
    > > be started with the file "run.do". Do you want to have a look at it?

    >
    > If you really want to, you can dig in and fix it yourself.
    > If you want to give up, I suggest that you find a local consultant or
    > call in your tool vendors. I have projects of my own to debug.
    >
    > -- Mike Treseler


    I have been working on that problem about one week now.
    And Altera MySupport does not answer ...


    I should have better not asked. Sorry for the inconvenience.

    Rgds
    André
    ALuPin, Nov 24, 2004
    #12
  13. ALuPin

    rickman Guest

    ALuPin wrote:
    >
    > Mike Treseler <> wrote in message news:<>...
    > > ALuPin wrote:
    > >
    > > > These descriptions make no difference.
    > > > What the hell is going on ?

    > >
    > > You have an error in your design.
    > > Read my previous posts.
    > >
    > > Sketch an entity schematic in your noteboook
    > > and check the port maps one by one.
    > >
    > > -- Mike Treseler

    >
    > I have done so.
    >
    > I made some changes in the meantime and again I have the first
    > problem described: The data on the INOUT port of my controller only
    > has a portion of the data on "t_dq" connected to the controller
    > and the SDRAM.
    >
    > I have zipped the project, the compilation and simulation can
    > be started with the file "run.do". Do you want to have a look at it?


    If the tristate bus is on chip IO signals, I believe you need to
    instantiate tristate primitives. When I got started with VHDL the
    software was not smart enough to infer them. I don't know if that has
    changed. I read here recently that if your tristate description is not
    in the top level of your design, it will not be inferred properly.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
    rickman, Nov 28, 2004
    #13
    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. Michael

    Tristate

    Michael, Sep 15, 2003, in forum: VHDL
    Replies:
    5
    Views:
    1,522
    Charles M. Elias
    Sep 16, 2003
  2. Jim

    Tristate Flip Flop

    Jim, Oct 27, 2004, in forum: VHDL
    Replies:
    12
    Views:
    4,848
    Ho. Li
    Nov 18, 2004
  3. Replies:
    5
    Views:
    2,057
  4. Replies:
    1
    Views:
    560
    radarman
    Mar 14, 2006
  5. Replies:
    1
    Views:
    827
    Mike Treseler
    Mar 11, 2007
Loading...

Share This Page