communication between processes

J

john

Guest
Hello,

I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.

Please Advice!
Thanks
john



Process ( State1 )
Begin

Case State1 is


When 0 =>
Flag1 <= '0';
Data_Bus ( 7 downto 0) <=USB_Data ( 7 downto 0);


nextstate1 <= 1 ;

When 1 =>
Flag1 <= '1';
Data_Bus ( 13 downto 8) <=USB_Data ( 5 downto 0);


nextstate1 <= 0 ;

When others =>

nextstate1 <= 0 ;
End Case;

End Process;


-- USB PROCESS

Process ( USB_CLK)
Begin

If (USB_CLK 'event And USB_CLK='1' ) Then

State1 <= nextstate1;


End If;

End Process;



-- DPR FSM#2

Process ( State2 , Flag1 )
Begin

Case State2 is


When G0=>

If (Flag1 ='1') Then

inc <='1';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G1;

Else

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G0;

End If;



When G1 =>

inc <='0';
UBL <='0';
LBL <='0';
Read_write <='0';

nextstate2 <=G2;


When G2 =>

If (Flag1 ='0') Then

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G0;

Else

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G2;

End If;



When others =>

nextstate2 <=G0;

End case;

End Process;

--DPR Process

Process ( DPR_CLK , State, nextstate )
Begin

If ( DPR_CLK 'event And DPR_CLK='1') Then

State <= nextstate;
State2 <= nextstate2;

End If;

End Process;
 
Consider running all the registers on
the faster clock and use the slower
"clock" as an input (a clock enable).

Consider writing a simulation testbench to debug
the problem. These things are very difficult
to solve by trial and error.

-- Mike Treseler
 
Pieter Hulshoff wrote:

1. Do not use signals generated on one clock (USB_CLK) directly on another
clock (DPR_CLK).
Does this apply only for clocks from different sources or even for a clock
Click to expand...
split to two signals which have different names. Some days ago I had a
really strange behavior with such kind of clocks.

Bye Tom
 
Thomas Reinemann wrote:

Pieter Hulshoff wrote:

1. Do not use signals generated on one clock (USB_CLK) directly on
another clock (DPR_CLK).
Does this apply only for clocks from different sources or even for a clock
split to two signals which have different names. Some days ago I had a
really strange behavior with such kind of clocks.
Click to expand...
If you split a clock to two signals, you'll need good control over the delay
in the clockpaths in order to make it work properly. Usually the splitting
of clocks is part of the clock tree synthesis.

Let's say you have two FFs, one driving the other, each on a different
clock, but with the same source. If the delay in the second clockpath >
delay in the first clockpath, you may get setup/hold violations, and
possible shootthrough (output of the 2nd FF takes on the value of the
output of the 1st FF just a fraction of a clock cycle after the output of
FF1 changes). If the delay in the first clockpath < delay in the second
clockpath, you may get setup/hold violations. I say _may_, because it is
the task of clock tree synthesis to prevent this from happening.
Alternatively, you could use a latch (negative latch for positive FFs) to
delay the data enough to prevent these problems. Only do this for FF to FF
transfer (without any logic in between), and only if the path delay between
the two FFs is not too large (FFs on opposite sides of a chip for
instance).

Regards,

Pieter Hulshoff
 
conphiloso@hotmail.com (john) wrote in message news:<73aa8725.0411180925.2985ac0@posting.google.com>...
Hello,

I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.

Please Advice!
Thanks
john



Process ( State1 )
Begin

Case State1 is


When 0 =
Flag1 <= '0';
Data_Bus ( 7 downto 0) <=USB_Data ( 7 downto 0);


nextstate1 <= 1 ;

When 1 =
Flag1 <= '1';
Data_Bus ( 13 downto 8) <=USB_Data ( 5 downto 0);


nextstate1 <= 0 ;

When others =

nextstate1 <= 0 ;
End Case;

End Process;


-- USB PROCESS

Process ( USB_CLK)
Begin

If (USB_CLK 'event And USB_CLK='1' ) Then

State1 <= nextstate1;


End If;

End Process;



-- DPR FSM#2

Process ( State2 , Flag1 )
Begin

Case State2 is


When G0=>

If (Flag1 ='1') Then

inc <='1';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G1;

Else

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G0;

End If;



When G1 =>

inc <='0';
UBL <='0';
LBL <='0';
Read_write <='0';

nextstate2 <=G2;


When G2 =

If (Flag1 ='0') Then

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G0;

Else

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G2;

End If;



When others =

nextstate2 <=G0;

End case;

End Process;

--DPR Process

Process ( DPR_CLK , State, nextstate )
Begin

If ( DPR_CLK 'event And DPR_CLK='1') Then

State <= nextstate;
State2 <= nextstate2;

End If;

End Process;
Click to expand...
HI,
your design does not have reset.So on power on FSM's are not in
definite known state.That me be one of the additional bug.

Raghavendra.S
 
john wrote:
I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.
Click to expand...
1. Do not use signals generated on one clock (USB_CLK) directly on another
clock (DPR_CLK). You can get the weirdest behaviour in simulation from
doing this, and in your chip you'll get even stranger behaviour.
2. Putting State and nextstate in your DPR process won't do anything, since
it is a clocked process (DPR_CLK) without any asynchronous behaviour.
3. How does your USB process synchronize? I understand you clock bits 7-0 in
the first and bits 13-8 in the second clock cycle, but how do you
synchronize it to the USB bus?
4. What are the frequencies of these two clocks? I could see a lot of
different behaviour happening depending on what the frequencies are, even
aside from the problem mentioned at 1.

If you could give us some information about the original problem (including
clock frequencies), I'm sure we can come up with some suggestions to
improve your design.

Regards,

Pieter Hulshoff
 
Hello,

Thanks very much for ur reply! The data from the USB chip is keep
coming to FPGA. There is no synchronization or handshaking between the
FPGA and the USB chip..

I have following choices regarding the USB frequency 1MHz, 6MHz, 12
MHz and 24MHz. Right now, I am testing the system with 1MHz USB clock
and 15 MHz DPR clock. I can go upto 100 MHz on the DPR clock. The
problem is that is that sometimes I get good data out of Dual port RAM
and sometimes bad data..So some times the FPGA writes correct data to
RAM and sometimes do not.
Please Advice!

Thanks
john


Pieter Hulshoff <phulshof@xs4all.nl> wrote in message news:<419d0440$0$34858$e4fe514c@dreader8.news.xs4all.nl>...
john wrote:
I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.

1. Do not use signals generated on one clock (USB_CLK) directly on another
clock (DPR_CLK). You can get the weirdest behaviour in simulation from
doing this, and in your chip you'll get even stranger behaviour.
2. Putting State and nextstate in your DPR process won't do anything, since
it is a clocked process (DPR_CLK) without any asynchronous behaviour.
3. How does your USB process synchronize? I understand you clock bits 7-0 in
the first and bits 13-8 in the second clock cycle, but how do you
synchronize it to the USB bus?
4. What are the frequencies of these two clocks? I could see a lot of
different behaviour happening depending on what the frequencies are, even
aside from the problem mentioned at 1.

If you could give us some information about the original problem (including
clock frequencies), I'm sure we can come up with some suggestions to
improve your design.

Regards,

Pieter Hulshoff
Click to expand...
 
conphiloso@hotmail.com (john) wrote in message news:<73aa8725.0411211004.286e4682@posting.google.com>...
Hello,

Thanks very much for ur reply! The data from the USB chip is keep
coming to FPGA. There is no synchronization or handshaking between the
FPGA and the USB chip..

I have following choices regarding the USB frequency 1MHz, 6MHz, 12
MHz and 24MHz. Right now, I am testing the system with 1MHz USB clock
and 15 MHz DPR clock. I can go upto 100 MHz on the DPR clock. The
problem is that is that sometimes I get good data out of Dual port RAM
and sometimes bad data..So some times the FPGA writes correct data to
RAM and sometimes do not.
Please Advice!

Thanks
john


Pieter Hulshoff <phulshof@xs4all.nl> wrote in message news:<419d0440$0$34858$e4fe514c@dreader8.news.xs4all.nl>...
john wrote:
I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.

1. Do not use signals generated on one clock (USB_CLK) directly on another
clock (DPR_CLK). You can get the weirdest behaviour in simulation from
doing this, and in your chip you'll get even stranger behaviour.
2. Putting State and nextstate in your DPR process won't do anything, since
it is a clocked process (DPR_CLK) without any asynchronous behaviour.
3. How does your USB process synchronize? I understand you clock bits 7-0 in
the first and bits 13-8 in the second clock cycle, but how do you
synchronize it to the USB bus?
4. What are the frequencies of these two clocks? I could see a lot of
different behaviour happening depending on what the frequencies are, even
aside from the problem mentioned at 1.

If you could give us some information about the original problem (including
clock frequencies), I'm sure we can come up with some suggestions to
improve your design.

Regards,

Pieter Hulshoff
Click to expand...
What kind of SRAM are you using ?
Try to get a SRAM VHDL model and perform a timing simulation. It is the
best way to get things visualized.

Of course you can also test it in real hardware.
You could use some Embedded Logic Analyzer to see the data you have read
out of the SRAM ...
 
Hello,

I think there is no need to use the VHDL model of the Dual Port RAM
(SRAM) because actual chip is there. plus I am analyzing the data bus
through logic analyzer. The part number of the RAM is " IDT 70T633 ".
Thanks
john

ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0411220302.5407d6a1@posting.google.com>...
conphiloso@hotmail.com (john) wrote in message news:<73aa8725.0411211004.286e4682@posting.google.com>...
Hello,

Thanks very much for ur reply! The data from the USB chip is keep
coming to FPGA. There is no synchronization or handshaking between the
FPGA and the USB chip..

I have following choices regarding the USB frequency 1MHz, 6MHz, 12
MHz and 24MHz. Right now, I am testing the system with 1MHz USB clock
and 15 MHz DPR clock. I can go upto 100 MHz on the DPR clock. The
problem is that is that sometimes I get good data out of Dual port RAM
and sometimes bad data..So some times the FPGA writes correct data to
RAM and sometimes do not.
Please Advice!

Thanks
john


Pieter Hulshoff <phulshof@xs4all.nl> wrote in message news:<419d0440$0$34858$e4fe514c@dreader8.news.xs4all.nl>...
john wrote:
I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.

1. Do not use signals generated on one clock (USB_CLK) directly on another
clock (DPR_CLK). You can get the weirdest behaviour in simulation from
doing this, and in your chip you'll get even stranger behaviour.
2. Putting State and nextstate in your DPR process won't do anything, since
it is a clocked process (DPR_CLK) without any asynchronous behaviour.
3. How does your USB process synchronize? I understand you clock bits 7-0 in
the first and bits 13-8 in the second clock cycle, but how do you
synchronize it to the USB bus?
4. What are the frequencies of these two clocks? I could see a lot of
different behaviour happening depending on what the frequencies are, even
aside from the problem mentioned at 1.

If you could give us some information about the original problem (including
clock frequencies), I'm sure we can come up with some suggestions to
improve your design.

Regards,

Pieter Hulshoff

What kind of SRAM are you using ?
Try to get a SRAM VHDL model and perform a timing simulation. It is the
best way to get things visualized.

Of course you can also test it in real hardware.
You could use some Embedded Logic Analyzer to see the data you have read
out of the SRAM ...
Click to expand...
 
Pieter Hulshoff Wrote
3. How does your USB process synchronize? I understand you clock bits
7-0 in the first and bits 13-8 in the second clock cycle, but how do
you
synchronize it to the USB bus?

A. Thanks very much for ur reply! The data from the USB chip is keep
coming to FPGA. There is no synchronization or handshaking between the
FPGA and the USB chip..

4. What are the frequencies of these two clocks? I could see a lot of
different behaviour happening depending on what the frequencies are,
even
aside from the problem mentioned at 1.

A.I have following choices regarding the USB frequency 1MHz, 6MHz, 12
MHz and 24MHz. Right now, I am testing the system with 1MHz USB clock
and 15 MHz DPR clock. I can go upto 100 MHz on the DPR clock. The
problem is that is that sometimes I get good data out of Dual port
RAM
and sometimes bad data..So some times the FPGA writes correct data to
RAM and sometimes do not.
Please Advice!

Regards,

John


raghurash@rediffmail.com (Raghavendra) wrote in message news:<1776d39.0411230451.258cf891@posting.google.com>...
conphiloso@hotmail.com (john) wrote in message news:<73aa8725.0411180925.2985ac0@posting.google.com>...
Hello,

I am having communication problems between two processes. I am getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws up the
writing to the SRAM.

Please Advice!
Thanks
john



Process ( State1 )
Begin

Case State1 is


When 0 =
Flag1 <= '0';
Data_Bus ( 7 downto 0) <=USB_Data ( 7 downto 0);


nextstate1 <= 1 ;

When 1 =
Flag1 <= '1';
Data_Bus ( 13 downto 8) <=USB_Data ( 5 downto 0);


nextstate1 <= 0 ;

When others =

nextstate1 <= 0 ;
End Case;

End Process;


-- USB PROCESS

Process ( USB_CLK)
Begin

If (USB_CLK 'event And USB_CLK='1' ) Then

State1 <= nextstate1;


End If;

End Process;



-- DPR FSM#2

Process ( State2 , Flag1 )
Begin

Case State2 is


When G0=>

If (Flag1 ='1') Then

inc <='1';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G1;

Else

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G0;

End If;



When G1 =>

inc <='0';
UBL <='0';
LBL <='0';
Read_write <='0';

nextstate2 <=G2;


When G2 =

If (Flag1 ='0') Then

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G0;

Else

inc <='0';
UBL <='1';
LBL <='1';
Read_write <='0';

nextstate2 <=G2;

End If;



When others =

nextstate2 <=G0;

End case;

End Process;

--DPR Process

Process ( DPR_CLK , State, nextstate )
Begin

If ( DPR_CLK 'event And DPR_CLK='1') Then

State <= nextstate;
State2 <= nextstate2;

End If;

End Process;

HI,
your design does not have reset.So on power on FSM's are not in
definite known state.That me be one of the additional bug.

Raghavendra.S
Click to expand...
 
"john" <conphiloso@hotmail.com> wrote in message
news:73aa8725.0411290801.5d82f71@posting.google.com...
Pieter Hulshoff Wrote
3. How does your USB process synchronize? I understand you clock
bits
7-0 in the first and bits 13-8 in the second clock cycle, but how do
you
synchronize it to the USB bus?

A. Thanks very much for ur reply! The data from the USB chip is keep
coming to FPGA. There is no synchronization or handshaking between
the
FPGA and the USB chip..

4. What are the frequencies of these two clocks? I could see a lot
of
different behaviour happening depending on what the frequencies
are,
even
aside from the problem mentioned at 1.

A.I have following choices regarding the USB frequency 1MHz, 6MHz,
12
MHz and 24MHz. Right now, I am testing the system with 1MHz USB
clock
and 15 MHz DPR clock. I can go upto 100 MHz on the DPR clock. The
problem is that is that sometimes I get good data out of Dual port
RAM
and sometimes bad data..So some times the FPGA writes correct data
to
RAM and sometimes do not.
Please Advice!

Regards,

John


raghurash@rediffmail.com (Raghavendra) wrote in message
news:<1776d39.0411230451.258cf891@posting.google.com>...
conphiloso@hotmail.com (john) wrote in message
news:<73aa8725.0411180925.2985ac0@posting.google.com>...
Hello,

I am having communication problems between two processes. I am
getting
data from the USB and I am getting it to the
data bus of the SRAM.I write correct data to the SRAM, if I do
not
check the status of "Flag1" but if I insert "Flag1"into
the process then I get garbage data from the SRAM and it screws
up the
writing to the SRAM.

Please Advice!
Thanks
john
Click to expand...
You haven't assigned Flag1 in the others => branch of your case,
so you are implying a latch.

regards,
Alan


--
Alan Fitch
Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 mail:
alan.fitch@doulos.com
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

The contents of this message may contain personal views which are not
the
views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top