0
\$\begingroup\$

For low power design, clock enables can be used to turn off a block, thus reducing dynamic power. For example, if raw ADC data is being obtained and not FFT processed data, then that FFT module could be shut down using the clock enable.

My question is this:

  • Does anyone have any resources (papers, white papers, app notes) that discuss separate block resets, where those resets are (a) secondary to the global reset and (b) are tied to a uProc's register map? Is this even good design practice?
  • The design intent would be for run-time debug. Let's say we have a FIFO filled with data that is being transferred to uProc working memory via DMA. Now, if the DMA engine flags up that it has an issue, it would be useful to reset the DMA engine separately to the FIFO. Obviously global reset would reset everything including the FIFO and the uProc, meaning the data and processor status that was obtained during the fault is lost.
  • For a uProc controlled FPGA design (SoC), there may be SPI/I2C peripherals, there may be DMA engines, memory banks, Ethernet controllers, DSP IP cores etc. If there was an issue with an SPI controller for example, I want to be able to reset this without a full global reset.

Has anyone seen any white papers or application notes for this strategy?

Many thanks.

\$\endgroup\$
0
\$\begingroup\$

Yes, what you just described is called Clock Gating. A popular technique used in the SoC Industry to disable peripherals to reduce dynamic power (especially when using a generic SoC for a specific usecase). You will find a lot of resources on this by looking up the term "Clock Gating". Here's one for example. The mechanisms to handle FIFO are also discussed in various resources such as 1, 2 and 3

For a uProc controlled FPGA design (SoC), there may be SPI/I2C peripherals, there may be DMA engines, memory banks, Ethernet controllers, DSP IP cores etc. If there was an issue with an SPI controller for example, I want to be able to reset this without a full global reset.

What kind of issues are you referring to? When dealing with digital logic peripherals, there are usually programmable registers within each peripheral that allow recovering from known issues (such as DMA/Security errors) etc. Although special cases do have a reset separate from a Global Reset. For example: In a multi-core system you would want to keep the system reset independent from the individual core resets, so that the current state is not lost when one of the cores need a reset.

\$\endgroup\$
  • 1
    \$\begingroup\$ Yes. Under both (clock gating and independent peripheral resets) I knew these were reasonably common. I'm more looking for resources that discuss these. For example Cumming's SNUG papers on resets etc. The case here is the creation of new blocks, interfaces, peripherals etc and the best practices surrounding their development. \$\endgroup\$ – user2286899 Apr 26 at 7:52
  • \$\begingroup\$ As a direct example, say there are 2 clock domains, Aclk: main processor sub-system and Bclk: input data, DSP and initial FIFO sub-system. There may be cases, where the data clock from an external ADC is not yet stable, or experiences some glitch issue. For the case of SERDES data, perhaps this disrupts frame decoding back into parallel and requires bitslip to be re-locked. The bitslip block should re-train itself, but a SW-controlled reset may be another option. The Xilinx reset module, PG164, provides similar functionality. \$\endgroup\$ – user2286899 Apr 26 at 7:59
  • 1
    \$\begingroup\$ For example, the Xilinx intellectual property interface (IPIF) generator allows the definition of a software reset register that can be set by any other master on the AXI-Lite bus: xilinx.com/support/documentation/sw_manuals/xilinx14_6/… I guess what I'm getting at is not, should this be done or how it is done, but some higher-level literature as to justification of this requirement. When coming up with requirements such as async reset assert, synchronous de-assert, there often needs to be some justification. \$\endgroup\$ – user2286899 Apr 26 at 8:21
  • \$\begingroup\$ You are right! I've often found the need for such resources too. But haven't found good literature that captures all of it in a single place. Most of this comes as best practices. Cummings papers are good but then again they're limited to a set of topics. I'm going to look for this too and update here when I find something. Thanks! \$\endgroup\$ – Rajesh S Apr 26 at 16:31
0
\$\begingroup\$

I think you're referring to two things, gating a clock to save power, and providing CPU controlled reset signals to specific logic blocks. I agree with Rajesh, for the former what you are doing is called Clock Gating, and is a normal technique.

As to the second part, it is quite common in my experience for a CPU peripheral to have a reset signal, usually implemented as a bit in a CPU accessible register. For example, see the SOFTR register in the xilinx IIC controller: https://japan.xilinx.com/support/documentation/ip_documentation/axi_iic/v2_0/pg090-axi-iic.pdf

Personally, I believe it is a good practice to allow a software driver to reset a peripheral to its power-on state. There are lots of cases where this can be useful, e.g. jumping from a bootloader to another application, resetting the processor-only while debugging, or as you say, when debugging a problem with a particular custom peripheral. I recommend adding a reset bit to any custom peripherals you create.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.