Every microcontroller evaluation boards has an unsung hero in it which helps the microcontroller to interact with the external world. Whether it’s pressing a button, blinking an LED, or reading data from a sensor…. We connect them to a special set of IO pins in the microcontroller. Yes, we are talking about the General Purpose Input Outputs or GPIOs which make this interfacing with outside world possible.
So, are they just IO pins after all? No. GPIOs are not just “a bunch of IO pins sticking out of the chip.” Behind these pins lies a digital block, which gives the microcontroller the ability to configure, drive, and sense these IOs. It’s called a GPIO core.
GPIO core is an inevitable peripheral in a microcontroller. In this blog, we will explore about GPIOs and how to design a GPIO core in RTL and test it on board.
How GPIOs work?
Let’s take a microcontroller to explain how GPIOs work. GPIO core is a memory-mapped peripheral inside a microcontroller. The processor inside the controller can write into the GPIO peripheral registers to control the direction, state, and interrupt capability of the GPIO pins.
GPIO core in a Microcontroller
Memory-mapped peripherals are the building blocks of any SoC built around a CPU or a bus master. I have written a whole blog on the fundamentals of memory-mapped peripherals here.
IO pins are driven by IO buffers in a chip. Bi-directional IOs are typically driven by tristate buffers. So, the ultimate goal of a GPIO core is to control the tristate buffers to drive/read the GPIO pins.
A tristate buffer has two controls: the data input (driver signal) and the Output Enable (OE).
When OE = 1, the buffer drives its output with the input signal.
When OE = 0, the output enters a high-impedance (Hi-Z) state, effectively disconnecting it from the driver.
GPIOs – controlled by Tristate buffer
The direction of an IO pin is configured through a control register.
- When set as input, the output driver is disabled (OE = 0).
- When set as output, the output driver is enabled (OE = 1) to allow actively driving the pin.
The state of the IO pin is controlled by a data register in the GPIO core. This register directly drives the IO buffer.
- To drive an IO pin high or low, write the required state into the corresponding bit in the data register.
- To read the state of an IO pin, simply read the data register.
Simple & elegant!
Additionally, GPIOs may have interrupt capability, i.e., the input pins can act as interrupt sources. This is particularly useful to detect external events instantly without constantly polling them. For example, a GPIO interrupt can wake a microcontroller from sleep or interrupt its operation when an external button or sensor trigger an event.
Designing a GPIO core
From the understanding of the basic requirements of a GPIO core, let’s define the minimum specifications of our GPIO core.
- Registers to dynamically control the direction, data, interrupt capability of the GPIOs.
- A simple bus interface to write/read the control & status registers (CSRs).
- A core interrupt to notify the bus master or CPU.
GPIO v1.0 IP core uses APB interface to access the CSRs. The CSRs control the IO buffers and interrupt blocks. The core has comprehensive interrupt capability as well; like being able to configure the interrupt enable/disable, type (level/edge), masking.
GPIO v1.0 – Block Diagram
The IO pins configured as inputs can be additionally enabled as interrupt sources. The interrupt handling by the core is as follows:
- Once the interrupt is enabled, a level/edge event at the pin can trigger interrupt requests.
- The interrupt requests are accumulated, status is logged, and the core interrupt is generated to notify the bus master or CPU.
- The interrupt source can by identified (which IO pin?) by the bus master by reading the interrupt status register. Then, the corresponding ISR (Interrupt Service Routine) can be executed.
- The status is cleared by the bus master after furnishing the ISR.
Testing on board
GPIO v1.0 IP package includes a test-suite which can be simulated and synthesised on FPGA boards. The core can be tested by connecting a bunch of buttons and LEDs to the inputs and outputs. Buttons generate interrupt; the test bench which emulates a bus master acknowledges it and turn the LED on/off. Refer to the IP user guide for more details.
FPGAs typically have tristate buffers on their IO blocks (IOBs). So, they are automatically inferred by the RTL when the GPIO core is synthesised on FPGAs. GPIO v1.0 is an FPGA-friendly IP core, hence the tristate buffer instantiation is kept within the core, so that it can be directly inferred on the IOBs. If ASIC is the target, you may have to remove the tristate buffer instantiation from the GPIO core and keep only the control signals (data signal, OE). During the synthesis/P&R time, it can be mapped to the technology-specific IO cells.
GPIO v1.0 – Source codes and Documentation
GPIO v1.0 is a fully tested, portable, configurable, and synthesisable soft IP core. All source codes of the IP are open-source licensed and can be downloaded for free from the links below. The source codes include:
- Design source codes.
- Makefile to compile, build, and simulate.
- Test suite to simulate and test the IP on board.
Download the IP package and resources from the Chipmunk IP Catalog:
IP Solutions – gpio_v1_0
Support
Leave a comment or visit support for any queries/feedback regarding the content of this blog.
If you liked Chipmunk , don’t forget to follow!:
Like this:
Like Loading...
Related