Seamlessly integrated microcontroller chip

Abstract

Techniques in electronic systems, such as in a system with a CPU die and one or more external mixed-mode (analog) chips, may provide improved advantages in one or more of system design, performance, cost, efficiency, and programmability. In one embodiment, the CPU die includes at least one microcontroller CPU and circuitry that enables the at least one CPU to have full and transparent connectivity to the analog chip as if they were designed as a single-chip microcontroller, and the interface design between the two can be highly efficient and wire-limited, yet still provide improved performance, with no impact on functionality or software models.

Description

Technical Field

[0001] Describe the communication of signals between dies in a seamlessly integrated microcontroller chip that includes a microcontroller CPU, memory, and analog devices existing on separate process nodes. This integrated system brings reduced cost or complexity, higher efficiency, and shorter time to productization while maintaining seamless integration without significant loss of performance.

Background Art

[0002] Unless explicitly identified as known or well-known, references in this specification to techniques and concepts, including for context, definition, or comparison purposes, should not be construed as an admission that such techniques and concepts are previously known or otherwise part of the prior art. References cited in this specification (if any), including patents, patent applications, and publications, are hereby incorporated by reference in their entirety for all purposes, whether specifically incorporated or not.

[0003] In the world of microcontrollers and microcomputers, we face the challenge of effectively developing and integrating I / O peripheral devices and systems that are compatible with various environments and functions. A solution that works well for one industry does not necessarily work well for all and needs to be modified. This challenge, in turn, causes a major scaling problem where ASIC devices need to be modified for almost all control functions.

[0004] Existing solutions integrate the CPU, memory, and peripheral device access on a single die. The interface between the I / O peripheral devices and the CPU, clock, and memory access is tightly coupled and managed to achieve the desired performance.

[0005] Changes to the I / O or any other elements within the die may require new hardware and software designs to maintain performance and external interfaces into the die. A change to the CPU would have the same effect.

[0006] Furthermore, while some components, such as CPU logic and memory, can be better implemented in one manufacturing process, others, such as high-voltage and high-precision analog components, can be better implemented in different manufacturing processes. Implementing all components on the same die can increase costs and decrease performance compared to what would be achieved if each component were implemented in a manufacturing process better suited to its needs.

[0007] The close relationship and associated interactions between the bus, interrupts, direct memory access (DMA), and the clock make it difficult to isolate the CPU from I / O.

[0008] To overcome this problem, existing solutions involve placing numerous wires (inputs / outputs) within the die to allow external interfaces to manage the system. Alternatively, some solutions separate the CPU from peripherals as standalone ASICs (sometimes analog ASICs), which creates complex interface problems for system designers and programmers. Separating the CPU from the ASIC does not solve the programming challenges that arise when the two are stacked together (or side-by-side).

[0009] The programming complexity of inter-die interfaces includes the need to use more CPU instructions to perform logical operations on peripherals on remote dies. Furthermore, changes to common interfaces such as interrupt service requests and direct memory access requests may result in software having to manage such functions using polling mechanisms and providing individual general-purpose inputs / outputs for interconnects to these functions. While some functions, such as bus transaction security management, peripheral data flow control for bus transactions, transaction error reporting, and data block transfer, may require direct software management, in a single-die approach these can be handled in hardware. Other functions, such as providing automatic PMU state propagation between the CPU and power management that may be located on a remote die, must also be managed by software or dedicated interconnects provided for direct transfer of standard signals.

[0010] Therefore, there is a need for an inter-die hardware architecture that allows bridging the overall bus + interrupt + DMA and other desired structures, while simultaneously minimizing the inter-die communication interface by replacing far more wires with a logical structure that gives each die a logically uniform behavior to its components as would occur if they were implemented on the same die using the normal, fully parallel set of signals. An interface that allows peripherals located on different dies from the CPU to be implemented with a full-featured standard bus interface allows peripherals to be designed agnostically for whether they ultimately reside on the same die as the CPU or on a different die. Furthermore, adding / removing peripherals from the ASIC portion, or moving components between the CPU die and the ASIC die, does not affect the interface and therefore allows for rapid design changes related to diverse systems and their unique needs. And if the interface itself is a comprehensive format, any die containing a CPU can be coupled to any die containing peripherals, even if these two dies are not necessarily both designed for this particular arrangement. A CPU die can be used across multiple designs (including designs not originally envisioned when the CPU die was designed). Alternatively, a non-CPU die can be paired with multiple different CPU dies to efficiently implement variations in processing power using a common design for common peripherals. [Overview of the project] [Means for solving the problem]

[0011] The system is described below. This system may include a first die having a central processing unit (CPU) and a first bridge, and a second die having a second bridge, wherein the second die may have a third CPU that is not associated with the first or second bridge, or may exclude a second CPU. Furthermore, the system includes an inter-die interconnect that is electrically coupled to the first and second bridges, wherein the inter-die interconnect has fewer signal lines than the first bus in the first die and the second bus in the second die. In addition, the first and second bridges mask the presence of the inter-die interconnect so that the functionality of the second die appears to the master (such as the CPU) on the first die as if it were implemented on the first die.

[0012] It should be noted that the first die may include multiple devices, and one or more of these devices may act as a bus master involved in bus transactions to bus slaves on the second die via an inter-die interconnect.

[0013] Furthermore, the second bridge may interrupt a transaction by the bus master on the first die, allowing service work for a transaction by the second bus master on the first or second die to be performed via the inter-die interconnect before the interrupted transaction by the first bus master is finalized.

[0014] Furthermore, the second die may include multiple devices, one or more of which may act as bus slaves with respect to the first and second bridges.

[0015] Furthermore, the first die may provide a single, wider-bandwidth interconnect when only a single instance of the second die is implemented, while allowing for two narrower-bandwidth connections for implementations where two instances of the second die are present.

[0016] In some embodiments, the software model implemented on the first die is the same as that implemented on a single-die system.

[0017] It should be noted that the first and second buses may share a common format. For example, the format may include the ARM Advanced Microcontroller Bus Architecture (AHB), AHBLite, or AHB5. Alternatively or additionally, the format may include the Wishbone Architecture.

[0018] Furthermore, the system may include a second bus master on the second die, electrically coupled to a third bus on the second die, and a third bridge electrically coupled to the third bus as a bus slave; a second bus slave on the first die, electrically coupled to a fourth bus on the first die, and a fourth bridge electrically coupled to the fourth bus as a bus master; and a second die interconnect for transmitting a second signal between the third and fourth bridges, where the number of second die interconnects is less than the number of signal lines between the second bus master and the third bridge. The first bridge, the second bridge, and the die interconnects may enable the bus master to participate in bus transactions with bus slaves in the same manner as if the bus transactions were performed within a single die system.

[0019] Furthermore, the CPU instructions for accessing the bus slave on the second die may be the same as if the bus slave were implemented on the first die.

[0020] Furthermore, the first and second bridges may use the die interconnects in sequence for command transfers and subsequent selective data transfers. In some embodiments, command transfers are communicated within a single clock cycle. Alternatively, command transfers may be serialized over several clock cycles, while being transparent to the first die or to the software model on the first die. Moreover, the serialization length for the serialization may be variable, at least in part, based on the command content.

[0021] Note that command transport may maintain the same clock cycle as if the system were implemented on a single die without the first or second bridge.

[0022] Furthermore, the data phase may have different data directions for one or more of the die interconnects. For example, the data direction may be decoded from the command content. Additionally, data transfers may be communicated within a single clock cycle or serialized over several clock cycles. The data transfer serial length may be decoded from the previous command content.

[0023] In some embodiments, the die interconnect may provide a phase indication from the first die to the second die regarding whether the subsequent phase is a command phase or a data phase. For example, the phase indication may be used to perform two or more data transfers for a single command transfer.

[0024] Furthermore, the bus address on the second die may be updated in each data phase according to instructions provided during the previous command phase.

[0025] Furthermore, the first bridge may perform multiple data phases in response to burst indications on the first bus.

[0026] In some embodiments, the first bridge may execute a plurality of data phases in response to detecting a sequential access address on the first bus. Alternatively or additionally, the first bridge may execute a plurality of data phases in response to a direct memory access (DMA) controller indication.

[0027] Note that the die - to - die interconnect may perform transactions not related to the first bus or the second bus.

[0028] Moreover, unrelated commands may be indicated by coding during a command phase.

[0029] Other embodiments provide a first die.

[0030] Other embodiments provide a second die.

[0031] Other embodiments provide an electronic device including a first die, a second die, and a die - to - die interconnect.

[0032] Other embodiments provide a method for communicating between a first die having a first bridge and a second die having a second bridge. This method includes at least some of the operations performed by the first die and the second die.

[0033] This summary is provided for the purpose of showing some exemplary embodiments so as to provide a basic understanding of some aspects of the subject matter described herein. Thus, it should be understood that the features described above are examples and should not be construed in any way as narrowing the scope or spirit of the subject matter described herein. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description of the invention, the drawings, and the claims.

Brief Description of the Drawings

[0034] [Figure 1]Block diagram of a single die system, [Figure 2A] A block diagram showing selected details of one embodiment of a single-die system. [Figure 2B] This block diagram shows selected details of one embodiment of a two-die system, including a CPU die, an ASIC chip, and a selected internal architecture. [Figure 3] A block diagram showing selected details of one embodiment of a two-die system. [Figure 4] This block diagram shows selected details of one embodiment of an interface between two die systems having a reduced set of wires. [Figure 5] This figure shows selected details of one embodiment of a bus transaction. [Figure 6] This figure shows selected details of one embodiment of bus error propagation and secure bus access. [Figure 7] This figure shows selected details of one embodiment for handling various bursts. [Figure 8] This figure shows selected details of one embodiment of interrupt bridging between an interrupt source on an ASIC die and an interrupt controller on a CPU die. [Figure 9] This figure shows selected details of one embodiment of a sequence diagram illustrating DMA request synchronization between an ASIC die DMA-enabled bus slave and a CPU die DMA controller. [Figure 10A] This is a flowchart illustrating one embodiment of the configuration and discovery process for a two-die system. [Figure 10B] This flowchart illustrates one embodiment of the configuration and discovery process for a two-die system with fixed ASIC die capability. [Modes for carrying out the invention]

[0035] Note that throughout the drawing, the same reference number refers to the corresponding part. Furthermore, multiple instances of the same part are specified by a common prefix separated by a dash from the instance number.

[0036] The disclosed communication techniques can be implemented in numerous ways, for example, as processes, articles, apparatus, systems, compositions, and computer-readable media such as computer-readable media (e.g., media in optical and / or magnetic mass storage devices, such as integrated circuits with non-volatile storage like disks and flash storage) or as computer networks through which program instructions are transmitted via optical or electronic communication links. As will be described in more detail below, this disclosure provides descriptions of one or more embodiments of the disclosed communication techniques that may enable improvements in one or more factors such as security, cost, profitability, performance, efficiency, and / or utility of use in the art identified above. The modes for carrying out the invention include an introduction to facilitate understanding of the remainder of the modes for carrying out the invention. The introduction includes one or more exemplary embodiments of systems, methods, articles, and computer-readable media by the concepts described herein. As will be described in more detail below, the disclosed communication techniques encompass a number of possible modifications and variations within the scope of the published claims.

[0037] The disclosed communication technique provides an inter-die interface / bridge that enables multi-die microcontroller implementation in a transparent manner for end users. By bridging several standard microcontroller interfaces between two dies, peripherals can be implemented in a highly agnostic manner depending on which of the two dies they are implemented on. In fact, the user encounters a single microcontroller unit. The bridging is not trivial and may provide a solution for omitting elements within existing technologies.

[0038] Existing bus extensions do not support typical functionality and behavior in single-die microcontrollers. When dividing a single die into multiple dies, one might simply assume that all wires can be connected in principle. Typically, this only works in theory and often requires physical line connections for all internal interfaces.

[0039] The approach of "connecting all the wires" doesn't make sense simply because it's easier to have them all on the same die. What we are exploring is minimizing the number of interconnects while enabling moderately complex interactions with multiple remote dies. The communication technique we disclose may be superior to conventional external bus extensions (e.g., I2C, SPI, parallel memory buses, etc.). In particular, this communication technique may offer the following advantages: The same software programming model for single-die integration. Bus peripherals on remote dies directly respond to CPU bus memory-mapped access. Despite a lower number of interconnects, this results in lower latency for accessing peripherals on remote dies. In some embodiments, this can be virtually zero additional latency using practical configurations. This involves reducing the number of opcodes executed by software for each remote peripheral access operation, and furthermore, the number of opcodes is the same as for a single die, but fewer than when other external bus extensions are used. To provide normal bus functionality using a standardized, normal interface for masters on the CPU die and slaves on remote dies, including transparent slave stalling (flow control) when a remote slave is not ready for data delivery (either read or write), transaction error reporting, support for security features such as access privileges / security, automatic arbitration of remote slaves between multiple bus masters (e.g., CPU and DMA), and / or burst mode transfers. To provide the ability to receive individualized interrupt requests from potentially many peripheral devices in a conventional manner, for example, in a manner transparent to the endpoint. To provide individualized DMA request capabilities from peripheral devices in a conventional manner. For example, stopping DMA request assertions during DMA data transfer synchronized with the bus transfer data stage. To enable inter-die synchronization of power management functions in a transparent manner. To enable transparent security function configuration between the CPU die and the ASIC die, other than bus access privileges such as debug port access. Remote die design and manufacturing independent of the CPU die, and enabling the urgent addition or redesign of interfaces / peripherals on a remote die without affecting the CPU die or software model. To enable multi-die products in which components that are impossible or impractical to integrate on a CPU die (for example, due to incompatible process technologies) can be paired with a remote die that implements these components, while being transparent to component interface standards and programmer models on both dies. To enable boot time discovery / mapping of peripheral device dies. To enable runtime-adjustable interconnect counts in order to pair a single CPU die with multiple different ASIC dies having different interconnect counts, without changing the software model or peripheral component design on a remote die.

[0040] A detailed description of one or more embodiments of the disclosed communication techniques is provided below, along with accompanying drawings illustrating selected details of the disclosed communication techniques. The disclosed communication techniques are described in relation to embodiments. Embodiments in this specification are to be understood as merely illustrative. The disclosed communication techniques are not expressly limited to any or all of the embodiments in this specification, and the disclosed communication techniques encompass a number of combinations, alternative forms, modifications, and equivalents. To avoid monotony in the description, various word labels (such as first, last, several, various, further, other, specific, select, several, and significant) may be applied to separate sets of embodiments, and when used herein, such labels are not expressly intended to convey quality or any form of preference or disadvantage, but merely intended to conveniently distinguish between separate sets. The order of some operations of the disclosed process is modifiable within the scope of the disclosed communication techniques. Whenever multiple embodiments are useful in describing variations of a process, system, and / or program instruction function, other embodiments are contemplated that perform a static and / or dynamic selection of one of multiple operating modes corresponding to each of the multiple embodiments, according to predetermined or dynamically determined criteria. Numerous specific details are provided below to give a full understanding of the communication techniques disclosed. These details are provided for illustrative purposes, and the invention may be practiced in accordance with the claims without some or all of these details. For clarity, known technical material in the art relating to the communication techniques disclosed is not described in detail, so as not to unnecessarily obscure the communication techniques disclosed.

[0041] Microcontrollers are used in a wide range of systems and devices. Devices often utilize multiple microcontrollers that work together within the device to handle their respective tasks.

[0042] A microcontroller is an embedded, real-time device used to control a single or limited number of functions in a device or a larger system. A microcontroller does this by interpreting data it receives from its peripherals using its central processor (CPU) and memory. Peripherals (e.g., a temperature sensor or wireless communication interface integrated into the microcontroller) can integrate analog I / O interfaces (e.g., an analog-to-digital converter or LCD driver) or digital interfaces (e.g., a general-purpose individual input / output signal driver or SPI communication interface). Temporary information received by the microcontroller is stored in its data memory, where the processor accesses the data memory and uses instructions stored in its program memory to decode and apply the incoming data. The processor then uses its I / O peripherals to communicate and / or perform appropriate actions.

[0043] For example, an automobile may have many microcontrollers that control various individual systems, such as anti-lock braking systems, traction control, fuel injection, or suspension control. Such microcontrollers may be responsible for interacting with the hardware that implements these systems, such as sensing and controlling analog or digital components. Furthermore, these microcontrollers frequently communicate with each other using communication interfaces to coordinate their actions. Some may communicate with the more complex central computer within the automobile, while others may only need to communicate with other microcontrollers.

[0044] Figure 1 shows a single-die microcontroller 100 architecture at a high level, including a clock multiplier and multiplexer (mux) 110 and its source 115, multiple CPUs and an optional DMA controller 120, basic ASIC functions 145 interfaced using an AHB bus 125, multiple interrupt request signals (IRQs) 160 for managing interrupts, multiple DMA request signals (DRQs) 130 for automated DMA service work, a power management unit (PMU) interface 135, and a debug access port (DAP) 150 that interacts with one or more CPUs or other internal components through a debug access port interface 140. (Note that the Advanced High Performance Bus, or AHB, is a bus architecture defined in the ARM Advanced Microcontroller Bus Architecture (AMBA), an open standard on-chip interconnect specification for connecting and managing functional blocks in system-on-chip (SoC) designs. Other bus formats in AMBA include APB and AXI.) Figure 1 shows some of the functionalities and internal interfaces, which will be described in more detail as we move from single-die to multi-die designs of the disclosed communication techniques. Throughout this disclosure, the AHB125 may be used as in one embodiment. The disclosed communication techniques are not limited to specific characteristics of the AHB bus design, and known techniques are used as implementation examples. Furthermore, the AHB interface 125 may include further bus tiers inside the ASIC function 145, such as one or more APB buses, so that bus slaves inside the ASIC function 145 may be attached to it not directly but through the AHB interface 125.

[0045] Microcontrollers are typically provisioned to trade computing power for low cost. Due to the real-time nature of the sense / response sequence, the computing performance in a microcontroller is typically optimized to limit the combined latency of the system by limiting the sense / response sequence. The time it takes to execute this overall sequence can often be measured in fractions of milliseconds. This differs from computing processors, which can accept much larger and more variable latencies, however, while potentially handling many unrelated tasks, and are optimized for averaged performance over much larger timescales. As a result, the architecture connecting the CPU to its peripheral resources becomes even more tightly coupled. Typically, a microcontroller CPU operates at the same frequency (or some smaller multiple) as the peripherals and main memory, and the CPU expects to interact with these components at the word level (the native word bit size of that particular system) on the CPU's own main bus (or is bridged through to several buses with different formats). Each word access to which the target imposes an access delay results in processor execution stalling during that delay. Computational processors are typically optimized to interact with local cache memory and have various mitigation measures to continue performing useful work when the cache does not contain the desired data. In these processors, the processor connects to non-cache components primarily through the cache. Furthermore, in this case, slow peripheral access is converted into block transactions or cache pages, typically filled with initial CPU execution stalls during the loss of data transfer. Typically, a CPU has several stalls measured across its various threads, when the stalled thread waiting for data is only part of the overall workload, and that thread can often relinquish its execution to other threads while the data block is being transferred.Subsequently, the computing processor can work efficiently on the entire block of data without interruption due to access latency. When the microcontroller accesses peripheral memory more frequently, typically on a word-by-word basis, slow peripherals will stall the CPU again with each word access. For performance reasons, the microcontroller typically either directly attaches the peripheral or bridges it directly to the CPU's own bus structure.

[0046] The conceptual purpose of the CPU bus is to handle the transfer of memory (or memory-mapped) data. However, other functions are usually required and therefore performed over this same bus. These tasks consist of data stalls from bus slaves, responses from slaves indicating the outcome of a transaction (e.g., OK or unauthorized access), and / or bus master indications of the transfer purpose / privileges, such as whether the access purpose is code or data, whether the access is from kernel or user access privileges, whether the transaction is for secure data, and / or whether write access can be buffered (if the slave is slow, there is no need to wait for a slave response before moving on to the next transaction).

