Project

General

Profile

Bug #5736

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

Added by Sergey Smolov over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Engine (Simulator)
Target version:
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.

History

#1

Updated by Igor Melnichenko over 4 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).

#2

Updated by Igor Melnichenko over 4 years ago

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

#3

Updated by Sergey Smolov over 4 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?

#4

Updated by Igor Melnichenko over 4 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.

#5

Updated by Sergey Smolov over 4 years ago

  • Status changed from Resolved to Verified

I doubt rather this concept is correct both for VHDL and Verilog designs. So see you on Wednesday, 25.03.

#6

Updated by Sergey Smolov about 4 years ago

  • Status changed from Verified to Closed
  • Published in build set to 20150701

Also available in: Atom PDF