Sub- Nyquist Sampling System Hardware Implementation

1. Sub- Nyquist Sampling System Hardware Implementation • System Architecture Group – Shai & Yaron • Data Transfer, System Integration • and Debug Environment • Part B – final presentation

2. Outline • Introduction • GOALS • Concepts • 1st part short review • 2nd part milestones • Difficulties we encountered • Creating controlling GUI • Summary

3. Introduction • Providing communication between the units, I.e. transferring data between FPGAs. User GUI Sub Nyquist Sampler Digital board A/D MODULE x(t) Reconstruction module Analog board

4. Board block diagram

5. Project Goals • Expander, CTF and DSP must communicate using the board resources. • The communication must be efficient and reliable. • The system must have a debug environment for the whole units together and separately. • The debug environment must be easy to use and requires a GUI

6. Concepts • Sub-Nyquist sampling system architecture assembles 3 FPGAs to one electrical circuit composed from few different logical units. • Each FPGA contain 1, or more, of these logical units. • Since each unit needs to communicate with the other units, there is a need to implement special units for communicating between FGPAs. • Large amount of data needs to be transferred between FPGAs using very limited resources.

7. Concepts • The whole communication between the FPGAs and the PCI should work flawless, and so, requires a debug environment for the system, in addition to a debug environment for each FPGA by itself.

8. 1st Part short review • Learning the ProcStar board and Its abilities: • transferring data between FPGAs using Quartos FIFOs and the board’s BUSes.

9. 1st Part short review • Learning the ProcStar board and Its abilities: • transferring data between FPGAs using Quartos FIFOs • and the board’s BUSes. • Transferring DATA between FPGAs on board, using Registers and Mega-FIFOs: DATA transferred through Internal FIFO with different Clock Frequencies on input and output ports. • doing so, we learnt to transfer large amount of data (more than 200 bits) over the Main BUS (40 bits only).

10. 1st Part short review • Learning the ProcStar board and Its abilities: • transferring data between FPGAs using Quartos FIFOs • and the board’s BUSes. • Transferring DATA between FPGAs on board, using Registers and Mega-FIFOs: DATA transferred through Internal FIFO with different Clock Frequencies on input and output ports. • doing so, we learnt to transfer large amount of data (more than 200 bits) over the Main BUS (40 bits only). • Implementing our own transition devices, due to non-standard requirements of the logical units.

11. 2nd part milestones • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware; while keeping the self-debug option infrastructure of each unit (previous architecture group environment).

12. Dataflow with black boxes

13. 2nd part milestones • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware; while keeping the self-debug option infrastructure of each unit (previous architecture group environment). • Adding the Transfer & Receive modules we build in the previous part of the project.

14. Building required environment for each unit on its designated FPGA, with all its inputs and outputs. • The environment enables us to send/receive data, with a large number of bits, over the 40 bit wide main BUS.

15. 2nd part milestones • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware; while keeping the self-debug option infrastructure of each unit (previous architecture group environment). • Adding the Transfer & Receive modules we build in the previous part of the project. • Adjusting the controllers to have various debugging capabilities.

16. 2nd part milestones • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware; while keeping the self-debug option infrastructure of each unit (previous architecture group environment). • Adding the Transfer & Receive modules we build in the previous part of the project. • Adjusting the controllers to have various debugging capabilities. • Adding the CTF-DSP interface.

17. Creating the Controlling GUI Testing method + work environment for the Modules

18. Creating the Controlling GUI Testing method for Communication Modules

19. BERT-GUI Bit error rate test-Graphical user interface • Testing DATA Stream BER (bit error rate)- the number of bit errors of Data stream over a communication channel, meaning the number of bits that had been altered due to noise, interference, distortion or bit synchronization errors during the DATA stream transfer. • Lower & Higher words equal- Check for differences • Higher word incremented, Lower word decremented- • Plain increment – Sequential DATA change, problem can be seen by eye • Toggle 0x00000000, 0xFFFFFFFF- Checks for bits stuck high or low and Checks for ground bounce issues with the input of the driver • Toggle : 0xaaaaaaa, 0x55555555- Checks for bits stuck high or low - cross coupling • Toggle : 0xCCCCCCCC, 0x33333333- • Add 0xaaaaaaaa each iteration- test random jitter and the asymmetry of transition times. • 1-HOT- Pattern contains the longest string of consecutive zeros with the lowest ones density • 0-HOT- Pattern contains the longest string of consecutive zeros with the lowest ones density

