Can I ignore peaks in simulation?

Hi

I have combinational logic that evaluates some logic expressions and to
do so it needs to compare some values that are stored in registers. The
simulation works as intended but when I take a closer look at the single
bits of a 32-bit wide register I can see that I have some bits that are
1 when the clock raises to high and goes than immediatelly back to ZERO.
Looks like a glitch in some way, as the bit doesnt remain the state
until the next rising clock. As I said, the simulation works but I cant
figure out what causes these peaks. Can somebody perhaps guide me how to
trace such a problem or can I ignore this?

Many thanks!
Flo

Florian

[jeppe]

Hi Flo

Depends on what you want to drive with those outputs.

If you "only" drives leds etc will those peaks not be visiable anyway, but if your using signals combination with a 32-bit comparator, could it cause you problems, if an "unwanted" combination appears due to the peaks.

Moreover - if your using one of the "peaky" signal for a clock the could it give you extra pulses for a counter etc.

Hope this helped you.

Jeppe

jeppe

"Florian" <> wrote in message news:g1erc2$5gp$...
> Hi
>
> I have combinational logic that evaluates some logic expressions and to do
> so it needs to compare some values that are stored in registers. The
> simulation works as intended but when I take a closer look at the single
> bits of a 32-bit wide register I can see that I have some bits that are
> 1 when the clock raises to high and goes than immediatelly back to ZERO.
> Looks like a glitch in some way, as the bit doesnt remain the state until
> the next rising clock. As I said, the simulation works but I cant figure
> out what causes these peaks. Can somebody perhaps guide me how to trace
> such a problem or can I ignore this?
>
> Many thanks!
> Flo

http://en.wikipedia.org/wiki/Hazard_%28logic%29
http://en.wikipedia.org/wiki/Synchronous_system
http://en.wikipedia.org/wiki/Static_timing_analysis

Symon

On May 26, 1:17 pm, Florian <Flo...@yahoo.com> wrote:
> Hi
>
> I have combinational logic that evaluates some logic expressions and to
> do so it needs to compare some values that are stored in registers. The
> simulation works as intended but when I take a closer look at the single
> bits of a 32-bit wide register I can see that I have some bits that are
> 1 when the clock raises to high and goes than immediatelly back to ZERO.
> Looks like a glitch in some way, as the bit doesnt remain the state
> until the next rising clock. As I said, the simulation works but I cant
> figure out what causes these peaks. Can somebody perhaps guide me how to
> trace such a problem or can I ignore this?
>
> Many thanks!
> Flo

Why don't you show us the code that describes this hardware? Maybe we
can find something wrong.

Rick

rickman

> Why don't you show us the code that describes this hardware? Maybe we
> can find something wrong.
>
> Rick

That sounds good Rick, the problem is however that its quite a bit of
code so I copied here the most important parts and I hope it will be
enough to understand it.

RegDST and RegSRC are 4x16 arrays that store ressources that are locked
or available at the moment. I read than in a new instruction to execute
and compare the locked/available ressources to the ressources that the
instruction needs for dependencies. This is done with the following logic:

RanIB_tmp(0) <= '1' when
((RegDST(0)(conv_integer(std_logic_vector(RIB_RegD est)))='1')
or RegSRC(0)(conv_integer(std_logic_vector(RIB_RegDes t)))='1')
or (RegDST(0)(conv_integer(std_logic_vector(RIB_RegSr c1)))='1')
or (RegDST(0)(conv_integer(std_logic_vector(RIB_RegSr c2)))='1'))
else '0';


RanIB_tmp(1) <= '1' when
((RegDST(1)(conv_integer(std_logic_vector(RIB_RegD est)))='1')
or (RegSRC(1)(conv_integer(std_logic_vector(RIB_RegDe st)))='1')
or (RegDST(1)(conv_integer(std_logic_vector(RIB_RegSr c1)))='1')
or (RegDST(1)(conv_integer(std_logic_vector(RIB_RegSr c2)))='1'))
else '0';

RanIB_tmp(2) <= '1' when
((RegDST(2)(conv_integer(std_logic_vector(RIB_RegD est)))='1')
or (RegSRC(2)(conv_integer(std_logic_vector(RIB_RegDe st)))='1')
or (RegDST(2)(conv_integer(std_logic_vector(RIB_RegSr c1)))='1')
or (RegDST(2)(conv_integer(std_logic_vector(RIB_RegSr c2)))='1'))
else '0';

