Problem with signals between FSM and some components in ModelSim

[showsellar]

Hi
I have built a state machine with components and for a robot and got strange behaviors.
it's seems to be that the control signal for the motor isn't coming for some reason... I have made a modelsim simulation and I believe I have found the reason for those behaviors... some signals that connect between the components and the fsm are red.
I didn't found the reason for that yet.
Could you take a look

 

[zel]

Re: modelsim bad signals

as what i understand, the red signals means that the signals of pwm, m_p_pwm & s_p_pwm being assign from many source. correct me if i am wrong.
do check your code especially pwm, m_p_pwm & s_p_pwm assignment.

 

[showsellar]

Re: modelsim bad signals

your not worng but I did checked my code and I don't see any double assignments to those signals.
I only assign a value to the signal at the pwm component (pwm signal) after enable

---------- Post added at 08:19 ---------- Previous post was at 08:16 ----------

this is the code where I am assigning the value where pulse_length and enable are signals giving from the fsm code
PwmReg: process (Clk,Rst)
begin
if (Rst='0') then
Counter <= (others=>'0');
Pwm <='0';
elsif rising_edge(Clk) then
if (Enable='1') then
if (Counter = duty_cycle) then
Counter <= (others => '0');
else
Counter <= Counter + 1;
end if;
if (pulse_length > Counter) then
Pwm <= '1';
else
Pwm <= '0';
end if;
else
Pwm <= '0';
end if;
end if;
end process PwmReg;

---------- Post added at 08:36 ---------- Previous post was at 08:19 ----------

as what i understand, the red signals means that the signals of pwm, m_p_pwm & s_p_pwm being assign from many source. correct me if i am wrong.
do check your code especially pwm, m_p_pwm & s_p_pwm assignment.

I have putted an sync reg consisted from 3 FF and it's solved the problem
I thought that a component is a part of the system there for If the system is synchronized I don't need a sync reg between like I need in the case of getting data from the real world like a sensor... am I right?

if I am wrong please tell me
I will keep you posted about the debuging I still need to fix the avg reg and the s_datain signals of the encoder

 

[zel]

Re: modelsim bad signals

hm..i've change the code a lil' bit.but i dont test it..

PwmReg: process (Clk,Rst) begin
    if (Rst = '0') then
        Counter <= (others => '0');
        Pwm     <= '0';
    elsif rising_edge(Clk) then
        if (Enable = '1') then
            if (Counter = duty_cycle) then
                Counter <= (others => '0');
            else
                Counter <= Counter + 1;
            end if;
        else
            Counter <= Counter;
        end if;
       
        if (pulse_length > Counter) then
            Pwm <= '1';
        else
            Pwm <= '0';
        end if;
    else
        Pwm <= '0';
    end if;
end if;

 

[showsellar]

Re: modelsim bad signals

hm..i've change the code a lil' bit.but i dont test it..

PwmReg: process (Clk,Rst) begin
    if (Rst = '0') then
        Counter <= (others => '0');
        Pwm     <= '0';
    elsif rising_edge(Clk) then
        if (Enable = '1') then
            if (Counter = duty_cycle) then
                Counter <= (others => '0');
            else
                Counter <= Counter + 1;
            end if;
        else
            Counter <= Counter;
        end if;
       
        if (pulse_length > Counter) then
            Pwm <= '1';
        else
            Pwm <= '0';
        end if;
    else
        Pwm <= '0';
    end if;
end if;

why did you added that line... if the enable isn't activated there is no counter and the enable wont't come done untill the counter is done and zero out
so I don't see the point

 

[zel]

Re: modelsim bad signals

my point is, when the enable is asserted, it will increment the value of Counter until the Counter value is same to the duty_cycle, but the worst case is what happen when the enable is 0? what happen to the counter value when the enable is 0? is it assigning the current value?? or reset the value? so, i put

Counter <= Counter;

..in case the enable isn't activated, there is no counter(as you said) and it will assign the current value.

 

[showsellar]

Re: modelsim bad signals

so he will assign the reset value zero or the last assign value (after the count is done I am asssinging zero as well),
and if I am not sure what value he have why not assign him zero instead of his last value that should be in that case zero any way?

 

[TrickyDicky]

Re: modelsim bad signals

Im going to comment on the code. It contains unneccesary bits and code that will not synthesise

PwmReg: process (Clk,Rst) begin
    if (Rst = '0') then
        Counter <= (others => '0');
        Pwm     <= '0';
    elsif rising_edge(Clk) then
        if (Enable = '1') then
            if (Counter = duty_cycle) then
                Counter <= (others => '0');
            else
                Counter <= Counter + 1;
            end if;

        --else
        --    Counter <= Counter;

        --you do not need this else condition. It is implicit, counter will hold its value if enable is not '1'. You only need this if the counter does something other than hold.

        end if;
       
        if (pulse_length > Counter) then
            Pwm <= '1';
        else
            Pwm <= '0';
        end if;

--    else
--        Pwm <= '0';

--This will NOT synthesise, because you are asking the synthesisor to make logic that only has a value when the clock edge is rising (a very small length of time), then '0' for the rest of the clock cycle. This is not realistic and will not compile.

    end if;
end if;

 

[zel]

Re: modelsim bad signals

yes you can set the value to zero when the enable isnt activate, but i think it will break your purpose.
the code you want to implement is able to count until reach the value of duty_cycle, right? correct me if i'm wrong..
the code that i've edit is same like your previous code. i just cover up all possibility to assign the Counter.
try simulate with that code, because i dont test it. and i hope the 'red signals' from your simulation will gone..

 

[showsellar]

Re: modelsim bad signals

so I don't need it and the else pwm <= 'o' was wrote in order to try and solve an unknown signal state at the modelsim, you right it's redundant
as I said before I have put a sync reg in order to solve the problem and I thought I did but only because the signal is to small and I didn't see it becoming red.
If I whant the problem to be solved I can't put a sync reg without counting the pulse needed for the pipeline length to match I need to use a flag to mark that the process is over right?

 

[zel]

Re: modelsim bad signals

ooo...yea..sorry..i miss the main point.. the 'Pwm'.

If I whant the problem to be solved I can't put a sync reg without counting the pulse needed for the pipeline length to match I need to use a flag to mark that the process is over right?

yup..you can

 

[showsellar]

Re: modelsim bad signals

yes I can what?
I run your code and it didn't solve the issue and as I said the sync reg hasn't solved it either for the S_P_PWM & M_P_PWM
I have attached images

 

[zel]

Re: modelsim bad signals

i send you private message..

 

[showsellar]

Re: modelsim bad signals

let make it simpler shell we
I have removed any redondent logic and left only a small state machine and one pwm component
still the same problem
any help will be much appreciated
**broken link removed**

View attachment fsm_tb.txt
View attachment fsm.txt

 

[TrickyDicky]

Ive told you the answer on the altera forum
You've got m_p_pwm connected to the fsm and the motion_pwm. You can only connect one signal to one output.