Update readme.md

Author: flymin

readme.md

@@ -30,7 +30,7 @@ BRAM部分使用了类似内存管理中页表的结构，即将BRAM索引的高
 
 Figure 2：weight索引方式示例
 
-采用这样的索引方式主要是由于BRAM的存储资源不足，无论是weight还是data或者result，片上的BRAM资源都无法满足单层运算存储这个最基本的要求，但这些数据访存都具有连续性，因此采用这样的方式，并设置存储器自主管理和PS的交互，这样只需要使用一个17位深度的BRAM（即32片）就可以满足要求，这也是在现有资源的前提下的最大存储深度（32\*4=128\<144）。
+采用这样的索引方式主要是由于BRAM的存储资源不足，无论是weight还是data或者result，片上的BRAM资源都无法满足单层运算存储这个最基本的要求，但这些数据访存都具有连续性，因此采用这样的方式，并设置存储器自主管理和PS的交互，这样只需要使用一个17位深度的BRAM（即32片）就可以满足要求，这也是在现有资源的前提下的最大存储深度 ![](http://latex.codecogs.com/gif.latex?(32\*4=128\<144)) 。
 
 功能实现
 --------
@@ -69,11 +69,9 @@ Figure 2：weight索引方式示例
 
 以上分析的目的是希望设计出一个基本的计算单元（乘加器）。考虑到当前FPGA片上的DSP资源只有220个，因此不可能一次性计算出一个卷积核（所有通道），而为了拆解计算时方便数据整理，这个计算单元需要尽可能的被计算尺寸整除。考虑到单个卷积核（3\*3）的计算是不可拆解的，因此计算单元的尺寸应为：
 
-$$
-3 \times 3 \times n
-$$
+![](http://latex.codecogs.com/gif.latex?3\times{3}\times{n})
 
-观察数据，最终选择$$n = 16$$作为计算单元的大小。使用这个计算单元，可以最大程度的利用DSP资源在一个周期内并行完成144\*144个数据的乘加计算，具体到各层，见表格 3。
+观察数据，最终选择![](http://latex.codecogs.com/gif.latex?n=16)作为计算单元的大小。使用这个计算单元，可以最大程度的利用DSP资源在一个周期内并行完成144\*144个数据的乘加计算，具体到各层，见表格 3。
 
 表格 3：计算单元复用说明
 
@@ -168,8 +166,7 @@ Figure 8：DSP仿真结果
 
 Figure 9：计算单元仿真结果
 
-计算单元一个周期内完成的运算规模为$$3 \times 3 \times 16 = 144Byte =
-1152bits$$的运算，而相应方式和单个DSP的响应时序相同，这一点在仿真结果中可以得到验证。因此，实际应用时，也需要延迟一个周期读取结果才能得到正确的结果。为了实现这一点，在所有引用计算结果的地方都引入了delay信号用来延迟读取设计。
+计算单元一个周期内完成的运算规模为![](http://latex.codecogs.com/gif.latex?3\times{3}\times{16}=144Byte=1152bits)的运算，而相应方式和单个DSP的响应时序相同，这一点在仿真结果中可以得到验证。因此，实际应用时，也需要延迟一个周期读取结果才能得到正确的结果。为了实现这一点，在所有引用计算结果的地方都引入了delay信号用来延迟读取设计。
 ```python
 if(times >= InWidth/(`datachannel*`K_size*`K_size))
 begin