谢谢leadphone的耐心回答。
我按照你的建议查找了0x12回送包后的程序，没有发现什么问题。
我现在把它打印出来，请你帮我看看。我分解了一下：

（1）第一次get description
host请求包：

/---------------RX_FIFO0,setup request---------------------
the HEX COMMAND :80*06*00*01*00*00*40*00*
/---------------------in standard req handler------------------
NUM :6
in std dev get desc
in dev desc

设备第一次应答get description包：

The control buffer: the HEX COMMAND :12*01*10*01*00*00*00*08*

/----------------------In TX event-------------------------
The control buffer: the HEX COMMAND :00*04*5D*C3*00*01*01*02*

ALT 中断请求：

in alt event handler
the ALT MASK the HEX COMMAND :50*

the ALT VALUE the HEX COMMAND :4A*

in alt event handler
the ALT MASK the HEX COMMAND :50*

the ALT VALUE the HEX COMMAND :42*

in alt event handler
the ALT MASK the HEX COMMAND :50*

the ALT VALUE the HEX COMMAND :4A*

（2）set address 请求过程：
/---------------RX_FIFO0,setup request---------------------
the HEX COMMAND :00*05*02*00*00*00*00*00*
/---------------------in standard req handler------------------
NUM :5
in the dev set address
/----------------------In TX event-------------------------

（3）第二次get description 过程：

/---------------RX_FIFO0,setup request---------------------
the HEX COMMAND :80*06*00*01*00*00*12*00*
/---------------------in standard req handler------------------
NUM :6
in std dev get desc
in dev desc

第二次应该get description过程：
The control buffer: the HEX COMMAND :12*01*10*01*00*00*00*08*

/----------------------In TX event-------------------------
The control buffer: the HEX COMMAND :00*04*5D*C3*00*01*01*02*

/----------------------In TX event-------------------------
The control buffer: the HEX COMMAND :00*01*

/----------------------In TX event-------------------------
第二次应答的描述符包完毕。
in alt event handler
the ALT MASK the HEX COMMAND :50*

我查看了描述符的内容，发送的内容好像没有什么错误，而且。从
TX的事件处理程序来看，这些数据也是发送成功的。
leadphone帮我看看描述符包有什么问题。内容如上示，16进制表示，每字节用*号隔开，共18个字节。我想问一下，usb1.1的bcd数是：0x0110,还是0x0101呢。

get config出来了。
leadphone我想请教你一个问题。在原来9603的固件程序中，函数
usbn9604_rx_event_handler（）中，在标准请求处理分支中（switch）,有一句endpoint_stat[0]->toggle_bit =0x01；
为什么在这里要把toggle 位重置为1啊。是不是每次进行标准请求设置的时候，都要进行toggle的的重新同步啊。

set addr之后要发一个空包？为什么在9603的例程里面没看到这个步骤？在FAR里写完默认地址0x0和AD_EN之后就是FLUSH和ENABLE_RX0了，哪里有发空包？

USBN9603的文档中有介绍，如果你要发送的控制数据正好为8的倍数的话，那么在你发送完数据后，要发送一个zero length packet告知数据已经发送完了，如果不是8的倍数，那么usbn9603会根据寄存器中数据不足8（未填满发送缓冲区）来判断数据已经发送完。
在USBN9603的例子程序中,有一个数据结构来记录是否发送zero length packet,在tx_event_handler中会根据该记录来发送zero length packet，用usbn9603_tx_enable().
好好看看源代码（最好用source insight软件来看）

看来是我对USBN9604/9603的工作过程还是没有理解透彻了？
我的工作是要在FPGA上实现一个与USBN9604的接口，我的想法是这样的：FPGA上电之后，我写的模块就开始向USBN9604的寄存器里写一系列控制信息，也就是源代码里USBN9604_init()这个函数里做的事情，当USBN9604_init()里最后一步ATTACH_NODE做完之后，就可以等待9604发过来的中断了（代码里有个0到0xffff的延时需要吗？datasheet里好像没有要求吧）；我用的是查询方式来等待中断，隔段时间检查一下中断，如果有中断就去读MAEV这个寄存器，没有就继续等待...这个初始化工作过程是不是这样的？请各位指点！

get config出来了。
leadphone我想请教你一个问题。在原来9603的固件程序中，函数
usbn9604_rx_event_handler（）中，在标准请求处理分支中（switch）,有一句endpoint_stat[0]->toggle_bit =0x01；
为什么在这里要把toggle 位重置为1啊。是不是每次进行标准请求设置的时候，都要进行toggle的的重新同步啊。
 

是的

另：说实话，你打印的那些东西我看不太懂 :(也就看出个大概步骤来

看来是我对USBN9604/9603的工作过程还是没有理解透彻了？
我的工作是要在FPGA上实现一个与USBN9604的接口，我的想法是这样的：FPGA上电之后，我写的模块就开始向USBN9604的寄存器里写一系列控制信息，也就是源代码里USBN9604_init()这个函数里做的事情，当USBN9604_init()里最后一步ATTACH_NODE做完之后，就可以等待9604发过来的中断了（代码里有个0到0xffff的延时需要吗？datasheet里好像没有要求吧）；我用的是查询方式来等待中断，隔段时间检查一下中断，如果有中断就去读MAEV这个寄存器，没有就继续等待...这个初始化工作过程是不是这样的？请各位指点！

“代码里有个0到0xffff的延时需要吗？”，这个延时没有必要，你理解的初始化工作过程是对的，没有问题。

回楼上：那为什么我检测到中断后从MAEV里读出一个0x08出来，以上过程跟frame number有什么关系？