Cannot transmit correct result consecutively


Z

ZHIQUAN

I have a weird question here. When I test the transmission part, the
first transmission result is correct. But the second time, the
transmission result sent back are strange numbers instead of the
result expected. If I push the RESET button, and do again. It
transmits correct again. So I guess there is something wrong on the
RESET part. Then I commented the reset part of the program to see what
the difference is.
When I go to this part: When I comment the cnt:=(others=>'0') in the
RESET. Even I push the RESET button, it cannot get correct result. If
i remove the comment and try again. I push the RESET button, It get
the correct result. Actually when the program finishes the ·IF
COUNTRX= NumAllWord1 THEN·The cnt will be clear up to zero. It is
same to the reset function here. Why it did not get the correct
result? Or my understanding gets wrong about the use of Variable ?

countRX_inst: process(WRRAMCLK,RESET)
VARIABLE cnt : std_logic_vector(15 DOWNTO 0):=(OTHERS=>'0'); --
RAM PORT A ADDA, 15 BITS
VARIABLE rd1,rd2,rd3,rd4: std_logic:='0'; --delay the read signal
for one cycle
begin
if (RESET = '1') then
cnt:=(OTHERS=>'0');
elsif WRRAMCLK'event and WRRAMCLK = '1' then
IF rd4 = '0' and rd3 = '1' and rd2 = '1' and rd1 ='1' then
DINA <= DATAIN; --read data from input-register in uart to
ram_input input register
WEA <= '1';
COUNTRX <= cnt;
cnt := cnt + "0000000000000001";
STAPPB <='0';
END IF;

IF COUNTRX= NumAllWord1 THEN
WEA <= '0';
COUNTRX <= (OTHERS=>'0');
cnt:=(OTHERS=>'0');
STAPPB <='1'ï¼›
END IF;
rd4 := rd3;
rd3 := rd2;
rd2 := rd1;
rd1 := readb; --delay "read" three cycles
end if;
END PROCESS;
 
Ad

Advertisements

P

Pieter Hulshoff

ZHIQUAN said:
countRX_inst: process(WRRAMCLK,RESET)
VARIABLE cnt : std_logic_vector(15 DOWNTO 0):=(OTHERS=>'0'); --
RAM PORT A ADDA, 15 BITS
VARIABLE rd1,rd2,rd3,rd4: std_logic:='0'; --delay the read signal
for one cycle
begin
if (RESET = '1') then
cnt:=(OTHERS=>'0');
elsif WRRAMCLK'event and WRRAMCLK = '1' then
IF rd4 = '0' and rd3 = '1' and rd2 = '1' and rd1 ='1' then
DINA <= DATAIN; --read data from input-register in uart to
ram_input input register
WEA <= '1';
COUNTRX <= cnt;
cnt := cnt + "0000000000000001";
STAPPB <='0';
END IF;

IF COUNTRX= NumAllWord1 THEN
WEA <= '0';
COUNTRX <= (OTHERS=>'0');
cnt:=(OTHERS=>'0');
STAPPB <='1'ï¼›
END IF;
rd4 := rd3;
rd3 := rd2;
rd2 := rd1;
rd1 := readb; --delay "read" three cycles
end if;
END PROCESS;

What does STAPPB do? I presume DINA is your write port, WEA your write enable,
and COUNTRX your address port; is this correct? What generates readb exactly,
and how is this signal defined?

Regards,

Pieter Hulshoff
 
Z

ZHIQUAN

Pieter said:
What does STAPPB do? I presume DINA is your write port, WEA your write enable,
and COUNTRX your address port; is this correct? What generates readb exactly,
and how is this signal defined?

The signal STAPPB is used for triggering an application. Readb is
generated by the UART output.
 
A

Andy

I have a weird question here. When I test the transmission part, the
first transmission result is correct. But the second time, the
transmission result sent back are strange numbers instead of the
result expected. If I push the RESET button, and do again. It
transmits correct again. So I guess there is something wrong on the
RESET part. Then I commented the reset part of the program to see what
the difference is.
When I go to this part: When I comment the cnt:=(others=>'0') in the
RESET. Even I push the RESET button, it cannot get correct result. If
i remove the comment and try again. I push the RESET button, It get
the correct result. Actually when the program finishes the ·IF
COUNTRX= NumAllWord1 THEN·The cnt will be clear up to zero. It is
same to the reset function here. Why it did not get the correct
result? Or my understanding gets wrong about the use of Variable ?

countRX_inst: process(WRRAMCLK,RESET)
VARIABLE cnt : std_logic_vector(15 DOWNTO 0):=(OTHERS=>'0'); --
RAM PORT A ADDA, 15 BITS
VARIABLE rd1,rd2,rd3,rd4: std_logic:='0'; --delay the read signal
for one cycle
begin
if (RESET = '1') then
cnt:=(OTHERS=>'0');
elsif WRRAMCLK'event and WRRAMCLK = '1' then
IF rd4 = '0' and rd3 = '1' and rd2 = '1' and rd1 ='1' then
DINA <= DATAIN; --read data from input-register in uart to
ram_input input register
WEA <= '1';
COUNTRX <= cnt;
cnt := cnt + "0000000000000001";
STAPPB <='0';
END IF;

IF COUNTRX= NumAllWord1 THEN
WEA <= '0';
COUNTRX <= (OTHERS=>'0');
cnt:=(OTHERS=>'0');
STAPPB <='1'ï¼›
END IF;
rd4 := rd3;
rd3 := rd2;
rd2 := rd1;
rd1 := readb; --delay "read" three cycles
end if;
END PROCESS;

Simulation is your friend...

