Problems with Tristate

[ALuPin]

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é

 

[Mike Treseler]

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

 

[ALuPin]

This is a signal declaration, right?


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


That sounds ok.


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]

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é

 

[Mike Treseler]

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]

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é

 

[ALuPin]

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é

 

[Mike Treseler]

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]

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

 

[ALuPin]

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é

 

[Mike Treseler]

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

 

[ALuPin]

But you are not done yet.

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

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é

 

[rickman]

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

(e-mail address removed)
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