The present disclosure relates to the field of integrated circuits, and, more particularly, to a reconfigurable System-on-Chip (SoC), and related methods.
Microelectronic products, such as SoC products, may include digital intellectual property (IP) units that serve a wide spectrum of applications. A differentiating factor between similar products is the efficiency of using the silicon area dedicated to the digital circuits.
One or more embodiments may include a reconfigurable digital unit (e.g., a digital circuit), a corresponding reconfigurable apparatus (e.g., a System-on-Chip or SoC product such as a microcontroller), a method of operating a reconfigurable digital circuit, and a computer program product loadable in a memory of at least one computer and including software code portions to run on the at least one computer. As used herein, reference to a computer program product is understood as a reference to a computer-readable means containing instructions for controlling a processing system. Reference to “at least one computer” is intended to highlight the possibility for one or more embodiments to be implemented in modular and/or distributed form.
One or more embodiments may include sequential logic available in digital circuits where their basic functionality is not otherwise exploited.
One or more embodiments may provide a reconfigurable system of a group of digital IP blocks by switching the digital IP blocks to user-accessible memory locations (e.g., RAMs).
One or more embodiments may provide flexibility of system architectures, e.g., at the design and prototyping stages.
One or more embodiments may be applied, e.g., to SoC products including RAM memories.
One or more embodiments may be suitable for systems with embedded cores, interconnect-based communication and a relatively large amount of digital peripherals, where a microcontroller unit is an example of such a system.
One or more embodiments may be applied to general purpose platforms with application scenarios, which may vary, while providing the possibility of using the benefit of one or more embodiments.
One or more embodiments may be used for digital IP debug purposes, e.g., to debug peripherals. For example, when a digital IP unit may be “suspected” of incorrect behavior during a prototyping phase, one or more embodiments may permit to switch operation to a virtual RAM mode thus making it possible to read the current (possibly defective) state as this is still stored in the sequential elements and thus accessible, e.g., via software.
One or more embodiments may be beneficial in increasing the speed of the design phase of derivative products (e.g., derivative microcontroller units with different memory sizing and reduced/extended set of peripherals) by statically switching unused peripherals to operate as memories (e.g., to extend the system RAMs). This makes it possible to reduce the time-to-market of derivative products of general-purpose platforms.
One or more embodiments may retain the working state of a digital IP unit in a system placed in a low-power state by using a word-based interface.
One or more embodiments will now be described, by way of non-limiting example only, with reference to the annexed figures, in which:
In the ensuing description one or more specific details are illustrated, aimed at providing an in-depth understanding of examples of embodiments. The embodiments may be obtained without one or more of the specific details, or with other methods, components, materials, etc. In other cases, known structures, materials, or operations are not illustrated or described in detail so that certain aspects of embodiments will not be obscured.
Reference to “an embodiment” or “one embodiment” in the framework of the present description is intended to indicate that a particular configuration, structure, or characteristic described in relation to the embodiment is comprised in at least one embodiment. Hence, phrases such as “in an embodiment” or “in one embodiment” that may be present in one or more points of the present description do not necessarily refer to one and the same embodiment. Moreover, particular conformations, structures, or characteristics may be combined in any adequate way in one or more embodiments.
The references used herein are provided merely for convenience and hence do not define the scope of protection or the scope of the embodiments.
The block diagram of
The sequential elements 12 (e.g., edge-triggered D flip-flops) may store states of the digital circuit and may be reset before the system or a certain functionality thereof is started.
When a certain component in the circuit is not used, the values stored by the sequential logic 12 become irrelevant and may be assumed to correspond to the reset states.
Those of skill in the art will appreciate that the representation of
At the system level, the digital blocks exemplified in
In one or more embodiments as schematically represented in
In one or more embodiments, a system may thus include an IP block where a set of IP registers (e.g., the sequential logic 12) may include, possibly together with other partitions: a first partition 12a including registers which may be configured in a VRAM mode; and a second partition 12b including other registers that, for any reason, may not be held to be suitable for being configured in a VRAM mode.
A purpose of the VRAM mode may be to reconfigure the IP internal registers in a way that they become accessible at a system level essentially as a RAM (as shown in
In one or more embodiments such an approach may involve creating (possibly by re-using a portion of the logic 10—see
The system (IP block) may thus operate in two (e.g. mutually exclusive) modes: a “conventional” IP mode, and a VRAM mode.
At a system level, the configuration register 14 may be added (which may be both external to the IP block or included among the IP block registers) in order to enable/disable the VRAM mode, e.g., via software.
When in such a VRAM mode, the sequential elements in the digital IPs 12a may then act as a memory accessible, e.g., via the interconnect 106 within a certain address space (e.g., the same address as the original peripheral, possibly by remapping/expanding the address space as detailed in the following) with the capability of receiving “VRAM” inputs, e.g., input data
VRAM DI and issuing corresponding “VRAM” outputs, e.g., output data VRAM DO.
Reference number 16 in
In one or more embodiments, these two modes may be mutually exclusive and the MUX module 16 (including e.g., a MUX for each register) may keep the two modes (standard IP and VRAM) separate so that the sequential block 12 may receive: the value produced by the logic 10 in a conventional functional mode, or, alternatively, the value from the logic 120.
As schematically represented in
In fact, the logic 10 may be unmodified, while however, with the “functional” conventional IP mode and the VRAM mode being mutually exclusive, the functional output provided when in the VRAM mode may be meaningless (e.g. ignored, blocked or kept at a known value) since the registers are “captured” by the other combinational logic.
In one or more embodiments may thus involve providing one or more of: some combinational logic 120, e.g., in order to access and re-organize the sequential elements as words; read/write pointers RD PTR/WR PTR; and decoding logic for the “virtual” RAM.
In that way, respective input data VRAM DI may be received and respective output data VRAM DO issued by the combinational logic elements 120 when switched to the VRAM mode.
Reference number 1200 in
For instance, the block diagram of
In one or more embodiments, the values of these two selection signals may produce any of the three following modes of operation:
i) standard functional input data funs_data are taken when in the standard IP mode;
ii) the data stored in the DFF 1200 are recirculated as recirculation_data, when in the VRAM mode with the DFF 1200 not selected for write operation; and
iii) new memory data are selected when, in the VRAM mode, the DFF 1200 is selected for a write operation wr_data.
The logic involved in the VRAM mode may be described at a RTL-level (together with the digital IP) or can be added at a netlist level. For instance, a basic netlist implementation flow may collect topologically-close word-sized groups of DFFs and replace a standard cell with a custom element including the 3×1 multiplexer, essentially as a scan insertion mechanism.
The block diagram of
For instance, the diagram of
It will be appreciated that, in one or more embodiments, the MUX 1206, which makes it possible to implement recirculation of e.g., a 32-bit word, may not be completely alternative to the MUX 1202 associated with each DFF, but rather adds thereto. The presence of the MUX 1206 and the clock gating mechanism makes it otherwise possible for each 3×1 MUX 1202 in
In that way, both recirculation and writing of data are manageable (word_enable) as an alternative to IP operation as sequential elements (func_enable).
An implementation relying on such an approach may take advantage of the possibility of sharing similar functional logic (IP mode), which may already be present. In one or more embodiments, clock gating cells may be common, especially in low power designs. The digital unit may then be likely to have several of these already present in its functional (IP mode) implementation which may be used in the VRAM mode with low extra logic requirements.
In one or more embodiments, common digital structures such as register banks, FIFOs and soft memories may be exploited by, turning them into virtual RAMS with a reduced silicon area overhead. In one or more embodiments, the VRAM mode may extensively re-use configuration registers which are addressable by construction.
The diagram of
The block diagram of
While the map of
With the VRAM mode activated, the address map may be reconfigured (in a more common case, it will have to) to receive the new RAM seen by the software as a substitute, extension or (full) repositioning.
One may consider
Stated otherwise, 121 and 122 are (in the IP mode) at the addresses shown in the upper part of the map. When the VRAM mode is activated, the spaces denoted IP1 and IP2 may no longer be accessible by software, while the portions VRAM1 and VRAM2 (which are “prohibited” in the IP mode) now become accessible. In the example given, the portions VRAM1 and VRAM2 are contiguous to the Main RAM, and the new address map gives to software a single “large” RAM.
From a system perspective, the software SW can either see a certain RAM at the same address of the original peripheral or at an extension to one of the system RAMs (e.g., through address remapping).
In one or more embodiments, when in the virtual RAM mode a (significant) part of the original interface can be re-used e.g., protocol state machines to communicate over the interconnect 106.
In that respect,
Efficiency in implementation will aim at increasing the intersection of the logics 10 and 120 (increasing as much as possible the portion of the logic 10 which is re-used to create the logic 120) and reducing the partition 12b to the benefit of the partition 12a (by exploiting as many registers as possible in a VRAM mode).
In one or more embodiments some logic may be devoted to extend the allowed address space. For example, in the IP mode, configuration registers may only be accessed via software SW, while additional flip-flops may be included in the addressable region in the VRAM mode. Address decoders throughout the interconnect 106 may support a remapping function, if present.
Without prejudice to the underlying principles, the details and embodiments may vary, even significantly, with respect to what has been described by way of example only, without departing from the extent of protection. The extent of protection is defined by the annexed claims.
Number | Date | Country | Kind |
---|---|---|---|
102015000017584 | May 2015 | IT | national |
Number | Name | Date | Kind |
---|---|---|---|
6392438 | Cliff | May 2002 | B1 |
6467009 | Winegarden et al. | Oct 2002 | B1 |
6732068 | Sample | May 2004 | B2 |
20020130681 | Cliff | Sep 2002 | A1 |
20050097499 | Sun | May 2005 | A1 |
20050108495 | McKenney et al. | May 2005 | A1 |
20050248366 | Chung | Nov 2005 | A1 |
Entry |
---|
Marshall et al.—A Reconfigurable Arithmetic Array for Multimedia Applications, ACM/SIGDA International Symposium on Field Programmable Gate Arrays, FPGA '99, Monterey, CA Feb. 21-23, 1999, pp. 135-143. |
Number | Date | Country | |
---|---|---|---|
20160352337 A1 | Dec 2016 | US |