Re: How to solve "XXXX" problem

[Zhi]

On 23 May, 18:30, Mike Treseler <[email protected]> wrote:
> Zhi wrote:
> > Thank you Mike.
>
> You're welcome.
> Hey, go easy on that reply button.
> One click will do it.

Sorry, when I did it, the message said i have to try later. That is
why i click it more than once.
>
> > My RAM is a dual port RAM. There are already data in the RAM.
>
> The simulator only knows about data written to the RAM
> during the sim session. Maybe you want a ROM.
> Post your code.

This code is quite long. I don't know if it is convinent to post here.
>
> -- Mike Treseler

[Michael Jørgensen]

"Zhi" <[email protected]> wrote in message
news:[email protected] oups.com...

> This code is quite long. I don't know if it is convinent to post here.

Well, I would start by tracing *all* signals into and out of the RAM and
look at the waveforms in the simulator. And as Mike pointed out, the
simulation session starts with the RAM containing only 'X'. From the
waveform you can see, if you are reading from an address that was not
previously written too.

-Michael.

[Michael Jørgensen]

Oh, and one more thing. If you are reading from and writing to the same
address in the same clock cycle, then the read will most likely return
garbage. In that case you need to explicitly implement some bypass logic
around the RAM block.

-Michael.

[Zhi]

On 24 May, 08:33, "Michael Jørgensen" <[email protected]> wrote:
> Oh, and one more thing. If you are reading from and writing to the same
> address in the same clock cycle, then the read will most likely return
> garbage. In that case you need to explicitly implement some bypass logic
> around the RAM block.
>
> -Michael.

I try to explain my problem clearly. Here is 2 block rams. There are
some data in these rams. I want to compare the values in the 2 rams.
Then I address the 2 rams and get the 2 value from the 2 rams. My
problem is the first ram work well, the value corresponding to the
address is correct. But for the 2nd ram, the first value from the
address is correct. Then the 2nd value is correct as well but stop
earlier one clock cycle than what I expected and following the data
became unknown signal "XXXX" in the one cycle clock. I am curious why
the address is not changed, why the data from the address would stop
eariler one clock and the missed one clock cycle data is replaced
unknown data "xxxxxxxxx".

[Mike Treseler]

Zhi wrote:

> I try to explain my problem clearly. Here is 2 block rams. There are
> some data in these rams. I want to compare the values in the 2 rams.
> Then I address the 2 rams and get the 2 value from the 2 rams. My
> problem is the first ram work well, the value corresponding to the
> address is correct. But for the 2nd ram, the first value from the
> address is correct. Then the 2nd value is correct as well but stop
> earlier one clock cycle than what I expected and following the data
> became unknown signal "XXXX" in the one cycle clock.

Maybe the testbench and the RAM are driving
the node at the same time.
Set some breakpoints.
Trace some code.
Look at waves.
Edit, compile.
Repeat.
Debug.

-- Mike Treseler

[Zhi]

On 24 May, 19:52, Mike Treseler <[email protected]> wrote:
> Zhi wrote:
> > I try to explain my problem clearly. Here is 2 block rams. There are
> > some data in these rams. I want to compare the values in the 2 rams.
> > Then I address the 2 rams and get the 2 value from the 2 rams. My
> > problem is the first ram work well, the value corresponding to the
> > address is correct. But for the 2nd ram, the first value from the
> > address is correct. Then the 2nd value is correct as well but stop
> > earlier one clock cycle than what I expected and following the data
> > became unknown signal "XXXX" in the one cycle clock.
>
> Maybe the testbench and the RAM are driving
> the node at the same time.
> Set some breakpoints.
> Trace some code.
> Look at waves.
> Edit, compile.
> Repeat.
> Debug.
>
> -- Mike Treseler

Thank you. I have been checked the codes these days. I did make some
mistakes in the codes. But the red line with Mark "X" still there. I
guess there is a conflict in the following codes.
IF stbup1='0' and stbup='1' then
bupover <='0'; if mdiff=0 then
tmpb:=signthtdoutb;--(signthtdoutb <= signed(thtdoutb);)
else
tmpb(31 downto 1):=signed(thtdoutb(30 downto 0));
tmpb(0) :='0'; ---b=b*2;
end if;
tmpR :=(others=>signiptdoutb(15));
if mdiff >1 then ----fix(R(:,k)/2^(mreg-m-1)) tmpR(16-
mdiff downto 0):=signed(iptdoutb(15 downto mdiff-1)); else
tmpR(15 downto 0):=signiptdoutb; end if;
if ad(0)='0' then
tmpb:=tmpb-tmpR; else
tmpb:=tmpb+tmpR;
end if; thtdina <= conv_std_logic_vector(tmpb,
32); thtaddra <=rdcnttht; thtwea <='1';
rdcnttht :=rdcnttht + "0000001";
BUPState <=UPS2;
end if;
---------------------------------------------------
These codes execute the value update in THTRAM. Don't they cannot be
finished in one cycle? I looked them a little bit weird but I cannot
what the problem is. Do you think these codes are logically correct?

[Michael Jørgensen]

> Thank you. I have been checked the codes these days. I did make some
> mistakes in the codes. But the red line with Mark "X" still there. I
> guess there is a conflict in the following codes.
> IF stbup1='0' and stbup='1' then
> bupover <='0'; if mdiff=0 then
> tmpb:=signthtdoutb;--(signthtdoutb <= signed(thtdoutb);)
> else
> tmpb(31 downto 1):=signed(thtdoutb(30 downto 0));
> tmpb(0) :='0'; ---b=b*2;
> end if;
> tmpR :=(others=>signiptdoutb(15));
> if mdiff >1 then ----fix(R(:,k)/2^(mreg-m-1)) tmpR(16-
> mdiff downto 0):=signed(iptdoutb(15 downto mdiff-1)); else
> tmpR(15 downto 0):=signiptdoutb; end if;
> if ad(0)='0' then
> tmpb:=tmpb-tmpR; else
> tmpb:=tmpb+tmpR;
> end if; thtdina <= conv_std_logic_vector(tmpb,
> 32); thtaddra <=rdcnttht; thtwea <='1';
> rdcnttht :=rdcnttht + "0000001";
> BUPState <=UPS2;
> end if;

The above is completely unreadable to me :-( What is the code trying to do?

First, you need to add some comments.
Second, you should me consistent with the indentation. It makes it much
easier to read.

-Michael.

[Michael Jørgensen]

Oh, and one more thing. The variable names may be obvious to you, but to me
they look like random strings of characters. Use longer variable names.

-Michael.