3 COB模型—一种数据空间下的描述方式

        COB模型为Class-Object& Block模型的简称，意义为将问题描述抽象为动力与作用两个层级，建立动力层与作用层中关键变量的映射属性。参考面向对象的方法去定义Class和Block，通过实例化的Class对象Object来建立具体的Object动力，通过变量链接到作用层，实现我们的设计期望。COB模型的实现依赖于数据空间的一个固有特性——映射链接属性，也是因为这样，让我们开始认识到在数据空间下可以做出一些在传统的软件空间或者电路空间难以想到且不容易做到，但又能明显丰富和拓展产品功能的事情。而这就是我们一直等待的变化，恍惚突然进入了一个全新的空间，一些本来以为很复杂或者纠结的功能，开始变得是那么的顺其自然，到处都是惊喜，到处到妙不可言，如同凡夫俗子被打通了任督二脉，注入了盖世神功一般。关于COB模型诞生的始末，在此把故事好好说说。

        前面说到，把问题放在数据空间中描述，实现Hltc是迈开的第一步，那么数据空间该如何去描述问题呢？问题又该采用怎样的模型在数据空间中表现呢？在实现Hltc之初，其实我还没有比较明确的答案。那时我也不清楚到底采用数据空间来描述问题会产生怎样的形态或者不同点在哪里。只是感觉上十分认同这样的一种思想，便义无反顾往后面走了。开始认真思考这个问题是在2016年5月末的时候，成功实现了Hltc给予了我极大的动力，迫不及待要尝试采用这个新家伙去小试小试牛刀。因此，关于Halim设想的实现，迈开的第二步便是，寻找一个能够充分表现数据空间优势的问题描述模型。

       第一版本的Hltc的深度只有80*8bit的大小，也即80个字节的空间。要用仅仅80个字节来定义气体控制器的全部功能，那时心里也没底。一开始的做法是把定义第一版气体控制器功能需要的全部变量确定下来，同时确定每个变量的数据类型，即变量占用的字节长度，最后统计结果是78个字节，采用手动编址的方式进驻Hltc，勉强可以描述。考虑到可能需要进一步细化控制器的描述，又或者后面可能存在轻易被空间约束描述完备性的情况，只有80深度的Hltc必然是瓶颈。于是进一步优化了Hltc的Verilog代码，成功把空间拓展到91个字节，同时也优化气体控制器的数据描述，需要的字节也增长到88个字节。下图是第一次Halim架构下的气体控制器的数据空间下的描述 - HG1（Halim Gasloop 第一版）。

        基于HG1，通过逐个建立各功能的电路解析板，在一个月的时间里，即在2016年7月初，我们在完整数据空间的描述下，成功实现了气体闭环控制器的期望功能，即原来第一版控制器全部功能在Halim新框架下成功恢复。关于如何建立各功能电路解析板，这里不详细说，后会逐一谈到。就在这个节点，这个小目标的实现具有重要意义，起码证明了Halim的设想是能够应用在实际的，另外，思想本身能够走通等于给我们吃了一颗定心丸。

       纵然HG1让我们恢复了老版本的功能让人的确有几分激动，但是，如果说只能做到这样，结果毫无疑问是让人沮丧的。当然，Halim不可能只能走这么一点点就到尽头了，反而相反，这仅仅是只是开始，只要根基被确认可靠，那我们便能自由在上面构建新大厦了。因此，很明显，事情还没有完。细致斟酌，HG1虽然实现了功能，但是并没有充分表现出数据空间描述的优势。

       HG1最少面临着两朵乌云，一是，关于控制器的描述变量是一个确定的描述方式，就是把老版本的结构变量独立在Hltc之中，借用空间变换的思想将局部数据变换到电路空间之中，从而驱动整个控制器功能的实现，Hltc只是充当多口RAM的作用，虽然这是Hltc的本份属性，但是如果只能这样用，显然让人有点失落；二是，变量是通过手动编址的方式进驻Hltc的，变量的地址在设计的时候，就要被规定和固化，如果设计要发生变更或者需要插入新的描述，那必然是牵一发动全身，和原来第一版本控制器面临着同样的风险，这样关于Halim的设想便是多此一举，这是致命的。所以，HG1并不是我们期待的问题描述模型，我们必须寻找新的描述模型，重建数据空间下的描述方式。于是，在纠结了大约两个星期之后，就在2016年8月初，COB模型被整理出来。

        COB模型克服了HG1面临的两朵乌云，一是引入了变量映射链接属性，这是数据空间下的一种重要特性，二是实现动态地址方法进驻Hltc。为了实现COB模型，Hltc再一次被优化到256*8bit深度。关于COB模型更多，我们下篇继续。

（未完待续）