这几天一直为这个问题头疼，几天终于解决了！可能快熬到头了或者是中午belinda给我带来的好运！反正是解决了~

出现问题是在所有的demux模块combination的过程中，原来每个模块的testbench验证表明ok；但通过的demux的testbench发现在功能仿真中，出现问题。

情况如下：

仿真开始后

# ** Fatal: (vsim-3603) Zero-delay oscillation loop detected at time 11175 ns.

通过查询verror 3603指令

verror 3603

#

# Message # 3603:

# The simulator detected a connectivity loop in the design that is

# oscillating due to the delays being zero, and the loop not settling

# out to a stable state. The pathnames to each instance in the

# connectivity loop should be displayed along with this message.

# The simulation cannot be continued after this error occurs.

这个解释说明，代码中出现了“死锁“现象，最主要是the loop not settling out to a stable state。说明存在0延时的震荡，是由于不能建立一个稳定的状态。但是如何查找呢？首先对testbench进行测查，修改之后发现只能改变出现问题的时间；看来和这个无关，再分析memory interface和datamux的部分，发现启动这两个模块就有问题。怀疑memory的FIFO，因为内部的双端口RAM是采用xilinx的

core generator生成的，因为潜意识里好像有人在论坛上说过类似PLL引起的问题。结果被误导，一无所获。今天仔细分析code和中断时的wave graph，终于发现问题所在。

这是memory 内部的状态：

该状态机的敏感量

always @(fifoRd_fsm or reset or

DemuxReq

)

fifoGrant:// complete one time cycleFIFO read of demux

begin

if( DemuxReq == 1'b0)

begin

DemuxGrant = 1'b0;

fifoRd_next_fsm = RdCounterAdd ;

end

else

DemuxGrant = 1'b1;

end

同时ES slice模块的一个状态：

该状态敏感量

always @(reset or ES_fsmor

ESRDGrant

or ESValid or ESRDValid or ESWRGrant or ESsliceValid )

CodeStartReq:// request

begin

if(ESRDGrant == 1'b1)

begin

ESRDReq =1'b0;

ES_next_fsm = prefixCodeDo;

end

else

ESRDReq = 1'b1;

end

这两个通过wire连接即ESRDgrant = demuxgrant;ESRDReq = DemuxReq。

同时跃迁的clk一样。

问题因此而产生，本来采用握手协议，保证数据可靠传输。

但由于潜意识减少状态变迁次数，采用了不成熟的代码风格。

导致

step1: DemuxReq =1;

则

Demuxgrant =1;// A fsm

step2:ESRDGrant = 1: // B fsm ,敏感量 ESRDGrant

则

ESRDReq =0;

step3: DemuxReq =0;// A fsm,敏感量 DemuxReq

则

Demuxgrant =0;

step4:ESRDGrant = 0: // B fsm ,敏感量 ESRDGrant

则

ESRDReq =1;

重新返回step1，构成loop；从而clk无法形成稳定的状态。

通过synplify分析发现,REQ和Grant信号都是有一个多路选择和锁存器构成，哦累了，下次再用RTL来分析