You'll find far more bugs faster if you simulate, rather than trying
to debug in the device itself.

Andy
 
A

Andy

One more thing, does the simulation tool can take into account the
time delay?

Typical RTL code for synthesis will simulate with "cycle accurate"
timing; in other words, outputs will occur within a few deltas after
the clock that generated them.

You can run post-synthesis or post-routed netlists through simulation
with full timing too, but these take longer to run (gate level models
are not nearly as efficient to simulate as well written RTL).

If you suspect a timing problem, make sure your timing constraints are
accurate, and run a static timing analysis in your P&R tool to find
most of those problems first.

Also, a tool such as chip scope (xilinx), or whatever the equivalent
is for Altera, can help debug live in the device too. I've had the
most luck with those by using them to narrow down the simulation test
cases I needed to isolate the bug in the simulator. These are extra $
tools.

Lastly, you can route suspect internal signals out to spare IO pins
where they can be monitored with scopes or logic analyzers.

Debugging in the device using these last two methods can be helpful if
you don't have a good understanding of what the inputs to the device
are doing (making it difficult to write a simulation model for them).

Andy
 
Ad

Advertisements

P

Peter

if (RESET = '1') then
cnt:=(OTHERS=>'0');
elsif WRRAMCLK'event and WRRAMCLK = '1' then

Hi,

have you forgot to reset some signals?
Only variable cnt is cleared by RESET, not WEA, COUNTRX etc.

/Peter
 
Z

ZHIQUAN

Yeah, I reset many things. The previous codes are
if (RESET = '1') then
cnt:=(OTHERS=>'0');
--COUNTRX <=(OTHERS=>'0') ;
--rd1 := '0';
--rd2 := '0';
--rd3 := '0';
--WEA <= '0';
--DINA <= (OTHERS=>'0');
Actually IF COUNTRX= NumAllWord1 THEN WEA <= '0';
COUNTRX <= (OTHERS=>'0');
cnt:=(OTHERS=>'0'); STAPPB <='1';
END IF;
This part has already reset everything to zero and triggered an
application using signal STAPPB.
I cannot remove cnt:=(others=>'0') from 'reset' function; If I remove
'cnt', the transmission result are wrong even I reset it. But if I
keep it, it gets correct result every time I reset it. Others from the
'reset' function doesn't affect the result. That is a weird thing.
 
P

Pieter Hulshoff

ZHIQUAN said:
I have a weird question here. When I test the transmission part, the
first transmission result is correct. But the second time, the
transmission result sent back are strange numbers instead of the
result expected.

Could you be a tad more specific on what you mean by "strange numbers"? As
far as I can tell, incorrect resetting of cnt could only result in a shift
of the bytes. Is that what you see, or are the bytes all scrambled up? Any
chance you could give us an example of input/output of your design?

Regards,

Pieter Hulshoff
 
Z

ZHIQUAN

I transmit 4 data 255,85,170,0. to a RAM and transmit back to Matlab.
First transmit is 255,85,170,0, Next one is
-255, 21760, -22016,0; Then -114,21760,-22016,0; Then -121,21760,
-22016,0

If I push the RESET button, it is 255,85,170,0 again

Thanks for your help.
 
D

Dave Pollum

I transmit 4 data 255,85,170,0. to a RAM and transmit back to Matlab.
First transmit is 255,85,170,0, Next one is
-255, 21760, -22016,0; Then -114,21760,-22016,0; Then -121,21760,
-22016,0

If I push the RESET button, it is 255,85,170,0 again

Thanks for your help.

Pieter, this is what I see in the data you supplied:
correct: 255 = 00FFh, 85 = 0055h, 170 = 00AAh, 0 =
0000h.
bad #1: -255 = FF01h, 21760 = 5500h, -22016 = AA00h, 0 = 0000h.
bad #2: -114 = FF8Eh ,21760 = 5500h, -22016 = AA00h, 0 = 0000h
bad #3: -121 = FF87h ,21760 = 5500h, -22016 = AA00h, 0 = 0000h

Bad #1 looks _almost_ like your correct data, but it's off by 4 bits.
Is the data sent to/from Matlab in serial or parallel?

HTH
-Dave Pollum
 
Ad

Advertisements

Z

ZHIQUAN

They are sent in serial.
Dave said:
Pieter, this is what I see in the data you supplied:
correct: 255 = 00FFh, 85 = 0055h, 170 = 00AAh, 0 =
0000h.
bad #1: -255 = FF01h, 21760 = 5500h, -22016 = AA00h, 0 = 0000h.
bad #2: -114 = FF8Eh ,21760 = 5500h, -22016 = AA00h, 0 = 0000h
bad #3: -121 = FF87h ,21760 = 5500h, -22016 = AA00h, 0 = 0000h

Bad #1 looks _almost_ like your correct data, but it's off by 4 bits.
Is the data sent to/from Matlab in serial or parallel?

HTH
-Dave Pollum
 
D

Dave Pollum

They are sent in serial.

Perhaps "IF COUNTRX= NumAllWord1" is always FALSE and so your counter
is never being reset.

Other thoughts - A UART sets a flag to show that it has received data,
and sets another flag when it can accept data to transmit. Are you
checking those flags? I'm guessing that "readb" is the UART's
received-data flag, but why does it need to be delayed?

-Dave Pollum
 
Ad

Advertisements

Z

ZHIQUAN

Hi, everyone

Thanks for your help. I guess the problem is solved. I added a '000Fh'
as data package head and '0000h' as data package tail. The transmisson
is correct at the moment. Shall the data transmission always need such
a head or tail as a package?

Zhi
 

Top