RanIB is a 4x4 array that stores the dependecies between 4 instructions.
If all the elements in a row are 0 this implies that there are NO
dependencies with other instructions. These dependecies I evaluate
with the following combinatorial code

I0 <= RanIB(0)(0) or RanIB(0)(1) or RanIB(0)(2);
I1 <= RanIB(1)(0) or RanIB(1)(1) or RanIB(1)(2);
I2 <= RanIB(2)(0) or RanIB(2)(1) or RanIB(2)(2);
I3 <= RanIB_tmp(0) or RanIB_tmp(1) or RanIB_tmp(2);

I1..I4 are then fed into a Random selection unit that picks me
one of the instructions which does not depend on any other instruction.
THis random selection unit outputs me two bits which I use to look
up the instruction in an 4x32 array called InsT

RIB_InstrReg <= InsT(conv_integer(A0 & A1)) ;

The glitches occur within the RIB_InstrReg signal.

The code above describes the combinatorical logic. At each rising clock
edge I update then the storage arrays.
if ( clk = '1' and clk'event ) then
InsT(conv_integer(A0 & A1)) <= FE_RIB_InstrReg;
RegDST(conv_integer(A0 & A1)) <= RegDST_tmp;
RegSRC(conv_integer(A0 & A1)) <= RegSRC_tmp;
....

I also read the RIB_InstrReg then synchronously, so hopeful this solves
this problem. Anyway, would be thankful for any helpful comment
concering the codefragment above

Floh

Florian

Florian schrieb:

> RanIB_tmp(0) <= '1' when
> ((RegDST(0)(conv_integer(std_logic_vector(RIB_RegD est)))='1')
> or RegSRC(0)(conv_integer(std_logic_vector(RIB_RegDes t)))='1')
> or (RegDST(0)(conv_integer(std_logic_vector(RIB_RegSr c1)))='1')
> or (RegDST(0)(conv_integer(std_logic_vector(RIB_RegSr c2)))='1'))
> else '0';

This is combinational logic and combinational logic has a very high
probability to produce glitches when one input changes. This is no
problem if the output value (RanIB_tmp(0)) is stable at least before the
setup-time of the following flipflop that samples this signal.

Ralf

Ralf Hildebrandt

On May 27, 6:11 am, Florian <Flo...@yahoo.com> wrote:
> > Why don't you show us the code that describes this hardware? Maybe we
> > can find something wrong.
>
> > Rick
>
> That sounds good Rick, the problem is however that its quite a bit of
> code so I copied here the most important parts and I hope it will be
> enough to understand it.
>
....snip...
>
> RIB_InstrReg <= InsT(conv_integer(A0 & A1)) ;
>
> The glitches occur within the RIB_InstrReg signal.
>
> The code above describes the combinatorical logic. At each rising clock
> edge I update then the storage arrays.
> if ( clk = '1' and clk'event ) then
> InsT(conv_integer(A0 & A1)) <= FE_RIB_InstrReg;
> RegDST(conv_integer(A0 & A1)) <= RegDST_tmp;
> RegSRC(conv_integer(A0 & A1)) <= RegSRC_tmp;
> ....
>
> I also read the RIB_InstrReg then synchronously, so hopeful this solves
> this problem. Anyway, would be thankful for any helpful comment
> concering the codefragment above
>
> Floh

I think you are looking at this as if it were a complex problem and it
isn't. It is a very, very simple problem. I can't say what it is,
since I don't know the definitions of all the signals. But you give
this equation...

> RIB_InstrReg <= InsT(conv_integer(A0 & A1)) ;

and you say RIB_InstrReg is misbehaving by having a different value on
each phase of the clock. This assignment is very simple so just look
to see which of the inputs is changing when you don't expect it to.
The options are A0, A1 and InsT(). Then once you know which input is
changing at the wrong time, you can need to repeat the same process
with the inputs to that signal's assignment.

The code is doing exactly what you are telling it to. The problem is
at a low level in one of the assignments or in the construction of
your clocked processes. Instead of looking at the big picture, you
need to start with the misbehaving signal and trace it back through
the misbehaving inputs until you find the incorrect assignment or
other construct.

Actually, I may be misunderstanding what you are saying. If you mean
that you are getting very brief glitchs following the active clock
edge, this is perfectly normal for combinatorial logic. You are
seeing the result of different paths with inputs changing on both,
with the changes arriving at the output at different times. This is
called a "race" condition and by using edge triggered registers you
will see no effect from this... as long as the delays in the real
circuit are shorter than the clock cycle. That is what static timing
analysis is for.

Rick

rickman