Active In SP
Joined: Sep 2010
31-12-2010, 04:11 PM
VI_report.docx (Size: 2.57 MB / Downloads: 74)
It is history to exchange data between various IC chips, at very high speeds; say, at 10 MHz or even more. Due to this high-speed aspect, the bus lines that will be used for communication cannot be too long, because their reactance increases too much, and the bus becomes unusable. The best and the most apt solution for this query is SPI bus. SPI stands for "Serial to Peripheral Interface", and it is a hardware and firmware communications protocol developed by Motorola and later adopted by everybody. This bus is mainly used on the PCB and is very good, because we can practically attach to the bus as many ICs (or devices) as we want. Besides from exchanging data between various IC chips, the SPI Bus is a method of multiplying controller's pins. In other words, if one has a tiny 8 pins controller, he could control with that little monster few hundreds of digital Inputs and Outputs. The SPI Bus contains three lines, and they can be on any general I/O controller pins. These Bus lines are: Clock, Data-In, and Data-Out. In addition, each IC connected to the SPI bus needs an individual Enable or Chip Select line. The beauty with the SPI bus is, it is Synchronous, meaning, when the controller sends the message to one IC, it is also able to receive data from that IC, on the same time. This particular aspect of the SPI protocol is particularly well suited for Controller-to-Flash communications. So, the SPI is a synchronous protocol that allows a master device to initiate communication with a slave device. The advantages of SPI are its simple interface (with no bi-directional pins), simple protocol and supports full duplex data streaming. With rapid adoption of SPI Protocol, industries are facing constant pressure in designing and validating the SPI on various kinds of Serial Flash and then improving its efficiency in data transfer. In this project and implimentation an attempt is made to develop compliance software for automating the data acquisition and analysis of the validation process for SPI Flash Protocol.
With the rapid advancement of SPI Protocol in data communication technology, serial flash with these capabilities are being designed and validated. These with the progress of time have become highly complex which has resulted in the development of software testing practices in the industry. With rapid adoption of SPI Protocol, the engineers designing and validating the serial flash for different modes of SPI face constant pressure to reduce the bugs and improve efficiency. Engineers need to perform a wide range of compliance tests quickly and reliably right on the bench. Once a design is complete, checking that all is well moves from being a logical activity to being a physical one. Testing is never complete as any protocol evolves (both through intent and accident) as it is used. So mechanisms for problem and issue management need to be put in place to handle this. There are reasons why at times a designer may be involved in troubleshooting a device. This is when the protocol is exhibiting unexpected behavior that cannot be explained by any known failure mechanism. This project and implimentation is an attempt to study the design challenges faced during validation and to develop comprehensive, integrated compliance software for automating the data acquisition and analysis of SPI Flash Protocol using LabVIEW and Tektronix CRO for various modes of SPI that enables to resolve validation challenges quickly and efficiently.
“To develop automation software to control the Tektronix CRO for Data Acquisition and Analysis of SPI Flash Protocol and to implement it on PIC and C51 microcontroller such that it enables to resolve validation challenges efficiently.”
SYSTEM SPECIFIC TARGETS
• To control the Tektronix CRO activation through LabVIEW
• To design an acquisition module to run the oscilloscope in normal sweep mode
• Acquire data captured by the oscilloscope
• To display the acquired data on waveform graph
• To design an extraction module to extract the relevant data time to time from the acquired data for decoding
• To decode the string displayed on LCD and 1-8 decimal digits displayed on 7 segment LEDs.
• To calculate the worst setup and worst hold time for each instruction.
• To save the results obtained in a file for future reference.
|Possibly Related Threads...|
|manufacturing automation protocol ppt||jaseelati||0||151||
23-12-2014, 01:52 PM
Last Post: jaseelati