20. Previous Test GUI • C Program to compare between • input DATA and output DATA • Patterns used for test: • Lower & Higher words equal • Higher word incremented, • Lower word decremented • Plain increment • Toggle 0x00000000, 0xFFFFFFFF • Toggle : 0xaaaaaaa, 0x55555555 • Toggle : 0xCCCCCCCC, 0x33333333 • Add 0xaaaaaaaa each iteration

21. Creating the Controlling GUI Testing method for Communication Modules Creating Sub-Nyquist Communication Modules test GUI

22. Creating the Controlling GUI Testing method for Communication Modules Creating Sub-Nyquist Communication Modules test GUI Integrating all Debug GUI’s under main Window Creating Complete System GUI 2nd part milestones 5.1 Fixing Mega-FIFO error 5.2 Adding missing Modules to the GUI 5.3 Correct separate Modules Debug GUI’s 5.4 Adding functionality to the – “Entire System” GUI 5.5 Debugging the Entire System (all Modules loaded) using the GUI

23. Creating the Controlling GUI 2nd part Fixing Mega-FIFO error Adding missing Modules to the GUI Correct separate Modules Debug GUI’s Adding functionality to the – “Entire System” GUI Debugging the Entire System (all Modules loaded) using the GUI

24. Integration with the units also requires to add existing unit debug environments for each unit, in addition to the system debug environment. What means that each Module can be watched during the work of the complete system

25. Creating the Controlling GUI 2nd part Fixing Mega-FIFO error Adding missing Modules to the GUI Correct separate Modules Debug GUI’s Adding functionality to the – “Entire System” GUI Debugging the Entire System (all Modules loaded) using the GUI

26. Creating the Controlling GUI 2nd part Integrating all Debug GUI’s under main Window

27. Creating the Controlling GUI 2nd part Fixing Mega-FIFO error Adding missing Modules to the GUI Correct separate Modules Debug GUI’s Adding functionality to the – “Entire System” GUI Debugging the Entire System (all Modules loaded) using the GUI

28. Status Learning the system and the needed tools Design and test communication Blocks Integrate communication blocks with Black Box Design Test the communication between modules using Black Boxes Prepare Debug GUI Prepare complete System GUI Integrate complete system designs Debug complete system

29. Difficulties we encountered CTF didn’t compile after numerous attempts  start over Procwizard had a bug in the card  new installation fixed it

30. Questions?

31. Backup

32. Data Transfer modules • Transit unit: • Placed in Expander’s FPGA • Data_in and Valid bit Received from Expander BB. • Data_out, Valid bit out and Last signals are sent to CTF and DSP over the Main BUS

33. Data Transfer modules • Receiver unit: • Placed in DSP and CTF’s FPGAs • Data_in, Valid bit in and Last signals are received from the Main BUS • Data out is the original data that was sent to CTF and DSP. With its Valid bit, it is ready to enter its required logic

35. 2nd part milstones • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware; while keeping the self-debug option infrastructure of each unit (previous architecture group environment). • Adding the Transfer & Receive modules we build in the previous part of the project. • Adjusting the controllers to have various debugging capabilities. • Adding the CTF-DSP interface.

36. Implementation Stages • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware. • Debug the environment with a temporary GUI.

37. Implementation Stages • Building Debug Environment for communication between FPGAs, using a Black Box approach inside FPGA, instead of real Hardware. • Debug the environment with a temporary GUI. • In the process of implementing the required Debug Environment there was a need to implement our own transition devices, due to non-standard requirements of the logical units.