Mini scope one semester project Project final Presentation Svetlana Gnatyshchak Lior Haiby Advisor: Moshe Porian Febuary 2014

Contents Motivation Top Architecture Micro architecture Testability and Simulation Conclusions

Motivation Today Future

Project Goals Main objective : Development of a mini-scope on FPGA Basic scope functions with added features for convenient using

Project Goals Various user changeable options like trigger position

Technical Demands Each unit is to be planned, built and tested separately. Later on the components will be merged into one system and tested as such. Wishbone Protocol for integrating SG with FPGA. Verification tools using VHDL and MATLAB.

TX Path Mini Digital Signal Scope Core Mini Digital Signal Scope Core RX Path WBM – Wishbone Master WBS – Wishbone Slave WB M WBS A2D Core A2D Core WBS Wishbone INTERCON Wishbone INTERCON FPGAFPGA RAM UART Host (Matlab) A2D MiniScope System Components The project’s main focus WBS Partly implemented for simulation

Top Architecture Mini Digital Signal Scope Core Mini Digital Signal Scope Core WBS RAM WBM WBS connections RAM a2d_to_write_controller_connections A2D RAM user_to_registers_connections WBS User’s WBM A2D’s WBM WBS Scope’s WBM User’s WBS scope

Micro architecture user_to_registers_connections WBS User’s WBM WBS buffer_for_registers registers To connections Goal: Receive the user’s commands via wishbone and save them in the registers

Micro architecture connections write_controller read_controller connections RAM user_to_registers _connections a2d_to_write_controller_connections Scope’s WBM Goal: To receive the constant flow of data from the A2D, save it in the RAM, search for the trigger, and after all relevant data is found, send it to the user

Write Controller block( the heart of system ) Goal: write all incoming data from A2D to RAM until find he trigger, after that saved the rest data according to percentage and after finish saving give the order to the read controller start read the data.

Start searching the trigger

Find trigger

Read Controller block Goal: read all the relevant data from RAM after the write controller give an enable and the start address.

Read controller simulation

RAM block Goal: The basic storage unit. All data saved in RAM in cyclic way.

RAM simulation

Registers block Goal: save the user settings for a system

Register simulation

Mini Digital Signal Scope Core Data Flow Chart The mini tour Data Flow Chart The A2D constantly sends data (via wishbone) to the Write Controller The data is sent in batches of 255 bits. Data Flow Chart The user chooses the following parameters: Trigger size Trigger type Trigger’s Filter level Trigger percentage Trigger start search User read enable You can read Trigger size, type, filter, percentage, search Data Flow Chart Once the WC receives the “trigger search” command, it keeps on saving, but also starting to go through the incoming data in search of the appropriate trigger Data Flow Chart When the trigger is found, the WC keeps telling the RAM to save until we saved enough according to the user (calculation is done according to the trigger percentage) Data Flow Chart When we finish saving all the required data, the write controller stops enabling the RAM to save and gives a Read Enable to the Read Controller Data Flow Chart Once the RC has been enabled, it tells the WB Master where to start, and how much addresses to send. The data usually transfers in two batches, but in some cases it might transfer only in one. Data Flow Chart All the data is extracted and sent (via wishbone) back to the GUI for display. ? Data Flow Chart The user’s wishbone component returns an ACK signal to say everything went ok, afterwards the WB master tells the write controller all data has been sent Data Flow Chart The Read Controller passes the signal back to the Write Controller and it, in turn, will enable saving again, and wait for new orders

Simulation Add-ons

Simulation of the complete system Including Extra components for Tests The signal from Matlab

How different percentage values affect the output data 0% shown prior to the appearance of the trigger 100% shown prior to the appearance of the trigger 25% shown prior to the appearance of the trigger 75% shown prior to the appearance of the trigger

How different filter values affect the output data We took a basic example – trigger size is still 139, the percentage is 50, the type is 0 (need to have a higher value than 139 to trigger). What changes? – the filter! First filter – low (only 1 ‘hit’ to trigger). Third filter – highest filter (8 and above ‘hits’ to trigger) Second filter – high filter (4-7 ‘hits’ to trigger)

Synthesis Results

Timing result Fmax – 31.89Mhz

Testability

Test plans Building a Test Bench for every unit in the Scope Building integration tests between all the units Tests for the Scope’s system, without wishbone Tests for the Scope’s system, with wishbone

Tests per unit Check unit functionality Check edge cases Check what happen when the given data suddenly not valid Check the unit behavior in different use cases

System tests: Trigger level tests Expected resultTrigger directionTrigger level * trigger detectioncommon, opposite0.01,0.25,0.5,075,0.99 no trigger detectioncommon1.1 trigger detectionopposite1.1 trigger detectioncommon-1.1 no trigger detectionopposite-1.1 * Multiply by (absolute) Peak value

System level tests: More features tests Expected result ValueFeature name Saving data in RAM according to the percentage value Percentage = 0,20,50,70,100 How much data prior to trigger Without the appropriate consecutive appearances of triggering values, there will be no transition to the next state Low level middle level high level Consecutive appearances of ‘triggering values’ We expected read all relevant data in right order without dependency in RAM address where first signal after trigger was saved. RAM addresses: 0, RAM size /2 RAM size – 1, Check the different places of first signal after trigger in RAM

Few more tests.. Expected resultTest name The WC will return to idle state after each finished transfer, and the system will continue as if it was just restarted. Test a long simulation, no reset between sequences System will stay idle, meaning the data is still being stored but no trigger will be searched. Test a wrong input from the user (not enough arguments) System will keep on searching until a trigger is found. If the user wishes, he can insert a new input. Test a non-existent trigger

Generics value for simulation low_level_g:integer :=1; --enough find one trigger mid_level_g :integer :=2; --2 consecutive triggers high_level_g :integer :=4; -- 4 consecutive triggers highest_level_g :integer :=8; -- 8 consecutive triggers data_width_g: integer :=8; -- data width in bits addr_width_g: integer :=8 -- address width, The RAM's size is determined by the address width => 2^add_width_g

Work Methods Documentation - SVN Coding Guidelines: Suffix (_c, _g …) Headers Shifting Comments etc… Code review

What have we learned so far? Planning and Specifying a project Documentation of the components and the work’s process Writing reusable generic code Integration of a large quantity of components Verifying capabilities

Future Vision FPGA GUI communication between the scope and the GUI Finding and using an A2D Creating an application suitable for a user, including tutorials for beginners and for experts