[0047] Peripheral devices typically use interrupts by a microcontroller to indicate the occurrence of time-constrained events. Peripheral devices can drive interrupt request (IRQ) signals to indicate conditions that may require CPU action. Microcontroller CPUs are typically paired with interrupt controllers, such as nested vector interrupt controllers (NVICs), which register events on various IRQ lines when they are set in interrupt hold registers. (Note that nested vector interrupt control (NVICs) are a way to prioritize interrupts, improve CPU performance, and reduce interrupt latency. NVICs also provide implementation schemes for handling interrupts that occur when other interrupts are running or when the CPU is in a process of restoring its previous state and resuming its interrupted processes.) While the hold register for that IRQ line is set, subsequent changes on that IRQ line are ignored. Furthermore, policies can be placed where hardware responses to IRQ activity should be provided, such as automatically starting execution of a block of code associated with that IRQ line (an interrupt handler). If an interrupt handler is programmed to execute automatically, the execution by that handler typically automatically clears the associated interrupt event register. If the CPU chooses not to enable the automatic handler, the CPU can check the pending register itself and clear it to re-arm IRQ capturing. With the interrupt controller having several inputs for receiving such signals, microcontroller peripherals typically implement their IRQ indications as individualized signals to the interrupt controller. In some cases, microcontroller peripherals may be expected to provide multiple IRQ signals, such as indicating different events on different IRQ signals.

[0048] IRQ signals are typically represented as level-based or edge-based. Level-based interrupts are typically used for situations where the intended interpretation is that a peripheral has one or more unprocessed events. This is particularly appropriate when a peripheral may have multiple different types of events to signal, and such multiple events may occur simultaneously. The peripheral typically marks the unprocessed event (interrupt flag) in a register accessible to the microcontroller via the bus. As long as any event is marked in this register, the peripheral asserts the IRQ line. The CPU then processes that event (such as performing a responsive action or changing a memory state to mark it for some subsequent action), and can then clear one or more events from this register via bus access. If an interrupt handler exists and there are unprocessed events in the flag register, the IRQ line remains asserted, and the pending register is set again for further processing.

[0049] Edge-based interrupts are communicated as events from a peripheral to an interrupt controller, typically as data changes on an IRQ signal, such as data 0 and the subsequent data 1 (rising edge). In this case, the interrupt controller can be configured to simply set a pending register in response to this sequence, and the peripheral can ensure that this sequence is delivered only once per peripheral event. Edge-based interrupts are more commonly used when the message from the peripheral should be interpreted as a single event (for example, when it is necessary for the number of events to be counted precisely, or when accidental re-entry of the interrupt handler due to the deactivation of the IRQ line being delivered to the interrupt controller after some delay would impair the behavior).

[0050] Microcontrollers can be implemented using direct memory access controllers (DMAs) to help automate data transfers. Typically, a microcontroller implements third-party DMA rather than first-party DMA, and as a result, a peripheral device with data to be moved to another location, such as main memory, can alert the DMA controller that certain actions are required, allowing the controller to perform the necessary actions as a bus master along with the peripheral device as a bus slave. Third-party DMA has lower implementation costs but also lower performance. DMA transactions can be either CPU-initiated or peripheral-initiated. It is common for peripherals to use a DMA(DRQ) request signal driven by the peripheral to the controller to alert the DMA controller that there is a desired peripheral-initiated transaction. The controller can then respond to the request according to the policy the CPU has assigned to that request. When the controller is not already involved in a transaction for that policy, it interprets the active level on the DRQ line as a request for a transfer to take place. Except for a few exceptional cases (such as the CPU intervening and canceling a pending transfer), the peripheral is expected to continue requesting until a responsive transfer takes place. This could involve performing sufficient transfers to fill the data buffer to a desired level, or providing an indication that the data buffer can be rolled back, or other conditions specific to the operation of the peripheral requesting it. With the DMA controller having several inputs for receiving such signals, microcontroller peripherals typically indicate their DRQ indications to the DMA controller as individualized signals. In some cases, one might expect microcontroller peripherals to provide multiple DRQ signals, such as indicating different types of required transfers on different DRQ signals.

[0051] DMA transactions can be fixed-length or variable-length, and can be implemented by a DMA controller using one or more preferred bus transactions, such as AHB bus access or burst access. For example, a given peripheral can always transfer 32 bytes of data per request as a fixed-length transaction. In other cases, the length of each transfer can be situation-dependent, so that the peripheral (but not the controller) knows the desired data to transfer. A typical strategy to enable a third-party master to handle this situation is to have the implemented peripheral logic keep the DRQ line at the active level while there is still more data in the transaction. The controller can then check the DRQ line after each word of the transfer and abort the transfer in the first bus cycle, where the peripheral asserts the DRQ against it as the data is delivered. For this reason, it is useful that the assertion of the DRQ is delivered to the DMA controller in exactly the same cycle as the bus data. Otherwise, the DMA controller may transfer the wrong number of words. Similar considerations may be used for fixed-length DMA transactions. If a peripheral device asserts and stops its DMA request near the end of a fixed-length DMA transaction, the delay difference between the DMA controller's completion of the bus transaction and the arrival of the DRQ assertion stop may cause the DMA controller to mistakenly recognize a DRQ signal that should still be asserted after the previous DMA transaction has completed, leading the DMA controller to incorrectly start a subsequent transaction.

[0052] Figure 2A is a component-level diagram of an existing single-die architecture with additional details to help map some of the system's complexity. In Figure 2A, the microcontroller die 200 implements several interconnects 220 to its peripheral components, representing possible data and event bus lines, including multiple DATA BUS 125, IRQ signal 160, DRQ signal 130, PMU interface 135 indicator, and other signals representing events and states. This bus and line is used to interface with other subsystems of the microcontroller, such as custom DSP logic 211 with interconnection interface 220 229, DMA controller 212 with interconnection interface 220 230, RAM 216 with interconnection interface 220 231, FLASH memory 213 and CPU 217 with interconnection interface 220 236, and other ASIC logic such as LV comms 221 with interconnection interface 220 237, LV sensor 222 with interconnection interface 220 238, LV actuator 223 with interconnection interface 220 239, communication interfaces such as CAN / LIN 224 with interconnection interface 220 240, HV sensor 225 with interconnection interface 220 241, and HV actuator 226 with interconnection interface 220 242. Note that these are merely examples of embodiments and may include other elements. In addition, it includes a power management unit PMU205, a debugger 218 with a CPU interface 234, an oscillator 219 for providing a clock input via interface 235, and a composite comms / sensor / actuator 210 that interfaces with a custom DSP logic 211 via interface 227.

[0053] The interconnection unit 220 provides communication between various components. These communications typically include data bus transactions (e.g., AHB), IRQ signaling, DRQ signaling, and PMU control and display. These interconnection units are typically accessed by the various components using standardized interfaces, such as CPU interconnect interfaces.

[0054] It should be noted that it is not unusual for the interconnect 220 to include some built-in logic to support the low-level needs of these interfaces. For example, the data transaction interconnect 125 may often include block address decoding and data multiplexing functions to assist in routing data bus transactions to the appropriate bus slaves for addresses presented by the bus master. In other protocols, the address decoding function can be computed independently by each bus slave, and the logic included in the interconnect 220 utilizes address matching representations from various bus slaves to assist in data routing. To provide the ability for multiple data bus masters to participate in bus transactions simultaneously, a multi-lane bus fabric (e.g., multi-layer AHB) is often implemented with routing and conflict resolution logic built into the interconnect 220. Furthermore, it is common to include retiming or synchronization logic in the interconnect 220 in cases of cross-clock domain or clock rate differences.

[0055] An example of the use of the interconnector 220 is an AHB data bus 125 transaction between the CPU 217 and the LV sensor 222. Such a transaction can be initiated by the CPU 217 issuing an AHB address phase for the AHB transaction on the AHB master signal in interface 236. The block address decoding logic present in the interconnector 220 decodes that the address indicated in the address phase for this transaction is within the address block allocated to the LV sensor 222. The interconnector 220 then presents this AHB address phase to the AHB slave signal in interface 238. The subsequent AHB data phase executes the requested transaction between the CPU 217 and the LV sensor 222 through interfaces 236 and 238 and the interconnector 220. The data phase may result in data being transferred immediately, data being transferred after a stall, or no data being transferred at all due to the bus slave indicating a transaction error. Transaction errors can occur in response to unacceptable transactions, such as transactions without proper authorization, or to malformed transactions, such as incorrect addresses or data sizes, for other reasons. Other data bus formats may have different transaction results. Other bus masters can similarly use the interconnect 220 to initiate transactions using the AHB master signal in their interfaces to the interconnect 220, such as the DMA controller 212 using the AHB master signal in interface 230. Other bus slaves can also conduct transactions through the interconnect 220 using the AHB slave signal in their interfaces, such as the custom DSP logic 211 using the AHB slave signal in interface 229, or the RAM 216 using the AHB slave signal in interface 231.

[0056] Another example of the use of the interconnector 220 is when the HV actuator 226 issues an interrupt request that brings an interrupt controller located in the CPU 217. The HV actuator 226 can indicate an interrupt request on one or more interrupt request source signals in its interface 242. This signal can be provided via the interconnector 220 to an interrupt request receive signal in interface 236. One way to achieve this is to provide a numbered set of interrupt request receive signals in interface 236 and route the interrupt request source signal in interface 242 to one of these numbered receive signals. Other interrupt source signals connected via the interconnector 220 on other interfaces can then be routed differently to the numbered interrupt request receive signals in interface 236. Other interrupt request sources can indicate an interrupt request via the interconnector 220 by indicating on the interrupt request source signals in their interfaces, such that the custom DSP logic 211 uses the signal in interface 229. Other interrupt controllers can receive interrupt requests through the interconnect 220, through their interrupt request reception signals in their interfaces, such that the DMA controller 212 uses the signals in interface 230.

[0057] Another example of the use of the interconnector 220 is when a DMA transaction transfers data between LV comms 221 and RAM 216 via the DMA controller 212. LV comms 221 can indicate the need to execute this transaction using one or more DMA request source signals in interface 237. The interconnector 220 can route this signal to a DMA request receive signal in interface 230, indicating to the DMA controller 212 that the transfer is desired. One way to achieve this is by providing a numbered set of DMA request receive signals in interface 230 and routing the DMA request source signal in interface 237 to one of these numbered receive signals. Other DMA request source signals connected through the interconnector 220 on other interfaces can then be routed differently to numbered DMA requests received as signals via interface 230. Upon receiving a DMA request, the DMA controller 212 can then perform responsive actions such as AHB transactions using LV comms 221 and RAM 216 via the AHB master signal in interface 230 and the AHB slave signals in interfaces 237 and 231 via the interconnect 220.

[0058] In some implementations, the CPU 217 may have additional connections for direct communication with components. The CPU 217 may access the flash memory 213 directly through a dedicated interface 232, and may access the RAM 216 through a dedicated interface 233. This can enable advantages such as lower latency, faster transfer rates, and the ability to perform simultaneous transfers through the interconnect 220 on the dedicated interface using interface 236.

[0059] Many microcontroller systems include power management features such as power sequencing and one or more sleep modes to conserve power when there is no required activity. The microcontroller's CPU can execute commands to enter this sleep mode, and such commands can result in various power-saving actions, such as disabling clocking, disabling power to logic blocks, disabling power to memory, disabling power to analog components, and disabling power to power supplies to ports. The CPU can take any action it deems necessary to prepare itself for this sleep mode, and then (see Figure 1) can indicate to the PMU 205 on the PMU interface 135 that sleep should be performed. The PMU 205 can implement the logic to perform the steps necessary to perform this sleep. Often, the PMU 205 and CPU 217 can sequence actions to perform a power mode change, often using recognition responses exchanged to indicate the completion of actions in the sequence. The CPU 217 typically has a dedicated interface 256 (which may be part of the PMU interface 135) to enable these interactions with the PMU 205. It is also common for the PMU 205 to have a more comprehensive interface 283 to the interconnect 220 (which may implement at least a portion of the PMU interface 135), for data bus signals for parametric configuration, interrupt requests for software notifications, etc.

[0060] Before performing sleep, the software can set policies regarding which resources will be disabled during sleep and what conditions will cause the processor to wake from sleep. One common technique for detecting a wake event is to trigger this wake-up using one or more selected interrupts when detected. Since the interrupt controller itself can typically be part of the sleeping circuit configuration, some of the internal state of the interrupt controller can be transferred to the outer logic of the area that should be put to sleep in the wake-up interrupt controller (WIC). The WIC is part of the logic of the PMU205. This WIC can then remain active during sleep to detect appropriate interrupt activity and initiate the wake-up. The WIC can then signal the PMU205 to take any steps necessary to re-enable the resources that were disabled during sleep. Once this is done, the CPU can be given an indication to resume the activity. Part of this resumption of activity may be transferring the relevant portion of the WIC state back to the NVIC. This allows the interrupt controller to provide the CPU with information about which of the various possible events caused the wake-up, for example, by putting those interrupts into a pending state.

[0061] To facilitate software development and fault analysis, the microcontroller die 200 can be implemented with a debug port implemented with debugger logic 218. This allows for the attachment of a communication interface, which can then control and / or inspect the state of the microcontroller die 200 by controlling code execution, inspecting register contents, mastering transactions on the data bus, controlling the PMU state, etc. The CPU 217 can implement a dedicated interface 234 to enable these debugging operations.

[0062] Figure 2B shows one embodiment of splitting a single-die microcontroller 200 into a two-die system while maintaining full functionality and without requiring any changes to the software model. The principle of "maintaining full functionality and without requiring any changes to the software model" is made possible by the communication technique disclosed. Existing methods often fail to meet these criteria. Components that would otherwise be implemented on the single-die microcontroller 200 are instead implemented in a multi-die system having a CPU die 246 and an ASIC die 271. The CPU die 246 implements the CPU 217, RAM 216, flash memory 213, and DMA controller 212. The ASIC die 271 implements the oscillator 265, low-voltage communication peripheral 221, low-voltage sensor peripheral 222, low-voltage actuator peripheral 223, CAN / LIN communication peripheral 224, high-voltage sensor 225, high-voltage actuator 226, custom DSP logic 211, and its associated analog block 210. The PMU205 is divided into a PMU controller 244 implemented on the CPU die 246 and a PMU 268 implemented on the ASIC die 271. The CPU die 246 includes an interconnector 248 that provides connectivity between various components on the die. The ASIC die 271 includes an interconnector 272 that provides connectivity between various components on the die.

[0063] This choice of die location for each component in this example offers several advantages. The CPU 217, flash memory 213, RAM 216, and DMA controller 212 may be difficult or expensive to implement in the same semiconductor process as some of the other components, such as the HV sensor 225, HV actuator 226, CAN / LIN 224, PMU 268, and composite comms / sensor / actuator 210. By distributing the system across multiple dies, each die can be implemented in a semiconductor process technology appropriate for the components placed on that die. Furthermore, while the components on the CPU die 246 are relatively comprehensive, the components on the ASIC die 271 are more specific to particular application examples. Using this configuration, it may be possible for one product to use the same CPU die 246 paired with an ASIC die 271 while other products use the same CPU die 246 paired with different ASIC dies having components selected for different application examples.

[0064] Placing some of these components on the CPU die 246 and others on the ASIC die 271 presents a challenge, as many of them were interconnected within the single-die microcontroller 200 via interconnects 220. A seemingly simple solution would be to provide a dedicated inter-die interconnect 261 for the interconnect 220 signals for the components on the ASIC die 271, such that the interconnect 220 is the same as that for the single-die microcontroller 200, but is distributed across both dies as a combination of interconnects 248, interconnect 272, and inter-die signals 261. However, upon consideration, this design approach presents challenges for typical systems, as the required number of inter-die signals 261 are not practical to implement and cannot be scaled. Another drawback of this approach is that the inter-die signals 261 are specific to the components located on the ASIC die 271, and therefore pairing the CPU die 246 with different ASIC dies containing different / revised components would require a redesign of the CPU die 246 for every new ASIC die 271.

[0065] In one embodiment of the disclosed communication technique, connectivity between the CPU die 246 and the ASIC die 271 is implemented using a significantly reduced number of die interconnects 262. These interconnects are connected through a pair of communication bridges, namely a master bridge 245 located on the CPU die and a slave bridge 264 located on the ASIC die. The master bridge 245 accesses the CPU die interconnect 248 on its interface 260. The slave bridge 264 accesses the ASIC die interconnect 272 on its interface 201. The combination of interface 260, master bridge 245, die interconnect 262, slave bridge 264, and interface 201 works together to enable components on the CPU die 246 to interact with components on the ASIC die 271 in a manner similar to what would be done if more die signals 261 were implemented. Furthermore, the CPU die component interfaces to the CPU die interconnect 248 may be the same as those for their component interfaces to a single die interconnect 220. Similarly, the ASIC die component interfaces to the ASIC die interconnect 272 may be the same as those for their component interfaces to the single die interconnect 220. For example, the AHB signals in the CPU interface 236 and the LV sensor interface 238 may be the same as if they were in a single die 200 configuration, even though they are located on different dies and attached to different interconnects 248 and 272, respectively.

[0066] In one embodiment of the disclosed communication technique, the die interconnect 262 is used for transaction and message exchange. These transactions and message exchanges propagate relevant changes between the CPU interconnect 248 and the ASIC die interconnect 272 in a manner similar to how it would have been if more simple die signals 261 were implemented. For example, if a signal in interface 238 for LV sensor 222 changes from data 0 to data 1, this change can be propagated to an equal signal in interconnect 248. To accomplish this, interconnect 272 can propagate this signal to interface 201, from which a slave bridge 264 can detect the data transition. The slave bridge 264 can then schedule a message or transaction to communicate this data change to the master bridge 245. The master bridge 245 can then tune a synchronized version of this signal through interface 260 so that it becomes available in interconnect 248 for use by components in the CPU die 246. Similarly, the master bridge 245 can observe changes in the interconnection 248 signals for synchronization through the die interconnection 262 and slave bridge 264, and can provide synchronized versions of such signals on the ASIC die interconnection 272 via interface 201 for use by components within the ASIC die 271.

[0067] Simple signals can thus be synchronized by data change propagation, and in other embodiments, many typical signals and signal groups within interconnects 248 and 272 are synchronized by leveraging their system intent and characteristics. For example, signal groups related to data bus transactions such as AHB already indicate transactions between components. Data bus transactions implied by these groups of signals can be detected and propagated between bridges, like transactions specially coded between bridges to be remastered as equal transactions on other dies. Signal groups that perform a series of PMU state changes using a completion handshake can similarly be translated into appropriate transactions specially coded between bridges. Interrupt requests and DMA requests can be coded into transactions or messages in a more effective manner for signaling the intent of these interfaces.

[0068] Using the previously described AHB databus transaction between CPU 217 and LV sensor 222 as an example, as performed in a two-die system with two components on CPU die 246 and ASIC die 271, respectively, this transaction is initiated by CPU 217 issuing an AHB address phase for the AHB transaction on the AHB master signal in interface 236. Block address decoding logic residing in interconnect 248 decodes that the address indicated in the address phase for this transaction is within an address block allocated to the ASIC die address range. Interconnect 248 then presents this AHB address phase to the AHB slave signal in interface 260. This is detected by master bridge 245, which then schedules the corresponding AHB-specific inter-die transaction through inter-die interconnect 262. Slave bridge 264 detects and decodes this inter-die transaction and issues its own AHB address phase for equal AHB transactions on the AHB master signal in interface 201. The block address decoding logic present in the interconnection unit 272 decodes that the address shown in the address phase for this transaction is the address block assigned to the LV sensor 222. The interconnection unit 272 then presents this address phase to the AHB slave signal in interface 238. This results in two incomplete AHB transactions, namely, one between the CPU 217 and the master bridge 245, and the other between the slave bridge 264 and the LV sensor 222. Depending on the implementation, these transactions may be issued in the same clock cycle by combining and transferring the detected transactions across the bridge, or there may be one or more clock cycles of propagation and / or arbitration latency between the address phase presented on interface 231 and the associated address phase presented on interface 201.

[0069] Both AHB transactions must then complete their AHB data phases. Any write data provided by the CPU 217 on interface 236 is routed by the interconnect 248 to interface 260 of the master bridge 245. This data is propagated to the ASIC die 271 as the data phase of an inter-die transaction through the inter-die interconnect 262 to the slave bridge 264, which then provides it as the AHB data phase on its interface 201. The interconnect 272 routes this data to interface 238 for use by the LV sensor 222. Any read or response data provided by the LV sensor 222 on interface 238 is routed by the interconnect 272 to interface 201 of the slave bridge 264. This data is propagated as the data phase of an inter-die transaction through the inter-die interconnect 262 to the master bridge 245, which then provides it as the AHB data phase on its interface 260.

