Weird !!

[Kausi]

Iam struggling with a piece of code that has been giving me sleepless
nights for the past one week. What i fail to understand is that the
code works absolutely fine, without even a glitch in modelsim. But
when i burn the code on an fpga (spartan-3), i get weird results. Find
the snipet of my code below.


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity Non_restoring_float_sqrt is
Port ( Float_Input_IEEE_Format: in bit_vector(31 downto 0);
Result: out bit_vector(31 downto 0);
reset: in bit;
CLK: in bit);
end Non_restoring_float_sqrt;

architecture Behavioral of Non_restoring_float_sqrt is

type dstate is range 24 downto 0;
signal state : dstate;
signal result_temp : bit_vector(8 downto 0);
signal Shift_Reg: bit_vector(23 downto 0);

begin

process(Float_Input_IEEE_Format,reset)
variable A_exponent: bit_vector(7 downto 0);
constant B_exponent: bit_vector(7 downto 0):="00111111";
variable Float_Local_exponent: bit_vector(7 downto 0);
variable Float_Local_fraction: bit_vector(22 downto 0);
variable Sum_Temp_variable: bit_vector(8 downto 0);
variable Sign_bit: bit;
begin
if reset='1' and reset'event then
Sign_bit:=Float_Input_IEEE_Format(31);
Float_Local_exponent := Float_Input_IEEE_Format(30 downto 23);
Float_Local_fraction := Float_Input_IEEE_Format(22 downto 0);
A_exponent:= '0' & Float_Local_exponent(7 downto 1);
-- I have not pasted the function to reduce the length.
Sum_Temp_variable:=Adder_for_exponent(A_exponent,B_exponent,Float_Local_exponent(0));
result_temp(8 downto 0)<= Sign_bit & Sum_Temp_variable(7 downto 0);
if Float_Local_exponent(0)= '0' then
Shift_Reg<='1' & Float_Local_fraction(22 downto 0);
else
Shift_Reg<= "01" & Float_Local_fraction(22 downto 1);
end if;
else null;
end if;
end process;

process(Shift_Reg,state)
variable r0: bit_vector(1 downto 0);
variable r2: bit_vector(23 downto 0);
variable c_temp,control: bit;
variable A,B: bit_vector(23 downto 0);
variable r : bit_vector(23 downto 0);
variable sh : bit_vector(23 downto 0);
variable d_sub : bit_vector(23 downto 0);
begin
case state is
when 23 =>
d_sub:=Shift_Reg;
A:="000000000000000000000000";
B:="000000000000000000000000";
sh:="000000000000000000000000";
c_temp:=d_sub(23) or d_sub(22);
r2:="000000000000000000000000";
r0(0):= not d_sub(22);
r0(1):= d_sub(23) xnor d_sub(22);
control:=r2(23);
r2:=addsub(A,B,c_temp,control);
sh:=sh(22 downto 0)& (not r2(23));
r:=r2(21 downto 0)& r0(1 downto 0);
d_sub:=d_sub(21 downto 0)& "00";

when 22|21|20|19|18|17|16|15|14|13|12|11|10|9|8|7|6|5|4|3|2|1 =>
c_temp:=d_sub(23) or d_sub(22);
r0(0):= not d_sub(22);
r0(1):= d_sub(23) xnor d_sub(22);
B:=sh;
A:=r;
control:=r2(23);
r2:=addsub(A,B,c_temp,control);
sh:=sh(22 downto 0)& (not r2(23));
r:=r2(21 downto 0)& r0(1 downto 0);
d_sub:=d_sub(21 downto 0)& "00";

when 0 =>
c_temp:=d_sub(23) or d_sub(22);
r0(0):= not d_sub(22);
r0(1):= d_sub(23) xnor d_sub(22);
B:=sh;
A:=r;
control:=r2(23);
r2:=addsub(A,B,c_temp,control);
sh:=sh(22 downto 0)& (not r2(23));
r:=r2(21 downto 0)& r0(1 downto 0);
d_sub:=d_sub(21 downto 0)& "00";
Result(31 downto 0)<=result_temp( 8 downto 0) & sh(23 downto 1);


when others=> null;
end case;

end process;

