communication between processes

[john]

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;

 

[mike_treseler]

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]

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

 

[Thomas Reinemann]

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.

Bye Tom

 

[Pieter Hulshoff]

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.

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

 

[john]

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

 

[ALuPin]

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

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

 

[john]

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

 

[Raghavendra]

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

 

[john]

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

 

[Alan Fitch]

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


(e-mail address removed) (Raghavendra) wrote in message

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