[0070] The inter-die transaction format does not need to be a direct coding of the bridged AHB transaction, nor does it need to have the same data rate or use the same native bus width. It only needs to be able to relay the address and data phases so that the corresponding AHB transactions in interfaces 260 and 201 complete with the correct results. In some implementations, it may be desirable to reduce the interconnector 262 signal count so that signals can be shared between the address and data phases, or serialized into multiple smaller transfers. It is also not necessary that signals used for inter-die transactions for the purpose of AHB transaction bridging be used exclusively for this purpose. During times when those interconnector 262 signals are not busy relaying AHB transactions, other synchronization or communication needs can use those same interconnector 262 signals by differently coded inter-die transactions.

[0071] One point to note is that the block address decoding logic in interconnects 248 and 272 forms a two-stage block address lookup. The block address decoding logic in interconnect 248 does not require knowledge that the transaction address maps to a specific block in the ASIC die 271 components, but only knowledge that it could map to one of those addresses. When an AHB transaction is remastered on interface 201, the address decoding logic in interconnect 272 can re-examine the address and route it to the correct component on the ASIC die 271. This allows the CPU die 246 to implement a simple and comprehensive address decoder, for example, by pre-allocating large blocks of addresses to the ASIC die components, so that the address decoding logic in interconnect 248 does not need to be different when paired with different ASIC dies.

[0072] Another example of inter-die synchronization is the previously described interrupt request from the HV actuator 226 to the interrupt controller in the CPU 217. The HV actuator 226 can indicate an interrupt request on one or more interrupt request source signals in its interface 242. This is propagated via the interconnect 272 to an interrupt request receive signal in the interface 201 of the slave bridge 264. The slave bridge 264 can then schedule a message or transaction via the inter-die interconnect 262 to propagate the detected interrupt activation to the master bridge 245, which responds by indicating an interrupt request on one or more interrupt request source signals in its interface 260. This signal can be provided via the interconnect 248 to an interrupt request receive signal in the interface 236. In one implementation configuration, the slave bridge 264 can supply a numbered set of interrupt request reception signals into interface 201, each of which can be routed via the interconnect 272 to interrupt source signals in the interfaces of various components on the ASIC die 271. The master bridge 245 can then implement the same number of interrupt source signals into interface 260 and provide them to the CPU die components via the interconnect 248.

[0073] The slave bridge 264 can communicate various numbered interrupt request activations to the master bridge 245 by providing enumerated event messages through the die interconnect 262. Not all such enumerated messages need to correspond to interrupt activations, and as a result, other enumerated messages can be used for other purposes. Furthermore, in some cases, signals in the die interconnect 262 used for this messaging can be shared with signals in the interconnect used for other purposes, such as sharing with the die transaction response signal at some time. If even lower latency is desired, a subset of the signals in the die interconnect 262 can be dedicated to this event message passing function.

[0074] As described elsewhere in this disclosure, it may be advantageous to use different mechanisms to handle interrupt request activation and deactivation. For example, interrupt request activation detected at interface 201 may be propagated to CPU die 246 via event messages through die interconnect 262, and deactivation may be detected by other mechanisms, such as preferred die transactions on die interconnect 262.

[0075] Another embodiment of die synchronization is the previously described DMA-initiated transfer of data from LV comms 221 and RAM 216 via DMA controller 212. LV comms 221 can indicate the need to perform this transaction using one or more DMA request source signals in interface 237. The interconnect 272 can route this signal to DMA request and receive signals in interface 201. Slave bridge 264 can then schedule a message or transaction via the die interconnect 262 to propagate the detected DMA request activation to master bridge 245, which responds by indicating the DMA request on one or more DMA request source signals in its interface 260. The interconnect 248 can route this signal to the DMA request receive signal in interface 230, indicating to DMA controller 212 that the transfer is desired. Upon receiving the DMA request, DMA controller 212 can then perform a responsive action, such as an AHB transaction involving LV comms 221 and RAM 216 via the AHB master signal in interface 230. Since the RAM 216 is located on the same die as the DMA controller 212, communication between them can proceed through the interconnect 248 in the same way as in the single-die configuration 200. The DMA controller 212 initiates communication with the LV comms 221 by initiating a data bus transaction on its interface 230, as in the single-die configuration 200, but the block address decoding logic in the interconnect 248 selects the master bridge 245 on the interface 260 for the target slave. The data bus transaction through the inter-die interconnect 262 can then proceed in the same manner as the CPU 217 and LV sensor 222 data bus transactions described earlier. The DMA controller 212 does not need to be aware that the LV comms 221 is on a different die.

[0076] In one implementation configuration, the slave bridge 264 can supply a numbered set of DMA request receive signals into interface 201, each of which can be routed via interconnect 272 to DMA request source signals in the interfaces of various components on the ASIC die 271. The master bridge 245 can then implement the same number of DMA request source signals into interface 260 and provide them to the CPU die components via interconnect 248.

[0077] The slave bridge 264 can communicate various numbered DMA request activations to the master bridge 245 by providing enumerated event messages through the die interconnect 262. It is not necessary for all such enumerated messages to correspond to DMA activations, as other enumerated messages can be used for other purposes, such as the interrupt request activations described earlier. Similar mechanisms for reducing the die interconnect count can also be used by sharing message signaling with other functions, such as the interrupt signaling described earlier.

[0078] It may be useful to update the DMA request indication to the interface 230 of the DMA controller 212 in a cycle-accurate manner so that the DMA controller 212 can respond to the deactivation of a DMA request by stopping a transfer or not performing subsequent operations after a completed operation. To enable this, the response signal to an inter-die transaction between the master bridge 245 and the slave bridge 264 via the inter-die interconnect 262 can indicate an update to the DMA request signal as part of the data phase transfer. For example, if LV comms 221 provides an inactive DMA request source signal on interface 237 during the data phase of a data bus transaction, the slave bridge 264 can detect this on interface 201 and provide a modified transaction response to include this updated DMA request information as part of the inter-die transaction data phase. This can be detected by the master bridge 245, which can then update its DMA request source signal on interface 260 to provide this update in the same cycle as the data phase of the data bus transaction on interface 260 is completed. In one embodiment, the DMA controller 212 may provide an additional signal on interface 230 as part of the data bus address phase to indicate which DMA request is relevant to its bus transaction. This can then be routed to interface 260 via interconnect 248 as an additional address phase signal, so that an inter-die transaction via inter-die interconnect 262 can provide this information to the slave bridge 264, which then knows which of its DMA requests on interface 201 to monitor for its data bus transaction.

[0079] Die-to-die synchronization can also be used to synchronize power management functions. Since the PMU 268 is located on the ASIC die 271, it does not have direct access to the CPU PMU interface 256 located on the CPU die 246. To enable PMU state changes and handshake transactions to occur between the CPU 217 and the PMU 268, these state changes and transactions can be translated into die-to-die transactions and messages through the die-to-die interconnect 262 and bridges 245 and 264. This can be achieved by including the PMU controller logic 244 within the ASIC die 246, which can interact with the CPU 217 as if it were the PMU 205, while actually forming one end of the synchronization bridge for interacting with the PMU 268. To accomplish this, the PMU controller 244 communicates with the master bridge 245 using interface 258, while the PMU 268 communicates with the slave bridge 264 using interface 281. Transactions and messages exchanged through interface 256 are then converted into inter-die transactions or events via the inter-die interconnect 262 along this path. This allows the CPU 217 to interact with the PMU 268 in a similar manner to how the CPU 217 interacts with the PMU 205 in a single-die implementation, and in both cases, the CPU PMU interface 256 is the same. These inter-die transactions and events can be shared with wires used for other purposes, such as by providing inter-die transaction coding for PMU use or by creating enumerated event messages for PMU use, thus eliminating the need for dedicated wires within the inter-die interconnect 262.

[0080] Die-to-die synchronization can also help locate debug access to the ASIC die 271 (for example, within the security manager 267). This can be beneficial for multi-die systems in several ways. Because the PMU 268 is located on the ASIC die 271, it may be possible for the entire CPU die 246 to be clocked and / or unpowered when in an extremely low power state. If debug access is located on the ASIC die 271, an external debugger can interact with the PMU 268 through interface 282 to enable a change in power mode, so that it can initiate or maintain communication with the CPU die 246 by disabling the no-clock or no-power mode during a debug session. The external debugger can also interact with the ASIC die 271 components even when the CPU die 217 is clocked or unpowered, such as by mastering data bus transactions through the interconnect 272, for example by communicating with the slave bridge 264 using interface 280 to master AHB transactions on interface 201. This also allows for debugger control via the ASIC die 271 component when the CPU die 246 is damaged or absent, such as for fault analysis or testing of partially assembled products during manufacturing.

[0081] Another advantage of locating debug access on the ASIC die is that it allows external voltage signaling for this port to be decoupled from the voltages used on the CPU die 246. This simplifies the design of the CPU die 246 by reducing the number or range of signaling voltages, and also allows different products using the CPU die 246 with different ASIC dies to have different signaling voltages.

[0082] To enable a debugger connected to debug access to interact with the CPU 217, inter-die synchronization can be used through the inter-die interconnect 262. This can be achieved by including CPU debug logic 299 on the CPU die 246. The CPU debug logic 299 can interact with the CPU 217 using interface 234 in a similar manner to how the debugger logic 218 interacts with the CPU 217 in the single-die implementation configuration 200. This can be achieved by translating debug operations into transactions or events through the inter-die interconnect 262 and bridges 245 and 264. The CPU debug logic 299 can interact with the CPU 217 using interface 234, as if it were the debugger 218 in the single-die implementation configuration 200, while translating these operations into appropriate signaling traversing the inter-die interconnect 262 using interface 257 to the master bridge 245. The slave bridge 264 on the ASIC die 271 can then use interface 280 to interact with the debug access logic in the security manager 267 to perform the desired debugger operation. The interconnect 262 signals used for this purpose can be shared with signals used for other purposes, such as by providing inter-die transaction coding for debugger use or by creating enumerated event messages for debugger use. In some embodiments, interconnect 262 of different widths may be used with different ASIC dies and the ability to reveal discovery. For example, a low-end product may use debugging with slower speeds and fewer pin counts, while a high-end product wire may allow for more detailed tracing and debugging.

[0083] Security for debug access logic can be improved by adding a security manager 267 to the ASIC die 271. This security manager can be used to verify that an attached debugger has the correct permissions before allowing it to be presented to other interfaces, such as interface 280 for CPU 217 debugger operation or interface 282 for PMU debugger operation. This could include allowing one or more debugger operations only to debuggers with the required security credentials, allowing one or more debugger operations only when the product is in a certain lifecycle state, or allowing one or more debugger operations only when the product is in a required operating mode.

[0084] A security manager 243 may be included on the CPU die 246 to enable the CPU die 246 components to act on and store security policies. The security manager 243 may be provided with access to non-volatile memory, such as flash memory 213 via interface 252, for storing security policy configurations, such as product lifecycle status, debugger authorization credentials, and other security configurations. The security manager 267 can manage security policies synchronized with the security manager through inter-die interconnects 262 via bridges 245 and 264 using inter-die transactions. Signals in the interconnects 262 used for these inter-die transactions may be shared with signals used for other purposes.

[0085] The debug communication port, which was previously connected to the debugger 218 on a single-die microcontroller, is now located on the ASIC die 271 and connected to the debug access logic.

[0086] It should be noted that, since the wires in the interconnect 262 are shared for different synchronization purposes, it may be necessary to include arbitration and prioritization among the various uses of the shared wires in the logic of bridges 245 and 264. When multiple competing services require synchronization, this arbitration logic allows for selection from among various services in response to a service work command while other services await time allocation.

[0087] An oscillator 265 and its interface 279 to the bridge 264 are implemented on the ASIC die 271, and thus the clock is extended to the bridge and CPU die 246. To extend debug access via the interconnect 262, debug access connects to the bridge master 264 via interface 280 using a security manager 267. The PMU 268 can provide power management functions on the ASIC die 271 and can also optionally supply power to the CPU die 246, and can be synchronized with the PMU controller 244 on the CPU die via the interconnect 280 using the security manager 267. Peripheral interfaces 272, which can include bus interfaces such as AHB, IRQ signals, DRQ signals, and peripheral PMU indicators, can be synchronized with the bridge masters 245 and 264 as well as their similar counterparts 248 via the interconnect 262 through interfaces 260 and 201. (Note that peripheral interfaces 272 may be coupled to peripherals 221, 222, 223, 224, 225, and 226, which may have the same implementation configuration as the corresponding peripherals on a single die 200.) When the number of signals in interfaces 248, 257, and 258 may be too large to be directly interconnected effectively, bridge masters 245 and 264 may coordinate to produce the logical effect 261 that they are doing so, and as a result, components such as the CPU 217, DMA controller 212, and peripherals 221, 222, 223, 224, 225, and 226 may implement their interfaces 237, 238, 239, 240, 241, and 242 in the same way that they would be implemented for the same components on a single die microcontroller 200.

[0088] It should be noted that the die interconnect 262 may perform physical links to enable logical links 262 for various interconnect 220 services. The die interconnect 262 interface is described in detail in Figure 2B. The die interconnect 262 interface connects the CPU die bridge master 245 and the ASIC die bridge master 264. This interconnect 262 actually enables and implements the extension of the set of interfaces 261 between the two dies in each bridge master 245 and 264.

[0089] It is easy to see that this division of a single microcontroller is not trivial, and the need to solve this problem becomes clear when considering the attempt to significantly reduce the number of connecting wires, for example, the attempt to fully expand the internal interconnectivity of a single-die microcontroller with a reduced wire count.

[0090] The disclosed communication technique introduces a microcontroller architecture and an interface 260 to bridge 245 to include an overall bus + interrupt + DMA structure that reduces the number of wires and replaces the wires with a logical structure that communicates through an even smaller set of signals. Furthermore, other die-to-die behaviors, such as PMU state, can be synchronized across this interface and debugger port control / data. These interfaces are acquired using other control devices, such as CPU debug 299 via interface 257 and PMU controller 244 via interface 258. (Note that the PMU controller 244, interface 258, master bridge 245, die interconnect 262, slave bridge 264, interface 280, security manager 267, interface 282, and PMU 268 perform the same function as the PMU interface 256. Also note that the explicit relatives of debug security are not shown in Figure 2A.) This logical structure leads to minimizing the communication interconnect while maintaining the desired logical behavior, as if these removed wires were present and under the complete control of the microcontroller firmware. This allows the microcontroller system to be implemented using multiple dies and / or packages while keeping the interconnect signal count small without requiring significant changes to the logic or behavior of peripherals or the CPU.

[0091] In Figure 3, the main interfaces described in Figure 1 are used to split the single-die microcontroller into two dies, namely the CPU die 246 and the ASIC die 271. To understand how to reduce the number of connecting wires while maintaining the full functionality of the single-die microcontroller, we will focus on the following interfaces, namely the bus interface AHB330, EVENTS335 which can include IRQ160 and DRQ130, PMU synchronization 340, and DAP345. (Note that the bus interface AHB330 may communicate a subset of interface 135 to which peripheral devices are located on the ASIC die 271. Since block addressing is handled in a distributed manner, there may be an unlimited number of peripheral devices on the ASIC die 271. Furthermore, EVENTS335 may communicate a subset of DRQ130 and IRQ160 for allocation to peripheral devices to which peripheral devices are located on the ASIC die 271, or to the comprehensive CPU die, or to peripheral devices that may be located on the ASIC die 271. In addition, PMU synchronization 340 may communicate a subset of interface 135 that is not handled by the PMU controller 244. Typically, clock gating and / or local power gating may be handled by the PMU controller 244, but other PMU functions may involve interaction with the ASIC die 271. Furthermore, DAP345 may communicate a subset of port interface 140 that can be handled through interface 280 and the debug access port.)In one embodiment, there may be a clock source 315 (or clock source 115) on the ASIC die 271 to provide a clock 317 (which may be an unnumbered clock, provided from clock source 115 to the clock multiplier and mux 110 and further provided to bridge 264 or bridge 365), and these can be extended to a CPU die clock multiplier and mux 310 (which may have a similar function to the clock multiplier and mux 110, and in some embodiments may be the clock multiplier and mux 110, but may transmit an additional synchronization signal from mux 310 to bridge 350 to handle clock multiplication, as described below). In one embodiment, bridge / serdes 350 and bridge / serdes 365 are connected through an inter-die logic interconnect 262 using retiming and I / O interfaces 355 and 360, respectively. Bridge / serdes350 can be attached to CPU die interfaces 330, 335, 340, and 345, and can provide the CPU die interface clock 325. Bridge / serdes365 can be attached to ASIC die interfaces 370, 375, 380, and 385, and can provide the ASIC die interface clock 317. (Note that ASIC die interfaces 370, 375, and 380 communicate signaling related to ASIC function 390, and interface 385 communicates with DAP395. These interfaces are relative to interfaces 330, 335, 340, and 345.) The two bridges 350 and 365 communicate through the interconnect 262 to extend the CPU die interfaces and synchronize them with their corresponding ASIC die interfaces.

[0092] In general, the challenge is to develop a microcontroller with two or more dies that a user and / or programmer can program (and reference) as a single-die microcontroller. Furthermore, the communication technique disclosed uses the concept of a bridge, which allows IP to be integrated into the microcontroller while residing on a second die, without involving changes to the normal microcontroller interface they would be using if they were on the same die. In other words, bridge 350 and its relative 365 create an appearance to both sides (software / CPU and hardware peripherals) where they are directly connected to each other. Moreover, the hardware interface on ASIC die 271 is intentionally the same as if it were implemented on the same die as the CPU.

[0093] In one embodiment, the AHB bus 330 has at least 115 signals, which consist of the following: HCLK (clock) HRESETn (Bus Reset) HREADY (Indicates that the data phase was not stalled, and therefore the command phase should be registered.) HADDR[31:0] (32-bit address bus) HPROT[3:0] (Bus access context information) HTRANS[1:0] (Transfer type) HSIZE[1:0](Transfer size) HWRITE (transfer direction) HBURST[2:0] (Burst type) HMASTLOCK (Displays locked sequences) NHNOSEC (Secure Access vs. Insecure Access) HWDATA[31:0] (Write data, from master to slave) HRDATA[31:0] (Read data, slave to master) HREADYOUT (Slave indicates ready to complete the data phase) HRESP (Slave indicator indicating whether the data phase should be completed with an error) (Note that each slave has an instance of HREADYOUT. Therefore, each of interfaces 237, 238, 239, etc., has its own instance. The bus logic may multiplex these signals into the HREADY broadcast signal. Furthermore, each slave may provide its own versions of HRESP and HRDATA. Therefore, each of interfaces 237, 238, 239, etc., may provide such outputs. The bus logic may multiplex these signals into a single set of unmultiplexed signals, which are provided to the bus master on interface 236, for example, when the CPU is the bus master.)

[0094] Furthermore, a typical controller has multiple peripheral IRQ channels. For example, the ARM Cortex M4 can provide 240 peripheral IRQ channels. A DMA controller can typically have 8 to 32 IRQ channels. To enable interrupts to wake up from sleep, this implementation requires an additional set of signals, each the same width as the IRQ set in the PMU interface. Many more signals are needed to support continuous entry into and exit from sleep mode. Security policy synchronization and debug ports will typically require additional signals. Directly connecting these signals between dies with dedicated wires would therefore be impractical for implementations, as even 100 wires would be impossible due to cost and / or manufacturing issues. Note that these signals may reside on interconnects 248 and 272 on individual dies, but may also be passed via messaging through the inter-die interconnect 262.

[0095] In one embodiment, a complete implementation (for example, typically without bus stalls and with minimal latency for IRQ / DRQ and PMU support) may use 42 wires to implement one or more functions. Alternatively, other embodiments (which may be slightly slower) may use 18 wires. Note that the DDR version may further reduce this to a 10-wire implementation with similar performance.

[0096] Another embodiment for systems without DMA or PMU support that allows for 16 interrupts may be implemented using three wires. While this method may be slow, many microcontroller applications can accommodate peripheral access latency.

