13-04-2013, 04:05 PM
Proof of Concept Implementation With the SPARTAN 3E FPGA Evaluation Board for the CAL POLY SuPER Project
Proof of Concept Implementation.pdf (Size: 624.04 KB / Downloads: 82)
Introduction
In 2005, Dr. James Harris presented his white paper discussing a proposed activity to develop a low-cost, sustainable source of solar power with a 20 year life cycle[1]. The project is intended to help financially troubled regions with high levels of solar radiation. In an ever-growing weak global economy, where government aid and humanitarian projects lack funding, a possible solution has been brought to research by the members of Cal Poly‟s Sustainable Power for Electronic Resources (SuPER). With solar technology and energy conversion efficiency increasing every year, Dr. Harris, along with Dr. Ali Shaban and various EE and CPE students have started a prototype that aims to solve the fundamental problem of power distribution and affordability. The idea is to harness solar energy via a solar panel to bring energy to household necessities such as lighting and refrigeration for a cost of under $500. Currently the project is still in Phase 1 and the estimated price tag is about $1500, but great strides and improvements have been made along the way. This project will help move into Phase 2 by producing a proof of concept that will dramatically reduce overhead by replacing the current laptop with an FPGA device. The lab top acts as the central device that stabilizes the entire system and processes all the data and controlling algorithms. Technology has brought the FPGA industry into the high performance market of computers, yet can be reprogrammed rapidly to adapt to changing circumstances and environments. For greater control and reliability, progress is currently underway to install an OS onto the FPGA [12]. This project focuses on the actual interface functions for the FPGA to handle.
Background
The system is currently controlled by a laptop computer. The laptop is the interface between data acquisition, the PIC microcontroller, the DC-DC converter, and the MOSFET switches, shown in Figure 2.1. It is an integral component to the functionality of the SuPER design, but consumes a large portion of power and is also very costly.
Hardware Design and Configuration
PWM Signal and Timer/Counter
As stated in the last section, the MicroBlaze EDK supports a Timer/Counter IP core that can operate in several timing modes. The IP core can be configured using two separate counter registers within the core architecture that act as a PWM‟s period and duty-cycle. Witts[9] had found the ideal operating frequency to be 25 kHz for the DC-DC converter; therefore, this system was modeled according to that specification. The PWM core also offers an interrupt signal which is connected to the Interrupt Controller IP core to maximize the codes efficiency, since the system will not have to poll the PWM to check its status. The interrupt is sent to the uBlaze processor and the proper interrupt service routine (ISR) is followed. Within this routine, a pseudo-MPPT algorithm was created to adjust the duty-cycle according to a specific power supply voltage acting as a system sensor. The original MPPT algorithm is very complicated and requires several of the systems status signals and sensor readings in order to calculate the proper operating mode and duty-cycle adjustment.
MUX Layout and Control
The current SuPER design uses 21 sensors and 11 switches to monitor and control
the entire system. There are plans to add at least an additional three signals for the ultracapacitor,
and more for other components. Therefore, to allow for the additions, this
design recommends planning for 32 individual input sensors. Since the ADC offers two
channels, the most efficient MUX solution would be implementing two separate selector
devices to maximize throughput. This will require two 16:1 MUX‟s, each requiring four
selector control lines, a chip-enable, and supply voltages. The selector lines are defined
in the uBlaze project as general-purpose I/O‟s (GPIO‟s). The GPIO‟s can be configured
to any data width (< system data bus width) and can varied within software to select the
desired channel.