Download
1 / 23
230 likes | 344 Views
Final Presentation. Infrastructure design & implementation of MIPS processors for students lab based on Bluespec HDL. Students: Danny Hofshi, Shai Shachrur Supervisor: Mony Orbach. Winter 2012. What we did ?. FPGA. C++ Perl. Bluespec Scemi. Bluespec HDL. MIPS. Xilinx FPGA.
E N D
Final Presentation Infrastructure design & implementation of MIPS processors for students lab based on Bluespec HDL Students: Danny Hofshi, Shai Shachrur Supervisor: MonyOrbach Winter 2012
What we did ? FPGA C++ \ Perl BluespecScemi Bluespec HDL MIPS Xilinx FPGA
Project Goals Creating the Laboratory working environment. Creating varied types of MIPS architectures: • Multi-cycle • Pipelined (forwarding, Branch predictor, Cache). • Testing & debugging. Documentation and lab flow walkthrough.
Project tools • Bluespec • SCEMI • C++ • PERL • Plan ahead • XilingVirtix 5 FPGA.
Emulation flow Linux Environment PCIe cable Virtex 5 FPGA
Simulation flow Write Assembler Code & Data memory Type executable command Receive performances and data Communication module C++ MIPS addi $t1 $zero 2 addi $t2 $zero 2 add $t3 $t1 $t2 sw $t3 $zero 0 stop Compiler Data received 604569602 0 0 1 0 604635138 4 4 1 0 1952289 8 8 1 0 2 8 86402048 12 12 1 0 1082130432 16 16 1 0 0 1 1 1 2 2 0 0 1 2 1 0 0 1 2
Test your processor Machine output
Libraries content Project source codes Perl: compiler for Assembly code Sim: Simulation compile environment to test the Mips designs on TCP\IP communication FPGA: Emulation build environment to test the Mips designs on PCIe communication SRC: Bluespec source codes for 9 different architecture combinations TB: C++ Test Bench communication code. F I N A L D I R E C T O R Y LAB 1 PROC#1: Bit file PROC#2: Bit file PROC#3: Bit file Programs Assembly LAB 2 PROC#1: Bit file PROC#2: Bit file PROC#3: Bit file Programs Assembly
Conclusions • Conclusions regarding using Bluespec as preferred language. • Conclusion regarding Scemi • Conclusion regarding the lab.
Bluespec HDL • During code writing of bluespec we encountered with some issue’s in the language , for example:
Bluespec HDL If in some clock cycle, y2=a , x2=b We would expect that in the next cycle: y2 = b+1 x2= a+1 However, bluespec always sequence all the rules which are fired in the same clock cycle. In Bluespec, if a register (x2,y2) appears in more then one rule. The rule which reads the register will always fire before the rule that updates the register.
Bluespec HDL • In our example, • rule r2a must fire before rule r2b because r2a reads y2 • value and r2b updates y2 value. • rule r2b must fire before rule r2a because r2b reads x2 • value and r2a updates x2 value.
Bluespec HDL This scenario is treated as a conflict by the compiler And the scheduler will choose only one of the rules to fire. We encountered this situation in many places in our design and had use various workaround’s .
Bluespec HDL Conclusion: Writing methodology should be developed for writing bluespec HDL which can utilize the advantages of the language.
Bluespec HDL • Debugging : • There are only 2 ways available to debug Bluespec • Waveform of the verilog compilation output • Using $display • Bluespec does not provide proper debug method that works in the same abstraction level as the code development
Scemi Scemi enabled us to create “click of a button” interface between hardware in software. However, Scemi makes it difficult using other periphery devices on the FPGA board. In addition, in most platforms, a reboot is required after a bit-stream is loaded to the FPGA.
Scemi Conclusion: consider developing USB interface with platform coupled with generic software that will replace SCEMI functionality, thus eliminating both problems.