[0097] Figure 4 shows selected details of one embodiment of an interface between two die systems with a minimal or reduced set of wires. The CPU die 246 includes a CPU die bridge 350, and the ASIC die 271 includes an ASIC die bridge 365. These bridges are connected to an interconnect 262 having signals NCLK420, NDIO421, NPHASE422, NRESP423, and NEVT424. The bridges combined with the interconnect can be used to synchronize various transactions, events, and services between components located on the two dies in a transparent manner. The signals NDIO421, NRESP423, and NEVT424 may be multi-bit signals in some implementations, but may be single-bit implementations in other implementations.

[0098] The interconnect 262 is divided into three signal groups. The first group includes a signal NCLK420 which can act as a synchronous clock for data transfer over the remaining signals. NLCK420 may be provided by a clock 459 from a clock source 315 on the ASIC die 271, which may correspond to a clock 458, and subsequently to a clock multiplier 401 on the CPU die 246, and a clock FCLK402. The second group, namely the transaction interconnect 460, may have NDIO421, NRESP423, and NPHASE422, which are used to implement transactions initiated by the CPU die 246 while being received and / or responded to by the ASIC die 271. An exemplary use for this interconnect is to relay a memory-mapped bus transaction 330 on the CPU die 246 to a remastered transaction 370 on the ASIC die 271, for example, between an AHB master 405 and an AHB slave connected via an AHB interface 437. Other transactions that the CPU may need to initiate for other purposes are also performed on the transaction interconnect 460. A third group includes the event relay interconnect NEVT 424, which is primarily used to propagate event message 375 from the ASIC die 271 to event 335 on the CPU die 246. Other services can utilize both the transaction interconnect 460 and the NEVT signal group, such as synchronizing the CPU die 246 PMU state and event 340 with the ASIC die 271 PMU state and event 380, or the CPU die debug interface configuration and event 345 with the ASIC die debug interface configuration and event 385.

[0099] This example uses an AHB format bus on CPU die 246 and ASIC die 271, but other format buses can be used for the bus interfaces to bridges 350 and 365. Furthermore, all or some of the bus interfaces can be in different formats.

[0100] The die-to-die bridge enables the implementation of multi-die controllers in a highly transparent manner for end users. In this context, transparency should be understood as functional transparency, rather than situational or systematic latency. By bridging several standard microcontroller interfaces between two dies, peripherals can be implemented in a highly agnostic manner to which of the two dies they reside on. This system bridges two dies in a master / slave relationship. The CPU die 246 is expected to include at least one microcontroller core (CPU) and its tightly coupled memory. The CPU die 246 may also include one or more DMA controllers 212.

[0101] The CPU die 246 does not need to have any direct connection to a lead frame (or other type of packaging style). The ASIC die 271 can be the gateway of the CPU die 246 to the outside world and can include memory-mapped peripherals to implement either interface and logic required to complete product functions that are not implemented on the CPU die 246 in a transparent manner to the CPU. Furthermore, in many cases, the CPU die 246 does not need to have any power management analog content, so that all or part of the PMU circuit configuration and associated logic can be implemented on the ASIC die 271. The CPU die should still control the PMU content as if it were a single-die system, which leads to the need for a distributed PMU system.

[0102] Interfaces bridged between dies may include the AHB bus, interrupts, DMA requests, and PMU requests and recognition responses. Furthermore, logical bridges may include at least the AHB, IRQ, DMA, PMU, and security. Transactions are conducted through these logical bridges via inter-die interconnects, including the transaction interconnect 460 and the event relay interconnect NEVT424. The transaction interconnect 460 can be used to bridge AHB transaction 330 to a remastered AHB transaction 370, but also to provide non-AHB control commands, for example, to synchronize PMU state 340 to PMU state 380. While the CPU die 246 can process AHB transaction 330 so that multiple AHB masters 405 and 406 are remastered to the ASIC die AHB transaction 370 on the ASIC die 271, many implementations may only perform service work for a single AHB master 405. The ASIC die 271 can remaster AHB transaction 370 on multiple AHB master interfaces 437 and 436, but many implementations only require the implementation of one master interface.

[0103] The transaction interconnect 460 synchronizes various services such as AHB bus transactions, PMU state changes, DMA and IRQ repolling, and / or security. This is accomplished by implementing a physical layer transaction bridge, which includes PHY 415 and PHY 426 connected by the transaction interconnect 460 through I / O 355 and I / O 360. This enables transaction exchange between CPU die 246 interfaces for synchronization with their AISC die 271 interfaces. For example, transactions presented to AHB slave interfaces 405 and 406 can be remastered into appropriate similar transactions on AHB master interfaces 437 and 436. Similarly, PMU operations presented to PMU transaction interface 404 can be remastered into equivalent transactions on PMU transaction interface 438. The DRQ synchronization logic 414 can similarly use interface 448 to perform transactions in order to communicate with the DRQ synchronization logic 428 through interface 465. The IRQ synchronization logic 451 can execute transactions using interface 449 to the IRQ synchronization logic 431, which uses interface 474. Signaling on the transaction interconnect 460, such as being encoded and sequenced by PHY 415, provides information decoded by PHY 426, enabling the transaction interconnect 460 to route transactions to the relevant interfaces. In one embodiment, this information is encoded as part of a command phase transfer. The event relay interconnect NEVT 424 can be used to pass enumerated ASIC die events 375 to CPU die events 335. Uses may include interrupt transfers and DMA request assertions. Other uses are for PMU synchronization, for propagating PMU state changes and events, or for forcing a reset from the ASIC die 271 to the CPU die 246.

[0104] Interrupt request synchronization is responsible for synchronizing interrupt requests detected on the ASIC die IRQ interface 433 with corresponding interrupt requests on the CPU die IRQ interface 475. For interrupts using event-based interrupt types, this synchronization can be performed using only the event relay interconnect 424 by translating detected IRQ activations as enumerated events. For interrupts using level-based interrupt types, this synchronization may require access to the transaction interconnect 460. If the interrupt controller provides configuration information in either IRQ interconnect 475 or as programming in the configuration SFR bank 417, each interrupt line can behave correctly for each interrupt.

[0105] DMA request synchronization is responsible for shadowing the DMA requests on the ASIC die 271 on the ASIC die DMA interface 434 to the corresponding DMA requests in the CPU die 246 DMA interface 407. Since DMA requests are level-based, a pair of state machines coordinate to ensure that the CPU die 246 DMA request line-level knowledge is appropriate to meet the needs of the DMA controller 212. This requires access to both transaction and event communication links to perform this function.

[0106] In some embodiments, it may be advantageous to add optional retiming logic to I / O355 and / or I / O360, such as handling clock skew or clock frequency differences.

[0107] The protocol can be implemented using multiple interconnect widths, one of which is more suitable for implementing many interconnects and flip-bump assemblies such as mechanisms for inter-die communication, while the other interface reduces the number of interconnects for implementation by utilizing a subset of pins, such as enabling smaller ball grid arrays or bond wire interconnect situations. A larger exemplary pin list includes NCLK420 being a single signal, as well as master interface clocks for transaction interconnects 460 and event relay interconnects 424. The master interface clocks can also be used as timing sources for CPU die 426 internal logic or clock generators and interface signals. Transaction interconnects 460 may include NPHASE422, NDIO421, and NRESP423. NPHASE422 is, for example, a single bit and can perform command / data phase control of NDIO421. NDIO421 is, for example, 32 bits and contains command / data content. The NRESP423, for example, is 3 bits and can provide transaction responses from the slave, as well as flow control. The event relay interconnect from the ASIC to the CPU includes the NEVT424. This interface may have a suitable width for coding a desired number of enumerated events within one or more transfer cycles.

