1 / 27

Firmware based array sorting and Matlab testing suite midterm presentation may 4 th , 2011

Firmware based array sorting and Matlab testing suite midterm presentation may 4 th , 2011. Elad Barzilay Uri Natanzon Supervisor: Moshe Porian. Project Goals. Building a generic integer array sort firmware on an FPGA board Develop a comprehensive testing

eugene
Download Presentation

Firmware based array sorting and Matlab testing suite midterm presentation may 4 th , 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Firmware based array sorting and Matlab testing suitemidterm presentationmay 4th , 2011 EladBarzilay Uri Natanzon Supervisor: Moshe Porian

  2. Project Goals Building a generic integer array sort firmware on an FPGA board Develop a comprehensive testing and debugging environment.

  3. The need for Histograms Many image processing algorithms relay on the use of histograms. For example - Photo “auto fix” – histogram equalization Photo Min Photo Max 0 Full Dynamic Range

  4. For example:

  5. Project Overview System capabilities & requirements Sorting an array of finite integers set. Zero latency system. Fully debug-able. System operation via PC interface. Design principles Generic implementation. Top down design. Error detection and handling. System implementation on the DE2 evaluation card. PC GUI implementation on MATLAB. Complete development process: Characterization-> debugging platform.

  6. SORT_TOP – Inputs & OutputsTime Diagram

  7. High-level overview

  8. High-level overview

  9. High-level overview

  10. High-level overview

  11. High-level overview

  12. High-level overview

  13. High-level overview

  14. High-level overview

  15. High-level overview

  16. SORT_TOP – Block diagram

  17. DPR_update – Block diagram

  18. DPR_block – Block diagram

  19. DPR_reader – Block diagram

  20. Message Pack Structure 8 bits SOF 1 Byte. Some constant predefined flag ID 1 Byte. For message tracking address 1 Byte. Specifies the addressed block address 1 Byte. Type options are : set, query, sort Data Length 2 Bytes. Specifies the length of the data segment in bytes. Data (Payload) [Data Length] X Bytes. (up to 65535 bytes) Holds the data and control signal to be fed into SORT_TOP CRC 1 Byte. The CRC type will be defined later. EOF 1 Byte. Some constant predefined flag

  21. Firmware Testing - simulation • All FW sub-modules were tested in VHDL TestBenches. • Verification of module behavior by MODELSIM waveform analysis. • All blocks - Tests included valid operation conditions. • Sorting block - Tests also included “worst case” scenarios: • Sort_update– repetitions, fast toggling. • Sort_reader– zero repetitions, single repetitions, multiple repetitions. • Communication path - tested in firmware. • Error handling and CRC – not yet implemented. Will be tested separately. Comprehensive tests will be held via “DUDE” – Our Matlab GUI

  22. “DUDE” – Debugging Under Development Environment MATLAB based GUI for data injection, result validation and status query

  23. “DUDE” – implementation goals achievements • Send user defined arrays of data to be sorted. -Done • Send random arrays of data to be sorted. -Done • Verify the correctness of the sorted returned data array. – partially done. Not yet In GUI but capability implemented and used for debug. • Create fully user generated packets to generate errors. –Not implemented yet. • View bit representation of the messages sent and received . – Capability exists but not in GUI. • Logging of out/in-bound messages. –Not implemented yet.

  24. “DUDE” – implementation guidelines • OOP based GUI. • 2 main classes implemented: • CSettings – holds all the framework data and manages the messages list • CMessage – holds all the data per one given message and manages the dynamic data creation such as CRC and data length calculation. • This modular design allows the GUI to be versatile and parameter independent. • All non implemented features are easily implemented with small effort. • Easily adjustable to additional requested features.

  25. Project Time Line

More Related