第六章逻辑结构设计小结
第六章逻辑结构设计小结
逻辑结构设计的要点：将概念模型按一定规则转换成关系数据库模型，它是一个过程。
涉及到的概念：
1.函数依赖：完全函数依赖，部分函数依赖，传递函数依赖2.关系模式的规范化：范式，1NF,2NF,3NF,BCNF3.属性集合的闭包4.最小函数依赖集
具体的规范化过程：从1NF开始，通过模式分解，逐步消除非主属性的部分函数依赖和传递函数依赖，达到3NF，消除主属性的部分函数依赖和传递函数依赖，达到BCNF。
问题一：在概念设计阶段，我们也许会把所有可能的问题都想到了，由此，就会生成许多的函数依赖，这些函数依赖是不是都是必需的，抑或是只要从中挑选出一些，然后再由这些去推导出全部就行？
答：我们选择后者，因为我们需要最简洁的表述，即求取最小函数依赖集Fc.P128其求取的步骤：p1435
(1)依次分解F中函数依赖的右侧属性为单属性；ABC==》AB,AC(2)消除F中冗余的函数依赖，只要证明消除该项函数依赖，不影响结果即可（如何证明？）
(3)依次去消除F中函数依赖左侧的冗余属性。AC,ABC以P143第5题第（1）为例，求解最小函数依赖集。
例：有关系模式R(A,B,C,D,E),F是R上的函数依赖集，求与R等价的最小函数依赖集。
F={BCD,CE,BE,DE,DBC}
步骤1：分解
F={BC,BD,BE,CE,DB,DC,DE}
步骤2：消除冗余依赖
BC求B+=BDECBD求B+=BEBE求B+=BDCECE求C+=CDB求D+=DCEDC求D+=DBEDE求D+=DBCEF={BD,CE,DB,DC}
步骤3：因为F中所有函数依赖的左侧属性均为单个属性，所以不存在冗余
问题二：如何证明去掉某项函数依赖后，不影响结果？
答：对XY,如果∈+{→}成立，则表示可以消除。即，去掉该函数依赖后，求得的属性X的闭包中仍旧包含了Y，则该函数依赖可以消除。R(U,F)
问题三：什么是属性X的闭包？P124
答：X是关于F的一个属性集，那么X的闭包就是记作+，X的闭包就是能由X(包含了X的子集)函数确定的所有属性的集合。如：XB,XC,+=XBCP1432
有关系模式
R(A,B,C,D,E,G,H),其函数依赖集为
F={ABC,CAH,HCD,ACDB,DEG,BHC,CGBD,CEAG}，求如下属性的闭包：(1)C+
初始化C+=C∵CAHC+=CAH
∵HCDC+=CAHDBEG整理一下：C+=ABCDEGH(2)(BD)+
初始化(BD)+=BD∵DEG(BD)+=BDEG(3)(EH)+
初始化(EH)+=EH(4)(ACD)+
(5)初始化(ACD)+=ACD(ACD)+=ACDHBEG
问题四、求得了最小函数依赖集后还能做什么？
答：求解候选码（也就是说，修行码也可以有相应的求解规则，而不是猜测得到的）
问题五：如何求解候选码？
1.先将现有的函数依赖集中的属性分成四类：P127(1)L类：仅出现在函数依赖的左部属性。(2)R类：仅出现在函数依赖的右部属性。(3)LR类：既出现在左部，又出现在右部的属性(4)NLR类：既不出现在左部，又不出现在右部的属性2.在上述基础上，给出两个划分规则：
规则一：将L类和NLR类放入集合K（K就是目标集合）规则二：R类属性一定不能出现在候选码中3.给出求解算法步骤：
(1)将L类和NLR类放入集合K；
(2)求K的闭包K+,若K+=U(U是所有属性的集合)，则输出K，算法结束，否则转步骤(3)
(3)依次将各个LR属性加入到集合K，重复步骤(2)由步骤(3)可以看出，候选码不唯一，也许有多个。
总结语：
有了候选码，就有了比较合理的函数依赖关系，水到渠成，可以进行关系模式的设计，当设计好相应的关系模式（关系表）后，还需要对它进行判断，若其规范化程度不高，会导致各种异常（插入异常，删除异常等），就需要进一步地模式分解，一般达到BCNF范式的程度就比较完美了。
有一个关系模式R，有函数依赖{BCDEFG,ABH}L类：B,ABNLR类：没有LR:没有B+=BCDEFGH(AB)+=ABHCDEFG
函数依赖{BCDEFG,ABH,ABB}
由于存在部分函数依赖，而2NF必须是消除了部分函数依赖的范式，该关系达不到2NF的标准，因此无法达到3NF的标准，所以R不是3NF.
（项目经理，机器）或者（机器，工程号）工程号项目经理，此函数依赖中没有包含以上任意一个候选码，所以达不到BCNF的级别
扩展阅读：逻辑设计心得
序
很早之前就想对这几个月工作经历写的东西，一是作为自己的总结，二是自己也很想将自己这段时间的一些经历和大家分享一下，希望对初学者而言能使得他们能少走一些弯路。只是公司里的事情很多，最近经常加班，所以一直拖到现在。
能来到这家公司应该是一种缘份--缘起NIOS。当初三月份altera来我们学校建立SOPC实验室的时候自己还不知道NIOS是什么东西，只是想在altera的FAE讲完NIOS后多问他几个时序约束的问题，然后拷一份PPT回去。但是想不到因为那一份NIOS的培训资料，我认识了edacn上的cawan，他给我讲了很多NIOS的东西，之后是丁哥在SOC版帖了位NIOS大赛的通知，然后我和队友就去报了名，并去川大参加了NIOS的培训，认识了峻龙的FAE----也是我现在的boss。在这里要谢谢cawan、丁哥、和我一起参加NIOS竞赛的队友刘科以及我的BOSS，是他们让我有了这一段的经历。
在公司里的几个月，做的项目其实不多，但是收获还是有一些，我觉得收获最大的是设计理念的改变，这也是我这段时间最想总结的，我会在后面逐渐阐述。时序是设计出来的
我的boss有在华为及峻龙工作的背景，自然就给我们讲了一些华为及altera做逻辑的一些东西，而我们的项目规范，也基本上是按华为的那一套去做。在工作这几个月中，给我感触最深的是华为的那句话：时序是设计出来的，不是仿出来的，更不是出来的。
在我们公司，每一个项目都有很严格的评审，只有评审通过了，才能做下一步的工作。以做逻辑为例，并不是一上来就开始写代码，而是要先写总体设计方案和逻辑详细设计方案，要等这些方案评审通过，认为可行了，才能进行编码，一般来说这部分工作所占的时间要远大于编码的时间。
总体方案主要是涉及模块划分，一级模块和二级模块的接口信号和时序（我们要求把接口信号的时序波形描述出来）以及将来如何测试设计。在这一级方案中，要保证在今后的设计中时序要收敛到一级模块（最后是在二级模块中）。什么意思呢？我们在做详细设计的时候，对于一些信号的时序肯定会做一些调整的，但是这种时序的调整最多只能波及到本一级模块，而不能影响到整个设计。记得以前在学校做设计的时候，由于不懂得设计时序，经常因为有一处信号的时序不满足，结果不得不将其它模块信号的时序也改一下，搞得人很郁闷。
在逻辑详细设计方案这一级的时候，我们已经将各级模块的接口时序都设计出来了，各级模块内部是怎么实现的也基本上确定下来了。
由于做到这一点，在编码的时候自然就很快了，最重要的是这样做后可以让设计会一直处于可控的状态，不会因为某一处的错误引起整个设计从头进行。做逻辑的难点在于系统结构设计和仿真验证
刚去公司的时候BOSS就和我讲，做逻辑的难点不在于RTL级代码的设计，而在于系统结构设计和仿真验证方面。目前国内对可综合的设计强调的比较多，而对系统结构设计和仿真验证方面似乎还没有什么资料，这或许也从一个侧面反映了国内目前的设计水平还比较低下吧。
以前在学校的时候，总是觉得将RTL级代码做好就行了，仿真验证只是形式而已，所以对HDL的行为描述方面的语法不屑一顾，对testbench也一直不愿意去学--因为觉得画波形图方便；对于系统结构设计更是一点都不懂了。到了公司接触了些东西才发现完全不是这样。
其实在国外，花在仿真验证上的时间和人力大概是花在RTL级代码上的两倍，现在仿真验证才是百万门级芯片设计的关键路径。仿真验证的难点主要在于怎么建模才能完全和准确地去验证设计的正确性（主要是提高代码覆盖），在这过程中，验证速度也是很重要的。
验证说白了也就是怎么产生足够覆盖率的激励源，然后怎么去检测错误。我个人认为，在仿真验证中，最基本就是要做到验证的自动化。这也是为什么我们要写testbench的原因。在我现在的一个设计中，每次跑仿真都要一个小时左右（这其实算小设计）。由于画波形图无法做到验证自动化，如果用通过画波形图来仿真的话，一是画波形会画死（特别是对于算法复杂的、输入呈统计分布的设计），二是看波形图要看死，三是检错率几乎为零。
那么怎么做到自动化呢？我个人的水平还很有限，只能简单地谈下BFM（busfunctionmodel，总线功能模型）。
以做一个MAC的core为例（背板是PCI总线），那么我们需要一个MAC_BFM和PCI_BFM及PCI_BM（PCIbehaviormodel）。MAC_BFM的主要功能是产生以太网帧(激励源），随机的长度和帧头，内容也是随机的,在发送的同时也将其复制一份到PCI_BM中；PCI_BFM的功能则是仿PCI总线的行为，比如被测收到了一个正确帧后会向PCI总线发送一个请求，PCI_BFM则会去响应它，并将数据收进来；PCI_BM的主要功能是将MAC_BFM发送出来的东西与PCI_BFM接收到的东西做比较，由于它具有了MAC_BFM的发送信息和PCI_BFM的接收信息，只要设计合理，它总是可以自动地、完全地去测试被测是否工作正常，从而实现自动检测。
华为在仿真验证方面估计在国内来说是做的比较好的，他们已建立起了比较好的验证平台，大部分与通信有关的BFM都做好了，听我朋友说，现在他们只需要将被测放在测试平台中，并配置好参数，就可以自动地检测被测功能的正确与否。
在功能仿真做完后，由于我们做在是FPGA的设计，在设计时已经基本保证RTL级代码在综合结果和功能仿真结果的一致性，只要综合布局布线后的静态时序报告没有违反时序约束的警告，就可以下到板子上去调试了。事实上，在华为中兴，他们做FPGA的设计时也是不做时序仿真的，因为做时序仿真很花时间，且效果也不见得比看静态时序分析报告好。
当然了，如果是ASIC的设计话，它们的仿真验证的工作量要大一些，在涉及到多时钟域的设计时，一般还是做后仿的。不过在做后仿之前，也一般会先用形式验证工具和通过静态时序分序报告去查看有没有违反设计要求的地方，这样做了之后，后仿的工作量可以小很多。
在HDL语言方面，国内语言很多人都在争论VHDL和verilog哪个好，其实我个人认为这并没有多大的意义，外面的大公司基本上都是用verilog在做RTL级的代码，所以还是建议大家尽量学verilog。在仿真方面，由于VHDL在行为级建模方面弱于verilog，用VHDL做仿真模型的很少，当然也不是说verilog就好，其实verilog在复杂的行为级建模方面的能力也是有限的，比如目前它还不支持数组。在一些复杂的算法设计中，需要高级语言做抽象才能描述出行为级模型。在国外，仿真建模很多都是用SystemC和E语言，用verilog的都算是很落后的了，国内华为的验证平台好像是用SystemC写。在系统结构设计方面，由于我做的设计还不够大，还谈不上什么经验，只是觉得必须要具备一些计算机系统结构的知识才行。划分的首要依据是功能，之后是选择合适的总线结构、存储结构和处理器架构，通过系统结构划分要使各部分功能模块清晰，易于实现。这一部分我想过段时间有一点体会了再和大家分享，就先不误导大家了规范很重要
工作过的朋友肯定知道，公司里是很强调规范的，特别是对于大的设计（无论软件还是硬件），不按照规范走几乎是不可实现的。逻辑设计也是这样：如果不按规范做的话，过一个月后调试时发现有错，回头再看自己写的代码，估计很多信号功能都忘了，更不要说检错了；如果一个项目做了一半一个人走了，接班的估计得从头开始设计；如果需要在原来的版本基础上增加新功能，很可能也得从头来过，很难做到设计的可重用性。
在逻辑方面，我觉得比较重要的规范有这些：
1.设计必须文档化。要将设计思路，详细实现等写入文档，然后经过严格评审通过后才能进行下一步的工作。这样做乍看起来很花时间，但是从整个项目过程来看，绝对要比一上来就写代码要节约时间，且这种做法可以使项目处于可控、可实现的状态。2.代码规范。
a.设计要参数化。比如一开始的设计时钟周期是30ns，复位周期是5个时钟周期，我们可以这么写：
parameterCLK_PERIOD=30;parameterRST_MUL_TIME=5;
parameterRST_TIME=RST_MUL_TIME*CLK_PERIOD;...
rst_n=1"b0;
#RST_TIMErst_n=1"b1;...
#CLK_PERIOD/2clkb.信号命名要规范化。
1)信号名一律小写，参数用大写。
2)对于低电平有效的信号结尾要用_n标记，如rst_n。
3)端口信号排列要统一，一个信号只占一行，最好按输入输出及从哪个模块来到哪个模块去的关系排列，这样在后期仿真验证找错时后方便很多。如：modulea(//inputclk,
rst_n,//globlesignalwren,rden,
avalon_din,//relatedtoavalonbussdi,//relatedtoserialportinput//outputdata_ready,
avalon_dout,//relatedtoavalonbus...);
4)一个模块尽量只用一个时钟，这里的一个模块是指一个module或者是一个entity。在多时钟域的设计中涉及到跨时钟域的设计中最好有专门一个模块做时钟域的隔离。这样做可以让综合器综合出更优的结果。
5)尽量在底层模块上做逻辑，在高层尽量做例化，顶层模块只能做例化，禁止出现任何胶连逻辑（gluelogic），哪怕仅仅是对某个信号取反。理由同上。
6)在FPGA的设计上禁止用纯组合逻辑产生latch，带D触发器的latch的是允许的，比如配置寄存器就是这种类型。
7)一般来说，进入FPGA的信号必须先同步，以提高系统工作频率（板级）。
所有模块的输出都要寄存器化，以提高工作频率，这对设计做到时序收敛也
是极有好处的。
9)除非是低功耗设计，不然不要用门控时钟--这会增加设计的不稳定性，在要用到门控时钟的地方，也要将门控信号用时钟的下降沿打一拍再输出与时钟相与。clk_gate_en------------
-----------------|DQ|------------------|\\gate_clk_out
||---------|)---------
------o|>|||/clk|--------|----------------------------------------
10)禁止用计数器分频后的信号做其它模块的时钟，而要用改成时钟使能的方式，否则这种时钟满天飞的方式对设计的可靠性极为不利，也大大增加了静态时序分析的复杂性。如FPGA的输入时钟是25M的，现在系统内部要通过RS232与PC通信，要以rs232_1xclk的速率发送数据。不要这样做：always(posedgers232_1xclkornegedgerst_n)begin...end
而要这样做：
always(posedgeclk_25mornegedgerst_n)begin...
elseif(rs232_1xclk==1"b1)...end
11)状态机要写成3段式的(这是最标准的写法)，即...
always@(posedgeclkornegedgerst_n)...
current_state3.ALTERA参考设计准则
1)EnsureClock,Preset,andClearconfigurationsarefreeofglitches.
2)NeveruseClocksconsistingofmorethanonelevelofcombinatoriallogic.
3)Carefullycalculatesetuptimesandholdtimesformulti-Clocksystems.
4)Synchronizesignalsbetweenflipflopsinmulti-Clocksystemswhenthesetupandholdtimerequirementscannotbemet.
5)EnsurethatPresetandClearsignalsdonotcontainraceconditions.
6)Ensurethatnootherinternalraceconditionsexist.7)Registerallglitch-sensitiveoutputs.
Synchronizeallasynchronousinputs.
9)Neverrelyondelaychainsforpin-to-pinorinternaldelays.10)DonotrelyonPower-OnReset.UseamasterResetpintoclearallflipflops.
11)Removeanystuckstatesfromstatemachinesorsynchronouslogic.其它方面的规范一时没有想到，想到了再写，也欢迎大家补充。如何提高电路工作频率
对于设计者来说，我们当然希望我们设计的电路的工作频率（在这里如无特别说明，工作频率指FPGA片内的工作频率）尽量高。我们也经常听说用资源换速度，用流水的方式可以提高工作频率，这确实是一个很重要的方法，今天我想进一步去分析该如何提高电路的工作频率。
我们先来分析下是什么影响了电路的工作频率。
我们电路的工作频率主要与寄存器到寄存器之间的信号传播时延及clockskew有关。在FPGA内部如果时钟走长线的话，clockskew很小，基本上可以忽略,在这里为了简单起见，我们只考虑信号的传播时延的因素。
信号的传播时延包括寄存器的开关时延、走线时延、经过组合逻辑的时延（这样划分或许不是很准确，不过对分析问题来说应该是没有可以的），要提高电路的工作频率，我们就要在这三个时延中做文章，使其尽可能的小。
我们先来看开关时延，这个时延是由器件物理特性决定的，我们没有办法去改变，所以我们只能通过改变走线方式和减少组合逻辑的方法来提高工作频率。1.通过改变走线的方式减少时延。
以altera的器件为例，我们在quartus里面的timingclosurefloorplan可以看到有很多条条块块，我们可以将条条块块按行和按列分，每一个条块代表1个LAB，每个LAB里有8个或者是10个LE。它们的走线时延的关系如下：同一个LAB中（最快）<同列或者同行<不同行且不同列。
我们通过给综合器加适当的约束（不可贪心，一般以加5%裕量较为合适，比如电路工作在100Mhz，则加约束加到105Mhz就可以了，贪心效果反而不好，且极大增加综合时间）可以将相关的逻辑在布线时尽量布的靠近一点，从而减少走线的时延。（注：约束的实现不完全是通过改进布局布线方式去提高工作频率，还有其它的改进措施）2.通过减少组合逻辑的减少时延。
上面我们讲了可以通过加约束来提高工作频率，但是我们在做设计之初可万万不可将提高工作频率的美好愿望寄托在加约束上，我们要通过合理的设计去避免出现大的组合逻辑，从而提高电路的工作频率，这才能增强设计的可移植性，才可以使得我们的设计在移植到另一同等速度级别的芯片时还能使用。
我们知道，目前大部分FPGA都基于4输入LUT的，如果一个输出对应的判断条件大于四输入的话就要由多个LUT级联才能完成，这样就引入一级组合逻辑时延，我们要减少组合逻辑，无非就是要输入条件尽可能的少，，这样就可以级联的LUT更少，从而减少了组合逻辑引起的时延。
我们平时听说的流水就是一种通过切割大的组合逻辑（在其中插入一级或多级D触发器，从而使寄存器与寄存器之间的组合逻辑减少）来提高工作频率的方法。比如一个32位的计数器，该计数器的进位链很长，必然会降低工作频率，我们可以将其分割成4位和8位的计数，每当4位的计数器计到15后触发一次8位的计数器，这样就实现了计数器的切割，也提高了工作频率。
在状态机中，一般也要将大的计数器移到状态机外，因为计数器这东西一般是经常是大于4输入的，如果再和其它条件一起做为状态的跳变判据的话，必然会增加LUT的级联，从而增大组合逻辑。以一个6输入的计数器为例，我们原希望当计数器计到111100后状态跳变，现在我们将计数器放到状态机外，当计数器计到111011后产生个enable信号去触发状态跳变，这样就将组合逻辑减少了。
上面说的都是可以通过流水的方式切割组合逻辑的情况，但是有些情况下我们是很难去切割组合逻辑的，在这些情况下我们又该怎么做呢？
状态机就是这么一个例子，我们不能通过往状态译码组合逻辑中加入流水。如果我们的设计中有一个几十个状态的状态机，它的状态译码逻辑将非常之巨大，毫无疑问，这极有可能是设计中的关键路径。那我们该怎么做呢？还是老思路，减少组合逻辑。我们可以对状态的输出进行分析，对它们进行重新分类，并根据这个重新定义成一组组小状态机，通过对输入进行选择(case语句)并去触发相应的小状态机，从而实现了将大的状态机切割成小的状态机。在ATA6的规范中（硬盘的标准），输入的命令大概有20十种，每一个命令又对应很多种状态，如果用一个大的状态机（状态套状态）去做那是不可想象的，我们可以通过case语句去对命令进行译码，并触发相应的状态机，这样做下来这一个模块的频率就可以跑得比较高了。
总结：提高工作频率的本质就是要减少寄存器到寄存器的时延，最有效的方法就是避免出现大的组合逻辑，也就是要尽量去满足四输入的条件，减少LUT级联的数量。我们可以通过加约束、流水、切割状态的方法提高工作频率。
友情提示：本文中关于《第六章逻辑结构设计小结》给出的范例仅供您参考拓展思维使用，第六章逻辑结构设计小结：该篇文章建议您自主创作。
来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
《第六章逻辑结构设计小结》
由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
http://m.bsmz.net/gongwen/577222.html
- 上一篇：中重型厂房结构设计小结
- 下一篇：结构设计大赛总结