1. High Speed Digital Systems Lab

2. Agenda  High Level Architecture.  Part A.  DSP Overview. Matrix Inverse. SCD  Verification Methods. Verification Methods on Modelsim. Synthesis Approximations on PlanAhead.

3. Agenda  LabView work methodology. Compatibility check on LabView Full System Integration on LabView. Verification on LabView. Full DSP block data flow.  Utilization.  LabView Bugs.  Problems.  LabView 2010 versus 2011.

4. High Level Architecture Xampling

5. High Level Architecture-Before  Mathscript: CTF Pseudo-Inverse (part of the DSP block) Pseudo-Inverse (part of the DSP block)  Implemented on Hardware: Expand Real Time Multiplier – working only at half rate (part of the DSP block) Real Time Multiplier – working only at half rate (part of the DSP block)

6. High Level Architecture-After  Mathscript: CTF  Implemented on Hardware: Expand Pseudo-Inverse (part of the DSP block) Pseudo-Inverse (part of the DSP block) Real Time Multiplier – working at full rate (part of the DSP block) Real Time Multiplier – working at full rate (part of the DSP block)

7. Part A  Achievements : Learning LabView. Learning the algorithm. Implementing DSP module except Triangle Matrix Inverse block. Verification.

8. DSP  Goal: Reconstructs the signal from the samples.  The unit receives the samples from the memory, matrix As from the memory, and signal support size from the CTF unit.  The support and samples are coordinated  The unit performs pseudo-inverse of matrix As.  Finally the unit multiplies the delayed signal with matrix As_Inv.

9. DSP Pseudo Inverse Multiplication Signal’s sample (from memory) Matrix A (from memory) Signal support (from CTF) Reconstructed signal As+ Reconstructed signal Signal’s sample (from memory) Matrix As (from host) Signal support size

10. Pseudo-Inverse QR Dec Mat Mult Interface Matrix Inverse R matrix Q matrix R_inv As Pinv(As)

11. Matrix Inverse  function[Rinv] =Matrix_Inverse(R)   s=size(R);  Rinv=zeros(24,24);   for(m=1:supportsize) for(n=1:(m-1)) ○ for(k=1:(m-1)) Rinv(n,m)=Rinv(n,m)+Rinv(n,k)*R(k,m); ○ end end for(w=1:(m-1)) ○ Rinv(w,m)=-Rinv(w,m)/R(m,m); end Rinv(m,m)=1/R(m,m);  end

12. Matrix Inverse Fifo Vector Inverse Matrix R (column) R Inversed Matrix R Inversed (row)

13. Verification Methods via Modelsim  We used the old design results and compared it to our results – for every part that we changed from Altera to Xilinx. The comparison was with Matlab.  We added a block to both designs that printed the input and the output matrixes.  We analyzed the results using Matlab, we checked correctness and precision.

14. Synthesis Approximations on PlanAhead  We used PlanAhead to make estimations of the utilization of the Pseudo Inverse block.  We found time constraint violations and used PlanAhead to find the problematic routes.

15. Compatibility Check on LabView  Each new block after the adjustment to Xilinx was compiled on LabView to verify its compatibility.  We also verified time constraint issues inside LabView environment.

16. Work Methodology on LabView Copy original project into 2011 version Change hostChange target Generate BitfileRun full system 2010 2011 copy bitfile Loop {

17. DSP Full Integration on LabView – Initial Plan  Adjustment of the host to send the non- inverted matrix.  Adjustment of the target to invert the matrix.  Adjustment of the target for real time multiplication.

18. DSP Full Integration on LabView – Fixed Plan  Adjustment of the host to send the non- inverted matrix.  Adjustment of the target to invert the matrix.  Cleaning the target to leave only pseudo inverse block and saving the matrixes.  Adjustment of the host to read the matrixes from the target.  Re-adjustment of the target to invert the matrix.  Adjustment of the target for real time multiplication.

19. SCD  The Support Change Detector was not implemented because the available design cannot be used to verify if it works.  The expander unit is not compatible to send a signal more than once.  The CTF unit as well cannot calculate the support more than once because it is not the real CTF unit and it is only a mathscript.

20. Verification on LabView of Pseudo Inverse Block - Target

22. Verification on LabView of Pseudo Inverse Block - Host

23. Verification on LabView of Pseudo Inverse Block  After the input and output matrixes were printed into excel files, we calculated the multiplication using Matlab to confirm that the result fits with the inversion.  We received an identity matrix with MSE ~ 1e-6.

24. LabView target changes  The Pseudo Inverse block was added.  The host to target FIFO was adjusted to Pseudo Inverse block.  It is written to the As_Inv FIFO only after the inversion is finished.  The multiplication time loop was adjusted to work on real time.  The RAM units were extended to fit the real time multiplication.

25. LabView Target Changes

26. Pseudo Inverse Block on LabView Top_LV Pseudo Inverse Matrix A (from memory) Signal support (from CTF) As_Inv (column) Matrix As_Inv (cell) Matrix As (cell) Signal support size As_Inv (cell) Shift Register As (column)

27. LabView target changes

28. LabView host changes  The mathscript was changed, so that the output now is As matrix (24 X 24).  The support size output was added to the mathscript.  Beta_Calc_first outputs were added to the mathscript.  Small changes on the diagrams were made in order to adjust representation to the Pseudo Inverse block inputs’ representation.

29. LabView host changes

30. DSP Data Flow on LabView LVDSHost Samples FIFO As FIFO Pseudo Inverse As_Inv FIFO As_Inv RAM Real Time Multiplier Host

31. Verification on LabView  There are some indicators that notify regarding important parameters of the flow such as: pseudo inverse started/finished, number of transfers from the LVDS, number of multiplication Etc.  We made a comparison between the old design and the new design results.

32. Utilization

33. Time Constraints

34. LabView Bugs  Intermediate files: FIFO size is too small please increase the size or change the implementation.  What should be done? 1. Increase the size by one and then decrease it back to the real size. 2. Close and reopen the project. 3. Close and reopen LabView. 4. Reboot the computer. 5. Repeat 1-4 until it works.

35. LabView Bugs  Generating cores: illegal FIFO size 536870912.  What should be done? 1. Close and reopen the project. 2. Close and reopen LabView. 3. Reboot the computer. 4. Copy VI. 5. Repeat 1-4 until it works. Copy VI: Ctrl + a (select all)  Ctrl + c (copy)  Ctrl + n (new VI)  Ctrl + v (paste)  Ctrl + s (save)

36. LabView Bugs  Synthesis: there is not enough fifo_exp36.  What should be done? 1. Remove the hardware that was added recently. 2. Close and reopen the project. 3. Close and reopen LabView. 4. Reboot the computer. 5. Copy VI. 6. Repeat 1-5 until it works. Copy VI: Ctrl + a (select all)  Ctrl + c (copy)  Ctrl + n (new VI)  Ctrl + v (paste)  Ctrl + s (save)

37. Problems  Every small change takes hours to check.  You can hardly predict which change will cause everything to collapse.  Lack of debug tools.  When it fails due to time constraints, it is impossible to understand what happened.  Two versions can not be compiled simultaneously.

38. Problems  Every small addition to the design can make the compilation fail or even cause error in other time loop.  We had to work on two different version of the program and we were unable to convert from 2011’s version to 2010’s, therefore there is no project that contains both the host and the new target.

39. LabView 2010 versus 2011 2011 80 compilations X 4 hours = 320 hours = 13.3333 days 2010 133.333 days !!! 80 compilations X 40 hours = 3200 hours = 133.333 days !!!