Upon the advice of many colleagues of ours, we approached the design trying to make the actual operations of the FPGA and the Hardware Modules as simple as possible. This took many forms from using lpm functions and available templates for MAXplus2 vhdl code to researching industry standards on hardware implementations of functions similar to what we were dealing with.

The design of the VHDL programming was influenced very heavily by our Hardware designs, so the logical details to start with are the actual hardware module designs and how we design our code to work with them after mentioning the final chip details.

The chip used 523 logic cells (45% of available cells) and used 1 dedicated I/O pin and 31 regular I/O pins. The register speed performance was 33.44 MHz, which was adequate for our project. We had originally chose the Altera board because it was reprogrammable, which suited our group design style, and it was large enough to hold our likely design.

- The LCD module was chosen based on what was available at Electronics Resources. The readily available choices were 8 bit LED chips, the Sharp 2 * 16 character dot matrix unit, and VGA monitors. We eliminated the 8 bit LED's because it would have taken 32 individual units to handle all our output data (letters and numbers). VGA monitors and the Dot Matrix Unit both had the required size and flexibility, so we chose the simpler of the two to implement, because as a smaller group, we had more time restrictions than a larger group (It has come to my attention that groups using the VGA monitors had one group member solely work on VGA portion of the project so it would appear we made the right decision). The LCD input is relatively easy to encode as it serially polls the output for data encoded in ASCII characters. 

- The temperature hardware was chosen originally upon what we could find in the data books with Morris Locker's aid. These devices would have consisted of an AD2202 temperature sensor with an Analog to Digital Output. While we were working on this design, we found a much better and reasonably cheap alternative, which would require minimal calibrations to the original sensor converter combination. This is why we chose the LM35C Precision Centigrade Temperature Sensor (National Semiconductor) and TLC7135C 4 1/2 Digit Precision Analog to Digital Converter (Texas Instrument). This combination works well together to provide accurate digital temperature reading in BCD digits. These digits are then outputted to the chip

 - The wind speed module design was a long and arduous task. The basic hardware configuration consisted of an Optical Switch (which turns on and off when something opaque is inserted between the halves of the center and then removed) and a code wheel (which is a simple circle of opaque material with slits cut into it). The idea is that as the wheel turns, the slit pass through the sensor. The sensor then turns on and off. This signal would then need to be decoded by the FPGA, before the wind speed could be determined from it. The first attempt was to try with one sensor. As the pulses from the sensor arrive, we would count the number of clock pulses into the Altera board. The number of pulses would then be compared to a predetermined period. Nested if statement would be used to decode the number of pulses counted into the chip. We would thus be measuring the period of the incoming signal, and use the period to determine the wind speed. Although this method may have worked, we found the code took over 2 hours to compile and took up over 30% of our chip space. We thus decided to abandon this approach and seek some advice.

After discussing our problems with the T.A. (Noah), we were given a large hint of trying to do this measurement the opposite way. Instead of counting the period, we should slow down the clock and count the frequency. This would mean that we would need to provide a counter to count up to the "1 kilometer per hour"(1kph) period. This number is hardware dependent (see hand written calculation) so a rough hardware design was considered. One extremely large counter would be needed to count up to the 3 million, which would be the amount of time needed for the second pulse to be detected if the wind was blowing at 1 kph. We assumed that the length of time between pulses would be linearly inversely proportional to the wind speed. This calculation neglects certain frictional and other unknown forces acting on the anemometer (the physical device that moves circularly in one direction when wind blows on it). By using the 1 kph period and the linear speed relation, the Altera board would actually receive the number of pulses equal to the wind speed between the two input pulses. In the LCD, we decided to decode the three numbers of the wind speed counter (not the 1kph period counter), and a decision was also made to use the decade count (0-9, 10-90, 100-900) which would use BCD instead of Binary. These BCD values would make the conversion of the counter data to ASCII simpler. A final note on the design: to make the 1 kph period counter 4 bits smaller, we would use a code wheel with 16 slits instead of 1. The idea for this number of slits came from actual speed detector code wheels, which have 1000's of slits in them.

In the prototype version, we did even another way of determining the wind speed. There are two sensor inputs to the Altera chip. These signals are input to the debounce module, which ensures that the sensors are reading the data correctly. The debounce signal is then used in an incremental counter. The incremental counter will count the number of pulses (ensuring that there are 10 pulses per kph), while the down counter will decrement from a predetermined number to zero. Once the down counter reaches 0, the value of incremental counter will be the wind speed. The wind speed is then converted to ASCII, before it is sent to the LCD controller. The wind speed was tested with a Quad 2-input NAND Schmitt trigger (HCT132 from Philips Semiconductors) and a variable resistor. This Schmitt trigger was chosen, because this was the only Schmitt trigger available, when this part was purchased.

-The wind direction module is another module. The hardware for the module consists of a weather vane with four optical sensors, and a code wheel with just over 3/8 of it cut out to provide a massive slit ( note: after project completion and final presentation a much better way to encode the wheel was found. It consists of using a transparent code wheel and four sensors. To determine the direction the sensors look down and through the code wheel. By lining the four sensors up in a row from the center to the edge of the wheel the wheel can be encoded by dividing it into 16 sections and blacking out the sixteen digital number in each section. A different sensor than the OPB 804 would be recommended for this method). The massive slit is lined up so that the middle of it is lined up directly with the arrow on the weather vane. The arrow of vane points in the current direction. This provides a '0' output where the slit is. This will activate up to 2 sensors thereby giving us 8 directions at the output. This input is then compared (using an if statement) which activates the correct outputs in ASCII.

In the prototype version, we used 4 Optical Switches (OPB804 from Optek) to test the wind direction. We picked these sensors because they were readily available from Morris Locker and from Active Components, and they gave the necessary on and off signals.

- An optional module that we planned to do provided that we had enough time was the RS 232 serial data communication. Unfortunately, due to time constraints, this code was not completed. Some of the most important sections was written and included in this report. The acount.vhd reduced MHz signals to 9600 baud, rs232rotate (producing serial data to the output) and the ram version of VHDL (since the data was received through the clock at very high speeds, the data has to be saved before it can be transmitted via 9600 baud).

The actual module interfaces to the chip are quite simple. The wind speed and wind direction pulses are simple digital signals, which are read directly into the chip, and so no other interfacing was required. The temperature module required extra interfacing. The 4 1/2 digit A to D converter for the temperature module had code written for it, because the digital signals arrived into the chip when the invert strobe and the converter outputs are read sequentially. The LCD module, which was the most difficult to interface due to timing constraints, also had special interfacing code written for it. The enable signal was required to output the data.

To explain the interfacing better we have included a diagram of the chip, which shows all the inputs from the hardware and outputs to the hardware. Hardware interfacing description on the IC data sheet explains the hardware configurations.