适于与柔性逻辑单元一起使用的通信接口的制作方法

1.本发明涉及一种电子系统，包括各种组件和/或单元，因此该电子系统可以称为异构系统。本发明的电子系统可以应用于电力系统数字控制领域，并且特别是针对(但不限于)要求硬实时和安全控制的纯电动或混合动力车辆电动马达的动力传动系的控制。


背景技术：

2.用于电力系统数字控制领域且特别用于控制纯电动或混合动力车辆电动马达的动力传动系的现有异构系统不能提供所需的硬实时和安全控制。
3.发明目的
4.本发明提供解决方案(的组合)以便利于在这些组件和/或单元之间的信息(数据)流动—否则可能由于其各自性质的多样性而受到损害。


技术实现要素：

5.本发明提供接口(的组合)以便利于在这些组件和/或单元之间的信息(数据)流动—否则可能由于其各自性质的多样性而受到损害。
6.本发明提供一种异构硬件系统(50)(80)，包括：(i)电子组件(10)、(50)；(ii)(iii)第一通信装置(40)(70)，适用于所述电子组件(10)和所述硬件可编程单元(20)之间的(至少单向)通信；所述异构硬件系统(50)(80)进一步包括：(iv)通信接口(30)、(60)，设置在所述第一通信装置(40)(70)和所述硬件可编程单元(20)之间，以支持所述电子组件(10)和所述硬件可编程单元之间经由所述第一通信装置的(至少单向)通信—因此是间接通信。
7.应强调以上组件、装置和接口都在同一芯片上。
8.在本发明的优选实施例中，作为可编程逻辑矩阵的硬件可编程单元(20)适于顺序执行至少两个任务，且因此在所述系统上执行(用户)程序期间发生任务切换。
9.在本发明的实施例中，第一通信装置(40)(70)适用于所述电子组件(10)和所述硬件可编程单元(20)之间的双向通信。
10.在本发明的优选实施例中，所述通信接口包括用于将待交换通信存储在队列中的一个或多个装置(150)、(130)、(210)、(220)。
11.在进一步优选实施例中，异构硬件系统包括一个或多个第二通信装置，适用于所述电子组件(10)和所述硬件可编程单元(20)之间的(至少单向)直接通信且设置在其间。
12.本发明被进一步指定用于具有柔性逻辑单元或flu的中央处理单元或cpu或类似单元，且还用于具有flu的外围单元，然而这些实施例可以以各种方式来组合。
13.在如图16中所示的第一组合中，实施例只是组合在一起，因此每个实施例经由各自的接口继续使用各自的总线，特别是这导致了如下异构硬件系统(300)，包括：(i)第一电子组件(10)，(ii)第二电子组件(53)；(iii)硬件可编程单元(20)，适于顺序执行至少两个任务；(iv)第一通信装置(40)，适用于所述第一电子组件(10)和所述硬件可编程单元(20)
之间的通信；(v)第二通信装置(70)，适用于所述第二电子组件(50)和所述硬件可编程单元(20)之间的通信；所述异构硬件系统(50)(80)还包括：(vi)第一通信接口(30)，设置在所述第一通信装置(40)和所述硬件可编程单元(20)之间，以及(vii)第二通信接口(60)，设置在所述第二通信装置(70)和所述硬件可编程单元(20)之间。
14.在图17中所示的第二实施例中，单元共享相同总线，导致如下异构硬件系统(300)，包括：(i)第一电子组件(10)，(ii)第二电子组件(53)；(iii)硬件可编程单元(20)，适于顺序执行至少两个任务；(iv)第一通信装置(40)(70)，适用于所述第一电子组件(10)和所述硬件可编程单元(20)之间的通信，所述异构硬件系统还包括：(v)第一通信接口(30)，设置在所述第一通信装置(40)、(70)和所述硬件可编程单元(20)(更具体地与其第一数据端口(320))之间，以及(vi)第二通信装置(60)，设置在所述第一通信装置(40)(70)和所述硬件可编程单元(20)(更具体地与其第二数据端口(310)，与所述第一数据端口不同)之间。
15.在本发明优选实施例中，如图18中所示预见一种另外的仲裁装置，这导致一种异构硬件系统(300)，包括：(i)第一电子组件(10)，(ii)第二电子组件(53)；(iii)硬件可编程单元(20)，适于顺序执行至少两个任务；(iv)第一通信装置(40)(70)，适用于所述第一电子组件(10)和所述硬件可编程单元(20)之间的通信，所述异构硬件系统还包括：(v)仲裁装置(340)，与所述硬件可编程单元(20)的数据端口(330)通信，(vi)第一通信接口(30)，设置在所述第一通信装置(40)、(70)和所述仲裁装置之间，以及(vii)第二通信接口(60)，设置在所述第一通信装置(40)、(70)和所述仲裁装置之间。
16.注意，所述仲裁装置的使用可以经修改后应用于图16中所示的实施例。
附图说明
17.图1涉及可以应用本发明方面的系统。
18.图2涉及本发明提供的虚拟存储器的延伸概念。
19.图3示意性地描述了(从)接口的概念。
20.图4提供了该(从)接口的可能示意图。
21.图5提供了该(从)接口的具体实现。
22.图6示意性地更详细地描述了与(从)接口的通信。
23.图7示意性地描述了在一个或两个方向上具有直接旁路的(从)接口的概念。
24.图8提供了这种(从)接口的进一步示意图，带有相关通信的指示(包括刷新信号的可选概念)。
25.图9示意性地描述了(主)接口的概念。
26.图10提供了该(主)接口的可能示意图。
27.图11示意性地描述了具有直接旁路的(主)接口的概念。
28.图12提供了该直接旁路的具体实现。
29.图13提供了该(主)接口的具体实现。
30.图14提供了具有直接旁路的该(主)接口的具体实现。
31.图15示意性地描述了在两个方向上具有直接旁路的(主)接口的概念。
32.图16示意性地描述了组合使用各自具有单独的总线的两个接口。
33.图17示意性地描述了组合使用共享总线的两个接口。
34.图18示意性地描述了共享总线且利用仲裁装置的两个接口的组合使用。
35.图19提供了在所述接口的一个芯片上的具体实现，带有包括直接旁路的flu和触发装置的概念。
36.图20提供了具有数据端口仲裁硬件的组合接口的具体实现。
37.图21描述了由本发明实现的有利操作。
38.图22描述了触发装置及其与flu的通信的具体实现。
具体实施方式
39.本发明涉及一种电子系统，包括各种组件和/或单元，因此该电子系统可以称为异构系统，更具体地本发明涉及该电子系统内的附加装置，以便利于上述组件和/或单元之间的信息(数据)流动—否则可能由于其各自性质的多样性而受到损害。
40.本发明的电子系统可以应用于电力系统数字控制领域，并且特别是针对(但不限于)要求硬实时和安全控制的纯电动或混合动力车辆电动马达的动力传动系的控制。
41.这种电子系统的特定实施例是fpcu类型的集成电路，具有诸如与“专用”子系统相结合的“标准”soc架构((一个或多个)cpu内核、互连、存储器、dma、通信外围设备)之类的特征，“专用”子系统包括一个或多个efpga矩阵(称为柔性逻辑单元或flu)，例如且优选地具有快速任务上下文切换能力和/或动力传动系就绪外围设备。
42.在这样的系统中，仔细处理flu、外围设备和/或cpu之间的i/o通信非常重要，以便在并行性和硬实时性方面充分利用efpga计算能力。
43.本发明特别适用于处理fpcu组件负责多个并发应用(逆变器控制、dcdc控制、adas决策)的情况。出于功能安全的原因，每个应用都必须使用虚拟化机制进行“沙箱化”，以避免各应用之间发生干扰。
44.更一般地说，本发明涉及一种异构硬件系统，包括：(i)至少一个电子组件；(ii)硬件可编程单元，其是可编程逻辑矩阵，以及(iii)便利于所述电子组件和所述单元之间通信的通信接口，其中所述电子组件是(a)软件可编程单元，优选为微处理器内核或图形或类似处理器内核，或(b)所述电子组件是外围硬件单元。
45.在fpcu架构的上下文中，我们可以区分两种外围设备：
46.‑“
系统接口外围设备”47.○
这些专用于来自(到)外部系统的流应用数据。
48.○
其作用是从(向)系统级使用的物理传输协议中提取(封装)“有效载荷”数据。
49.‑“
处理加速器”50.○
这些是完全fpcu内部的
51.○
其作用是加速复杂的数学运算。
52.值得注意的是，软件可编程单元和硬件可编程单元(分别是cpu/gpu、flu组件)负责执行完全由最终用户定义的功能(即：可编程)，而外围设备则提供一组预定义且优化的功能。
53.上下文不可知触发
54.在优选架构中，许多“触发”信号在外围设备、dma和flu之间传输，以执行其中不同
功能的同步和排序。因此，flu能够接收多个触发输入以供内部使用。实际上，每个触发可以与在flu中执行的上下文切换任务之一相关联。问题是触发信号是上升沿。触发发射器应保证触发足够长，能持续至少一个flu时钟周期，这样才可以正确地采样上升沿。但是此时，由于上下文切换到另一个任务上，目标flu映射的任务可能在flu中不活动。因此，触发事件可能会丢失。本发明还提供额外的解决方案来解决这个问题。
55.用于安全和虚拟化的flu任务识别
56.虚拟化的概念已经广为人知并广泛用于在cpu内核上运行的软件。在fpcu组件的概念中，固件的一部分实际上作为flu映射的功能运行。因此，必须将虚拟化机制扩展到flu。事实上，要解决的问题是确保在flu中执行的任务不能访问超出其允许范围的存储器映射区域。从系统的角度来看，存储器映射访问权限是通过软件配置的多层存储器保护单元(mpu)来管理的。当flu在属于不同应用的多个任务之间进行快速上下文切换时，必须使硬件机制就位，以自动处理这些任务的“沙箱化”，因为cpu不知道切换时间，而且它也不够快。因此，cpu软件无法在关于flu任务切换的正确时刻重新配置mpu。
57.需要强调的是，该系统可以包括多个所述电子组件(无论是软件可编程还是外围单元)；硬件可编程单元，以及通信接口，用于便利于每个所述电子组件和所述单元之间的通信。
58.本发明将首先针对软件可编程单元的上下文进行描述，然后针对外围单元进行描述，从而可以解决这些上下文中的每一个的特殊性。在此阶段，只需说明两种上下文可以作为组合出现在一个系统中，并且所提供的解决方案确实具有我们将在本说明末尾讨论的共性，就足够了。
59.总地来说，本发明可以被描述为异构硬件系统(50)，包括：(i)电子组件(10)；(ii)硬件可编程单元(20)，其是可编程逻辑矩阵；(iii)第一通信装置(40)(70)，适用于所述电子组件(10)和所述硬件可编程单元(20)之间的(双向)通信；所述异构硬件系统(50)(80)进一步包括：(iv)通信接口(30)，设置在所述第一通信装置(40)(70)和所述硬件可编程单元(20)之间。
60.部分a与cpu或类似组件组合的柔性逻辑单元
61.如上所介绍的，考虑的目标系统是fpcu。这尤其意味着集成电路中存在一个(或多个)cpu内核以及一个(或多个)flu(efpga)矩阵。在这种情况下，要求cpu可以与映射在flu中的功能进行通信。为此，使用常规soc互连总线，其中cpu为主，flu为从。图1左侧示出了示例性实施例。
62.现在考虑flu矩阵，其能够(非常快速)任务切换。这意味着，在分时的基础上，flu矩阵执行多个独立的任务，如图1中右侧所示。任务切换触发可以由硬件管理。因此，软件永远不会知道在任何时间点flu中实际运行的是哪个任务。因此，当cpu尝试对flu进行读取/写入总线访问时，其没有办法确保实际上访问了期望的任务。
63.针对上述问题的本发明解决方案如图2和图5中所示。
64.这些解决方案创建了flu和软件计算单元之间紧密的交互，因此flu被视为“好像”它是计算单元本身的一部分，因此能够扩展计算单元指令集，其中用户定义的功能由flu来执行。
65.虚拟存储器映射的概念适于：对于cpu任务，或更准确地说对于分配给所述任务的
数据，在flu中运行被表示为分离的存储器位置。
66.每个flu任务与唯一标识符(任务id)相关联。这种识别是在编程时完成的，其是软件架构决策。
67.在flu从接口中，一些系统总线存储器映射区域被预先分配给可以在flu中执行的每个任务。假设系统存储器映射是以cpu有效访问这些区域的方式完成的。
68.每个flu任务存储器映射区域之间的“偏移”在设计时是固定的(硬编码)。
69.从cpu软件的角度来看，每个flu任务寄存器组可以通过不同的地址范围独立地访问。
70.可在图3和图6中更概括性地认识到异构硬件系统，该异构硬件系统包括：软件可编程单元，可编程逻辑矩阵，适于或能够顺序执行至少两个任务，由此任务切换不受所述软件可编程单元控制而是在硬件控制下；(iii)第一通信装置，适用于(但仅以间接方式用于)所述电子组件和所述硬件可编程单元之间的通信；所述异构硬件系统还包括：通信接口，设置在所述第一通信装置和所述硬件可编程单元之间，所述通信接口适于确保对所述硬件可编程单元内部的数据的访问对应于其中执行的对应任务。
71.现在更详细地讨论接口的各个子部分，并在图4和图5中示出了该各个子部分。
72.接口的第一部分是系统总线接口。这可以是使用公共总线协议(如apb)的现有技术从接口。接口的第二部分是flu存储器映射解码器，它基于之前描述的“虚拟”存储器映射原理，确保来自cpu的每次访问被解码并关联到其对应的任务id。被称为访问请求队列的第三部分累积来自前一个块的访问请求，直到它们由flu访问控制器处理。每个请求包括：
73.●
目标flu任务id，标识cpu想要访问的功能。
74.●
flu任务寄存器地址
75.●
读取/写入命令
76.●
写入数据(在写入命令的情况下)
77.第四部分是flu访问控制器。
78.在任何时候，该模块从flu内核接收flu内部正在执行的有效任务的标识符。
79.只要访问请求队列中有访问请求可用，就会将flu任务id与请求目标id进行比较。如果两者相等，则执行以下序列：
80.●
flu访问控制锁定flu切换。这对于防止在后续步骤期间执行任何任务切换以避免访问损坏是必要的。
81.●
执行请求的寄存器访问
82.●
推送到“访问响应队列”时的访问响应
83.●
flu切换锁被解除
84.请注意，flu请求可以以乱序的方式处理：
85.●
如果对任务#0的多次访问与对任务#1的访问交错，则控制器可以被配置为处理对任务#0的所有访问，不考虑其相对于对任务#1的访问的排序。
86.最后的第五部分是访问响应队列。
87.●
所有flu访问响应排队等待cpu来检索它们。
88.●
生成对cpu的irq通知以通知软件请求响应可用。
89.在这个阶段，有几个方面值得强调。
90.回想本发明解决了由与所述电子组件的操作异步的任务切换机制引起的数据问题。
91.此外，以上阐述了如下实施例，其中解决了从cpu到flu的通信以及反向通信。可以想象编程上下文，其中以上提及的问题在这些方向之一中发生或仅在这些方向之一中严重，且类似地接口可以限于通信方向之一。
92.然而两个方向的共同点是所述通信接口包括一个或多个装置，用于将待交换通信存储在队列中。
93.同样如图6中所示的通信接口，更具体地说是第四部分，表示为flu访问控制器，适于(参见(500))在访问所述硬件可编程单元内的所需寄存器的同时将所述硬件可编程单元锁定到任务，并在此后解锁。
94.同样如图6中所示的通信接口，更具体地是表示为访问响应队列的最后的第五部分，适于(参见(510))向cpu提供通知以通知软件请求响应可用。
95.注意，通信接口也是硬件单元。其也可以实现为单独的flu，但在优选实施例中使用专用电路。
96.最后，因此本发明涉及一种适用于上文概述的异构硬件系统的接口，其适于确保对所述硬件可编程单元内的数据的访问对应于在其中执行的对应任务，所述通信接口包括用于将待交换通信存储在队列中的一个或多个装置，并且适于在访问所述硬件可编程单元内所需寄存器的同时将所述硬件可编程单元锁定到任务且然后解锁，和/或适于向cpu提供通知以通知软件请求响应可用。该接口还具有存储器映射解码能力，用于将所述电子组件所需的访问链接到对应任务，所述链接基于虚拟存储器原理。
97.触发
98.再次考虑flu处于任务切换操作上下文中，并且对于系统来说触发或触发信号可用，触发或触发信号是fpcu的元件之间的事件信号(这是对仅适用于cpu的irs概念的概括)。
99.尽管这些触发可以由flu映射的任务为其自身目的来采样，问题是触发根据定义是暂时的。这意味着触发的接收器必须永久“监听”以确保它不会错过事件。在上下文切换情形下，对于flu任务来说显然不是这种情况。
100.因此，接口的作用是永久“监听”触发，并每当有效监听时就将触发转发给flu任务。因此，接口以如下装置得以扩展，该装置对于每个触发输入线与“触发任务id”信息相关联，该信息被配置为指定到来的触发应该应用于哪个flu任务。
101.1.如果flu执行的任务id与该目标id匹配，则发送触发脉冲，不做任何改变
102.2.否则，触发脉冲维持有效，直到flu切换回指定的目标任务id。
103.在接下来的部分中描述与柔性逻辑单元与外围单元的组合相关的特定实施例之前，值得注意的是，如果需要，先前描述的实施例也可以与这样的外围单元一起使用。
104.部分b与外围单元组合的柔性逻辑单元
105.在目标fpcu系统中，子系统以许多采集外围设备和数学加速器来定义—其旨在为flu映射的功能提供稳定的数据流。在现有技术架构中，所有外围设备可以经由图1中底部所示的交叉开关(crossbar)上的一个(或多个)系统总线主端口来访问。这种架构在灵活性和硬件复杂性方面很方便。然而，其有一些固有限制，这对于硬实时应用来说是个大问题：
106.●
对系统总线的“读取访问”需要至少两个时钟周期。因此，不可能在每个时钟周期为flu映射的任务馈送新的传感器数据。
107.●
除了flu本身之外，系统总线架构与其它主设备(如cpu和dma)共享或可以共享，这可能会通过引入意外的等待状态来干扰flu事务。因此，应用设计人员必须提供时间裕度以保证实时约束。这是对计算资源的不可接受的浪费。
108.部分b.1与外围单元组合的柔性逻辑单元—直接访问
109.在本发明的一个方面，关键数据源寄存器在外围设备中被识别(示例：adc样本数据寄存器)。所有这些被收集起来，作为一个(或多个)多路复用器的输入。因此，这些寄存器的值在多路复用器的输入端始终可用。多路复用器的选择由flu内的功能控制。所以flu功能可以在每个时钟周期得到不同的关键输入数据。不使用系统总线，因此直接通道上没有虚假的等待状态。
110.实质上，这里我们考虑如图1中左下角所示的异构硬件系统，其包括：(i)电子组件，其是之前定义的(soc)外围硬件单元，优选地是多个所述外围硬件单元，可选地专用于电动引擎控制单元硬件功能；(ii)硬件可编程单元，其是可编程逻辑矩阵，适于顺序执行至少两个任务，由此工作频率比外围硬件单元的工作频率慢；
111.在如图11、图12、图14中所示的本发明的该方面中，除了以下通常的第一通信装置(总线)之外，该第一通信装置适用于所述电子组件和所述硬件可编程单元之间的通信，具有或不具有所进一步讨论的特定接口支持，异构硬件系统还包括一个或多个第二通信装置，该第二通信装置适用于所述电子组件和所述硬件可编程单元之间的通信且设置在它们之间，更具体地，所述多个第二通信装置连接到由所述硬件可编程单元控制的选择装置(多路复用器)。
112.部分b.2与外围单元组合的柔性逻辑单元—接口
113.除了以上提及的问题外，典型的电动引擎控制应用通常需要“同时”更新多个pwm通道占空比(即，在flu中运行的控制算法的一个时钟周期内)。理论上，由于efpga和系统总线之间的工作频率差异，如果flu总线主端口具有宽数据端口，则可以处理这种情况。参见图21。
114.示例：假设需要各自以16位数据更新4个pwm通道。在这种情况下，可以想象flu上的64位数据主端口在系统总线上“突发”执行，其实际上在4个pwm上执行了4个连续的16位写入访问。
115.不幸的是，在现有技术的soc存储器映射中，pwm配置寄存器通常不是连续的。因此，不可能通过系统总线“突发”事务来管理传输。
116.为了解决上述问题，如图13中所示且在图9中更概括性定义了另一特定接口。本发明的该方面可以与如图14和图11中所示地在前面讨论的直接访问设施相结合。
117.一般而言，公开了一种异构硬件系统，包括：(i)电子组件，其是(soc)外围硬件单元，优选为多个所述外围硬件单元，可选地专用于电动引擎控制单元硬件功能；(ii)硬件可编程单元，其是可编程逻辑矩阵，由此工作频率比外围硬件单元的工作频率慢；(iii)第一通信装置(70)，适用于所述电子组件和所述硬件可编程单元之间的通信；所述异构硬件系统(80)还包括：(iv)通信接口，设置在所述第一通信装置和所述硬件可编程单元之间，所述通信接口适于确保从所述硬件可编程单元到(所述多个)所述外围硬件单元的数据传输在/
可以在一个时钟周期内和/或来自所述(所述多个)所述外围硬件单元的数据传输能够实现硬实时调度。
118.表示为flu主接口的接口包括表示为(一个或多个)请求队列的第一部分。flu功能不是像apb或axi那样具有常规总线协议主接口，而是简单地在主接口模块上发布读取/写入访问请求。一个发布正好持续flu时钟的一个时钟周期。由于flu在相对于系统时钟相对低的频率下工作，其不需要得到请求确认，因此flu功能没有协议背压。
119.还表示为数据传输要求或描述符的每个队列传输请求包括(至少)：
120.●
传输描述符id
121.●
命令(读取/写入)
122.●
写入数据(如果写入请求)
123.所有请求以fifo排队以供事务管理器进一步处理。
124.主接口模块的第二部分表示为传输描述符，并具有本地存储器(ram)，本地存储器(ram)可以由软件用传输描述符对象列表填充。
125.每个描述符(至少)包括：
126.●
描述符id
127.●
命令(读取/写入)
128.●
指定要执行的传输的次数的整数(transnum)
129.●
以字节为单位指定每次传输的数据宽度的整数(transwidth)
130.●
存储器映射基地址列表(每次传输一个)
131.由于传输描述符，可以将来自flu的单个传输请求转变为在不连续地址位置的多个分开的系统访问。
132.示例：
133.再次使用以下示例：以各自的16位占空比信息更新4个pwm通道。假设flu具有到flu主接口模块的64位数据端口。
134.在这种情况下，cpu软件将初始化传输描述符，该传输描述符指定4个每次16位的传输。对于这些中的每一个，在传输描述符中也编程特定的存储器映射地址。
135.当flu任务需要更新4个pwm时，它会发布写入请求，其中四个16位数据串联在64位端口上并与以上传输描述符id相关联。
136.然后主接口将使用传输描述符信息在4个给定地址处执行四个连续的16位总线写入事务。
137.接口的第三部分是事务请求管理器。每当请求队列中存在请求时，管理器执行以下操作：
138.●
检索与请求的id匹配的传输描述符。
139.●
根据传输描述符信息将请求切分成多个原子传输。
140.●
将每个请求推送到总线接口队列。每个请求由以下组成：
141.○
请求传输描述符id
142.○
存储器映射地址
143.○
命令(读取/写入)
144.○
数据字节启用和相关联写入数据(如果写入访问)
145.接口的第四部分是总线接口队列。
146.●
在总线事务协议中转变原子请求
147.●
在读取访问的情况下，读取数据被推送到具有相关联的传输描述符id的读取队列
148.接口的最后的第五部分是读取数据队列。每当读取队列中有读取数据可用时，flu主接口执行以下操作：
149.●
其在flu输入端口上设置读取数据和相关联的描述符id。
150.●
数据维持正好一个flu时钟周期。
151.●
其不等待来自flu的任何确认(flu算法是硬实时的，因此假设其在时钟周期具有可预测的行为)
152.●
使用描述符id，flu能够识别发起数据的请求。
153.请求队列管理器可以以两种模式来配置：
154.●“
立即”：在这种模式下，请求被尽快处理
155.●“
突发”：在这种模式下，请求被将保留在队列中，直到flu触发“刷新”事件。
156.在这个阶段，有几个方面值得强调。
157.此外，以上阐述了如下实施例，其中解决了从外围单元到flu的通信以及反向通信。可以想象上下文，其中以上提及的问题在这些方向之一中发生或仅在这些方向之一中严重，且类似地接口可以限于通信方向之一。然而两个方向的共同点是所述通信接口包括一个或多个装置，用于将待交换通信存储在队列中。
158.请注意，该通信接口也是硬件单元。它也可以实现为分开的flu，但在优选实施例中使用专用电路。
159.特定组合
160.部分a(图3和图5)中描述的flu从接口的引入和部分b.2(图9、图13和图14)中描述的flu主接口的引入可以如图16、图17和图18中所示地组合，部分b.2(图9、图13和图14)中描述的flu主接口的引入示出与图12)的直接访问概念的进一步组合。
161.如上所述，本发明描述了仅具有主接口或从接口的实施例，也描述了具有主接口和从接口但各自分开的实施例，如图16和图17的实施例所示。
162.这些架构提供了flu输入/输出数据流中的最佳吞吐量性能。然而，其就efpga接口而言非常消耗，因为事务数据端口是分开的。
163.在图18和图20的实施例中，主从接口功能仍基本相同，除了它们共享相同的读取/写入数据接口之外。这需要额外的“仲裁器”功能来管理两个接口之间的访问优先级。
164.关于仲裁功能，值得强调的是flu容量是有限的，且优选地将其中大部分保留给“真实”客户算法。这意味着flu中的接口管理逻辑对客户来说总是损失计算资源。从flu的角度来看，本发明接口中或用于本发明接口之组合的仲裁功能特别有助于使flu中的接口尽可能简单。实质上，flu应优选地对管道、突发、未决请求
……
没有要求。所有这些特征使系统总线接口变得复杂并需要大量资源。
165.请注意，通常主接口概念是基于这样的理解，即flu应总是比主接口和系统总线运行慢得多，因此，如果分开的flu主接口模块处理与事务请求确认相关的复杂性，则该flu主接口模块会可用。这对于在flu中节省资源来说是重要的。因为请求/确认序列的管理需要
大量资源(状态机、数据缓冲)。此外，其会在硬实时处理方面引入潜在的不确定性，因为客户必须对请求/确认序列可能引起的最大数量的等待状态做出一些最坏情况假设。
166.请注意，部分b.2中描述的直接访问的概念也可以应用于部分a的上下文，如图7中一般性所示。
167.进一步的考虑
168.队列尺寸
169.如在本发明的优选实施例中提到的，所述通信接口包括一个或多个装置(150)、(130)、(210)、(220)，用于将待交换通信存储在队列中。
170.值得详细说明一些深度计算标准：
171.‑
在从接口上(在cpu
‑
flu上下文中使用)
172.○
fifo的深度可以指定为等于互连总线协议允许的事务“突发”中的最大字数。
173.■
apb示例：突发不存在(因此，深度＝1)
174.■
ahb示例：突发长度最大为19(因此，深度＝16)
175.■…
176.‑
在主接口上(在外围设备
‑
flu上下文中使用)
177.○
至少，像从接口一样对其进行计算
178.○
此外，其必须至少等于“可刷新”数据尺寸的数量。该尺寸受flu和互连总线之间的工作频率比的限制。
179.接口的实现
180.如所提及的，接口优选地是专用电路或硬连线的。原则上，接口可以放在硬件可编程单元或flu中。但是，请记住，与可以映射到内部的实际功能相比，efpga矩阵非常大。这意味着我们确实尝试为用户应用保留flu区域。因此，任何定义明确且足够通用的硬件功能都必须尽可能地硬连线(如此处情况)。
181.刷新功能
182.如图14中所示，可以预见刷新功能的可能性。
183.可能的用例如下：
184.○
设想一个配置，其中外围设备以100mhz工作，并且flu以10mhz工作。
185.○
通常，在运行马达控制算法时，期望在所有pwm通道上“同时”更新pwm占空比。
186.○
在我们的例子中，“同时”意味着“在控制算法的一个时钟周期内)
187.○
如果考虑4相马达，这意味着flu必须通过主接口向pwm外围设备写入4个数据
188.○
所以，在任何情况下，flu都需要4个时钟周期来写入这些数据
189.○
如果没有实施“刷新”功能，那么每次写入几乎立即被传输到pwm(因为接口比flu快10倍)。
190.因此，pwm不在单个flu时钟周期内被更新。
191.○
如果有“刷新”功能，序列如下
192.■
flu算法被设计为其预计pwm更新时间为5个周期
193.■
flu需要4个周期来写入pwm数据(这些被以fifo填充，但不传输到互连)
194.■
flu触发“刷新”请求
195.■
然后主接口逐个地刷新fifo请求。但是，由于10倍的频率比，4个事务可以在一
个flu时钟周期内轻松进行。
196.如图8中所示，还可以在从接口中添加刷新功能。