技术博，请自动跳过。

————————————-

Within the HSR evaluation phase of execution, each module instance’s code may be executed multiple times.

之前我是不理解这句话的，在手册上画了个大大的问号。经过毫无收获的一天，算是明白其背后的深刻内涵了！

由于组件的连接可能存在反馈，和通常所说的反馈概念一样，系统需要一个反复计算的过程才能达到反馈稳态。对于硬件来说，这样一个反馈过程就是硬件反复读取输入，经过电路，然后输出的过程，对于软件来说，经过的不是电路，而是一组计算过程,i.e. functions.

上面说"each module instance’s code may be executed multiple times"就是因为这个原因。为了达到稳态，每个模块就可能会参与多次计算。

Start Of Timestep

所有端口状态都被设置为LSE_signal_unknown。也就是说，再辉煌的历史，那都是历史了。未来掌握在新的计算之中。如何计算？最简单的一步：in/out.control中设置端口输出。这种输出是不依赖于任何外部输入值/信号就可以确定的部分，必须依赖于外部输入/信号的端口状态在下一步计算。

HSR( Heterogeneous Synchronous Reactive) Evaluation

在这一步中，LSE利用HSR计算模型（Model of Comutation，MoC）来推算模块端口状态。依据MSR MoC的定义，我们对模块端口状态的转换有一系列的限制。为什么要使用这样一套模型来做呢？我还不知道……在HSR计算环节，每个模块实例的代码可能被执行多次以获得最终状态。

最终内部状态是在这一步计算出来的。

End Of Timestep

上一步把最终状态计算出来了，但还没有更新到状态变量中来。这一步更新内部状态。结束这次的Timestep循环

 

下面再反思下整个过程

什么是内部状态？
它包括路由表、dynid、各种value、自定义变量等等，还包括emulator提供的数据。

哪些东西在开始被reset了？
注意，仅仅是signals被重置了，内部状态并没有被重置。这是我们进行连续计算的基础。

多个逻辑上并发的迭代地计算过程之间如果产生数据依赖该怎么办呢？
我猜测会发生信号无法解析的错误，不过不确定。
整个解析算法应该是利用图搜索的方式进行的，不断迭代，直到最终整个图状态稳定。

信号依赖的解决方案应该是怎样的呢？
以下是我的个人猜测：比如在Gate中，in、out信号明显依赖于门的控制点，在图搜索的过程中，会先计算出控制点的一个相对稳定值，然后再计算in、out值（in、out信号不受控制点控制的情况除外）。所以在设计的过程中我们需要注意这一点，以免产生信号无法解析的情况。

 

——

Way back into ….mist….