Bug #5736: EfsmSimulator.substituteVariables(EfsmSimulator.java:736) -> NullPointerException - Retrascope - Open-Source Projects

Actions

Copy link

Bug #5736

closed

EfsmSimulator.substituteVariables(EfsmSimulator.java:736) -> NullPointerException

Added by Sergey Smolov almost 10 years ago. Updated over 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Igor Melnichenko

Category:

Engine (Simulator)

Target version:

0.1

Start date:

03/23/2015

Due date:

% Done:

100%

Estimated time:

Detected in build:

svn

Platform:

Published in build:

20150701

Description

I've added the sample/sample.vhd VHDL design to project test suite. When I run Retrascope with the following parameters:

src/test/vhdl/sample/sample.vhd --target test --toplevel sample --engine efsm-fate-test-generator --loop-limit 25

I receive an error with the following log:

2015.03.23 13:36:08.129. ERROR: The exception has been encountered: java.lang.NullPointerException
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.substituteVariables(EfsmSimulator.java:736)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.executeAssignment(EfsmSimulator.java:695)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.executeAction(EfsmSimulator.java:595)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.initialise(EfsmSimulator.java:319)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.processEvents(EfsmSimulator.java:275)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.DirectedFateGenerator.generateSequence(DirectedFateGenerator.java:211)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.DirectedFateGenerator.getNextSequenceIterator(DirectedFateGenerator.java:167)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGenerator.start(EfsmFateTestGenerator.java:318)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGenerator.start(EfsmFateTestGenerator.java:52)
    at ru.ispras.retrascope.basis.Engine.start(Engine.java:200)
    at ru.ispras.retrascope.basis.ToolChain.start(ToolChain.java:106)
    at ru.ispras.retrascope.basis.Engine.start(Engine.java:200)
    at ru.ispras.retrascope.Retrascope$Run.start(Retrascope.java:116)
    at ru.ispras.retrascope.Retrascope.main(Retrascope.java:340)
    at ru.ispras.retrascope.Retrascope.main(Retrascope.java:362)

2015.03.23 13:36:08.130. INFO: Retrascope is shutting down
Exception in thread "main" java.lang.NullPointerException
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.substituteVariables(EfsmSimulator.java:736)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.executeAssignment(EfsmSimulator.java:695)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.executeAction(EfsmSimulator.java:595)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.initialise(EfsmSimulator.java:319)
    at ru.ispras.retrascope.engine.efsm.simulator.EfsmSimulator.processEvents(EfsmSimulator.java:275)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.DirectedFateGenerator.generateSequence(DirectedFateGenerator.java:211)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.DirectedFateGenerator.getNextSequenceIterator(DirectedFateGenerator.java:167)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGenerator.start(EfsmFateTestGenerator.java:318)
    at ru.ispras.retrascope.engine.efsm.generator.test.fate.EfsmFateTestGenerator.start(EfsmFateTestGenerator.java:52)
    at ru.ispras.retrascope.basis.Engine.start(Engine.java:200)
    at ru.ispras.retrascope.basis.ToolChain.start(ToolChain.java:106)
    at ru.ispras.retrascope.basis.Engine.start(Engine.java:200)
    at ru.ispras.retrascope.Retrascope$Run.start(Retrascope.java:116)
    at ru.ispras.retrascope.Retrascope.main(Retrascope.java:340)
    at ru.ispras.retrascope.Retrascope.main(Retrascope.java:362)

I've tried to compile the sample.vhd on ModelSim and GHDL simulators and they have said that it is ok.

Actions

Copy link

Updated by Igor Melnichenko almost 10 years ago

Status changed from New to Open

To resolve this issue we need to introduce variables' intial values (as mentioned here http://www.ics.uci.edu/~jmoorkan/vhdlref/var_dec.html) in the EFSM representation.
There are two options:
1) an explicit method (for example, setInitialValue(...)) which must be called for each variable;
2) filling all occurrences of the corresponding NodeVariables in guards and actions with the initial VHDL values before EfsmStates and EfsmTransitions creation.
Which option do you prefer? I'm considering the first one as more transparent solution.

Also information about initial values will be useful for initial state detection. For example, in case of sample.vhd the initial state would be STATE 0 instead of randomly chosen STATE 1 and there will be no reset guarded action (either null or an empty guarded action).

Actions

Copy link

Updated by Igor Melnichenko almost 10 years ago

Maybe in this case there is no need for complex heuristic for intial state and reset guarded action detection at all?

Actions

Copy link

Updated by Sergey Smolov almost 10 years ago

Status changed from Open to Resolved
% Done changed from 0 to 100

So, the problem is due to the fact that "resetting transition" and "initial EFSM state" were chosen incorrectly, right?

I think, it would be better now just to fix the sample.vhd in such way that CgaaEfsmTransformer will return adequate candidates for initial state and resetting transition.

I have done in in r1689.

We may also fix the initial state heuristic. For example, we may not to select the "first" state as initial, but the "zero" state (that assigns zero values to state-like variables).
Will this fix be helpful for test generation?

Actions

Copy link

Updated by Igor Melnichenko almost 10 years ago

Sergey Smolov wrote:

So, the problem is due to the fact that "resetting transition" and "initial EFSM state" were chosen incorrectly, right?

I think, it would be better now just to fix the sample.vhd in such way that CgaaEfsmTransformer will return adequate candidates for initial state and resetting transition.

I have done in in r1689.

Yes, test is generated successfully now.

Sergey Smolov wrote:

We may also fix the initial state heuristic. For example, we may not to select the "first" state as initial, but the "zero" state (that assigns zero values to state-like variables).
Will this fix be helpful for test generation?

For the previous version of sample.vhd - yes. But I think that the more natural way (at least for VHDL) to process such a type of designs (and all the rest too) is to drop current concept of reset guarded action and use explicitly initialised and leftmost values (as described in the link I provided) as initial ones. In this case initial state is just such a state which corresponds to the initial values.

Maybe it's worth to discuss on the Wednsday meeting.

Actions

Copy link