process(CLK,reset)
begin
if(CLK='1' and CLK'event and reset='1' ) then
if state/=0 then
state<=state-1;
else
state<=23;
end if;
end if;
end process;

end Behavioral;

The value of "Result" which is reflected by modelsim is as expected
for all possible combinations of input. Somehow after burning the code
on d fpga, it gives a weird output.

I do get some warnings when i synthesize, which i otherwise ignore.
The warnings are as below-
1. <r2> is unconnected in block <non_restoring_float_sqrt>.
2. Found 24-bit latch for signal <d_sub>.
Found 24-bit latch for signal <r>.
Found 24-bit latch for signal <sh>.
Found 24-bit latch for signal <r2>.
***************************************************************************************************

Any sort of help would be appreciated.

 

[Mike Treseler]

Kausi wrote:

Any sort of help would be appreciated.

I can meet that standard

I would put the whole design into the clocked process.
It is very easy to make latches in a combinational process.
It can't happen in a synchronous process.

-- Mike Treseler

 

[Mike Treseler]

Dave wrote:

I didn't know that latches could cause simulation mismatches.

There wasn't a mismatch.
Synthesis put in the requested LUT latches as best it could
and issued the correct warning.
The latches just didn't work with default constraints.

I know
they're often signs that you've made a mistake and left out an
assignment in a combinatorial process, but I thought they were valid
if you meant for a latch to be implemented, and would synthesize and
simulate identically.

If I want a latch to be implemented in an fpga,
and I still have a flop left, I am mistaken.

Like has been said, having everything in a clocked process makes state
machines easier to code and understand. There's no reason that the
next-state logic and output logic can't be in the same clocked
process.

Exactly.

-- Mike Treseler

 

[Kausi]

Thanks Mike !!

Writing it inside one process was something which i always wanted to
avoid, in order to have clear functionalities. If the FPGA doesnt
understand it, L have no other option but to oblige.

Regards,
Kauser.

 

[KJ]

On May 6, 12:48 pm, Kausi <kauser.jo...@gmail.com> wrote:

Iam struggling with a piece of code that has been giving me sleepless
nights for the past one week. What i fail to understand is that the
code works absolutely fine, without even a glitch in modelsim.

Simulators never glitch.

But
when i burn the code on an fpga (spartan-3), i get weird results.

Then it's generally some timing problem.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

Don't use std_logic_arith and std_logic_unsigned. numeric_std is
preferred.

entity Non_restoring_float_sqrt is
Port ( Float_Input_IEEE_Format: in bit_vector(31 downto 0);
       Result: out bit_vector(31 downto 0);
          reset: in bit;
          CLK: in bit);
end Non_restoring_float_sqrt;

architecture Behavioral of Non_restoring_float_sqrt is

type dstate is range 24 downto 0;
signal state : dstate;
signal result_temp : bit_vector(8 downto 0);
signal Shift_Reg: bit_vector(23 downto 0);

begin

process(Float_Input_IEEE_Format,reset)
variable A_exponent: bit_vector(7 downto 0);
constant B_exponent: bit_vector(7 downto 0):="00111111";
variable Float_Local_exponent: bit_vector(7 downto 0);
variable Float_Local_fraction: bit_vector(22 downto 0);
variable Sum_Temp_variable: bit_vector(8 downto 0);
variable Sign_bit: bit;
begin
if reset='1' and reset'event then

Hmm...reset is not in the sensitivity list. This will cause a
difference between simulation and synthesis. The synthesis tool
probably also gave you a warning about an incomplete sensitivity
list...fix it, and any others as well.

Sign_bit:=Float_Input_IEEE_Format(31);
Float_Local_exponent := Float_Input_IEEE_Format(30 downto 23);
Float_Local_fraction := Float_Input_IEEE_Format(22 downto 0);
A_exponent:= '0' & Float_Local_exponent(7 downto 1);
-- I have not pasted the function to reduce the length.
Sum_Temp_variable:=Adder_for_exponent(A_exponent,B_exponent,Float_Local_exp­onent(0));
result_temp(8 downto 0)<= Sign_bit & Sum_Temp_variable(7 downto 0);
if Float_Local_exponent(0)= '0' then
Shift_Reg<='1' & Float_Local_fraction(22 downto 0);
else
Shift_Reg<= "01" & Float_Local_fraction(22 downto 1);
end if;
else null;
end if;
end process;

process(Shift_Reg,state)
variable r0: bit_vector(1 downto 0);
variable r2: bit_vector(23 downto 0);
variable c_temp,control: bit;
variable A,B: bit_vector(23 downto 0);
variable r  : bit_vector(23 downto 0);
variable sh  : bit_vector(23 downto 0);
variable d_sub : bit_vector(23 downto 0);
begin
case state is
        when 23 =
             d_sub:=Shift_Reg;
                A:="000000000000000000000000";
                B:="000000000000000000000000";
                sh:="000000000000000000000000";
                c_temp:=d_sub(23) or d_sub(22);
                r2:="000000000000000000000000";
                r0(0):= not d_sub(22);
                r0(1):= d_sub(23) xnor d_sub(22);
                control:=r2(23);
                                r2:=addsub(A,B,c_temp,control);
                sh:=sh(22 downto 0)& (not r2(23));
                r:=r2(21 downto 0)& r0(1 downto 0);
                d_sub:=d_sub(21 downto 0)& "00";

        when 22|21|20|19|18|17|16|15|14|13|12|11|10|9|8|7|6|5|4|3|2|1 =
             c_temp:=d_sub(23) or d_sub(22);
                r0(0):= not d_sub(22);
                r0(1):= d_sub(23) xnor d_sub(22);
                B:=sh;
                A:=r;
                control:=r2(23);
                r2:=addsub(A,B,c_temp,control);
                sh:=sh(22 downto 0)& (not r2(23));
                r:=r2(21 downto 0)& r0(1 downto 0);
                d_sub:=d_sub(21 downto 0)& "00";

        when 0 =
             c_temp:=d_sub(23) or d_sub(22);
                r0(0):= not d_sub(22);
                r0(1):= d_sub(23) xnor d_sub(22);
                B:=sh;
                A:=r;
                control:=r2(23);
                r2:=addsub(A,B,c_temp,control);
                sh:=sh(22 downto 0)& (not r2(23));
                r:=r2(21 downto 0)& r0(1 downto 0);
                d_sub:=d_sub(21 downto 0)& "00";
                Result(31 downto 0)<=result_temp( 8 downto 0) & sh(23 downto 1);

Where is the assignment to 'Result' in any of the other cases
(including the 'when others' case. You've likely created a latch with
this...very bad mojo in FPGAs/CPLDs.

           when others=> null;
          end case;

end process;

process(CLK,reset)
  begin
 if(CLK='1' and CLK'event and reset='1' ) then
 if state/=0 then
 state<=state-1;
         else
 state<=23;
  end if;
end if;
  end process;

Now if you had simply put the logic from your previous processes
inside this clocked process, it would all have simply worked for you
I'm sure. You gain nothing, and lose lots (like a week's worth of
sleep it would seem) by ever using combinatorial processes when doing
FPGA/CPLD design.

 end Behavioral;

The value of "Result" which is reflected by modelsim is as expected
for all possible combinations of input. Somehow after burning the code
on d fpga, it gives a weird output.

There is more to FPGA design than running Modelsim. Like did you
peruse and fix warnings? Did you successfully complete timing
analysis?

I do get some warnings when i synthesize, which i otherwise ignore.

Oooooooo....that was a mistake.

The warnings are as below-
1. <r2> is unconnected in block <non_restoring_float_sqrt>.
2.  Found 24-bit latch for signal <d_sub>.
    Found 24-bit latch for signal <r>.
    Found 24-bit latch for signal <sh>.
    Found 24-bit latch for signal <r2>.

Very helpful, at least you know now where to look.

Any sort of help would be appreciated.

- Get some sleep and then fix those warnings. It's only a 'warning'
because it does not prevent the synthesis tool from completing it's
mission which is simply to produce a bitstream output file.

- Synthesis tool warnings are usually design errors.

- Good luck.

Kevin Jennings

 

[KJ]

On May 6, 1:46 pm, Kausi <kauser.jo...@gmail.com> wrote:

Thanks Mike !!

Writing it inside one process was something which i always wanted to
avoid, in order to have clear functionalities.

Although Mike prefers a single clocked process, his main point is to
use only clocked processes. You can still clearly delineate the
functionality with a process...make them clocked processes to avoid
the possibility of latches.

If the FPGA doesnt
understand it, L have no other option but to oblige.

The FPGA understood it just fine, your logic defined a combinatorial

loop and created a latch. These can not be *reliably* implemented in
an FPGA.

Kevin Jennings

 

[Kausi]

Thanks a ton. I'll get some sleep tonight and get back to the drawing
board tomorrow. Will first correct the mistakes highlighted above,
then post any new complications encountered. Thanks once again.

Regards,
Kauser.

 

[Dave]

On May 6, 1:53 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On May 6, 1:46 pm, Kausi <kauser.jo...@gmail.com> wrote:

Thanks Mike !!

Writing it inside one process was something which i always wanted to
avoid, in order to have clear functionalities.

Although Mike prefers a single clocked process, his main point is to
use only clocked processes. You can still clearly delineate the
functionality with a process...make them clocked processes to avoid
the possibility of latches.

If the FPGA doesnt
understand it, L have no other option but to oblige.

The FPGA understood it just fine, your logic defined a combinatorial
loop and created a latch. These can not be *reliably* implemented in
an FPGA.

Kevin Jennings

I didn't know that latches could cause simulation mismatches. I know
they're often signs that you've made a mistake and left out an
assignment in a combinatorial process, but I thought they were valid
if you meant for a latch to be implemented, and would synthesize and
simulate identically.

I know there are coding styles in the OP's code that aren't exactly
good form, and I think they've been hit by Mike and KJ. As far as why
the simulation mismatch is happening, though, I have a couple of other
thoughts:

1. Sensitivity lists, especially in the 2nd process, are missing quite
a bit. In a combinatorial process, everything that appears on the
right-hand side of an assignment should be in the sensitiivity list,
even if that signal is an output of that process. This includes
arguments of functions that are on the right-hand side, too. That
means d_sub, r2, A, B, c_temp, control, etc. need to be in the list.
Since synthesis tools ignore the sensitivity list, but simulators
follow it, this can very easily cause a simulation mismatch.

2. Reset functionality. The way you're using reset is a bit odd, using
it as a clock in the first process, and as an enable in the third
process. Make sure on your hardware that the reset stays high, since
the state machine will freeze if it is dropped low. You may want to re-
think how you use reset.

3. Timing problems, as has been said above. The slower your clock, the
less likely this is the problem, but obviously simulators don't catch
these problems unless you do post-place-and-route simulation, and even
they you might miss them.

Like has been said, having everything in a clocked process makes state
machines easier to code and understand. There's no reason that the
next-state logic and output logic can't be in the same clocked
process.

Dave

 

[Kausi]

@Dave-

That means d_sub, r2, A, B, c_temp, control, etc. need to be in the list.
Since synthesis tools ignore the sensitivity list, but simulators
follow it, this can very easily cause a simulation mismatch.

Firstly i was aware about the missing arguments in the sensitivity
listm, this is because i only wanted the signals(state, shift_reg) to
call the process. Second, the simulation works exactly as predicted
even when i use a 200ns clock while the fpga uses 20us.

And are you trying to say that if the entire length was within a
single process, latching would be eliminated?? I dont think so.
Because my combinational logic isnt that cumbersome and according to
the inertial gate delays assumed by VHDL, the entire work should be
completed well before the clock edge has arrived.

 

[Kausi]

One more doubt- If i assign a signal to a variable and vice-versa,
although the syntax is correct, is it a valid on FPGA ? Example as
shown below is an excerpt from my code:-

****************************************************
process(Float_Input_IEEE_Format)
variable A_exponent: bit_vector(7 downto 0);
constant B_exponent: bit_vector(7 downto 0):="00111111";
variable Float_Local_exponent: bit_vector(7 downto 0);
variable Float_Local_fraction: bit_vector(22 downto 0);
variable Sum_Temp_variable: bit_vector(8 downto 0);
variable Sign_bit: bit;
begin

Sign_bit:=Float_Input_IEEE_Format(31);
Float_Local_exponent := Float_Input_IEEE_Format(30 downto 23);
Float_Local_fraction := Float_Input_IEEE_Format(22 downto 0);
A_exponent:= '0' & Float_Local_exponent(7 downto 1);
Sum_Temp_variable:=Adder_for_exponent(A_exponent,B_exponent,Float_Local_exp­
onent(0));
result_temp(8 downto 0)<= Sign_bit & Sum_Temp_variable(7 downto 0);
if Float_Local_exponent(0)= '0' then
Shift_Reg<='1' & Float_Local_fraction(22 downto 0);
else
Shift_Reg<= "01" & Float_Local_fraction(22 downto 1);
end if;
end process;
**************************************************************

Shift_Reg is a signal which is defined in the architecture. Somehow it
isn't getting assigned with the correct values from
Float_Local_fraction. Any guesses why?

 

[Tricky]

Firstly i was aware about the missing arguments in the sensitivity
listm, this is because i only wanted the signals(state, shift_reg) to
call the process. Second, the simulation works exactly as predicted
even when i use a 200ns clock while the fpga uses 20us.

Sensitivity lists are only there for simulation purposes. Synthesisers
will ignore them and work out what affects what from the actual code.
So saying that you only wanted certain signals to "call" the process
is completly invalid. Signals do not call a process, a process is re-
evaluated when one of the signals in the sensitivity list has an event
on it. If you miss some out of the list, you're only making the
simulation behave wrongly. It is only working as predicted as you have
regigged the sensitivity list to make the code work how you think it
should, rather than re-write the code to make it work properly.

Secondly, as you have no propagation delays or anything time based and
assuming you're not doing a gate level simulation, the speed of the
clock is arbitrary in simulation. You could set it to 10s or 1ps, and
you would get the same results. It is only a functional simulation.
There are no gates in RTL level simulation.

And are you trying to say that if the entire length was within a
single process, latching would be eliminated?? I dont think so.
Because my combinational logic isnt that cumbersome and according to
the inertial gate delays assumed by VHDL, the entire work should be
completed well before the clock edge has arrived.

latching occurs when you dont assign an output from an asyncronous
process in EVERY possible case. So as you only assign result in case
24 and not in any other case, result will become latched. The easiest
way to fix this is to have a "default" state for a signal assigned
outside and before the case statement that is overridden in specific
case (remember that the last value for an assignment is taken, so this
is why it has to be before the case statement).

 

[Mike Treseler]

Kausi wrote:

One more doubt- If i assign a signal to a variable and vice-versa,
although the syntax is correct, is it a valid on FPGA ?

A variable can be updated with any value in process scope:
signal, variable or constant. However FPGA timing tools
expect a synchronous template.
I like the one here:
http://mysite.verizon.net/miketreseler/
Synthesis also requires an entity.

****************************************************
Shift_Reg is a signal which is defined in the architecture. Somehow it
isn't getting assigned with the correct values from
Float_Local_fraction. Any guesses why?

I wouldn't guess.
I would run a sim to eliminate syntax and logical errors.
I would put the entity on an rtl viewer to check the structure.

-- Mike Treseler

 

[Dave]

On May 6, 11:55 pm, Kausi <kauser.jo...@gmail.com> wrote:

@Dave-

That means d_sub, r2, A, B, c_temp, control, etc. need to be in the list.
Since synthesis tools ignore the sensitivity list, but simulators
follow it, this can very easily cause a simulation mismatch.

Firstly i was aware about the missing arguments in the sensitivity
listm, this is because i only wanted the signals(state, shift_reg) to
call the process. Second, the simulation works exactly as predicted
even when i use a 200ns clock while the fpga uses 20us.

And are you trying to say that if the entire length was within a
single process, latching would be eliminated?? I dont think so.
Because my combinational logic isnt that cumbersome and according to
the inertial gate delays assumed by VHDL, the entire work should be
completed well before the clock edge has arrived.

It's not that putting everything in a single process eliminates the
latches - it's putting everything in clocked (synchronous) processes.
There could be as many processes as you like, but if they're all
clocked, there will be no latches. There will, instead, be registers
for all the assignments.

As far as sensitivity lists, Tricky hit it right on. Every signal that
is read or used in an asynchronous process NEEDS to be in the
sensitivity list. Not doing so, while syntactically not an error, will
cause the simulator and synthesizer disagree.

Dave

 

[Kausi]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity Non_restoring_float_sqrt is
Port ( Float_Input_IEEE_Format: in std_logic_vector(31 downto 0);
Result: out std_logic_vector(31 downto 0);
clk,enable: in std_logic);
end Non_restoring_float_sqrt;

architecture Behavioral of Non_restoring_float_sqrt is

type dstate is range 24 downto 0;
signal state : dstate;
signal Shift_Reg: std_logic_vector(23 downto 0);
signal sh_signal,r_signal: std_logic_vector(23 downto 0);
signal pass: std_logic;

begin

process(clk,Shift_Reg,state,Float_Input_IEEE_Format,sh_signal,r_signal,enable)

variable r0: std_logic_vector(1 downto 0);
variable c_temp,control,Sign_bit: std_logic;
variable r,sh,r2 : std_logic_vector(23 downto 0);
variable A_exponent,Float_Local_exponent,Sum_Temp_variable:
std_logic_vector(7 downto 0);
constant B_exponent: std_logic_vector(7 downto 0):="00111111";
variable Float_Local_fraction: std_logic_vector(22 downto 0);
variable result_temp : std_logic_vector(8 downto 0);

begin
if enable='0' then

state<=23;
Sign_bit:=Float_Input_IEEE_Format(31);
Float_Local_exponent := Float_Input_IEEE_Format(30 downto 23);
Float_Local_fraction := Float_Input_IEEE_Format(22 downto 0);
A_exponent:= '0' & Float_Local_exponent(7 downto 1);
Sum_Temp_variable:=Adder_for_exponent(A_exponent,B_exponent,Float_Local_exponent(0));
result_temp(8 downto 0):= Sign_bit & Sum_Temp_variable(7 downto 0);
if Float_Local_exponent(0)= '0' then
Shift_Reg<='1' & Float_Local_fraction(22 downto 0);
elsif Float_Local_exponent(0)= '1' then
Shift_Reg<= "01" & Float_Local_fraction(22 downto 1);
else null;
end if;

elsif clk='1' and clk'event then

case state is
when 23 =>
sh:="000000000000000000000000";
r:="000000000000000000000000";
c_temp:=Shift_Reg(23) or Shift_Reg(22);
r2:="000000000000000000000000";
r0(0):= not Shift_Reg(22);
r0(1):= Shift_Reg(23) xnor Shift_Reg(22);
control:=r2(23);
r2:=addsub(r,sh,c_temp,control);
sh:=sh(22 downto 0)& (not r2(23));
r:=r2(21 downto 0)& r0(1 downto 0);
Shift_Reg<=Shift_Reg(21 downto 0)& "00";
sh_signal<=sh;
r_signal<=r;
pass<=r2(23);
state<=state-1;

when 22|21|20|19|18|17|16|15|14|13|12|11|10|9|8|7|6|5|4|3|2|1 =>
sh:=sh_signal;
r:=r_signal;
control:=pass;
c_temp:=Shift_Reg(23) or Shift_Reg(22);
r0(0):= not Shift_Reg(22);
r0(1):= Shift_Reg(23) xnor Shift_Reg(22);
r2:=addsub(r,sh,c_temp,control);
sh:=sh(22 downto 0)& (not r2(23));
r:=r2(21 downto 0)& r0(1 downto 0);
Shift_Reg<=Shift_Reg(21 downto 0)& "00";
sh_signal<=sh;
r_signal<=r;
pass<=r2(23);
state<=state-1;

when 0 =>
sh:=sh_signal;
r:=r_signal;
c_temp:=Shift_Reg(23) or Shift_Reg(22);
control:=pass;
r0(0):= not Shift_Reg(22);
r0(1):= Shift_Reg(23) xnor Shift_Reg(22);
r2:=addsub(r,sh,c_temp,control);
sh:=sh(22 downto 0)& (not r2(23));
r:=r2(21 downto 0)& r0(1 downto 0);
Shift_Reg<=Shift_Reg(21 downto 0)& "00";
sh_signal<=sh;
r_signal<=r;
pass<=r2(23);
state<=24;

when others =>
sh_signal<=sh_signal;
r_signal<=r_signal;
pass<=pass;
end case;
end if;

Result(31 downto 0)<=result_temp( 8 downto 0) & sh_signal(23 downto
1);
end process;
end Behavioral;
--
****************************************************************************--

I'hv modified my earlier code based on the constructive and useful
suggessions above. Have eliminated almost all the warnings except for
one as pasted below. Hope this breaks the ice on the hardware.

Warning- Found 9-bit latch for signal enable at line 115. This points
to the line-
if enable='0' then

 

[KJ]

On May 7, 3:33 pm, Kausi <kauser.jo...@gmail.com> wrote:
<snip> Have eliminated almost all the warnings except for

one as pasted below. Hope this breaks the ice on the hardware.

Warning- Found 9-bit latch for signal enable at line 115. This points
to the line-
if enable='0' then

A clocked process
- Has only 'clk' in the sensitivity list (remove all of your other
signals)
- Has an outermost 'if' statement that is "if rising_edge(clk)
then" (preferred) or "if clk'event and clk = '1' then". You've got an
outermost one of "if enable='0'", get rid of it.

process(clk)
begin
if rising_edge(clk) then
-- Put all of your stuff in here
end if;
end process;

Also, as a side note, std_logic_arith is not the preferred package to
be using, it is not a standard. Use ieee.numeric_std instead, it is a
standard. This won't affect your ability to build and test your
design, it is just good practice to use the proper packages.

Kevin Jennings