Cannot transmit correct result consecutively

Z

ZHIQUAN

Guest
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;
 
ZHIQUAN wrote:
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;
Click to expand...
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
 
Pieter Hulshoff wrote:
ZHIQUAN wrote:
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?
Click to expand...
The signal STAPPB is used for triggering an application. Readb is
generated by the UART output.
Regards,

Pieter Hulshoff
Click to expand...
 
On Apr 18, 9:37 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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;
Click to expand...
Simulation is your friend...

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

Andy
 
One more thing, does the simulation tool can take into account the
time delay?
Andy wrote:
On Apr 18, 9:37 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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
Click to expand...
 
On Apr 18, 2:17 pm, ZHIQUAN <threeinchn...@gmail.com> wrote:
One more thing, does the simulation tool can take into account the
time delay?

Andy wrote:
On Apr 18, 9:37 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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
Click to expand...
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
 
if (RESET = '1') then
cnt:=(OTHERS=>'0');
elsif WRRAMCLK'event and WRRAMCLK = '1' then
Click to expand...
Hi,

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

/Peter
 
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.

Peter wrote:
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
Click to expand...
 
ZHIQUAN wrote:

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.
Click to expand...
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
 
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 Hulshoff wrote:
ZHIQUAN wrote:

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
Click to expand...
 
On Apr 20, 3:43 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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 Hulshoff wrote:
ZHIQUAN wrote:

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
Click to expand...
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
 
They are sent in serial.
Dave Pollum wrote:
On Apr 20, 3:43 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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 Hulshoff wrote:
ZHIQUAN wrote:

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

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
Click to expand...
 
On Apr 21, 5:27 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
They are sent in serial.

Dave Pollum wrote:
On Apr 20, 3:43 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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 Hulshoff wrote:
ZHIQUAN wrote:

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

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
Click to expand...
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
 
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
Dave Pollum wrote:
On Apr 21, 5:27 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
They are sent in serial.

Dave Pollum wrote:
On Apr 20, 3:43 am, ZHIQUAN <threeinchn...@gmail.com> wrote:
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 Hulshoff wrote:
ZHIQUAN wrote:

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

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

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
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top