[0108] These signals can be synchronized by the interface clock NCLK420. In one embodiment, the clock can be provided from the ASIC die 271 to the CPU die 246; in another embodiment, the clock can be provided by the CPU die 246 to the ASIC die 271; or both dies can be provided by another source. In one embodiment, the interface clock can be synchronized to the CPU die 246 clock FCLK402 (which is the source for the die's bus clock, e.g., HCLK) by having a clock of the same frequency, or by making FCLK402 a multiple of NCLK420, for example. Similarly, the logic of the ASIC die 271 can be synchronized to NCLK420.

[0109] By using double data rate (DDR) signaling for their interconnect signals, such as by transferring NDIO421 data on both edges of the NCLK, it is possible to reduce all or part of the wire count at the interconnect. Other interfaces such as NRESP423 and NEVT424 can also use DDR to reduce the interconnect count.

[0110] If the FCLK402 of the CPU die 246 is a multiple of the NCLK420, a clock multiplier 401 can be used on the CPU die 246 to generate FCLK402 from NCLK420. To coordinate the timing of the inter-die interconnect, the clock multiplier 401 can provide the CPU die bridge 350 with a signal indicating the phase relationship between NCLK420 and FCLK402 for each cycle of FCLK402. In one implementation, the clock multiplier 401 can provide a logic signal RE_STRB416 synchronized with FCLK402, indicating that the next FCLK402 edge is also an NCLK420 edge. The sequencer / PHY415 logic can then use this signal to coordinate updates with the interconnect logic occurring at the NCLK420 edge, while signaling into the non-PHY components of the CPU die 246 can behave at the FCLK402 rate.

[0111] Transactions via the transaction interconnect 460 are executed as a command phase and a data phase (commands without a data phase skip the data phase). The NDIO421 communication interface is created from a stateful bidirectional driver to enable wire reduction. During the command phase, its direction is from CPU die 246 to ASIC die 271. The command phase content is coded to indicate to PHY426 whether a data phase is required and, if so, what the data direction should be. The command indicates what kind of transaction is desired and relevant details for that transaction, such as AHB address phase information to be executed or information about desired non-AHB transactions. For transactions that perform AHB bus transactions, this includes the address, read / write, number of bytes to transfer, and access privileges for the transfer. Other transactions may use command phase coding with an enumerated field to indicate what kind of transfer it is, and the remainder of the command data is decoded according to its enumerated command type. The data phase contains the transaction payload (for commands where the command phase content indicates that a data phase should be executed).

[0112] These transaction interconnection 460 transactions can be executed using bidirectional NDIO421 signals and NRESP423 signals from the ASIC to the CPU. NDIO421 propagates command and data phase contents, while NRESP423 primarily provides data phase responses (such as OK, ERROR, etc.) along with data phase flow control, although the command phase can be optionally used to provide other information from the ASIC to the CPU. Additional signals from the CPU to the ASIC signal NPHASE422 can be used to facilitate burst transactions and synchronization.

[0113] The number of interconnects allocated to a BUS transaction can be adjusted to create a cost-to-latency trade-off. The (exemplary) raw width of command and data phase transfers via NDIO421 is 32 bits. In one embodiment implementing a 32-bit AHB (or other pipelining) interface without any significant latency (to the CPU), NDIO421 can be 32 bits wide. Low latency is achieved because the pipelining CPU bus issues command phase transactions for the "next" data phase simultaneously with pulling up the data phase for the previously issued command phase. Thus, the command and data phases for peripheral access occur in different bus clock cycles, and therefore, NDIO interconnects can be used for command transfers in one NCLK cycle and the associated data transfers in subsequent cycles. Due to the normal behavior of compiled code, it is virtually impossible for the CPU to access a non-memory address in two consecutive cycles (because the CPU needs to calculate the next access address). In one embodiment, during the command phase, the CPU die 246 can provide up to 32 bits of command phase content on the NDIO interconnect 421 to instruct the ASIC die 271. If the command indicates a data phase, both the ASIC and the CPU adjust the data direction for the subsequent data phase, and the data (up to 32 bits) is transferred as a data phase using 32 NDIO 421 signals.

[0114] In one embodiment, to perform AHB bus operation, the command phase content can be allocated as 1 bit for the read / write data direction, 2 bits (8, 16, 32, or a special number of bits) for the data transfer size, and 20 bits for the access address (1 MB). This can be treated as an address offset from several mutually understood ASIC die base addresses, and / or up to 9 bits of additional information about the transfer.

[0115] To extend the available commands or address space, information coded in the first command bus cycle can indicate the need for a second bus cycle. In this embodiment, a combined 64 bits of the extended command content can be transmitted. For example, one of the additional reserved bits in the above example can be used to indicate an address with an offset greater than 1 MB from the base address. The 20 LSBs of the address may be transferred in the first command cycle as usual, and the second bus cycle is used to transfer the remaining MSB. The CPU side of the bridge can check the CPU's bus address offset, and if it can be represented in 20 bits, it can issue a more efficient single-cycle command. Otherwise, it can indicate the need for a second cycle and provide the remaining information. By configuring the address space in the ASIC die 271 to identify the location of the most commonly used addresses within the lower 1 MB, most accesses can then use shorter command versions. Similarly, the bits available for additional transfer information are insufficient to encode several candidates for various AHB address phase signals. By coding these bits such that one of the codes indicates the need to add an additional command phase cycle to provide additional command content, the other single-cycle coding can be used to represent the most commonly used values ​​for these AHB signals, and as a result, the second command phase transfer is rarely required.

[0116] Another technique for indicating extended and / or alternative commands is to utilize one or more uncoded values ​​from the normal command signals to indicate an alternative command format. For example, in the example above, there are two bits used to represent three candidates for the transfer size. Using a fourth (or otherwise incorrect) value for this two-bit coding can signal that the entire command coding should be handled in an alternative way. This can also be used to engage in transactions initiated by CPU die 246 that are not mapped from bus operations (CTRL commands) in order to provide more or different information about bus transfers. For example, it is possible to signal a PMU state change indication from the CPU to the ASIC. These CTRL transactions may have coding such that the data phase is skipped for some subset of the coding. This can enable frequent but concise CTRL transactions that use only command bus cycles, reducing the time spent on the bus. Other CTRL coding may indicate a data phase and may perform data transfers to transfer data related to that transaction.

[0117] The command phase can provide special security or sequencing information regarding the transfer. Some bus transactions may be permitted only to code running on the CPU die with certain execution privileges and / or certain authorized bus masters (for example, they may be performed only by CPU1, so that CPU2 and DMA controller 212 are not permitted). For bus transactions requiring these special permissions, the CPU side of the bridge can observe these conditions as existing on the CPU die 246 AHB slave interface 405 and communicate this additional transaction information regarding the propagation to the ASIC die AHB master interface 437 using an extended command cycle.

[0118] Once the command phase is executed (and the command coding indicates it is for the data phase), the NDIO421 signal can be used to transfer data. If the data direction is from the ASIC to the CPU (read), both dies change the data direction on the NDIO421 after the command phase is complete. The data transfer can then use one or more cycles to transfer the relevant data. To perform a typical 32-bit single-bus transfer, a 32-bit NDIO421 bus can complete this within a single data phase cycle. To transfer even more data, a variant command can be used to indicate larger data. Both dies then use sufficient bus cycles to transfer the indicated amount of data. This can be used for bus burst transfers and for CTRL transfers with large payloads, as well as for transfers with word sizes larger than 32 bits (e.g., 64-bit atomic transfers).

[0119] To further reduce the interconnect width, command and data phase transfers can be serialized into multiple transfers with even smaller NDIO421 interconnect widths by exchanging bus cycles for interconnect counts. For example, an 8-bit NDIO421 can be used to transfer a 32-bit command and 32-bit data within 4 cycles. Since the transfer involves multiple NDIO421 cycles, the CPU must either wait through serialization and / or the NDIO421 data rate must be higher than the CPU bus rate. The same (or similar) command and data formats can be used on both sides, allowing for implementations with different interconnect counts to have the same functionality provided by each other. Aside from the additional latency in the transaction, nothing needs to be changed on either die except for the PHY415 and 426, I / O355 and 360 NDIO interconnect 421.

[0120] The improvement in serialization involves using data size information encoded within the command stage to indicate a transfer size smaller than 32 bits. For example, if an 8 or 16-bit transfer is indicated, the number of data phase cycles can be one or two, respectively, for an 8-bit NDIO421 interconnect width.

[0121] Similar improvements can be made in the command phase. By creating variants of the command with different lengths, the bridge can select the shortest coding length to encode the desired transaction. For example, 16-bit, 24-bit, and 32-bit commands can be used. A 32-bit variant may encode the command as if 32 interconnects were used, but even shorter variants can only encode a subset. A command can then be serialized into the number of cycles required to transfer its command width. For example, using an 8-bit NDIO421 interconnect width, 2 cycles may be used to transfer a 16-bit command.

[0122] To indicate the command width to the ASIC die 271, it is possible to allocate several bits within the first command cycle to indicate the command width. In the case of 16 / 24 / 32 width variations, this would use two bits in the first transfer phase for this information in the three variations, leaving 14 / 22 / 30 of the remaining useful bits for the command content. An alternative configuration may use dedicated bits in the second cycle to indicate the need for a third cycle, and similar bits in the third cycle to indicate the need for a fourth cycle. This would allow for 15 / 22 / 30 bits of useful command content. A third configuration can use a dedicated signal from the CPU to the ASIC, signal NPHASE422, to indicate a continuing command phase, so that none of the normal NDIO421 signals need to be used to communicate the command length. At the end of each command phase cycle, the ASIC die PHY426 can check NPHASE422 to determine whether further command phase serialization is required. In the first command phase cycle in which NPHASE422 indicates a discontinuation of the command phase, the ASIC die 271 can know the command width and move to the data phase (provided the command indicates a data phase).

[0123] NRESP423 is a response from the ASIC to the CPU that signals a path synchronized with the NDIO421 command / data phase. A typical width for NRESP423 can be 3 bits. In serialized versions, this can be reduced to 2 (such as when using 16 or 8 NDIO wires) or 1 (such as when using 4 or fewer NDIO wires). During the data phase, NRESP423 is used to provide indications from the ASIC to the CPU to provide information other than bus data. For example, an ERR response may be provided in the same bus cycle as the data is to be transferred to indicate a bus error in the ASIC peripheral. An OK response may be provided in the same cycle as the data to indicate a successful transaction. For slaves that require more time before they can transfer data, an STL response may be provided, which then delays the data phase until the next cycle. Other relevant information to be delivered from the ASIC to the CPU as part of the data phase can also be encoded.

[0124] An example of 3-bit (single-cycle) encoding for NRESP is shown below in Table 1.

[0125] [Table 1]

[0126] During the command phase, the NRESP423 can be used for other purposes. Since both sides of the bridge are aware of the command / data phase, the same bit pattern can be used to encode different concepts during the command and data phases. Some uses for this may be to indicate events such as an invalid command being issued, a command stall (the ASIC is not ready to receive a new command), and that a particular type of data or operation is ready.

[0127] In cases where NDIO421 signaling is serialized over multiple cycles, it may also be possible to serialize NRESP423 signaling. For example, 2 bits may be used for an NDIO421 with 8 interconnects. These may be coded as shown below in Table 2.

[0128] [Table 2]

[0129] In this coding, only one special response STL can be used in the first data cycle as a special code to restart the data in the next bus cycle when the ASIC is not yet ready to transfer data. Two of the other responses fully indicate the response code for that cycle. A fourth code is used to indicate that an additional cycle is needed to eliminate ambiguity among various other response candidates. The second bus cycle must then be used for the data phase to deliver this response (even when the data phase may have been completed in the first cycle, such as for an 8-bit transfer over an 8-bit NDIO). Additional data phase latency can be largely avoided by using longer serializations to encode only responses that rarely occur, while saving the interconnects required to signal possible responses within the first bus cycle.

[0130] For implementations requiring extremely low costs, the transaction interconnects NDIO421 and NRESP423 can be implemented using as few as two wires. In one implementation, NDIO421 may have an idle state, allowing the start of a serialized NDIO421 command to be indicated by a start bit. After the start bit is transmitted, the remainder of the NDIO421 command can be serialized. In one implementation, the number of command bits to be serialized may be fixed, allowing the ASIC die 271 to determine the end of the command phase by counting the number of command bits received after the start bit. An improvement is the use of a variable-length command phase, where coding in the bits preceding the command phase can indicate the total number of command bits and their meanings. After the command phase, the data phase can be serialized using one clock cycle per bit. The data phase can then proceed by serializing the number of bits indicated by the command phase command in the data direction indicated by that command. NRESP423 can also be serialized via a single wire. Following the command phase, the NRESP423 bits at the beginning of the read transaction data phase can indicate whether a stall should occur, for example, by indicating a high level on the NRESP423 for a stall. If no stall is required, the first data phase cycle of the NRESP423 can indicate a non-stall level, and the data phase can begin serialization on that cycle. If a stall is required, the ASIC die 271 stalls for the number of cycles necessary for the data to become available by driving the NRESP423 with the stall level. The stall can then be removed by driving a non-stall level, and as a result, data serialization can begin. During data serialization, various different codings of the NRESP423 can be serialized by different sequences of subsequent bits.In the case of write transactions, the storage mechanism can instead extend the last data phase serialization cycle in a similar manner.

[0131] Using a similar mechanism, any number of wires (two or more) can be used for transaction interconnects while maintaining bridging functionality, in order to strike a trade-off between bridging latency and interconnect count.

[0132] Transaction interconnect bridging can be improved by adding burst support. Many bus protocols, including AHB, provide support for burst transfers where a sequence of related addresses is used in a transaction. This is often used by the cache controller and DMA controller 212. This is also possible in the rare case where the CPU itself initiates a transaction on sequential addresses in consecutive clock cycles, whether as an explicit burst or in the exact same sequence as a burst. Furthermore, some bus slaves can implement FIFOing addresses, where each access to the same memory address is moved by the slave into FIFO enqueuing / dequeuing for write / read access, respectively. In the case of this type of slave, it is common to have several sequential accesses to this same address when it is desired to enqueue / dequeuing multiple FIFO items in a burst. When implemented by the DMA controller 212, this burst with a non-incrementing address becomes part of the DMA channel configuration. When this is done directly by software, this only becomes apparent after observing the sequence of bus transactions issued by the CPU. In these cases, it is desirable to use the NDIO421 interconnect to provide a mechanism for executing multiple related data transfers in response to only a single command transfer. Otherwise, after every data transfer, the NDIO interconnect would have to be used to provide the command phase for the next transaction in the burst, effectively halving the NDIO421 transfer rate for the burst.

[0133] To achieve burst transfer, an additional interconnect signal NPHASE422 can be introduced from the CPU to the ASIC. This signal indicates to the slave whether the next interconnect clock cycle is expected to be a data phase. The ASIC die 271 receives this signal, and if asserted during the data phase, understands that the next interconnect bus cycle should be a burst continuation from the current data phase. The ASIC die 271 can then issue a new command phase on its bus master interface 436 or 437 to continue the burst without requiring an additional command phase indication on NDIO421. To ensure that stalls are handled correctly, for data phases where NRESP423 is STL, both the CPU die bridge 350 and the ASIC die bridge 365 continue the data phase regardless of whether NRESP is asserted or not. This is because the data phase must be extended beyond this slave stall, regardless of whether the burst will continue or not. A command phase on NDIO421 can provide information on how bus transactions should be coordinated from a certain burst transaction to its continuation. Since it is more common to have incrementing transactions, the default command format can be set to default for this behavior. Note that incrementing typically means adding the appropriate amount to the address to advance beyond the previous address by the size of each transfer. For example, if a 16-bit transfer is indicated on the AHB bus using HSIZE, incrementing the address from the previous address would be adding 2, since the AHB uses byte addressing. Command variants may be provided to indicate other types of update behavior, such as non-incrementing transactions for FIFO addresses, or wrapping transactions for cache-like behavior.

[0134] The CPU die bridge 350 can also be configured to provide access to multiple AHB masters, for example, by providing multiple AHB slave ports on the CPU die bridge 350. An exemplary implementation provides a bus slave interface for a bus mastered by the CPU via AHB interface 405, and another bus slave interface for a bus slave interface mastered by a DMA controller via AHB interface 406.

[0135] An arbiter 418 may be provided to mediate the transaction interconnect between transactions issued by the CPU on AHB interface 405 and additional bus masters on AHB interface 406, and special BUS transactions unrelated to memory-mapped transactions, such as those on PMU interface 404 and DMA interface 407. Since these various services request access to the transaction interconnect for transactions, the arbiter can prioritize one source over others in case of conflict. The arbiter can do this by strict prioritization, by round-robin service work, by scheduling with guaranteed maximum latency, by a combination of these techniques, or by other preferred methods. The selected service may then be allowed access to PHY 415 using interface 457. In some implementations, the CPU may influence the mediation method by providing special function registers in its configuration SFR (register) bank 417. When multiple services request access, a stall indication may be provided for services whose access is temporarily denied by the arbiter 418, delaying the requested transaction until the service work is performed.

[0136] In an implementation where the CPU die bridge 350 is configured to act as a slave on multiple buses such as 405 and 406, it is possible that slow peripherals on the ASIC die 271 may unnecessarily stall the completion of transactions on the AHB bus 437 on the ASIC die 271. This creates a situation where NRESP 423 indicates STL for multiple cycles, occupying the transaction interconnect without any progress in data transfer. To improve performance in such cases, the ASIC bridge 365 may implement an additional bus master port 436 to master a second ASIC die AHB bus. If a transaction on the AHB bus master 437 takes several cycles to complete, an NRESP 423 indication of SPLIT may be shown during the NDIO 421 data phase for that transaction. This indication causes the CPU die bridge 350 to terminate the interconnect bus transaction without resolving it. The ASIC diverbridge 365 continues to master this interrupted operation on its AHB bus master interface so that the operation can continue on the AHB bus 437, and stores the AHB transaction results in its memory regardless of whether the bus slave completes the transaction. Meanwhile, the arbiter 418 can issue other NDIO421 command phases for unrelated transactions. If such a transaction is to occur and this transaction targets an AHB bus slave, this transaction can be issued by the ASIC diverbridge 365 as a bus operation using its alternative bus master interface 436. In some advantages, the arbiter 418 can issue an NDIO421 command variant JOIN to resume the data phase for a previously interrupted transaction. If the transaction on the bus master 437 has successfully completed by this time, a data phase response is delivered from the results stored in the bridge's memory.If there are still pending transactions on bus master 437, the data phase will resume as if the split had never occurred.

[0137] Transactions using the transaction interconnect provide a sufficient mechanism for the CPU die 246 to initiate relevant interactions with the ASIC die 271. In some cases, the ASIC die 271 may initiate interactions on its own. For this reason, event relay using the NEVT interconnect 424 is used. The NEVT 424 is driven by the ASIC die 271, which it can use to send messages to the CPU die 246. These messages typically take the form of selections from a default set of enumerations. Typical messages may indicate interrupt activity on the ASIC die 271, DMA request activity on the ASIC die 271, PMU state changes on the ASIC die 271, etc. In cases where the ASIC die 271 should further provide non-enumerated data as part of the interaction, coordination with the event recipient through the transaction interconnect allows for scheduling of payload delivery. Alternatively, it is possible to provide several cycles of an enumerated preamble and thereafter any data to be transferred via the NEVT 424.

[0138] Due to the relatively large number of potential enumeration events, NEVT424 signaling can be implemented as serialized messages to keep the number of NEVT424 interconnects small. In an exemplary implementation, NEVT424 can be implemented using, for example, five wires and two consecutive clock cycles of transmission with serialized event messages. The exception is a special coding (e.g., all 0s) which is a single-cycle pseudo-event IDLE indicating no events. Under this coding, there are 31 possible values ​​for the first cycle of a NEVT424 transmission and 32 possible values ​​for the second cycle, for a total of 992 possible events. Other implementations with different numbers of wires and different serialization lengths can be used to optimize the trade-off between the number of wires, serialization latency, and the number of possible events. Variable-length event coding can also be used so that more commonly used events and / or events where lower latency is desired can be represented using shorter serialization lengths, while longer serialization lengths still allow for an increase in the number of possible events that would suffer from the disadvantages of longer serialization. Other implementation forms include the start bit, and 2 N It uses only one wire, each containing an N-bit sequence for transmitting the same number of different events. To avoid potential problems involving a lack of synchronization, the N-bit sequences can be coded to avoid sequences with multiple trailing zeros, so that the guard band between one sequence and another for resynchronization is minimized.

[0139] In one embodiment, EVENT transfers can be optionally serialized to increase the number of possible events. In one implementation, five wires can provide 256 events by using one of the wires as a first / second transfer stage indicator and the other four as first and second data nibs. In another embodiment, a start bit, and 2N Only one wire is used, each having an N-bit sequence for transmitting the same number of different events. To avoid potential problems involving a lack of synchronization, the N-bit sequences can be coded to avoid sequences with multiple trailing zeros, so that the guard band between one sequence and another for resynchronization is minimized.

[0140] In cases where EVENT latency / bandwidth is less critical than a smaller interconnect count, it is possible to use a single set of interconnects to perform both NRESP423 and NEVT424 functions. This can be done by making the purpose of the shared NEVT424 / NRESP423 interconnects to function as transactional state for the transactional interconnect 460. During the time that NRESP423 representation is required to form a data phase response, both bridges can use the shared NEVT424 / NRESP423 interconnects for NRESP423 communication. If a NEVT424 event is being serialized when this is done, it can be understood that both bridges should suspend NEVT424 serialization for the duration of the NRESP423 communication. Once the NRESP423 content is communicated, both bridges can resume using the shared interconnects for NEVT424 purposes and can continue serialization from the same position where the suspension occurred.

[0141] IRQ indications are propagated from the ASIC die 271 to the CPU die 246 using a combination of the transaction interconnect 460 and the NEVT interconnect 424. The ASIC IRQ rising edge (activation) is detected by the IRQ synchronization logic 431 on the ASIC die 271 and transferred to the NEVT 424 interconnect telegram, i.e., an event or message to be notified to the CPU die 246. The IRQ synchronization logic 431 can request these NEVT communications by providing a request on interface 470. Because the NEVT interconnect may not be immediately available for sending this telegram due to other NEVT activity, the IRQ synchronization logic 431 may implement a register for its interrupt to indicate the need to send this telegram at a later time, such as when the NEVT arbiter / mux 430 grants this access. Reception of such a telegram is provided to the IRQ synchronization logic 451 on the CPU die 246 using an indication signal 447. Upon receiving such an indication, the IRQ synchronization logic 451 can provide a single-clock cycle IRQ indication at the appropriate index of its IRQ output on the IRQ interface 475. These IRQ outputs can be provided to an interrupt controller on the CPU die 246, such as an NVIC contained within the CPU 217. The CPU die 246 interrupt controller can be configured to use either edge detection or level detection for its IRQ interface 475 signals to its interrupt controller. This allows the CPU to see new events on the ASIC die IRQ interface 433, but does not, on its own, result in synchronization with the assertion of IRQ signals on the IRQ interface 433. How assertion is handled depends on whether the interrupt source intends its signals to be edge-detected or level-detected.

[0142] Interrupt service requests to edge-based ASIC die 271 sources are propagated from ASIC die 271 using event messaging on the NEVT424 interconnect, as previously described. This is a perfect solution for synchronizing such interrupt sources, as edge-based IRQs do not propagate any information about asserted stop edges.

[0143] Interrupt service requests to the level-based ASIC die 271 source are propagated from the ASIC die 271 to the CPU die 246 by a combination of NEVT424 and transaction interconnect 460 signaling. Activation of the interrupt service request on the ASIC die 271 is propagated to the CPU die 246, as in the edge-based case. The IRQ indication on the IRQ interface 475 is asserted for a single cycle, even if the corresponding signal on the ASIC die IRQ interface 433 is still asserted. This causes the interrupt controller to set the PENDED register for this interrupt line. The interrupt controller does not respond differently to any level on its own interrupt service request input, such as the IRQ signal on the IRQ interface 475, and therefore does not require further information from the interrupt source until its PENDED register is later cleared. Therefore, the CPU die bridge 350 can provide an inactive signal for its interrupt on the IRQ interface 475 and is not concerned with whether the ASIC die 271 interrupt service request in the signals on the IRQ interface 433 is active or inactive. The interrupt controller does not re-examine its interrupt service request input only after the PENDED register has been cleared. When the execution of the interrupt service routine clears the PENDED register, the PEND_CLR signal for that IRQ inside the interrupt controller can be asserted for a certain clock cycle, and the ACTIVE signal inside the interrupt controller can be asserted for the duration of the execution of that interrupt service routine. These signals can be provided from the interrupt controller to the CPU die IRQ synchronous logic 451 using IRQ hooks on the IRQ interface 475. When it is software that clears the PENDED register, this can result in the PEND_CLR signal for that IRQ inside the interrupt controller being asserted for a certain clock cycle without the ACTIVE signal being asserted.The interrupt controller will re-examine its interrupt service request input for its IRQ number only when its PENDED register is not set and the ACTIVE signal is not asserted. Therefore, the IRQ synchronization logic 451 of the CPU die bridge 350 can register the clearing of the PENDED signal by observing the assertion of PEND_CLR, and can wait for the ACTIVE signal not to be asserted as an indication that the ASIC die 271 IRQ signal needs to be re-polled on the IRQ interface 433 for that interrupt to be re-established, regardless of whether the interrupt source on the ASIC die 271 asserts its IRQ. The IRQ synch can execute this re-polling operation using a special command on the transaction interconnect 460 by requesting this command on the request signal 449 through the arbiter 418. Upon receiving this command, the ASIC die sequencer / PHY426 can notify the IRQ queuing / scheduling logic 431 that it should re-examine the appropriate interrupt request signal in the signals on the IRQ interface 433, and if asserted, can schedule a telegram indicating this via the NEVT424 interconnect. Note that this telegram may have the same coding as the previously described activation telegram, as its processing on the CPU die 246 may be the same. If this happens, the NEVT424 telegram will be received using the event receiver 412 and provided to the IRQ synch logic 451, resulting in a single-clock cycle assertion of the appropriate IRQ indication on the IRQ signal on the IRQ interface 475, causing the interrupt to be held again in the interrupt controller. If the interrupt is not asserted at this time, the IRQ queuing / scheduling logic 431 may wait for the rising edge of the interrupt signal in the IRQ signal on the IRQ interface 433 to provide the previously described activation NEVT424 telegram.

[0144] The CPU dibridge 350 can be provided with information for each interrupt indicating whether the interrupt is intended to be treated as an edge detection or a level detection. In one embodiment, the CPU dibridge 350 can provide this information using a configuration SFR bank 417. In another embodiment, the interrupt controller can provide this information as part of its interrupt hook on the IRQ interface 475. The CPU dibridge 350 can then use this information to select an appropriate method for synchronizing the IRQ state for each interrupt source.

[0145] In some CPU die implementations, access to the internal interrupt controller signals PEND_CLR or ACTIVE may not be available. To address this, an alternative mechanism for level-based interrupt repolling can be provided through special function register access. The special function register can be implemented within the configuration SFR bank 417 of the CPU die bridge 350, allowing the CPU to directly request repolling for an IRQ. This can be accomplished by providing a repolling indication to the IRQ synch logic 451 from appropriate access to the configuration SFR bank 417, such as detecting a write access in the appropriate address of the configuration SFR bank 417. Software can then directly request repolling by writing the appropriate value to this special function register, regardless of whether the level-based interrupt requires repolling. Typical examples include software clearing the PENDED bit for that interrupt, or at an appropriate point within the interrupt service routine.

[0146] DMA request synchronization from the ASIC271 die to the CPU die 246 can be performed by a combination of NEVT424 and transaction interconnect 460 signaling. The ASIC die DRQ synchronization logic 428 and the CPU die DRQ synchronization logic 414 communicate through their interconnects to propagate changes in the DRQ indication on the DRQ signal 434 to corresponding changes on the CPU die DMA signal 407, thereby providing the ability for DMA enable peripherals to provide the DRQ signal on interface 434 to interact with the DMA controller 212 via the DRQ signal in interface 407. The DRQ synchronization logics 414 and 428 can statefully propagate changes on interface 434 to corresponding signals on interface 407 in a manner appropriate to the intent of the signal as a DMA request.

[0147] For each DRQ signal in interface 434 to be synchronized with CPU die interface 407, CPU die DRQ synchronization logic 414 may have states UNKN, ARMD, and TRIGD. ASIC die DRQ synchronization logic 428 may have states UNKN, ARMD, PEND, and TRIGD. Note that some of these states may have the same name, but their state codings do not need to be the same, and there are cases where synchronization logics 414 and 428 do not need to be in states with the same name at any given time.

[0148] At startup, or whenever the relevant DMA channel is disabled, both synchronization logics 414 and 428 may be in the UNKN state. When the ASIC die DRQ synchronization logic 428 is in the UNKN state, it expects the CPU die to have no interest in synchronizing the relevant DRQ signal in interface 434. When the CPU die DRQ synchronization logic is in the UNKN state, it expects the ASIC die to not notify it of any changes and to provide an inactive signal to the relevant DRQ signal in interface 407. Whenever the CPU die synchronization logic 414 is in the UNKN state and the relevant DRQ is enabled for service work, the synchronization logic 414 can indicate this to the ASIC die synchronization logic 428 via a transaction on the transaction interconnect 460 through interfaces 448 and 465. Once this transaction is complete, both the DRQ synchronization logics 414 and 428 can enter their ARMD state for their DRQ signal.

[0149] In the ARMD state, the ASIC die synchronous logic 428 expects the CPU die synchronous logic 414 to also be in the ARMD state and hopes to be notified of any active level observed on the relevant DRQ signal in interface 434. When the CPU die synchronous logic 414 is in the ARMD state, it provides an inactive level on the corresponding DRQ signal in interface 407, expecting the ASIC die synchronous logic 428 to also be in the ARMD state and to be notified of any observed activation of the corresponding DRQ signal in interface 434.

[0150] Whenever the ASIC die synchronous logic 428 is in the ARMD state and an active level is detected on the relevant DRQ signal in interface 434, the ASIC die synchronous logic 428 can enter the PEND state. In this state, the ASIC die synchronous logic 428 can attempt to schedule a DRQ activation telegram on the NEVT using interface 467 via the NEVT arbiter / mux 430. Once this telegram is complete, both the ASIC die synchronous logic 428 and the CPU die synchronous logic 414 can enter the TRGD state. The ASIC die synchronous logic 428 can detect this telegram completion on interface 467, while the CPU die synchronous logic 414 can detect this telegram completion on interface 454 from the NEVT receiver 412.

[0151] When in the TRIGD state, the CPU die synchronous logic 414 provides an active level on the relevant DRQ signal in interface 407, expecting the DMA controller 212 to respond by taking appropriate responsive action. When in the TRIGD state, the ASIC die synchronous logic 428 expects the CPU die synchronous logic 414 to also be in the TRIGD state and hopes that any deactivation of the relevant DRQ signal in interface 434 will be notified.

[0152] The DMA controller may require a precise update of the cycle to the DMA request line initiating its responsive bus transaction. In the case of variable-length data to be read from a DMA slave, this can be used to terminate the transfer after the data has been delivered. In other cases, this may be because, in response to a previous DMA request, the DMA controller is in the process of completing the requested transfer, and the propagation delay from the slave's DMA request assertion stop for processing the last bus data phase may result in an incorrect re-trigger of a DMA operation that was not actually requested by the slave. For each DMA responsive AHB bus transaction, it is desirable that the DRQ signal in interface 407, synchronized with the CPU die, arrives with the same latency as the synchronized response signal on the CPU die AHB interface 405 or 406. In this way, the relevant signals in the combined interfaces 405 / 406 / 407 during the CPU die cycle in which the DMA controller 212 completes its data phase are the same as the corresponding signals in interfaces 437 / 436 / 434 for the ASIC die cycle, and the data phase of the corresponding AHB transaction data phase is completed for the ASIC die DMA enable peripherals. To enable DRQ assert stop to be cycle-synchronized with AHB data phase delivery, NRESP 423 in a transaction on the transaction interconnect 460 can be used to indicate assert stop as part of the data phase response. The DMA controller 212 can use the DMA hook 407 to provide an indication of which DMA request a particular transaction on the AHB interface 405 or 406 is responding to during its AHB address phase, for example, by providing a binary-coded DRQ number as part of the address phase. An NDIO 421 command that synchronizes the relevant AHB transactions on the transaction interconnect 460 can include this DRQ number information as part of the command coding.This information can be provided to the ASIC die DRQ synchronization logic 428 via interface 465 so that it can select the appropriate DRQ signal in interface 434 to monitor the AHB transaction data phase on interface 437 or 436, and to PHY 426 using interface 465. PHY 426 of ASIC bridge 365 can then provide two variations of the NRESP 423 coding for a successful data phase, namely OK and OKDN. OK indicates that the data phase has completed successfully and that the DMA request indicated during the associated command phase is now active. OKDN indicates that the data phase has completed successfully and that the DMA request indicated during the associated command phase is now not active. The PHY 415 of the CPU die bridge 350 can detect OKDN coding on the NRESP 423 during the completion of the data phase of the transaction interconnect 360, and can provide this information to the DRQ synchronization logic 414 using interface 455 by providing a signal to each of the DRQ sources 434 indicating that the transaction marked as a response to that DRQ is showing an OKDN NRESP. The CPU die DRQ synchronization logic 414 can respond to this OKDN reception by asserting a stop to the relevant DRQ in interface 407 and changing its internal state for that DRQ to ARMD. Similarly, whenever an OKDN is delivered as a response phase on the NRESP 423, the ASIC die DRQ synchronization logic can change its internal state for the relevant DRQ from TRGD to ARMD.

[0153] The synchronization of the DRQ signal deactivation on the ASIC die 271 outside of a responsive AHB transaction does not require such synchronized latency. The ASIC die synchronization logic 428 can detect the deactivation of the DRQ signal with the TRGD state in interface 434, which is not related to any currently ongoing transactions on the transaction interconnect 460, and can attempt to schedule a DRQ deactivation telegram on the NEVT using interface 467 via the NEVT arbiter / mux 430. Once this telegram is complete, both the ASIC die synchronization logic 428 and the CPU die synchronization logic 414 enter the ARMD state. The ASIC die synchronization logic 428 can detect the completion of this telegram on interface 467, and the CPU die synchronization logic 414 can detect the completion of this telegram on interface 454 from the NEVT receiver 412.

[0154] Whenever the CPU die synchronization logic 414 is not in an UNKN state for a DRQ and the associated DRQ is disabled for service work, the synchronization logic 414 can indicate this to the ASIC die synchronization logic 428 via a transaction on the transaction interconnect 460 through interfaces 448 and 465. Once this transaction is complete, both the DRQ synchronization logics 414 and 428 can enter their UNKN state for their DRQ signals, and the associated DRQ in interface 407 can be asserted and stopped.

[0155] Using these mechanisms and circuit techniques, the CPU die bridge 350 and the ASIC die bridge 365 can bring about DRQ synchronization between the CPU die 246 (having DRQ synchronization logic 414) and the ASIC die 271 (having DRQ synchronization 428), synchronizing the ASIC die DRQ signal 434 with the CPU die DRQ signal 407 so that the DMA controller 212 on the CPU die 246 can respond to DMA enable peripherals on the CPU die 271, as indicated by the DRQ signal 434. Each of these state machines can track its internal state for each synchronized DRQ signal 434 to assist in this synchronization.

[0156] PMU state transitions and synchronization can be synchronized between two dies using the transaction interconnect 460 and the NEVT424 die interconnect. In particular, PMU event signals on the PMU interface 432 may be communicated by the event transmitter 429, received by the event receiver 412, and provided as PMU event signals on the PMU interface 411. These PMU event signals on the PMU interface 432 can originate from the ASIC die PMU 268, and the PMU interface 411 signals can then be provided to the CPU die PMU controller 244, thereby enabling the ASIC die PMU 268 to provide updates to the CPU die PMU controller 244. Any number of enumerated events can be reserved for such updates so that each event message can provide different information. Typical events such as reset propagation, voltage drop warning, tuner ready indicator, and clock speed change notification may include reset propagation, voltage drop warning, tuner ready indicator, and clock speed change notification. To enable a wide range of extensible events, it is also possible to reserve one of the enumerations for events that require subsequent transactions on the transaction interconnect to remove ambiguity. As a result, events that do not require low latency can use this common event coding, thereby not consuming one of the enumeration NEVT codings.

[0157] Similarly, the CPU die PMU controller 244 can initiate such a transaction using the PMU transaction interface 404 to communicate with the ASIC die PMU 268 via the transaction on the transaction interconnect 460. The arbiter / mux 418 can then schedule time for this transaction for service work by the CPU die PHY 415. The ASIC die PHY 426 can then decrypt the transaction and provide a display on the PMU transaction hook interface 438, which can then be provided to the ASIC die PMU 268. In some cases, this transaction can be treated like an enumeration event from the CPU die to the ASIC die, such that only the command phase encoding this enumeration event is required to be transaction on the interconnect 460. In this case, the decrypted command phase detection can be provided as information about the PMU transaction interface 438, and both PHY 415 and PHY 426 skip the interconnect 460 data phase. Other PMU command coding can imply a data phase, allowing additional data to be transferred between the PMU controller 244 and the PMU 268 using interfaces 404 and 438.

[0158] In many cases, the ASIC die 271 may include circuitry that supplies power to the CPU die 246, other components on the ASIC die 271, or external ports. In these cases, most of the PMU logic involved in sleeping and wake-up, including the WIC, may also reside on the ASIC die 271. In most microcontroller architectures, sleep is initiated by the CPU.

[0159] During the sleep sequence, the CPU provides its signaling of its intention to sleep on its PMU interface 256. In a single-die implementation configuration 200, this interface 256 can communicate directly with the PMU 205. In a multi-die implementation configuration, the CPU die PMU controller logic 246 can block this signaling. The CPU die PMU controller logic 246 can then interact with the ASIC die PMU 268 to perform the sleep by engaging in several transactions on the transaction interconnect 460. For a CPU implementing WIC, the CPU can use its PMU interface 256 to transfer the relevant portion of its NVIC state to the WIC state, providing a configuration for interrupt / exception detection logic that reflects a similar interrupt masking function in NVIC. The CPU die 246 PMU controller 244 can instead receive this signaling and use the transaction interconnect 460 to translate it into one or more transactions and transfer the state to the WIC implemented in the ASIC die PMU 268. This allows the PMU to disable NCLK420, power supply to the CPU die 246, or other services during sleep, while still providing a standard wake-up mechanism for the WIC controller. Other communications on the transaction interconnect 460 and NEVT424 can be used by this PMU synchronization logic to perform correct inter-die sequencing and enable a multi-step handshake type sleep sequence between the CPU 217 and PMU 268 via the CPU PMU interface 256 in a standard manner. During wake-up, similar transaction interconnect 460 and NEVT424 transactions can execute the necessary sequences between the CPU 217 and PMU 268 via the CPU PMU interface 256.When a wake-up is initiated by the WIC on the ASIC die 271, the transfer of state back to the NVIC can be performed as part of the wake-up sequence, for example, by a transaction interconnect 460 transaction that reads this state from the ASIC die WIC as part of the wake-up sequence. Alternatively, all or part of this WIC state transfer in wake-up can be performed using an enumerated event on NEVT424 at a suitable time during or after the wake-up sequence. For example, it may be possible to alert the CPU die NVIC which interrupt or exception caused the wake-up by using the ASIC die IRQ synchronization logic 431 to send the same NEVT424 enumerated message that it would do if this same interrupt or exception were occurring outside of sleep. By transferring this event at a suitable time for the wake-up sequence, the logic on the CPU die 246 can ensure that this interrupt or event is held in the CPU die NVIC before the CPU 217 begins execution.

[0160] Another aspect of sleeping is the proper management of the interconnect interface so that both the transaction interconnect 460 and the NEVT interconnect 424 are idle. As a result, when sleep occurs, communication on their interfaces is only partially serialized, potentially leading to abnormal transactions. If this is to happen, one die may understand that data transfer is complete or that events or handshakes are being communicated, while the other die has a different understanding. To address this, transactions on the transaction interconnect 460 can be used during sleep negotiations to disable any further new NEVT424 activity, even after any NEVT424 serialization that may already be in progress has been completed. To ensure that NEVT424 messages are delivered atomically and that further NEVT424 messages are interrupted when sleep is initiated, this command can be automatically issued by the PMU controller 244 as part of the sleep sequence at an appropriate time during sleep negotiations. Incomplete transactions on the transaction interconnect 460 can be avoided by performing the final transaction on that interconnect before entering sleep mode (a "completed transaction" with coding indicating that it can now enter sleep, which finalizes the sleep negotiation sequence). The CPU die BUS arbiter / mux418 and the ASIC die NEVT arbiter / mux430 can then stall any requested operation through the sleep sequence and then reactivate service work at a suitable point in the subsequent wake-up sequence.

[0161] Furthermore, the ASIC die 271 may include a configuration register bank 419. Security policy synchronization for the debug access port can also be synchronized using a transaction interconnect and NEVT bridging. In one embodiment, a communication interface for the debug access port may be located on the ASIC die 271. An attached debugger can communicate to this interface according to a policy accessed via a security manager 267, which can be set by a security manager 243 on the CPU die 246. This security policy may include whether the attached debugger is allowed to access communication with the CPU die, whether the debugger is allowed to directly access resources on the ASIC die 271, whether power state transitions can be initiated by the debugger during sleep modes or other times when the CPU die may not be powered on or clocked, and authorization credentials such as challenge / response sequences to permit several types of access.

[0162] The security policy can be transferred from the CPU die security manager 243 to the ASIC die security manager 267 located on the ASIC die during the initial power-up sequence by using a transaction on the transaction interconnect 460 initiated by the CPU die security manager 243. Until this policy is transferred, the ASIC die security manager 267 may not allow access to resources with ambiguous security policies until the relevant policy is transferred, in order to prevent unauthorized activity on the debug port. Alternatively, the ASIC die security manager 267 may disable the debugger communication interface until the policy is provided. The ASIC die security manager 267 may maintain this policy through any CPU die 246 sleep cycle so that it can respond to debugger requests. Updates to the security policy, such as by the CPU 217 software adjusting the configuration of the security manager 243, can be communicated to the ASIC die to update its policy using a transaction on the transaction interconnect 460.

[0163] Some debugger operations can initiate changes to a desired CPU state, such as forcing a power state and halting / unhalting CPU operation. The debug port on ASIC die 271 can initiate such operations, subject to permission from the security manager on one or both dies, using the NEVT424 message.

[0164] During some stages of the manufacturing and product development process, it may be useful to be able to attach a debug port to the ASIC die 271 without any connected CPU die 246. To enable this, the ASIC die security manager 267 can determine that there is no attached CPU die 246 and enable a default policy of accessing all or part of the ASIC die 271 resources according to the security policy of the unattached portion.

[0165] When analyzing faulty parts or parts returned by the customer, it may be useful to allow access to insecure resources during fault analysis. To enable this, a default security policy can be implemented within the ASIC die security manager 267 to address cases where the security policy fails due to misconduct on CPU die 246.

[0166] When the CPU die security manager 243 is enabled along with lifecycle management, product lifecycle progression can be implemented. For example, to enable debugging of product returns, a portion of the lifecycle can be changed from the normal operating mode to a fault analysis mode. The ASIC die security manager 267 can be implemented to respond to lifecycle state change commands from an attached debugger. The security manager 267 and debug interface on the ASIC die 271 can be implemented to respond to this communication regardless of the security policy provided by the CPU die security manager 243. The ASIC die security manager 267 can initiate a lifecycle state change using the NEVT424 event. This event can be provided to the CPU die security manager 243, which can then engage in a BUS transaction to perform authentication against the debugger's credentials, such as by forming a challenge and verifying the response. Upon successful authentication, the CPU die security manager 243 can take the necessary steps to execute the lifecycle change, such as erasing confidential non-volatile memory and writing the lifecycle state progression into non-volatile memory that stores this state. Once completed, the debug ports and security managers 243 and 267 can use the updated security policies that match this new lifecycle state.

[0167] Figure 5 shows an example sequence diagram of bus transactions using this technique. In this example, signals are shown for signals on CPU die 246, inter-die signaling 262, and ASIC die 271. In detail, selected signals from CPU die AHB330 address phase signal 514 and CPU die AHB330 data phase signal 512 are shown. Similarly, selected signals from ASIC die AHB370 address phase signal 508 and ASIC die AHB370 data phase signal 512 are shown. In this example, both the CPU and ASIC implement AHB on data buses 248 and 277 (note that the ports on which the bridge interacts with AHB are 405 and 437). In this example, the CPU initiates four bus transactions for addresses A0, A1, A2, and A3. A0 relates to peripheral (BLOCK1) 216 on ASIC die 271, A1 and A3 relate to SRAM block 518 on CPU die 246, and A2 relates to peripheral (BLOCK2) 520 on ASIC die 271. In this case, the clocks are synchronized with each other and at the same rate. BLOCK1 and / or BLOCK2 are any slave peripherals located on the ASIC die.

[0168] As cycle 1 522 begins, the CPU issues an AHB transaction on its address phase signal 514 for a 32-bit write to address A0. The CPU die AHB block address decoder determines that this address is in the ASIC die 271 block address space and therefore activates HSEL532 to the CPU die bridge 350 during the AHB address phase. The CPU die bridge 350 uses the required information (e.g., LSB of HADDR570, HWRITE566, HSIZE568, etc.) to form a command to be issued on NDIO421 as the interconnect 460 command phase. In this example, it is assumed that the command phase signal is generated by combining the CPU die AHB address phase signals, but this can also be done with registration. If registered, the command will be issued on NDIO421 in a clock cycle later than the clock cycle for the CPU die's AHB address phase. The ASIC die bridge 365 responds to this command by initiating the corresponding AHB bus transaction on its address phase signal 508. The AHB block address decoder on ASIC die 271 determines that the address is associated with BLOCK1 and therefore issues an HSEL516 for that block as part of the ASIC die AHB address phase.

[0169] In cycle 2 534, the CPU provides a write payload D0 on HWDATA 536 as part of the CPU die AHB data phase signal 512 for the transaction to A0 initiated in the previous cycle. The CPU die bridge 350 receives this data and transfers it to the ASIC die 271 using the NDIO 421 interconnect signal as the interconnect 460 data phase. The ASIC die bridge 365 propagates this data to its own HWDATA 538 for use by the BLOCK1 peripheral. In this case, the BLOCK1 peripheral can complete its operation during its cycle and therefore asserts its HREADYOUT 540 to allow the ASIC die AHB data phase to complete. The ASIC die 271 AHB HREADYOUT mux selects this signal for its HREADY 562 to provide to the ASIC die bridge 365. This information is propagated by the ASIC die bridge 365 through the interconnect 460 by indicating OK on NRESP 423. The CPU die bridge 350 then propagates this further to its own HREADYOUT 544, allowing the CPU die 246 AHB data phase to complete.

[0170] Also, in cycle 2 534, the CPU uses its address phase signal 514 to initiate a transaction to address A1. The AHB block address decoder on CPU die 246 determines that this address is associated with SRAM 216 on CPU die 246, and therefore asserts HSEL 518 against that block during the AHB address phase. The CPU die bridge 350 does not participate in this transaction, so it ignores it and continues with the previously scheduled data phase. If the data phase is not already scheduled, it will drive an IDLE pseudo-command on the NDIO421 interconnect as the command phase. If the CPU die AHB address phase on cycle 2 534 is directed to the CPU die bridge by asserting its HSEL 532, the bridge will register the CPU die AHB address phase signal 514 so that it can later issue an NDIO421 command phase after the already scheduled NDIO data phase is complete. The ASIC die bridge 365 has already committed to transferring D0 in the data phase and therefore does not treat the NDIO contents as a new command phase. Since the ASIC die bridge 365 is not given a new NDIO command phase, it does not initiate any further transactions on its AHB address phase signal 508 during cycle 2 534. The SRAM transaction is completed on CPU die 246 in cycle 3 546.

[0171] In cycle 6, at 548, CPU die 246 initiates a 16-bit read transaction to address A2. The CPU die AHB block address decoder determines that this address is in the ASIC die 271 block address space and therefore activates the CPU die bridge's HSEL 532 on its AHB address phase signal 514. This is propagated into the command phase on NDIO 421 and further propagated into the ASIC die AHB 370 address phase in the same manner as in cycle 1, at 522. In this case, the ASIC die AHB block address decoder determines that address A2 is associated with the BLOCK2 peripheral and therefore issues an HSEL to this block.

[0172] In cycle 7, at 550, BLOCK2 asserts its HREADYOUT 552 to stop, indicating that it is not ready to complete the ASIC die AHB data phase. The ASIC die 271 AHB HREADYOUT mux selects this signal for its HREADY 562 to provide to the ASIC die bridge 365. This is propagated by the ASIC die bridge 365 through the NRESP 423 interconnect as an STL indication. The CPU die bridge 350 receives this STL indication and responds by asserting its HREADYOUT data phase signal 544 to stop, indicating that it is not ready to complete the CPU die data phase. Since this is a read command, both bridges reverse the data direction on NDIO 421, as the data phase is of read type, and it is the ASIC die 271 that drives the interconnect during this cycle. However, since the slave is not being provided with data as indicated by the STL indication, the data on NDIO 421 is ignored by the CPU die bridge during this cycle.

[0173] In cycle 8, at 554, BLOCK2 asserts its HREADYOUT552 to indicate that it is now ready to complete the data phase. BLOCK2 further provides the requested data on its HRDATA556. The ASIC die AHB data phase mux selects these signals due to the previously registered address phase and provides them to the ASIC die bridge 365. The ASIC die bridge 365 propagates this through the interconnect by indicating OK on NRESP423 and driving HRDATA556 on NDIO421. The CPU die bridge 350 then propagates this to the CPU AHB bus by asserting its HREADYOUT544 and driving data D2 on its HRDATA558.

[0174] In cycle 9, at 560, the CPU issues a read transaction to address A3. The AHB block address decoder determines that this relates to SRAM 518 and therefore issues an HSEL to that block. The CPU bridge 350 and ASIC bridge 365 have already reversed to the command phase due to the transaction interconnect signaling at 460 and restore the original CPU to the ASIC data direction on the NDIO 421 interconnect. Since no HSEL has been asserted to the CPU die bridge 532, the bridge has nothing to perform a transaction with and therefore issues an IDLE pseudo-command on the NDIO. The ASIC die bridge receives this IDLE command and interprets it as indicating nothing to perform a transaction with and therefore does not issue an address phase on its AHB address phase signal 508.

[0175] In this example, it is shown that many signals are generated by combining with other signals so that AHB signals 514, 512, and 508 propagate to and from the interconnect 262 signal in the same cycle, when the sequencing allows it. It should be clear that one or more of these signal transfers can be performed in a registered manner so that the generated signals are delivered in a later cycle than the source signals, such as allowing the NCLK420 frequency to be further increased while still maintaining signal timing.

[0176] Similarly, in this example, the number of signals in the interconnect 262 is sufficient to transfer the required amount of command and data phase content within a single cycle. If fewer interconnects are used, multiple NCLK420 cycles can be used to transfer the required content within several serialized cycles.

[0177] Throughout this sequence, the CPU die 246 and the software running on it do not need to provide any special processing to the BLOCK1 and BLOCK2 peripherals. From the perspective of the CPU die 246 AHB bus, transactions were issued and responded to in the usual manner. It is only necessary to allocate the bus addresses of the BLOCK1 and BLOCK2 peripherals so that the AHB block address decoder on the CPU die associates these addresses with the CPU die bridge 350 block address space. It is not even necessary to have awareness of the components implemented on the ASIC die 271 during the specification of the CPU die 246. Since the ASIC die 271 implements its own AHB block address decoder to provide HSEL signals to its various AHB slaves, it is sufficient for the CPU die's AHB block address decoder to allocate a large block of addresses to the ASIC die 271 and let the ASIC die 271 handle the remainder of the block address decoding. This allows the CPU die 246 to be inclusive, so that a single CPU die 246 implementation can potentially mesh with multiple different ASIC dies.

[0178] Furthermore, peripheral devices on the ASIC die 271 do not require any special processing due to their implementation on the ASIC die 271. From the perspective of ASIC die peripherals, they can connect to the standard AHB bus 370 and operate according to the normal AHB protocol.

[0179] To handle a scenario where software initiates a transaction for an unimplemented address on the ASIC die 271, the block address decoder (or peripheral) can provide an HRESP indication of the error during the ASIC die data phase. This can be propagated via NRESP423 as an ERR indication, and the CPU die bridge 350 can propagate the ERR indication to the CPU die AHB bus 330 via its own HRESP. From the perspective of the CPU and the code running on it, this behavior is the same as if its own block address decoder had determined that the address does not match any of the implemented AHB slaves. Furthermore, bus transactions may be invalid due to insufficient security authorization. In AHB systems, this may be a bus access with HPROT.PRIVILEGED612 asserted, which typically indicates user-privileged code accessing an address in a bus slave that is only legitimate for kernel-privileged code access. Furthermore, an attempt to access an address in a bus slave that is only valid for access where HNONSEC is not asserted, or an access where HNONSEC is asserted, should generate a transaction error. In these cases, the bus slave on the ASIC die 271 may be provided with a normal AHB signal by the ASIC die bridge 365, and can then respond to that AHB signal when it deems appropriate, such as by issuing a bus error using the HRESP 423.

[0180] Figure 6 shows an example sequence diagram of bus error propagation using this technique. In this example, the CPU initiates three transactions, two of which complete with error responses. In cycle 1 622, the CPU initiates a write transaction to address A0, which is allocated in the ASIC die block address space, and thus the HSEL532 on the CPU bridge is activated during the CPU AHB address phase in cycle 1 622. The CPU die bridge 350 configures command C0 618 to present to the NDIO421 interconnect. The ASIC die bridge 365 further propagates this on the ASIC die AHB bus during the AHB transaction address phase. The block address decoder in the ASIC die 271 does not associate this address with any implemented bus slave, and therefore the HSEL of the AHB default slave is activated. The default slave performs a two-cycle error response by activating its HRESP data phase display as required by the AHB specification and by performing a bus stall using its HREADYOUT. The HRESP and HREADY signals are propagated to the ASIC die bridge 365 using normal AHB data phase multiplexing. The ASIC die bridge 365 indicates an ERR using NRESP423 signaling to indicate that the data phase has completed with an error. The CPU die bridge 350 then performs its own two-cycle error response using its HRESP574 and HREADYOUT544 signals to complete this CPU die AHB transaction with the error.

[0181] In cycle 4, at 610, the CPU initiates another bus transaction. In this case, the address aligns with bus slave BLOCK1 516 on ASIC die 271, but that bus slave is configured not to allow unprivileged access. In cycle 4, at 610, the CPU initiates the AHB transaction address phase and uses the PRIVILEGED612 bit of HPROT612 to indicate that this is unprivileged access. The block address decoder on CPU die 246 detects that this address is associated with CPU die bridge 350, and therefore the HSEL532 of the CPU die bridge is activated. The CPU die bridge 350 propagates this into the NDIO421 command phase C1 620. The contents of that command phase include information that the PRIVILEGED612 bit is not set. The ASIC die bridge 365 propagates this into the ASIC die AHB transaction, and the PRIVILEGED bit 614 of HPROT is not activated. The ASIC die bridge 365 activates HSEL for BLOCK1 516 when its block address decoder aligns this address to BLOCK1. BLOCK1 516 is configured to respond with an error in the case of unprivileged access, and therefore performs an ERROR response in the data phase during cycles 5 616 and 6 624. This is propagated to the ASIC die bridge 365 through normal AHB data phase muxing. The ASIC die bridge 365 indicates an ERR on the NRESP423 interconnect, and the CPU die bridge 350 detects this and performs a two-cycle error response to the data phase of the CPU die AHB bus.

[0182] In cycle 7, 626, the CPU issues another transaction to BLOCK1 516, this time with the privileged bit set. The command relayed through NDIO421 C2 contains this information. The ASIC die bus initiates this transaction with its own HPROT PRIVILEGED 614 bit set, so that the BLOCK1 slave completes the transaction without error. This is indicated back to the CPU die 246 with the OK NRESP423 indication, and the CPU die bridge 350 responds to the OK NRESP423 indication by completing the CPU die AHB data phase without error.

[0183] Figure 7 shows an exemplary sequence diagram with various bursts. The first burst is a sequential transaction with an explicit AHB burst indication. The AHB bus master on CPU die 246 issues a transaction in cycle 1 742 using HBURST 710 of INCR, starting from bus address HADDR570 A0. Address A0 is determined by the block address decoder on the CPU die to be in the block address space of ASIC die 271, and therefore, HSEL532 on the CPU bridge is asserted during the AHB address phase. The CPU die bridge 350 receives various AHB address phase signals and forms the NDIO421 command phase C0 740. Since HBURST 710 is indicated to be INCR, command C0 740 is formed to indicate to the ASIC die bridge 365 that it was a burst that was to occur, and the address of each transfer should be incremented from the previous 1. Since this is the most common case, the command coding can be structured so that this can be assumed as the default behavior if no other burst types are indicated. If HBURST710 is to be one of several other AHB burst types, such as WRAP8, then C0 740 can be coded to provide this indication instead. In cycle 2 744, the data word D0 is transferred as usual. Also in cycle 2 744, the CPU diabridge 350 receives another AHB command that matches the burst continuation and therefore asserts NPHASE422 to indicate the burst continuation in the data phase. Consistency checks may include verifying that HADDR570 is incremented correctly, as well as that HWRITE566 and HSIZE568 are consistent with the previous transfer. The ASIC divergence 365 detects that NPHASE is asserted and therefore forms a pipelined address phase on its AHB bus to indicate burst continuation with an updated HADDR526 and optionally an updated HTRANS (unnumbered).The ASIC die bridge 365 does this even when the NDIO interconnect is transferring data D0 and therefore is not used to provide other command phases in this cycle. The desired AHB transaction on the ASIC die is inferred from the previous C0 740 command and the burst continuation as indicated by NPHASE. Then, in cycle 3 746, data D1 is transferred via NDIO421 to complete the second data phase in that burst. This continues similarly in cycles 4 748 and 5 750, except that the AHB master does not issue a transaction in cycle 5 750 and therefore NPHASE422 is not asserted during that cycle. Since NPHASE422 was not asserted in cycle 5 750 and the data phase NRESP423 in cycle 5 750 was not STL, the NDIO421 interconnect in cycle 6 752 is understood by both bridges as being reserved for the command phase. If other CPU AHB transactions targeting ASIC die 271 are initiated during cycle 6 752, or if CPU AHB transactions unrelated to the ongoing burst are initiated during cycle 5 and queued for later transactions in CPU die bridge 365, then the command for their transfer can be issued on NDIO421 during cycle 6 752. In this example, no such transactions are shown, so the pseudo-command IDLE is issued on the NDIO421 interconnect.

[0184] In cycle 7, at 754, the AHB master on CPU die 246 initiates an AHB transaction to the ASIC die slave using SINGLE HBURST710, indicating that this transaction is unlikely to be part of a burst. The ASIC die bridge 365 forms command C4 and begins bridging that transaction to ASIC die 271. Command C4 can be coded to indicate a default burst type, even if nothing is explicitly indicated by the bus master. During the subsequent data phase in cycle 8, at 756, the CPU die AHB initiates another AHB transaction that coincidentally matches the default burst type already issued in command C4. In this case, the ASIC die bridge 365 can infer a burst and issue NPHASE422 in cycle 8, at 756, to convert the individual transactions into an NDIO421 burst.

[0185] In cycle 11, at 7:22, the DMA controller 212 on the CPU die 246 initiates the first AHB transaction in a series of FIFO transactions to the same address A6. The DMA controller 212 may provide the CPU die bridge 350 with an extra signal NOINCR724 as a hint to issue the NDIO421 command C6, indicating that the burst continuation should use the same bus address for each transfer. In cycle 12, at 7:26, the DMA controller 212 issues the next transaction in this sequence. The CPU die bridge 350 can verify the consistency of this new transaction with a valid burst continuation of the current command C6 and assert NPHASE422 to continue the burst without incrementing. The ASIC die bridge 365 forms this in the address phase of cycle 12, at 7:26 on its AHB bus, indicating a transaction to the same address as the previously issued address.

[0186] In cycle 14, at 7:28, the CPU diverbus master initiates the first transaction in a series of FIFO transactions to the same address A8. In this case, it does not indicate NOINCR724, resulting in the CPU diverbridge 350 forming an NDIO421 command phase C8 with a default bursting type that is not the same as non-incrementing. During the data phase in cycle 15, at 7:30, the CPU diverbus master initiates a second transaction, and the CPU diverbridge 350 determines that the second transaction matches a different burst type than the one it previously indicated on command phase C8. In this case, the CPU diverbridge 350 detects that the observed AHB sequence matches a non-incrementing burst. Since the NDIO421 command C8 does not match the inferred burst type, the CPU diverbridge 350 asserts NPHASE422 in cycle 15, at 7:30, to halt the NDIO421 interconnect back to the command phase for the next cycle 16, at 7:32. During cycle 16 732, the CPU die bridge 350 issues an updated NDIO421 command C9 to indicate a presumed burst type that does not increment. During this cycle, the CPU die bridge 350 asserts HREADYOUT544 on the CPU die AHB bus to stall the data phase while a new command C9 is issued on the NDIO421. Then, for cycles 17 734 to 19 738, each command received on the CPU die AHB bus 405 matches the bursting type indicated by C9, and therefore the remainder of the burst can continue without interruption, as NRESP can be used to continue the burst.

[0187] Figure 8 shows a sequence diagram illustrating interrupt bridging between an interrupt source on ASIC die 271 and an interrupt controller on CPU die 246. In this example, two interrupt sources on ASIC die 271 generate interrupt indicators IRQ1 810 and IRQ2 812 on that die. The IRQ1 interrupt source uses edge-based indicators, and the IRQ2 source uses level-based indicators. The interrupt controller on CPU die 246 is configured to accept indicators IRQ1 814 and IRQ2 816 from bridge 818 (which are a group of interface signals between the CPU die bridge 350 and other components within the CPU die 246). Since the CPU die bridge 350 provides only single-cycle indicators on these interrupt request lines, the CPU die interrupt controller can be configured to accept them as either level-based or edge-based indicators. The CPU die bridge 350 provides a TYPE indicator for these two interrupt sources, which can be either EVENT or LEVEL. EVENT indicates that the ASIC die 271 interrupt source uses edge-based signaling and therefore each interrupt activation should be treated as a simple event. LEVEL indicates that the interrupt source uses level-based signaling and that the ASIC die's interrupt request should be re-polled in response to clearing the relevant PENDED register within the interrupt controller.

[0188] In cycle 1 848, the ASIC die IRQ1 810 line on ASIC die 271 is asserted by an interrupt source. The ASIC die interrupt bridge detects the 0-to-1 sequence and determines that it needs to propagate the interrupt rising edge to CPU die 246. The ASIC die interrupt bridge requests the NEVT424 transmitter 429 to propagate the appropriate enumeration event to CPU die 246, while also registering the need to propagate this event in its own QUEUED register for its IRQ822. When the event bridge is idle, the ASIC die interrupt bridge can immediately begin serializing this event on the NEVT424 using the two-clock sequence E0.0 and E0.1 to form the serialized event E0. Furthermore, the ASIC die NEVT424 serializer 429 indicates to the ASIC die IRQ bridge 826 that the messaging of E0 (a set of signals from the ASIC bridge 365 to the ASIC die 271) is complete, and therefore clears its QUEUED register for IRQ1 822 as the required message has been sent. In cycle 2 850, the CPU die bridge 350 detects the reception of the E0 event and determines that the reception of the E0 event should be encoded as an event for the IRQ1 814 assertion. The CPU die bridge 350 then drives the CPU die 246 IRQ1 814 signal for a single cycle. The interrupt controller registers this indication in the pending register for IRQ1 in the NVIC868, i.e., IRQ1.PENDED828. Depending on the configuration of the interrupt controller, this PENDED configuration may result in the execution of an interrupt service routine, or it may simply be available to software for reading. In either case, if an interrupt is being processed for CPU execution, the PENDED indicator can be cleared by the CPU asserting the IRQ1.PEND_CLR830 signal. Inside the interrupt controller, this results in clearing the IRQ1.PENDED828 register. This PEND_CLR signal is then made available to the CPU diode 350.The bridge notices that its IRQ1.TYPE832 is an EVENT, and therefore ignores this message as no further action is needed.

[0189] In cycle 5, at 852, the ASIC die 271 IRQ2 812 source activates its interrupt request. The ASIC die bridge 365 responds similarly to its response to IRQ1 in cycle 1, at 848, resulting in a serialized NEVT424 message E1 to the CPU die 246. The CPU die 246 responds similarly to the previous E0 message, ultimately resulting in the IRQ2.PENDED834 register in the interrupt controller being set via a single-cycle activation of the IRQ2 signal 816 on the CPU die.

[0190] While E1 is still being serialized, the IRQ1 810 source on ASIC die 271 activates its interrupt request. In this case, the NEVT424 interconnect is busy serializing E1, and therefore the IRQ bridge 826 on ASIC die 271 sets only its IRQ1.QUEUED822 register to remember that it should be serialized later. In cycle 7 854, the NEVT424 interconnect becomes available, and therefore the ASIC die 271 NEVT424 serializer begins serializing E2 to indicate this IRQ1 810 activation event at the request of the ASIC die 271 IRQ bridge 826. Note that E2 can have the same coding as E0, as it represents the same interrupt activation as for E0. In cycle 8, at 856, the serialization of this event is completed, resulting in the IRQ1.PENDED828 register in the interrupt controller being set via a single-cycle activation of the IRQ1 signal 814 on the CPU die. This causes the NEVT424 serializer to report that the event transmission was successful, and consequently, the IRQ1.QUEUED822 register is cleared.

[0191] In cycle 10, at 858, the CPU enters the interrupt service routine for IRQ2 816, causing the IRQ2.PEND_CLR836 and IRQ2.ACTIVE838 signals to be asserted. The CPU die 246 IRQ bridge 818, noting the PEND_CLR assertion and the setting of IRQ2.TYPE to LEVEL, sets its IRQ2.REPOLL840 register. Since the IRQ2.ACTIVE838 signal is set inside the interrupt controller, the CPU die 246 IRQ bridge 818 should not yet repolling and therefore takes no further action in this cycle. In cycle 11, at 860, the IRQ2.ACTIVE838 signal is stopped asserting inside the interrupt controller. Now that the CPU die 246 IRQ bridge 818 has its IRQ2.REPOLL840 register set, and IRQ2.ACTIVE838 is not set, the CPU die 246 IRQ bridge 818 requests the use of the transaction interconnector 460 to send a special transaction indicating that the ASIC die 271 IRQ bridge 826 needs to re-examine its IRQ2 812 interrupt indicator and generate another NEVT424 event if that signal is currently high. This interconnector 460 transaction C0 844 is performed in cycle 12 860. The IRQ bridge 826 on the ASIC die 271 responds to receiving this transaction by re-examining its IRQ2 812 input indicator. Since IRQ2 812 is asserted, the IRQ bridge 826 sets its IRQ2.QUEUED register and requests serialization of event E3 to indicate to the CPU die 246 that the interrupt source is currently active. In this example, the NEVT424 interconnect is not busy, and therefore the serialization of E3 can begin in cycle 13 862. Note that it is possible to encode E1 and E3 using the same enumeration, as the CPU bridge 350 does not need to treat them differently.Receiving event E3 results in the IRQ2.PENDED834 register being set via signaling on IRQ2 816, using the same method as for event E1.

[0192] In cycle 17, at 864, the IRQ2.PENDED834 register is cleared by software. This causes the IRQ2.PEND_CLR836 signal to be asserted without the IRQ2.ACTIVE838 bit signal being asserted. The CPU die 246 IRQ bridge 818 sets the IRQ2.REPOLL840 bit of IRQ2.PEND_CLR836 because it is active and IRQ2.TYPE842 is LEVEL. Since IRQ2.ACTIVE838 is not set, the CPU die 246 IRQ bridge 818 can immediately request the transaction interconnect 460 to repoll the IRQ2 812 interrupt source on the ASIC die 271. This causes the transaction to be performed in cycle 19, at 866, in transaction C1 846, which may have the same coding as C0 844. The ASIC die 271 IRQ bridge 826 responds to the C1 846's reception by checking its IRQ2 812 interrupt request input and taking no further action because it is not asserted. The CPU die 246 does not receive any interrupt activation messages, and therefore the IRQ2.PENDED834 register remains unset. Some time later, when the ASIC die 271 IRQ2 812 interrupt source is activated again, the ASIC die 271 can indicate this to the CPU die 246 in a similar manner to the E1 NEVT424 transaction that occurred in cycle 5 852.

[0193] Figure 9 shows an exemplary sequence diagram illustrating DMA request synchronization between the ASIC die 271 DMA-enabled bus slave and a signal 922 contained within the DMA controller 212 of the CPU die 246. In this example, the DMA-enabled AHB die peripheral provides a DMA request DRQ1 910 to be synchronized with the CPU die DMA request DRQ1 920, which should result in the CPU die DMA controller performing a 4-cycle burst write to the FIFO address on the ASIC die 271. At the start of the sequence, the DMA controller 212 is not yet enabled for that channel. The CPU and ASIC die DRQ bridges 912 and 914, respectively, independently maintain states 916 and 918 for DRQ synchronization between the two dies, for each DRQ channel (there are also signals inside the DRQ synch state machines 414 and 428). At the beginning of this sequence, the state of the CPU die 246 for the DRQ channel DRQ1 920 is UNKN, indicating that the CPU die 246 has no knowledge of the DRQ1 910 signal on the ASIC die 271, and while in this state, it gives an inactive level to the DRQ1 920 input to the DMA controller 212. This state is the initial state from reset and is entered whenever the DMA controller 212 disables its DRQ channel for service work. The initial state of the ASIC die bridge 365 for DRQ1 910 is DISA, which indicates to its side of the bridge that the CPU die 246 is indifferent to DRQ synchronization for its channel.

[0194] In cycle 1 934, the service work for DRQ1 920 is enabled in the DMA controller 212. The CPU die DRQ bridge 912 receives the signal DRQ1.ENA, indicating that the DMA channel is enabled for service work. Since its synchronization state is UNKN, the CPU die DRQ bridge 912 requests a special command C0 930 on the NDIO421 interconnect, which requests synchronization of the DRQ channel DRQ1 910 to the ASIC die 271 DRQ bridge 914. Upon successful completion of transaction C0 930, the CPU die 246 DRQ bridge 912 enters the ARMD state for its DRQ channel. While in the AMRD state, the CPU die 246 DRQ bridge 912 provides an inactive indication to the DMA controller 212 for DRQ1 920. Upon receiving command C0 930, the ASIC die DRQ bridge 914 enters the ARMD state for its DRQ1 910 synchronization state 918.

[0195] The ASIC die's DRQ bridge 914, while in the ARMD state for the DRQ1 910 channel, checks for the DRQ1 910 indicator and, if it observes that the signal is active, enters the PEND state for that channel. This occurs in cycle 4. While in the PEND state, the DRQ bridge 914 requests the NEVT424 bridge to send an indicator of DRQ1 activation to the CPU die 246. In cycle 5, 938, the NEVT424 bridge is not busy and therefore begins serializing event E0 for two cycles to send the DRQ1 activation indicator. Once this event transmission is complete, the ASIC die's DRQ bridge 914 enters the TRGD state. The NEVT424 indicator of receiving event E0 in cycle 6 is provided to the CPU die's DRQ bridge 912. The DRQ bridge 912 is in the ARMD state for the DRQ1 channel when it receives this event and therefore enters the TRGD state for that channel. While the CPU die DRQ bridge 912 is in the TRGD state for the DRQ1 channel, it provides the DMA controller 212 with an active DRQ indicator DRQ1 920 unless it receives an indication from the transaction interconnect that a bus transaction has received an OKDN response on the NRESP423 for a BUS transaction related to that DRQ channel. In this case, the CPU die DRQ bridge 912 has not received this indication and therefore asserts DRQ1 920 to the DMA controller 212.

[0196] In cycle 9, at 940, the DMA controller 212 initiates a programmed AHB burst transaction in response to its assertion of its DRQ1 920 input. During the AHB address phase, the DMA controller 212 provides the CPU diabridge 350 with additional address phase information DRQN ​​924, indicating that the transaction is part of a DRQ1 920 responsive sequence. In this case, the required transaction is a non-incrementing burst, and therefore the DMA controller 212 also provides the NOINCR 724 address phase burst hint to indicate that the NDIO421 command phase command C1 932 should indicate a non-incrementing burst type. The CPU diabridge 350 issues the NDIO421 command C1 932 to initiate the bridged AHB transaction. The ASIC diabridge 365 receives this command and registers a DRQ channel number that should be monitored as DRQ1 910. During each of the one or more data phases for that transaction, whenever the transaction should indicate that the data phase has been successfully completed, the NRESP423 indicator is OK if the DRQ request on the ASIC die 271 for the DRQ channel indicated in the command phase is high during that data phase. Conversely, if the ASIC die 271 DRQ request is low during the data phase, the NRESP423 indicator is OKDN. For each data phase, the CPU die AHB bridge 926 accepts either OK or OKDN, indicating a successful completion of the data phase. For each OKDN received by the CPU die 246, the CPU die AHB bridge 926 further provides this indication to the DRQ bridge 912. The DRQ bridge 912 responds by asserting its own DRQ indication to the DMA controller 212 for that channel and also transitioning its DRQ synchronization state for that channel to ARMD. For each OKDN sent by the ASIC die 271, the ASIC die 271 DRQ synchronization state for that channel is changed to ARMD.In this exemplary sequence, this is done first in cycle 12 942, which synchronizes the deactivation of DRQ1 920 and 910 on both dies in the precise manner of the cycle.

[0197] In one embodiment, the CPU die and / or ASIC die are implemented using multiple NDIO421 width configurations that can be varied at runtime to enable coupling with multiple different configurations for other dies. This is desirable because a single design being coupled with multiple other designs having different interconnect widths allows for flexibility. In some embodiments, NEVT and NRESP may also be reclassified.

[0198] Figure 10A illustrates one embodiment of a reduced-rate initial data discovery procedure, such as during power-up or reset 1010, in which two dies can negotiate their capabilities to determine a mutually supported interconnect width. In one embodiment, at startup or in response to reset 1010, both dies making up some or all of the interconnect width perform an internal initialization process 1020 limited to the die in perspective, and both can start by assuming a small interconnect width that is widely supported, which can be used to connect (1030) by exchanging multiple connection messages, in some cases. The two dies can then exchange capability 1040 data using this minimum format, and then can agree (1050) to better execute a format that they both support. They may do this, for example, by independent evaluation, or by the CPU die 246 selecting its preferred format and communicating the mode change to the ASIC die using CTRL transaction 106, or both, for example, both dies identify the best capability set, and the CPU die sends its selected set to the ASIC die using transaction interconnect 460 transaction 1060. Furthermore, it may be desirable to renegotiate capabilities during operation, such as maintaining minimum capability to conserve power during normal operation, or optimizing interface power consumption. In this case, the two dies may start with the lower capability set, and the CPU die may always be selected later to modify the agreement using CRTL message 1060 without the need for a reset, based on an initial capability exchange 1040.

[0199] Figure 10B shows an embodiment of an alternative discovery process in which the CPU die 246 allows ASIC dies to be implemented only in a limited number of preferred widths, such as some or all interconnection widths being possible, but some or all width options and a set of non-arbitrary signals required by some optional signals. Only the interconnection parts provided by the ASIC dies are connected to the CPU die 246, and other optional interconnection ports of the CPU die 246 are left unconnected. After a reset or power-on 1010 and initialization 1020 of both dies, the ASIC die may demonstrate its connectivity during discovery by applying resistive pulls 1070 to some or all of its optional interconnection parts. The CPU die 246 can perform port discovery 1080 by sensing which of its optional interconnection ports can detect the presence of this resistive pull. In this way, the CPU die can determine the ASIC die interconnection width. Furthermore, using this information, the CPU die 246 sets up its internal capability 1090 to match the ASIC die without requiring any further message exchange. Once the interconnect width is detected, the ASIC die can remove the pull, for example, by detecting an appropriate command on the NDIO. In one embodiment, the ASIC die can apply a pull-up, and an IDLE command on the NDIO, coded as all 0s, can indicate the pull-up removal. Other ASIC die indicators, such as a weak current source, can also be used as alternatives to resistive pulls.

[0200] In some embodiments of the process shown in Figure 10A and / or Figure 10B, there may be additional or fewer operations. Furthermore, the order of operations may be changed, and / or two or more operations may be combined into a single operation.

[0201] In one embodiment, the disclosed communication technique provides a system that constantly bridges two dies in a master / slave relationship. The CPU die is expected to include at least one microcontroller core (CPU) and its tightly coupled memory. The CPU die is not limited to a single CPU core and supports multiple cores as well. The CPU die may also include one or more DMA controllers and memory. The CPU die is not expected to require any direct connection to a read frame. The ASIC die can be the gateway of the CPU die to the outside world. It includes memory-mapped peripherals to implement either the interfaces and logic required to complement the functionality of the CPU die for a particular application. The interfaces bridge bus transactions, interrupt events, and DMA requests between the ASIC die peripherals and the CPU die in a manner transparent to the CPU, and thus extend the CPU functionality. From the outside, to the user, the two dies appear to be a single CPU and can behave like a single CPU. From a CPU block perspective, the unit "thinks" it has direct wired connections to these peripherals, but in reality they are part of the second die (see Figures 2 and 3 for further details). To achieve this effect (for example, multi-die transparency in application development), this specification includes several embodiments.

[0202] In creating the text and drawings, certain selections have been made in the description solely for convenience, and unless otherwise indicated, these selections should not be interpreted as conveying additional information about the structure or operation of the described embodiments. Examples of such selections include specific organization or assignment of designations used for numbering the drawings, as well as specific organization or assignment of element identifiers (e.g., callouts or numeric indicators) used to identify and refer to features and elements of these embodiments.

[0203] The various forms of the words “include” and “equip” are intended to be interpreted as abstractions representing a logical set of open-ended scopes, and are not intended to convey physical inclusion unless explicitly stated (such as being followed by the word “~inside”).

[0204] While the embodiments described above are explained in some detail for clarity of explanation and understanding, the communication techniques disclosed are not limited to the details provided. Many embodiments of the disclosed communication techniques exist. The disclosed embodiments are illustrative and not restrictive.

[0205] It will be understood that many variations in configuration, arrangement, and use are possible without contradiction to this description and fall within the scope of the claims of any issued patent. For example, the bit width, clock speed, and type of technology used in interconnects and functional units are variable according to various embodiments in each component block. The names given to interconnects and logic are illustrative only and should not be interpreted as limiting the concepts described. The order and arrangement of processes, actions, and functional elements in flowcharts and flow diagrams are variable according to various embodiments. Conversely, unless otherwise specifically stated, specified value ranges, maximum and minimum values ​​used, or other specific specifications (such as file types, as well as the number of entries or stages in registers and buffers) are only those of the described embodiment and should not be interpreted as limiting, as improvements and changes in implementation technology are expected to be tracked.

[0206] Functionally equivalent techniques known in the art can be employed instead of those described to implement various components, subsystems, operations, functions, routines, subroutines, inline routines, procedures, macros, or parts thereof. Depending on embodiment-dependent design constraints and technological trends, many functional aspects of the embodiments can also be selectively implemented in either hardware (e.g., generally dedicated circuit configurations) or software (e.g., via several schemes of programmed controllers or processors). Certain variations in various embodiments include, but are not limited to, other variations that should be expected when implementing the concepts described herein, subject to differences in classification, different form factors and configurations, the use of different operating systems and other system software, different interface standards, network protocols, or communication links, and the inherent engineering and business constraints of a particular application.

[0207] This embodiment is described with a detailed and environmental context that far exceeds what is required for the minimum implementation of many of the embodiments described. Those skilled in the art will recognize that some embodiments omit components or features disclosed without altering the fundamental cooperation among the remaining elements. Therefore, it will be understood that many of the details disclosed are not necessary to implement the various embodiments described. The omitted components and features are not limiting to the concepts described herein, to the extent that the remaining elements are distinguishable from existing methods.

[0208] All such modifications in the design are minor changes that take precedence over the teachings conveyed by the embodiments described herein. It is also understood that the embodiments described herein have broad applicability to other computing and networking applications and are not limited to the specific applications or industries of the embodiments described herein. Accordingly, the communication techniques disclosed should be construed as including numerous possible modifications and variations that are covered within the claims of the issued patent.

[0209] The embodiments disclosed may be any electronic device (or may be included in any electronic device). For example, electronic devices may include cellular phones or smartphones, tablet computers, laptop computers, notebook computers, personal or desktop computers, netbook computers, media player devices, e-book devices, MiFi® devices, smartwatches, wearable computing devices, portable computing devices, consumer electronic devices, access points, routers, switches, communication equipment, test equipment, vehicles, ships, airplanes, automobiles, trucks, buses, motorcycles, manufacturing equipment, agricultural equipment, building equipment, or other types of electronic devices.

[0210] While specific components are used to illustrate this embodiment, different components and / or subsystems may be presented in alternative embodiments. Thus, embodiments of a system and / or integrated circuit may include fewer components, additional components, or different components; two or more components may be combined into a single component; a single component may be separated into two or more components; and / or the positions of one or more components may be changed.

[0211] Furthermore, the circuits and components in the system and / or integrated circuit embodiments may be implemented using any combination of analog and / or digital circuit configurations, including bipolar, PMOS, and / or NMOS gates or transistors. Additionally, the signals in these embodiments may include digital signals with substantially distinct values ​​and / or analog signals with continuous values. Furthermore, the components and circuits may be single-ended or differential, and the power supply may be unipolar or bipolar. Note that the electrical coupling or connection in the embodiments described above may be direct or indirect. In the embodiments described above, a single line corresponding to a route may represent one or more single lines or routes.

[0212] The integrated circuit may implement some or all of the functionality of the communication technique. This integrated circuit may include hardware and / or software mechanisms used to implement the functionality related to the communication technique.

[0213] In some embodiments, the output of a process for designing an integrated circuit or a part of an integrated circuit, including one or more of the circuits described herein, may be a computer-readable medium, such as magnetic tape or optical disk or magnetic disk. The computer-readable medium may be encoded with data structures or other information representing circuit configurations that may be physically instantiated as an integrated circuit or a part of an integrated circuit. Various formats may be used for such encoding, but these data structures are generally written in Caltech Intermediate Format (CIF), Calma GDS II Stream Format (GDSII), Electronic Design Interchange Format (EDIF), OpenAccess (OA), or Open Artwork System Interchange Standard (OASIS). A person skilled in the art of integrated circuit design can develop such data structures from the schematic diagrams and corresponding descriptions of the types detailed above and encode the data structures onto a computer-readable medium. A person skilled in the art of integrated circuit manufacturing can use such encoded data to manufacture an integrated circuit including one or more of the circuits described herein.

[0214] While some of the operations in the embodiments described above were implemented in hardware or software, in general, the operations in the embodiments described above can be implemented in a wide variety of configurations and architectures. Therefore, some or all of the operations in the embodiments described above may be performed in hardware, software, or both. For example, at least some of the operations in this communication technique may be performed using program instructions executed by a processor in an integrated circuit or in firmware.

[0215] Furthermore, while numerical examples are provided in the above description, different numerical values ​​will be used in other embodiments. Therefore, the numerical values ​​provided are not intended to be limiting.

[0216] The above description refers to "several embodiments." Note that "several embodiments" represents all subsets of possible embodiments, but does not necessarily specify the same subset of embodiments.

[0217] The above description is intended to enable any person skilled in the art to create and use this disclosure and is provided in the context of specific applications and their requirements. Furthermore, the above description of embodiments of this disclosure is presented for illustrative and explanatory purposes only. They are not intended to be exhaustive or to limit this disclosure to the forms disclosed. Accordingly, many modifications and variations will be apparent to a skilled practitioner in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of this disclosure. Moreover, the above description of embodiments is not intended to limit this disclosure. Accordingly, this disclosure is not intended to be limited to the embodiments shown, and the broadest scope corresponding to the principles and features disclosed herein should be given. [Explanation of symbols]

[0218] 100 Single-Die Microcontrollers 110 Clock multipliers and multiplexers (mux) 115 Clock Source 120 CPUs and optional DMA controllers 125 AHB bus, AHB interface, AHB data bus 130 DMA request signal (DRQ) 135 Power Management Unit (PMU) Interface 140 Debug Access Port (DAP) Interface 145 Basic ASIC Functions 150 Debug Access Port (DAP) 160 Interrupt Request (IRQ) 200 microcontroller dies, single-die microcontrollers 201 Interface 205 Power Management Unit (PMU) 210 Combined Comms / Sensors / Actuators, Analog Blocks 211 Custom DSP Logic 212 DMA Controller 213 Flash Memory 216 RAM 217 CPU 218 Debugger Logic 219 Oscillator 220 Interconnection section, single die interconnection section 221 Low-voltage communication peripherals 222 Low-voltage sensor peripherals 223 Low-voltage actuator peripheral equipment 224 CAN / LIN Communication Peripherals 225 High-voltage sensor 226 High-voltage actuator 227 Interface 229 Interconnection Interface 230 Interconnection Interface 231 Interconnection Interface 232 Dedicated Interface 233 Dedicated Interface 234 CPU Interfaces 235 Interface 236 Interconnection Interface 237 Interconnection Interface 238 Interconnection Interface 239 Interconnection Interface 240 Interconnection Interface 241 Interconnection Interface 242 Interconnection Interface 243 Security Manager 244 PMU controllers 245 Masterbridge 246 CPU dies 248 CPU die interconnect 252 Interfaces 256 CPU PMU interfaces 257 Interfaces 258 Interfaces 260 Interfaces 261 Inter-die signal 262 Inter-die interconnection section 264 Slave Bridge 265 Oscillator 267 Security Manager 268 PMU 271 ASIC Die 272 ASIC die interconnect 279 Interfaces 280 Interfaces 281 Interface 282 Interface 283 Interface 299 CPU Debug Logic 310 CPU die clock multiplier and mux 315 Clock Source 317 ASIC die interface clock 325 CPU die interface clock 330 Bus Interface AHB, AHB Transactions 335 EVENTS 340 PMU synchronization 345 DAP 350 bridges / serdes, CPU die bridge 355 I / O interfaces 360 I / O Interface 365 Bridge / serdes, ASIC Dibridge 370 AHB transactions, AHB 375 ASIC die event 380 PMU status and events 385 Debug Interface Configuration and Events 390 ASIC function 395 DAP 401 Clock Multiplier 402 Clock FCLK 404 PMU Transaction Interface 405 AHB Master, AHB Slave Interface 406 AHB Master, AHB Slave Interface 407 DMA interface, DMA signal, DMA hook 411PMU Interface 412 Event Receiver 414 DRQ synchronous logic, CPU die synchronous logic 415 Sequencer / PHY 416 RE_STRB 417 Composition SFR Bank 418 Arbiter / mux 419 Register Bank 420 NCLK 421 NDIO 422 NPHASE 423 NRESP 424 Event Relay Interconnection Unit NEVT 426 Sequencer / PHY 428 DRQ Synchronization Logic 429 Event Transmitter 430 Arbiter / Mux 431 IRQ Synchronous Logic 432 PMU Interfaces 433 IRQ Interface 434 DRQ signal, DMA interface, DRQ source 436 AHB Master Interface 437 AHB Master Interface 438 PMU Transaction Interface 447 Display signal 448 Interfaces 449 Interface 451 IRQ Synchronous Logic 454 Interface 455 Interface 457 Interface 458 clocks 459 Clock 460 Transaction Interconnection Unit 465 Interface 467 Interface 470 Interface 474 Interface 475 IRQ Interface, IRQ Interconnector

Claims

1. It is a system, A first die having a central processing unit (CPU) and a first bridge, A second die having a second bridge, wherein the second die does not have a CPU, or has a third CPU unrelated to the first bridge and the second bridge, A die interconnect is electrically coupled to the first bridge and the second bridge, and comprises a die interconnect having fewer signal lines than the first bus in the first die and the second bus in the second die. The first and second bridges are configured to mask the presence of the inter-die interconnects so that the functionality of the second die appears to the master on the first die as if it were implemented on the first die. The first bus and the second bus have a common format, The aforementioned format includes ARM Advanced Microcontroller Bus Architecture (AMBA) Advanced High Performance Bus (AHB), AHBLite, or AHB5. system.

2. The system according to claim 1, wherein the master comprises the CPU.

3. The system according to claim 1, wherein the first die comprises a plurality of devices, one or more of the plurality of devices are configured to act as a bus master, which is configured to participate in bus transactions to bus slaves on the second die via the inter-die interconnect.

4. The system according to claim 1, wherein the second bridge is configured to interrupt a transaction by the first bus master on the first die, allowing a transaction by the second bus master on the second die to be performed via the inter-die interconnect before the interrupted transaction by the first bus master is finalized.

5. The system according to claim 1, wherein the second die comprises a plurality of devices, one or more of which are configured to act as bus slaves with respect to the first bridge and the second bridge.

6. The system according to claim 1, wherein, for implementations having two instances of the second die, the first die is configured to provide a single wider bandwidth connection via the inter-die interconnect, while for implementations having two instances of the second die, the first die is configured to provide a single wider bandwidth connection via the inter-die interconnect.

7. The system according to claim 1, wherein the software model implemented on the first die is the same in terms of software as if it were implemented on a single die system.

8. The system according to claim 1, wherein the format includes a wishbone architecture.

9. A second bus master on the second die, electrically coupled to the third bus on the second die, and a third bridge electrically coupled to the third bus as a bus slave, A second bus slave on the first die, electrically coupled to the fourth bus on the first die, and a fourth bridge electrically coupled to the fourth bus as a bus master, A second die interconnect configured to transmit a second signal between the third bridge and the fourth bridge, wherein the number of second die interconnects is less than the number of signal lines between the second bus master and the third bridge, further comprising: The first bridge, the second bridge, and the die interconnect are configured to enable the bus master to participate in the bus transaction with the bus slave in the same manner as if the bus transaction were performed within a single die system. The system according to claim 1.

10. The system according to claim 9, wherein the CPU instructions for accessing the bus slave on the second die are the same as when the bus slave is implemented on the first die.

11. A method for communication between a first die having a first bridge and a second die having a second bridge, The first bridge receives a signal from the central processing unit (CPU) in the first die that corresponds to the function of the second die, The steps include communicating the signal to the second bridge via an inter-die interconnect that is electrically coupled to the first bridge and the second bridge, wherein the inter-die interconnect comprises fewer signal lines than the first bus in the first die and the second bus in the second die. When transmitting the aforementioned signal, the first bridge and the second bridge mask the presence of the inter-die interconnect so that the function of the second die appears to the master on the first die as if it were implemented on the first die. The second die either does not have a CPU or has a third CPU that is not associated with the first bridge and the second bridge. The first bus and the second bus have a common format, The aforementioned format includes ARM Advanced Microcontroller Bus Architecture (AMBA) Advanced High Performance Bus (AHB), AHBLite, or AHB5. method.

12. The method according to claim 11, wherein the master comprises the CPU.

13. The method according to claim 11, wherein the first die comprises a plurality of devices, and one or more of the plurality of devices act as a bus master involved in bus transactions to bus slaves on the second die via the inter-die interconnect.

14. The method according to claim 11, further comprising the step of allowing a transaction by a second bus master on the second die to be performed via the inter-die interconnect before the second bridge interrupts a transaction by a first bus master on the first die and finalizes the interrupted transaction by the first bus master.

15. The method according to claim 11, wherein the second die comprises a plurality of devices, one or more of which act as bus slaves with respect to the first bridge and the second bridge.

16. The method according to claim 11, wherein, for implementations having two instances of the second die, the first die provides a single interconnect with a wider bandwidth, while for implementations having two narrower bandwidth connections, the first die provides a single interconnect with a wider bandwidth only when a single instance of the second die is implemented.

17. The method according to claim 11, wherein the software model implemented on the first die is the same in terms of software as if it were implemented on a single die system.

18. It is an electronic device, A first die having a central processing unit (CPU) and a first bridge, A second die having a second bridge, wherein the second die does not have a CPU, or has a third CPU unrelated to the first bridge and the second bridge, A die interconnect is electrically coupled to the first bridge and the second bridge, and comprises a die interconnect having fewer signal lines than the first bus in the first die and the second bus in the second die. The first and second bridges are configured to mask the presence of the inter-die interconnects so that the functionality of the second die appears to the master on the first die as if it were implemented on the first die. The first bus and the second bus have a common format, The aforementioned format includes ARM Advanced Microcontroller Bus Architecture (AMBA) Advanced High Performance Bus (AHB), AHBLite, or AHB5. Electronic devices.

Images