Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

The DEVBOX development education platform : an environment for introducing Verilog to young students Lee, Keith 2016

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2016_may_lee_keith.pdf [ 11.08MB ]
Metadata
JSON: 24-1.0223892.json
JSON-LD: 24-1.0223892-ld.json
RDF/XML (Pretty): 24-1.0223892-rdf.xml
RDF/JSON: 24-1.0223892-rdf.json
Turtle: 24-1.0223892-turtle.txt
N-Triples: 24-1.0223892-rdf-ntriples.txt
Original Record: 24-1.0223892-source.json
Full Text
24-1.0223892-fulltext.txt
Citation
24-1.0223892.ris

Full Text

The DEVBOX Development Education Platform:An Environment for Introducing Verilog to Young StudentsbyKeith LeeB.A.Sc, The University of British Columbia, 2013A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of Applied ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES(Electrical and Computer Engineering)The University of British Columbia(Vancouver)January 2016c© Keith Lee, 2016AbstractHardware description languages are considered to be challenging to learn, as are the logic designconcepts required to effectively use them. University logic design courses are considered by many tobe much more difficult than their software development counterparts and the subject is not generallyaddressed by pre-university curricula. Introducing hardware description earlier in a student’s careerwill improve their chances of success in future logic design courses. The barrier-to-entry faced inintroducing hardware description, caused by complex development environments and the learningof fundamental logic design concepts, must be overcome in order to facilitate a self-directed andinteractive educational environment for young students. DEVBOX, an embedded System-on-Chipprogramming education platform, simplifies the learning process with its bare-bones developmenttools and interactive instructional material. It has been designed to be a self-contained, installation-freeeducational device with a browser-based interface that is self explanatory and easy to use. By includingVerilog, a popular hardware description language, alongside the software programming languages inits repertoire, DEVBOX caters to the needs of introductory and intermediate logic design students ina dynamic self-directed learning environment.iiPrefaceThis dissertation is original, unpublished, independent work by the author, K. LeeiiiTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Programing Education Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Programing Education Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Teaching Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Introductory Logic Design Education . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15iv3 The DEVBOX Platform Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Target Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.1 User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Device Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6 Device Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.7 Third-Party Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 The DEVBOX Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 FPGA Hardware and I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Operating System and Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Web Server and User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.1 The Back-End Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.2 The Front-End Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4.3 TutoriML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.5 Application I/O Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.6 Compilers and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.6.1 C and GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.6.2 Arduino C Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6.3 Verilog Emulation and Verilator . . . . . . . . . . . . . . . . . . . . . . . . 584.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655 Testing Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1 Verilog Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.1 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.1.2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70v5.1.3 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2 Verilog Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.1 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2.2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2.3 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3 Course Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3.2 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.1 Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.1.1 Editor and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.1.2 Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.1.3 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.2 Verilog Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.2.1 ZUMA eFPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.2.2 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.3 Community Websites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.4 Device Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90A Arduino Runtime Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93B Node.js Server Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101C Tutorials.php Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104D Logic Design VHDL Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111D.1 2013 Cohort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111viD.2 2014 Cohort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121viiList of TablesTable 3.1 Initial Discovery Steps for New Software/Hardware Development Students . . . . 18Table 3.1 Tutorial Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Table 3.2 Project Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Table 3.3 Help Resources Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Table 3.2 Requirement-to-Component Mapping . . . . . . . . . . . . . . . . . . . . . . . . 27Table 3.3 Langtable Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Table 4.1 ARM Cortex A9 Technical Specifications . . . . . . . . . . . . . . . . . . . . . . 37Table 4.2 DEVBOX Physical Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . 44Table 4.3 TutoriML Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Table 5.1 Control PC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Table 5.2 Test Verilog Design Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Table 5.3 Lab 1 Assignment Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Table 5.4 Lab 2 (2013) Assignment Results . . . . . . . . . . . . . . . . . . . . . . . . . . 79viiiList of FiguresFigure 1.1 Minecraft’s Redstone Logic Gates . . . . . . . . . . . . . . . . . . . . . . . . . 3Figure 2.1 The SCRATCH Development Environment . . . . . . . . . . . . . . . . . . . . 6Figure 2.2 Alice Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 7Figure 2.3 Codeboard.io Integrated Development Environment (IDE) . . . . . . . . . . . . 8Figure 2.4 One Laptop Per Child (OLPC) XO Laptop (src: wikipedia.org) . . . . . . . . . . 9Figure 2.5 Raspberry Pi Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Figure 2.6 BeagleBone Black . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Figure 2.7 Arduino Uno Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 2.8 Kano Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 2.9 Embedded Software Development Device . . . . . . . . . . . . . . . . . . . . . 13Figure 2.10 AEIOU Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 2.11 1:1 Mapping of Agile Concepts to Teaching Methods . . . . . . . . . . . . . . . 14Figure 3.1 XBOX One: a Modern Gaming Console (src: www.xbox.com) . . . . . . . . . . 19Figure 3.2 DEVBOX Design Concept Overview . . . . . . . . . . . . . . . . . . . . . . . 20Figure 3.3 Form-Factor Analogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figure 3.4 User Interface Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 3.5 DEVBOX Software Component Hierarchy . . . . . . . . . . . . . . . . . . . . 33Figure 3.6 Standardized Tutorial File Structure . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 4.1 The Terasic DE-1 SoC Board (image: www.terasic.com.tw) . . . . . . . . . . . 36ixFigure 4.2 DE-1 SoC Layout (image: www.terasic.com.tw) . . . . . . . . . . . . . . . . . 38Figure 4.3 DEVBOX Prototype Workstation . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 4.4 DEVBOX Prototype FPGA System Diagram . . . . . . . . . . . . . . . . . . . 40Figure 4.5 VGA Controller IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figure 4.6 User Space Versus Kernel Space . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 4.7 Character Device Driver Software Structure . . . . . . . . . . . . . . . . . . . . 44Figure 4.8 The DEVBOX Tutorials Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figure 4.9 DEVBOX Prototype Index Page . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figure 4.10 The Arduino Visualization Screen . . . . . . . . . . . . . . . . . . . . . . . . . 57Figure 4.11 Verilog Port Assignment Web Form . . . . . . . . . . . . . . . . . . . . . . . . 59Figure 4.12 AvalonMM Master Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 62Figure 4.13 Avalon MM Slave Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 62Figure 4.14 Avalon MM read/write Waveform . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 4.15 Emulating Avalon-MM Master . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Figure 5.1 Verilator Build Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Figure 5.2 Verilator Execution Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 5.3 Scalability of Compilation for ARM Verilator . . . . . . . . . . . . . . . . . . . 74Figure 5.4 Scalability of Execution for ARM Verilator . . . . . . . . . . . . . . . . . . . . 75Figure 5.5 Real vs. CPU Execution Times . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Figure 5.6 VGA Adapter Core as a Black Box . . . . . . . . . . . . . . . . . . . . . . . . 80xGlossaryAE-lS Agent-based E-learning SystemAEIOU Ambiente para la Ensenanza Integral deObjetos en UniversidadesAJAX Asynchronous JavaScript and XMLAPI Application Program InterfaceAXI Advanced eXtensible InterfaceCPLD Complex Programmable Logic DeviceCPS Cycles per SecondCPU Central Processing UnitCSS Cascading Style SheetDAC Digital-to-Analog ConverterDDR3 third-generation Double Data RateDE Development and EducationDMA Direct Memory AccessDSP digital signal processorECE Electrical and Computer EngineeringeFPGA embedded FPGAFAQ Frequently Asked QuestionsFF flip-flopFPGA Field Programmable Gate ArrayFSM finite state machineGB GigabyteGCC The GNU C CompilerGPGPU General-Purpose Graphics ProcessingUnitGPIO General Purpose I/OGUI Graphical User InterfaceHAL Hardware Abstraction LayerHD High DefinitionHDL Hardware Description LanguagexiHDMI High-Definition Multimedia InterfaceHPS Hard Processing SystemHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolHz HertzI/O Input/OutputIC integrated circuitIDE Integrated Development EnvironmentIP Intellectual PropertyISA Instruction Set ArchitectureJS JavaScriptKB KilobytekHz kiloHertzLCD Liquid Crystal DisplayLE logic elementLED Light Emitting DiodeLKM Linux Kernel ModuleLUT look-up tableMHz MegahertzMIME Multipurpose Internet Mail ExtensionMM Memory MappedMMU Memory Management UnitOLPC One Laptop Per ChildOOD Object Oriented DesignOOP Object-Oriented ProgrammingOS Operating SystemPC Personal ComputerPHP PHP: Hypertext PreprocessorRAM Random Access MemoryRGB Red-Green-BlueRGBA RGB-AlphaRTE Run-Time EnvironmentRTL Register-Transfer LevelSD Secure DigitalSDRAM Synchronous Dynamic RAMSoC System on Chipsof SRAM Object FileTCP/IP Transmission Control Protocol/InternetProtocolTutoriML Tutorial Markdown LayerUART Universal Asynchronus Reciever/Trans-mitterUSB Universal Serial BusxiiUX User eXperienceVGA Video Graphics AdaptorVPL visual programming languageVTR Verilog to RTLWPS WiFi-Protected SetupxiiiAcknowledgmentsMy gratitude to UBC, the Faculty of Applied Science, and the Electrical and Computer Engineeringdepartment for the opportunity to grow and learn, to Dr. Guy Lemieux for believing in me and for hispatience, and to Dr. Lutz Lampe and the Faculty of Graduate and Postgraduate Studies for openingthe door.To my parents, Derek and Nancy, I thank you for your unwavering support and understanding as Inavigated the most challenging time of my life. I owe you two a great deal.Most importantly, to my wife, Brandi: you have been my guiding light these past six years. Iwould not have made it this far without you.xivDedicated to my children, Payton, Garrett and Isla.May all doors in life be open to you.xvChapter 1IntroductionHardware Description Languages (HDLs) are text-based methods of describing the behavior of digitallogic circuits, much like a software programming language describes the behavior of an application.The internal design of a Central Processing Unit (CPU) or a Liquid Crystal Display (LCD) controllerare two examples of hardware behaviours easily described by HDLs.With the right tools, HDLs can be used to specify a digital implementation for Field ProgrammableGate Arrays (FPGAs), which are integrated circuits (ICs) designed to implement logic circuits. Theycan be programmed and reprogrammed to the user’s specifications. This is accomplished by using alarge array of logic elements (LEs), each containing one or more look-up tables (LUTs) and flip-flops(FFs), math-oriented digital signal processors (DSPs) and memory blocks on-chip. These elementscan be configured to interact, producing a desired logic behaviour. HDLs, as a part of logic design,are required learning in the field of Electrical and Computer Engineering (ECE), and are of increasinginterest in computer science coursework. They are, however, considered to be challenging to learn.1.1 MotivationMany of the challenges faced by introductory logic design students are analogous to those faced bynew computer programmers. They must acquire the necessary software tools to generate compiledoutput and learn to use them. While software programming with Integrated Development Environ-ments (IDEs) can be complex, the development environments for HDLs and the devices they program1are even more so.Once students have acquired the tools and the knowledge to use HDL development tools, theymust find resources to guide them through the learning process. Often, these resources come in theform of text-based or video tutorials. Videos distract from the learning environment and often moveat an accelerated pace, forcing viewers to pause the video frequently and watch important sectionsrepeatedly. Text-based tutorials allow readers to follow at their own pace, but still remove them fromthe tools they are using.Computer programming courses have been offered at some high schools as electives for manyyears, introducing students early on to software development concepts. Languages using simplifiedsyntax and interaction models like SCRATCH [29], a visual programming language (VPL) for chil-dren, have helped introduce computer programming to students as young as age eight. However,HDLs, despite requiring a similar learning process, are considered to be more difficult, and are gen-erally not introduced until advanced university courses. Introducing logic design concepts and HDLsat an earlier age, such as high school, will result in a better understanding of contemporary comput-ing challenges in parallelism and multiprocessing. As industry continues to have difficulty increasingCPU clock frequency above the 4 GHz mark, and hardware accelerators, such as General-PurposeGraphics Processing Units (GPGPUs) and FPGAs, become increasingly important in the foreseeablefuture, logic design skills will become a valuable asset to programmers.Many high school students have been unintentionally teaching themselves the fundamentals ofcombinational logic. Minecraft [9], the popular sandbox-style exploration video game, incorporateselements known as redstone blocks as analogs to logic circuits. Players can build simple logic gatesby connecting various redstone blocks, as seen in Figure 1.1. The creations assembled from thesecircuits can be as simple as a door-opening switch, or as complex as a calculator [2]. Since studentsare already gaining a rudimentary understanding of logic and microcircuitry, introducing HDL is asensible and complimentary next step.Further, in most university-level degree programs for computer science and ECE, developmentusing Verilog and VHDL, two popular HDLs, is under-emphasized in comparison to software de-velopment. It is introduced late in the curriculum or not at all and presents many teaching strategy2Figure 1.1: Minecraft’s Redstone Logic Gateschallenges. Hands-on learning is a valuable tool for both software and hardware design educationand promotes “learning by doing” in group or lab settings as well as independently. The tools andresources for software development are free, numerous, and readily available on the worldwide webto the point of excess. Conversely, the tools necessary for hardware design are sparse, prohibitivelyexpensive, device-specific, and are often produced and distributed by FPGA manufacturers them-selves. For example, Altera and Xilinx, who maintain a combined FPGA market are greater than85%, each have their own commercial products for developing and synthesizing hardware designs.These include custom versions of peripheral applications like Mentor Graphic’s ModelSim simulationsoftware. Some additional simulation and verification tools exist, including Verilator, a free and open-source Verilog-to-C++ compiler and simulator, but neither these nor FPGA developers’ proprietarytools are designed with HDL education in mind; they are large and complex, can impose licensing3constraints and can have challenging configuration problems.1.2 ObjectiveDespite the proven value of hands-on education techniques [17] [23] and the potential benefit of in-troducing Verilog or VHDL early on, very little has been done to facilitate self-directed education andexperimentation for logic design. To this end, this thesis has created a single development and edu-cation environment designed to teach traditional programming languages, such as C/C++, as well ashardware design with Verilog at an introductory to intermediate level. The proposed platform, dubbedDEVBOX, incorporates all of the tools necessary for this broad range of tasks onto an ARM-basedFPGA development board. The preconfigured DEVBOX platform is easy to use and works out of thebox, thus simplifying the setup procedure and allowing prospective students to focus entirely on thelearning process.Specifically, this thesis sets out to:(a) create a portable and easy-to-use development education platform,(b) demonstrate a dynamic IDE and training environment mock-up,(c) implement Verilog emulation functionality, and(d) evaluate the platform’s viability for use as an HDL education tool.1.3 SummaryAlthough the barrier to entry for introductory computer programming is steep, the challenges facedin introducing HDLs are even greater. It is thus desirable to simplify the initial learning stages andtarget pre-university students as well as early-year university students. DEVBOX has been conceivedto serve this purpose. This flexible and portable platform is capable of presenting a library of tutorialsand a development environment for multiple computer languages, including Verilog, with virtuallyno setup time. With DEVBOX, students will be able to teach themselves the fundamentals of logicdesign without dealing with the complexity of current FPGA development platforms.4Chapter 2Related WorkThis chapter provides an overview of work related to computer programming education and logicdesign software, hardware and strategies. A common strategy employed within these works is thatof simplification. The common goals among these resources are either to make the initial learningprocess as simple as possible or to make the acquisition of the necessary tools as easy as possible.Many discussions on the best programming paradigm to which students should first be exposed arealso present, but no common conclusion is prevalent. Some applications employ an imperative-firstapproach while others focus on object-first instruction models.Imperative-first instruction focuses on the syntax, sequence and structure of commands in anaction-driven runtime environment. Its strength lies in a more concrete and immediate feedback loopin a trial-and-error debugging process.Object-first instruction, as the name suggests, focuses on Object-Oriented Programming (OOP)and Object Oriented Design (OOD). Teaching the concept of classes and objects, member functions,inheritance and polymorphism. This paradigm is prevalent in professional programming environ-ments.2.1 Programing Education SoftwareAlice [18] [19] and MIT’s SCRATCH [32] [28] [29] are VPLs designed to instruct young studentsin the fundamentals of software programming. VPLs allow the student to interact with their code5Figure 2.1: The SCRATCH Development Environmentin a more tangible way by observing the interactions of various programming elements visually. Inanother example, Greenfoot [25] is not strictly a VPL, however it does present OOP in a very visualway. Online resources, such as Codeboard.io [6] are also available to connect educators with theirstudents. These applications are described in greater detail below.SCRATCH and its online community have steadily grown in popularity among grade-school in-structors and students since its public release in 2007 and has been included in several programmingstart-up kits. It follows an imperative-first instruction model with a similar code structure to C. Tai-lored to the needs of students aged 8 to 16, its colourful command blocks, single-page interface, livefeedback, tinkerability and lack of error messages make interacting with the development environmentfun. Command blocks fit together like puzzle pieces, as seen in Figure 2.1, eliminating syntactical er-rors by permitting only valid sequences of commands in the script. They control the behaviours of“sprites” on a “stage”. Adjusting variables and parameters is integrated into the visual nature of theVPL, making use of drop-down boxes and text fields within the control modules.Alice is a multi-paradigm visual programming language for 3D software development aimed atnovice programmers. It includes many of the features of SCRATCH, including drag-and-drop com-mand blocks and visual parameter editing, but is targeted to a much older audience. It introducesmore advanced concepts, such as OOP, and strips away the puzzle-piece design that forced syntaxand eliminated error messages in SCRATCH. It follows a UI design similar to SCRATCH providing6Figure 2.2: Alice Development Environmenta single page interface and minimizing the frequency of pop-up windows. Figure 2.2 illustrates theAlice user interface (UI).Greenfoot teaches object oriented design and programming by presenting a visual representationof the students’ classes and their inheritance trees. Similar to SCRATCH, projects are divided intotwo super-classes. The “World” is a parent class for the execution area of a given project, or “sce-nario”. The “Actor” superclass provides the behavioural methods for the instantiation, placement andmovement of actors within the world. An extensive code highlighting scheme helps to emphasize andclarify the structure of a class and its member functions.Codeboard.io [6] is an online IDE that allows educators to share programming exercises withstudents and automate testing and marking in an extensive array of languages. The site uses unittests written by the educator to analyze the validity of a student’s submission and generates a markbased on tests passedtests f ailed . Figure 2.3 presents the primary in-browser development interface, includingproject navigator, console Input/Output (I/O), and a drop-down menu providing a limited selectioneditor options. The IDE design emulates a layout common to many development applications, such as7Eclipse [8] and Code::Blocks [5].Figure 2.3: Codeboard.io IDE2.2 Programing Education HardwareCompanies and organizations are continuously providing new computer hardware platforms for pro-gramming education, many utilizing the software elements described in the previous section. Fromcheap preconfigured laptop computers to microcontroller-based Maker boards, a large number of ed-ucational resources exist for young programming students.Codestarter [31] is a non-profit organization whose primary goal is to provide young and un-derprivileged prospective programmers with the tools required to learn to code. By reconfiguringinexpensive Chromebooks with the required tools by a software developer and delivering them tounder-privileged grade-school students with the help of community donations, the Codestarter teamstrives to “[...] put a developer-friendly laptop into the hands of every kid that wants to learn how tocode”. By making the tools used to convert these Chromebooks open-source and readily available,anyone can easily obtain a programmer-ready PC for under $200.One Laptop Per Child (OLPC) [10] is another non-profit organization that strives to bring laptopsto young students in developing countries. Figure 2.4 presents the XO laptop, a $35 power-efficient,8Figure 2.4: OLPC XO Laptop (src: wikipedia.org)sturdy, and cost-effective computer. This is OLPC’s flagship product, distributed world-wide to helpchildren of impoverished communities learn technical skills. With alternative power sources, such assolar panels and hand cranks, the XO can be used and charged without access to a power grid.The Raspberry Pi [11] was developed by a collection of professors and researchers at the Univer-sity of Cambridge concerned with the decline of CS! (CS!) applicants’ programming experience. Theconcept is to encourage young people to experiment with computers. The Raspberry Pi 2 in Figure2.5a is a recent device from The Raspberry Pi Foundation. It is a full-featured ARM-based computerfor less than $45. The Raspberry Pi Zero, their latest device pictured in Figure 2.5b, is a miniaturizedversion of their original Pi for only $5.Beagleboards [3] are uncannily similar to the Raspberry Pi in design and functionality. The pri-mary differences are their purpose and I/O devices. BeagleBoards are designed for Makers, a classof hobbyists and tinkerers, to control homebrew electronic devices. It therefore has a wider array ofGPIOs with which these devices communicate with hardware and circuitry . This makes the develop-ment of embedded applications more appealing and accessible to the general public. The BeagleBone9Figure 2.5: Raspberry Pi Models(a) Raspbery Pi 2 (b) Raspbery Pi ZeroFigure 2.6: BeagleBone BlackBlack (Figure 2.6), starting at $60, is their small-scale embedded platform.Arduino [1], like the BeagleBone, is designed for Makers and artists to control custom elec-tronic devices. Its simple Application Program Interface (API) and IDE, reduced complexity, andactive development community make it the ideal platform for learning embedded programming. TheUno(Figure 2.7), Arduino’s most successful device, is built around the ATmega328P microcontroller.Kano [24] provides an inexpensive Raspberry Pi-based kit for young computer enthusiasts for10Figure 2.7: Arduino Uno Board$100. It gives them the opportunity to “Build your own computer” and customize it to their liking.Its flash memory comes pre-loaded with Linux and a variety of games, game-making tools (such asSCRATCH), and useful apps like the Geany IDE [33], media editors and a web browser. The goalwith Kano, like Codestarter, is to make acquiring a developer-ready computer easy and inexpensivefor kids. It has the added benefit of being fun to make, which adds to its appeal.The specialization of computer hardware to the task of programming education is relatively un-explored in the academic community and there are not many published papers on the subject. In theEnglish-translated abstract of their 2014 journal article [30], Tachi et al. describe teaching embeddedsoftware development using open source hardware, emphasizing the quick adoption of new technolo-gies in embedded systems. The device, shown in Figure 2.9, appears to be developed specificallyfor the course and challenges students to analyze technical documents in order to develop embeddedapplications.11Figure 2.8: Kano Kit2.3 Teaching StrategiesKoulouri et al. [26] recently performed a study quantifying the effectiveness of various approachesto introductory computer programming by evaluating the importance of language selection, instructorfeedback, and preparatory workshops in decreasing the fail/drop rate among first-year CS! students.The study iteratively modifies an introductory CS! curriculum, replacing Java with Python as theprimary programming language. The work shows that the use of a syntactically simple programminglanguage, such as Python, has a positive impact on the complexity of software created by studentswhile also decreasing the dropout/fail rate within introductory CS! courses. It also motivates theuse of individual formative feedback from instructors and illustrates the importance of preparatoryeducation.Licea et al. [27] have developed and deployed a localized Java education platform, Ambientepara la Ensenanza Integral de Objetos en Universidades (AEIOU), designed to gradually introduceOOP to Mexican engineering students. The AEIOU platform includes three tiers of complexity toaccommodate novice, intermediate and advanced students and presents the interface, help materialand compiler output in Spanish. This offers a much-needed relief of the language barrier that existsbetween non-English speaking students and the development of software. While the concept of a12Figure 2.9: Embedded Software Development Devicethree-tier programming interface allows for users to ease into the task of object oriented programmingand design, its localization limits its relevance to a relatively small population.Bassey Isong [21] discusses the importance of reformulating introductory computer programmingcourses to align the challenges in teaching and learning computer programming to the Agile devel-opment process in a dynamic and lab-oriented curriculum. The paper aligns each of the elements ofthe Agile manifesto to a teaching methodology and combines them to create a more effective courseconfiguration. A combination of pair-programming, lab-focused instruction, active instructor feed-back, and immediate course improvements lends itself to a modern and student-centric introductoryprogramming course.Ljubomir Jerinic [22] suggests that learning from making interesting mistakes could be a power-13Figure 2.10: AEIOU InterfaceFigure 2.11: 1:1 Mapping of Agile Concepts to Teaching Methods14ful teaching tool. He proposes an Agent-based E-learning System (AE-lS) that employs two softwareagents — autonomous computer programs designed to assist users — to guide students through pro-gramming tasks. One agent provides helpful tips and suggestions as the student progresses throughthe assignment. The other is designed to mislead the student into making mistakes. The use of ped-agogical patterns is also considered vital to assignment creation, capturing best practises in the givendomain.2.4 Introductory Logic Design EducationCifredo-Chacn et al. [17] recommend a first-year course curriculum that teaches students computerarchitecture, fundamental VHDL, and FPGA development. By eliminating all device-specific andnon-synthesis VHDL elements, the course material complexity is reduced to accommodate less expe-rienced students.Yen-Chu Hung [20] demonstrated that students given a problem-solving primer before learningVerilog scored better on final course examinations than those who received no additional training. Forthe first three weeks of classes, one test group was taught problem solving by deduction and anothergroup problem solving by analogy. The control group was given lessons in word processing instead.On average the control group scored significantly lower on the experiment’s post-test than the twoexperimental groups.2.5 SummaryThe academic community has invested a notable amount of time to identifying the primary challengesin early computer programming education. The result of these studies has been a variety of languages,such as SCRATCH and Alice, and comprehensive curricular mechanisms, including preparatory sem-inars and the use of syntactically simple programming languages, designed to address these roadblocks.The academic community has largely ignored the implementation of specialized hardware devicesfor programming education, leaving the field open to the tech industry. Organizations such as OLPCand Codestarter strive to supply programming-friendly laptops to students in need. Products like theRaspberry Pi are ideal for young developers and are included in kits designed specifically for this task.15All of these technologies and strategies are directed at introductory software development foryoung students, but do not touch on the subject of logic design, HDLs, or computer architecture.Materials discussing the early education of hardware developers is practically unexplored and limitedto freshman and sophomore university students. Despite evidence that pre-university programmingcourses reduce attrition in university CS! and ECE programs, no effort has been made to test the sameof hardware description.16Chapter 3The DEVBOX Platform Concept3.1 GoalThe primary goal of the DEVBOX platform is to provide a single platform that contains the resourcesnecessary to begin learning a software programming or hardware design language with minimal effortby the student. This is meant to reduce the initial startup time and burden of decision in early stages,thereby reducing the barrier to entry for new developers. In order to present an improved alternativeto the current model, the decision and setup process – from inception to fruition – must be as simpleand quick as possible. Table 3.1 describes the typical setup process for new developers compared tothe simplified procedure proposed by the DEVBOX model. The steps involved in the typical methodare greater in both number and complexity.To my knowledge, this approach to HDL and logic design education is unprecedented, as is thepresentation of Verilog to pre-university students. An early introduction to logic design and HDLwith a low-overhead, self-directed approach will give aspiring ECE and computer science students asolid foundation on which they can build their understanding of computer architecture, Systems onChip (SoCs), and parallel C.The simplicity of a standardized hardware with plug-in software is analogous in many ways tothe model of gaming consoles (Figure 3.1). When an individual purchases a new title for his console,he knows that it will “just work,” as the software is developed to match the exact specifications ofthe console itself. Additionally, little more than inserting a cartridge or disc is required to install17Table 3.1: Initial Discovery Steps for New Software/Hardware Development StudentsTypical DEVBOX• Select programming language • Connect device• Choose, download/install IDE • Select programming language• Install missing tools and libraries and re-solve software conflicts• Select tutorial• Install device drivers and resolve OS con-flicts• Begin reading instructions while testing andmodifying example code in single window• Search for and choose training resource on-line• Select tutorial• Read instructions• Copy example code from browser to IDE• Test and modify code• Install additional libraries as needed by tu-torial content to resolve build errorsthe game and instructions for its use are provided by the device itself. Comparatively, DEVBOXsetup requires the insertion of a micro SDcard, connection to a High-Definition Multimedia Interface(HDMI)-enabled display, and WiFi access.3.2 Target AudienceThe parallels between the DEVBOX model and that of gaming consoles does not end with functionalsimilarities. It also overlaps the target age range for the platform, generally grade school studentsaged 13 to 18. Some students in this demographic have a passing to strong interest in computerprogramming or hardware, or intend to enter the field of computer science or software engineeringafter graduation. Their experience with basic computer skills ranges from novice to intermediate:enough to use a browser, but anything more complicated than Office software is usually foreign.A secondary intended user is the educator. This includes teachers, tutors, and professors. Theeducator may be instructing grade school students in fundamental programming, or providing supple-mentary resources for more advanced students with regards to new programming models. They maywant to add tutorial resources or include new languages to the platform.18Figure 3.1: XBOX One: a Modern Gaming Console (src: www.xbox.com)3.3 ConceptIn order to meet the goal described above, DEVBOX must be portable, inexpensive, easy to use, andself-explanatory. To maximize portability, the DEVBOX device is designed to be a self-containedhost for interaction and execution. It requires no access to the Internet and is agnostic to the user’spersonal computing device. Its only external dependencies are upon a local WiFi network and aHDMI connection to a display device. Running its own web server, its of use comes from an intuitiveweb-based interface, developed to guide users through its pages as well as the development learningprocess. With a price tag below $50, it would be widely accessible. Figure 3.2 provides an outline ofthe overall design concept.3.3.1 User ExperienceIt is important to design DEVBOX user interaction to be as self-explanatory as possible in order to takeinto account the range of skill the target audience will have. A large number of users are likely to have19Figure 3.2: DEVBOX Design Concept Overviewminimal exposure to programming development software and training material and will require visualand textual cues in order to complete desired tasks. Use Cases 3.1 and 3.2 describe the interactionmodel for the two primary tasks to be performed by users. These procedure descriptions help identifyplatform features.Use Case 3.1 assumes that the user is interacting with the device for the purpose of HDL trainingfor the first time. This stems from the assumption that the user’s initial task will be to locate andaccess training materials before developing HDL modules independently. The preconditions for thisprocedure would be described through some aspect of the device’s packaging, such as a temporarydecal, or a box insert. The initial setup procedure will be as follows:1. Insert microSD card into device.2. Connect device to HDMI port of display.(this step may include connecting an external power source.)3. Turn device on and link to WiFi via WiFi-Protected Setup (WPS).It is meant to be no more complicated than setting up a video streaming device such as the Chromecaststick illustrated in Figure 3.3a. WPS is now a common feature among wireless routers that simplifies20the WiFi connection setup process. It allows for one-button passcode-free configuration of a device’sconnection settings.In the process of accessing training materials, the student must interpret connection instructionsdisplayed on the device’s connected display. The described steps must be concise but complete. Visualcues, such as an array of compatible web browsers’ icons and a graphic of a generic URL bar contain-ing the Transmission Control Protocol/Internet Protocol (TCP/IP) address assigned to the device, maybe employed to simplify the language used in the on-screen text.Next, the user must interact with a top-level menu page that will provide access to the variousinterfaces provided by the UI. As this use case is the first task a student is likely to perform with theinterface, a visual cue highlighting the “Tutorials” link and icon will be used when a session is startedin order to guide new users.Descriptive labels for fields in the tutorial page’s forms and a sensible split-screen layout willmesh with existing mental models. Similar document layouts are often used when students writeschool papers, with word processors on one half of the screen and web browsers or document viewerson the other. More icons will also be employed to carry over the embedded editor’s model to the mainIDE page.In Use Case 3.2, an assumption is made that the Tutorial use case has been completed. If thestudent is intending to develop his own Verilog module, he has already accessed the “Tutorials” pageand, consequently, is already connected through his web browser.Link styles will be consistent across the entire menu page. As such, the programming languageselection method must adhere to the page’s style, while still being self-explanatory. Tactics such asintegrating the drop-down menu into the link’s text, or using it to modify the link’s icon, rather thanincluding it as a separate field may be used to accomplish a coherent User eXperience (UX).Carrying over visual elements from the tutorial page’s editor frame will help a student to quicklyidentify the various components required to write, compile, debug, and run his code.The task of retrieving support documentation, as outlined in Use Case 3.3, must attempt to adhereto the mental model developed by the previous use cases. The tutorial and IDE pages employ a single-page design strategy. As such, the “Help” page should likewise follow a single-page strategy. The21initial state of this UI has a search bar above an index of document categories. Once the studentperforms an action, whether it be conducting a search or selecting a section of the index, the resultswill appear below the search bar and the index will move to the upper right-hand corner. Following alink to an internal document will display the contents in the same way, with both the search bar andindex visible at the top of the page.The help page’s visual representation on the main menu should be consistent with those of theother elements but should use a positional or chromatic variation in order to draw the student’s eyeand ensure that its location is well known. This is necessary to ensure that users are confident knowingthat assistance will be provided in the event that the platform fails to perform as expected.In addition to the cues described above, the main menu’s hyperlinks will be enhanced with de-scriptive tags that will pop up when the student’s cursor hovers over them. This active feedback willincrease the likelihood that the correct steps are performed to ensure task success.Use Case 3.1: Tutorial Use CaseUse Case Opening a Verilog TutorialDescription: A student has hooked up DEVBOX and will connect to the device toaccess a Verilog tutorial.Primary Actor: StudentPreconditions: • Device is connected to display and WiFi network• Device power is onPostconditions: Selected tutorial is displayed in browserMain Success Scenario:221. Student turns on display and sets its input to DEVBOX output2. DEVBOX IP address and connection instructions displayed3. Student opens browser on personal computing device (eg laptop, tablet) and enters IP into addressbar4. Browser displays welcome/menu page5. Student clicks on “Tutorials” link6. “Tutorials” page loads7. Student selects Verilog from Programming Languages drop-down box8. Student selects desired tutorial from revealed list and clicks “GO”9. First page of selected tutorial appears in browser.Instructional text in left-hand columnEditor with example code in right-hand column10. Student reads material, modifies code, and clicks Compile & Run11. Device executes code(a) “Messages” textbox below editor displays warnings encountered during compilation(b) “Output” textbox relays runtime messages from program execution(c) Arduino/Verilog I/O visualizer appears on display(d) Device I/O and display elements change to reflect Verilog emulation state transitions12. Student Clicks the Next button13. Next tutorial page is displayed and steps 10 to 13 are repeated until final page is reachedUse Case 3.2: Project Use CaseUse Case Starting a Verilog ProjectDescription A student begins and configures a new Verilog hardware design23Primary Actor: StudentPrecondition: Student is accessing device’s menu pagePostconditions: • HDL code compiles and is executed with Verilator• Port signals connect to hard I/Os and clock behaves correctlyMain Success Secenario:1. Student selects Verilog from drop-down menu next to “Editor” link and clicks on link2. Editor screen is loaded in browser3. Student enters list of port signals in text field next labeled module main4. Using a series of drop down menus on Right-Hand Side (RHS), Student associates signals withhard I/Os and clockClock cycle count configured to be infinite or to terminate emulation after N cycles5. In main text box, student composes HDL6. Student clicks “Compile and Run”7. Device compiles code into executable and emulates design on back-end8. Compilation warnings and errors are displayed in “Compile Messages” text box9. $display messages are printed in “Program Output” text box10. Hard I/Os respond during emulation according to described logicCompile Failure Extension:7-10a.7. Device attempts to compile code8. Detailed error messages are displayed in “Compile Messages” text box9. Student corrects structural and syntactical errors described by error messages10. return to step 624Use Case 3.3: Help Resources Use CaseUse Case Accessing Support DocumentationDescription A student encountering difficulty uses included “Help” documentationto resolve issuePrimary Actor: StudentPrecondition: Student is accessing device’s menu pagePostcondition: Student is provided with sufficient information to continue workMain Success Scenario1. Student clicks on question mark icon on menu webpage2. “Help” page displayed in browserSearch field at top of pageHelp document categories listed below:(a) Frequently Asked Questions (FAQ)(b) Manual(c) Programming language reference material(d) Troubleshooting guide(e) External links(f) “Contact Us”3. Student enters keywords into search field and clicks “Search”4. List of matching document sections displayed with brief excerpts, sorted by relevance, similar informat to Google search results5. Student clicks on link deemed most relevant6. Document is displayed at heading of indicated section25Extensions:1. (a) Access from other pages:1. Student follows “help” link from any other page within interface2. “Help” page is opened in a new tab or window(b) Direct access:1. Student enters URL of “help” directly into browser2. “Help” page is displayed in browser3-6. (a) Accessing local documents:1. Student clicks on category containing local documentsManualProgramming language reference materialTroubleshooting guide2. A list of documents in the given category is displayed with brief descriptions3. User clicks on desired document4. Browser displays contents of selected document(b) Accessing external web content:1. Student clicks on category containing links to external webpagesExternal Links“Contact Us”2. Page is displayed containing:list of hyperlinks accompanied by brief descriptionsrelated or pertinent text, such as mailing address3. Student clicks on desired link4. Browser is redirected to selected page4a. Search returns no results(a) “No results found” displayed in place of document sections263.4 Device HardwareThe proposed device for the DEVBOX platform is a simple television peripheral with a small formfactor and low-profile I/O hardware. Figure 3.3 demonstrates three examples of existing productsto which DEVBOX might bear resemblance. Figure 3.3a, for example, is Google’s Chromecast. Itprovides streaming video to a display device such as a television or computer monitor via HDMI.AppleTV, in Figure 3.3c, is much larger and performs a similar task as Chromecast but includesinternal storage for user state and app functionality. The Compute Stick in Figure 3.3b, on the otherhand, provides a miniature computer in a thumb drive-like device. All three of these devices share thecommon traits of small packaging, HDMI connectivity and minimal exposed I/O.In order for the DEVBOX device to meet all of the platform’s requirements, certain hardwareperipherals are necessary. For instance, without a processor, it would be unable to compile and runuser code, or host the interface. Table 3.2 maps some of the more important requirements to hardwareelements included in the design.Table 3.2: Requirement-to-Component MappingRequirement ComponentRemote user access WiFi adapter with WPSNative compilation and executionARM processorWeb hostingVideo feedback HDMI controllerMultiple HW paradigmsFPGAHDL simulationPlatform flexibilityOngoing developmentEnvironment modularity microSD-based filesystemPeripheral compatibility Arduino shield GPIOOn-board user I/O Switches, buttons and LEDsSerial developer connection MicroUSB slave controller3.5 User InterfaceThe primary UI is delivered by way of an internal web server. Students connect to the device via a webbrowser, and the WiFi-connected DEVBOX presents visual elements through the browser to guideusers through the learning process. This method of delivery was selected to allow for a platform-27agnostic IDE. Students are able to connect to the device with virtually any web browser on anycomputer connected to the local network. This includes, but is not limited to:• Windows PCs• MacOS PCs• Linux PCs• smartphones• tablets• Mozilla Firefox• Google Chrome• Apple Safari• Microsoft EdgeFigure 3.4 is a proposed layout of the various UI elements for DEVBOX. “Tutorials” providesa dynamic interface in which, as the student progresses through tutorial’s pages, an integrated codeeditor modifies the example code to reflect the new page’s subject matter. Users are able to review,modify, compile, and run example code without changing windows, leading to a more fluid learningprocess. “IDE” provides a bare-bones development environment in which users can build their ownprograms or modify project templates and then compile, run, and debug them. Because of majordifferences between Verilog and software languages, there are special I/O-related interface elementsto help configure the code to work with DEVBOX’s hardware. Verilog modules use ports to connectto one another and to I/Os. The ports of the top-most module must be mapped to the hard I/O devicesof the system in order to be observed by students. “Project Templates” provides a library of skeletonand vanilla example programs upon which students can build. “Project Wizard” provides a step-by-step guide to commenting and structuring a new project. “Language Documentation” containsfree-license manuals and textbooks for the various languages provided by DEVBOX. These are storedlocally so Internet access is not a requirement. Finally, “Help Files” provides troubleshooting andFAQ documentation specific to DEVBOX.3.6 Device SoftwareThere are many software elements within the DEVBOX device platform. Each one plays a differentrole in delivering the learning and programming environment to its students. Figure 3.5 shows their28organization. The top element, the Operating System (OS), provides a layer of abstraction and securityas well as vital hardware support to the other applications. Although students never interact with theOS itself, it enables all of the tools that DEVBOX provides.Within the OS are three vital elements. The first is the HyperText Transfer Protocol (HTTP) dae-mon. It delivers the primary user interface in the form of a dynamic web application. The front end ofthis website is primarily written in HyperText Markup Language (HTML) but also relies on CascadingStyle Sheets (CSSes) and JavaScript (JS) for many client-side features and activities, such as interac-tive menu systems, contextual code highlighting, and live program feedback. Back-end elements ofthe web app are provided with PHP: Hypertext Preprocessor (PHP)1 scripts. These scripts modifythe appearance and structure of existing pages based on form input data. They are also involved insome file system operations required for successful complication of users’ code. The final compo-nent of DEVBOX’s HTTP service is the Socket server. This Node.js host application performs thecompilation and execution of students’ programs independent of HTML preprocessing.This software configuration loosely resembles the Asynchronous JavaScript and XML (AJAX)web development platform, wherein client-side elements communicate asynchronously with the server.Next to the HTTP server several user-space applications provide valuable services, foremost ofwhich are the compiler toolchains. The GNU C Compiler (GCC), for example, is a set of tools thattransforms C and C++ code into binary applications. For each language that the platform supports, adifferent compiler may be required. Certain scripting languages, such as JavaScript and Perl, do notrequire compilers. They instead have parsers and interpreters that execute each command at runtime.In the case of Verilog, the code must be synthesized in order to be simulated in an application likeModelSim, or assembled into a bitstream to configure FPGAs. This multi-stage process is complexand lengthy. Synthesis into an FPGA can take from 5 minutes to multiple hours depending on designcomplexity. For the purpose of training, however, most tutorial-based designs are simple enough to bequick to synthesize.Commercial synthesis tools such as Altera’s Quartus II are closed-source and not compatible withARM processors. Instead, open-source HDL emulators, such as Verilator, can be ported and used1PHP is a recursive acronym which means that it contains itself. Another example of this is GNU, which stands for“GNU is Not Unix”.29to parse Verilog and generate equivalent C++ code. This code is then compiled into a stand-alonesoftware application and run.Certain languages require special software in order to be executed, called Run-Time Environments(RTEs). Java is one example of an RTE-dependent language. The benefit of using an RTE for programexecution is relative portability. The compilation process for developer applications can be cross-compatible. A Java application compiled on an x86 Windows PC will also run on ARM Linux,assuming the native RTE has been installed. In the case of Arduino C, program execution is heavilydependent the ATmega microcontroller’s architecture and its connected I/Os. As such, it also requiresan RTE in order for DEVBOX to simulate the behaviour of the Arduino board’s hardware.The HTTP server and user applications are vital, but without access to the device’s hardware andplatform-specific libraries students will not be able to compile their programs. Because DEVBOX usesa custom hardware configuration and architecture, specialized device drivers are required to exposehardware I/Os to the students. Similarly, software libraries with human-readable APIs are necessaryto facilitate usability.3.7 Third-Party DevelopmentSection 3.2 identifies educators as a user group for the DEVBOX platform. In order to facilitate theaddition of programming languages and instructional material into the system, Certain required activ-ities will be standardized or unified. For instance, the use of a centralized Makefile and languagedescription table such as langtable.csv (Table 3.3) drastically reduces the number of documentsthe user must edit in order to add a new programming language and compilation/execution script tothe platform. In this document, developers identify the display name for the language, the script usedby the IDE for contextual highlighting, its Multipurpose Internet Mail Extension (MIME), or Internetmedia, type, and the name of the file to which student code will be written. The web server uses thisinformation to populate drop down menus, configure editor text and correctly compile student code.Adding tutorials is also simplified by dynamically generating the tutorial list within the web inter-face by parsing a standardized directory structure within the device’s file system. As long as develop-ers add their custom tutorials to the disk image following the simple prescribed format, illustrated inFigure 3.6, the interface will present them correctly.30Table 3.3: Langtable ExampleLanguage JS Script MIME type Writeback Filec codemirror-4.2/mode/clike/clike.js text/x-csrc main.carduino codemirror-4.2/mode/clike/clike.js text/x-csrc main.cverilog codemirror-4.2/mode/verilog/verilog.js text/x-verilog main.vvb codemirror-4.2/mode/vb/vb.js text/x-vb main.vbjava codemirror-4.2/mode/clike/clike.js text/x-java main.javaLaTeX codemirror-4.2/mode/stex/stex.js text/x-stex main.texThe most challenging part of contributing a new programming language will be cross-compilingthe compiler tools. In certain cases, as with GCC, configuration scripts and tools are provided in orderto facilitate this cross-cross compilation. The configuration tools for other compilers may not providesettings for ARM-native builds.31Figure 3.3: Form-Factor Analogs(a) Google’s Chromecast (image www.google.com) (b) Intel’s Compute Stick (image www.intel.com)(c) Apple TV (image www.apple.com)32Figure 3.4: User Interface ElementsFigure 3.5: DEVBOX Software Component Hierarchy33Figure 3.6: Standardized Tutorial File Structure34Chapter 4The DEVBOX PrototypeThe DEVBOX prototype was developed to demonstrate the ability to provide the tools and resourcesnecessary for software and hardware programming education in a single embedded device as describedin Chapter 3. In order to accomplish this task an existing, flexible SoC-FPGA hardware platform waschosen. Its software and FPGA configuration was customized to DEVBOX’s specific needs.In this chapter the elements developed or employed to produce the functional prototype are dis-cussed. Section 4.1 describes the device upon which DEVBOX was built. Section 4.2 outlines theFPGA hardware elements used by the prototype and how the device accesses them. In Section 4.3,the OS and the libraries it uses to deliver the prototype’s services are discussed. The deployment ofthe browser-based mock-up UI and the tools that manage it is covered by Section 4.4. Section 4.5provides details concerning the development of custom device drivers required to expose the CycloneV’s FPGA hardware and Section 4.6 describes the required applications and tools for compiling andrunning code with the DEVBOX prototype.4.1 DeviceIn order to implement the DEVBOX prototype, an embedded computer and OS as well as a connectionto a local network and to a video display are considered to be the basic minimum requirements for theprototype device. For this and a great many other reasons, Terasic’s DE-1 SoC FPGA developmentboard, as seen in Figure 4.1, was selected.35Figure 4.1: The Terasic DE-1 SoC Board (image: www.terasic.com.tw)An SoC FPGA includes, alongside the FPGA hardware, a Hard Processing System (HPS). Thisis a physical CPU and its fundamental satellite components, including the Memory Management Unit(MMU) and data bus. The inclusion of a fast on-board processor with support for virtual memoryfacilitates the addition of a fully operational Linux kernel.Terasic Development and Education (DE) boards are often used in ECE programs at many univer-sities, including The University of British Columbia (UBC). The tools provided by Altera for thesedevices are well documented and familiar to many students in ECE programs.The board, shown in Figure 4.1, is built around Altera’s Cyclone V-SoC FPGA chip[14]. Asshown in Table 4.1, The processor is a dual-core Cortex-A9 and is one of the fastest ARM designs to36Table 4.1: ARM Cortex A9 Technical SpecificationsSpec ValueClock Speed 800 MHz# Cores 2Instruction Cache 64 Kilobyte (KB)Data Cache 64 KBL2 Cache 256 KBRAM 1.0 Gigabyte (GB) DDR3Storage Micro SD card socketCommunication Gigabyte EthernetVirutal Memory System ARM MMUdate, running at 800 Megahertz (MHz). The system contains 1GB of third-generation third-generationDouble Data Rate (DDR3) Random Access Memory (RAM), enough to host a full Linux environment.Figure 4.2 shows the layout of the device’s various I/Os with respect to the HPS and FPGA regionsof the chip. Beyond the required Video Graphics Adaptor (VGA) DAC hardware and RJ45 Ethernetcontroller, the DE-1 SoC hosts a wide selection of I/O devicesBy combining this device with a VGA monitor and an Ethernet connection to a WiFi, router theDEVBOX test workstation (Figure 4.3) was set up in a lab environment. Beyond these two externaldevices and a power cord, no other physical connection to the DE-1 was required during normaldevelopment and operation. The one exception to this is that modifying the bootloader’s environmentvariables and execution parameters a requires physical connection to the HPS’s microUSB UniversalAsynchronus Reciever/Transmitter (UART) interface.4.2 FPGA Hardware and I/OMany useful and important hardware devices are connected to the FPGA region of the DE-1 SoC’sCyclone V chip. In order for the HPS to access them, the FPGA must be programmed with hard-ware controllers for every desired I/O. These modules map the pins connected to external elementsto combinational and sequential logic that produce correct device behaviour. They, in turn, connectto internal communication channels to and from the HPS or between hardware controllers. Mod-ern ARM processors use a communication protocol and architecture known as Advanced eXtensibleInterface (AXI) [13]. Each entity on the AXI bus is defined as either a master or a slave, where37Figure 4.2: DE-1 SoC Layout (image: www.terasic.com.tw)masters issue instructions to be carried out by slaves. Figure 4.4 demonstrates how the ARM HPSis connected to the various hardware modules in DEVBOX’s FPGA design. Most of the clock andreset signals are omitted for clarity. AXI and Altera’s Avalon bus interfaces are strikingly similarand completely compatible. The HPS can easily communicate with Altera’s pre-designed hardwareIntellectual Property (IP) cores without intermediary hardware.Each of these modules is assigned a physical address to which the HPS can refer. In the DEV-BOX FPGA design, most modules are either Memory Mapped (MM) master devices initiating read38Figure 4.3: DEVBOX Prototype Workstationand write requests or MM slaves fulfilling these requests. There is also a streaming communicationinterface. Avalon Streaming (Avalon-ST) is often used between components that send or receive largeamounts of data, such as or Ethernet controllers. For MM communication between the ARM proces-sor and the FPGA, a request is sent along the AXI bus from the HPS, including the address of a MMslave. This request is transformed and issued along Altera’s Avalon architecture and received by thetarget module. Some of these devices, such as the VGA controller, are intricate and require multiplehardware components to implement.As is evident from Figure 4.2, the VGA hardware is connected to the FPGA and not to the HPS.39Figure 4.4: DEVBOX Prototype FPGA System Diagram40It is therefore necessary to provide the VGA controller within the FPGA framework. Altera providesmany pre-built and configurable hardware modules, commonly referred to as IP cores, or “soft” de-vices, to emulate common devices including VGA controller hardware. Without this infrastructurein place the DEVBOX prototype is unable to provide visual feedback to its users. The VGA controlpipeline is laid out in Figure 4.5. It is important to have the external visual feedback of a separatedisplay so as not to disrupt or detract from the student’s access to the UI. This allows students tocontinue editing code as they observe program behaviour.First, the ARM HPS is connected to the pixel buffer Direct Memory Access (DMA) controller.This device streams data from the FPGA’s off-chip Synchronous Dynamic RAM (SDRAM) startingat a hard-coded address. This region of memory acts as a framebuffer for the OS. The pixel datafrom RAM is fed into the Red-Green-Blue (RGB) resampler to scale values from 32-bit RGB-Alpha(RGBA) to 30-bit RGB. The result of this pixel scaling is then sent, along with character buffer data,to the alpha blender. This mechanism combines the characters with the pixel data from the resampler,overlaying printed text on top of the framebuffer’s image.At this point the video data must cross clock boundaries in order to be received by the VGAcontroller at a prescribed scan rate. The VGA controller then transmits the pixel data to the VGADigital-to-Analog Converter (DAC) to be transmitted to the monitor.The controllers for the other FPGA I/Os used by the DEVBOX prototype – Light Emitting Diodes(LEDs), switches, pushbuttons, and 7-segment numerical displays – are built using IP blocks in asimilar way to the VGA pipeline, but are much simpler to deploy. With these IP blocks in place, theHPS has direct access to FPGA hardware.4.3 Operating System and DriversThe DEVBOX prototype’s software package is built upon a custom Linux kernel provided by Terasic.Due to the highly varied configurations of embedded systems in which these ARM processors are used,there is no universal Linux distribution available for them. Terasic has gone through the trouble ofbuilding a DE-1-compatible distro with only one important omission – it did not include the necessarylibraries for compiling kernel modules. Linux Kernel Modules (LKMs) are required to provide useraccess to hardware I/Os by bridging the gap between unprotected user space addresses and the kernel’s41Figure 4.5: VGA Controller IPs42Figure 4.6: User Space Versus Kernel Spaceclosely guarded hardware addresses. Figure 4.6 is a generic outline of how user applications accessresources protected by the Linux kernel.User applications make system calls to the kernel, requesting the use of a physical resource ordevice. The resource’s LKM – also known as a device driver – sends the instruction associated withthe request to the physical address of the device. The kernel receives the response data and passes iton to the driver, which then delivers it to the user application, and execution continues in user space.Table 4.2 is a partial listing of the physical addresses for the DEVBOX I/Os.Terasic’s Linux distro includes a device driver for the soft VGA controller described in Figure4.5 to provide an identical framebuffer device similar to those on standard Personal Computers (PCs),but there is no driver for the additional hardware added to the FPGA for the DEVBOX prototype.In order to provide user space access to these devices, a driver – a custom LKM paired with an APIlibrary – was developed. APIs provide software developers with simple, logically named and easy touse functions to perform complex or convoluted tasks such as driver access. The interaction betweenAPI and LKM is illustrated in Figure 4.7. The term “Character Device” refers to the method of43Figure 4.7: Character Device Driver Software StructureTable 4.2: DEVBOX Physical Address MapDevice Description Address(Hex)LEDR Red LEDs 0x00010000KEY Pushbuttons 0x00010010SW Switches 0x00010040SEG7 7-Segment Displays 0x00010060communication the driver is configured to use, accepting plain text as function arguments.Compiling devbox_ioctl, the custom driver described above, required the “modules” librariesfor Terasic’s Linux kernel. In order to supply them, the OS was rebuilt from the Yocto Project [12]repository. Yocto Project is a collaboration between hardware developers whose goal is to providethe tools necessary to build Linux distros for many commercial embedded devices, including AlteraFPGAs. Once these modules are built and included in the devbox_ioctl compilation script, theresulting kernel object and the API library and header file are added to the DEVBOX file structure.The driver can then be registered with the kernel and accessed by user applications.The registration process, involving module installation and node generation, places a user-accessiblecharacter device file in the OS’s /dev directory. A start-up script performs this task as well as config-uring permissions for the devbox_ioctl node and framebuffer to provide read/write access to allusers.444.4 Web Server and User InterfaceThe previous sections of this chapter have described all of the necessary elements that support the pro-totypical DEVBOX platform. At this point, a UI for accessing these resources has not been discussed.The method selected for the DEVBOX prototype to provide the front-end interface was by way of aweb application. These dynamic websites are relatively platform agnostic, as they depend only on thecomputer’s web browser and not on the hardware or OS of the computer accessing them. Studentswill be able to use whichever computer they chose, such as a PC, Macbook, tablet or smartphone.To this end, an HTTP daemon was configured to deliver web content to students across a localnetwork connection. Lighttpd, a small, serviceable HTTP daemon was included with the original im-age and, with minor adjustments to its configuration, it proved capable of delivering the web servicesrequired by the UI.In addition to the visible web content, several background activities must occur asynchronouslyfrom users’ browser actions. Therefore, parallel to the HTTP daemon, a Node.js [15] “socket” serverwas developed to support back-end operations. The Node API enables JS embedded in webpagesto trigger server-side activities through sockets – virtual data channels that connect devices over theInternet.With the infrastructure for dynamic web applications in place, a mock-up UI was developed todemonstrate the DEVBOX concept. This functional prototype, built primarily with PHP, presentsthe interaction model for the major elements of the platform concept, namely tutorials and the IDE.General layout options for the less critical component are also explored, but as they do not pertaindirectly to the self-directed learning elements of the platform, their functionality was not explored.Web applications are divided into two parts – the front-end and back-end. The front-end compo-nent consists of the visual elements displayed in the browser and processing tasks performed locally.The back-end preprocesses HTML content based on submitted form data and client state and performsany server-side computation.454.4.1 The Back-End CodeThe back-end, or server side, components of the prototype’s UI are the PHP preprocessing scriptsand Node.js server. These two processes operate concurrently on very different tasks. Their use andimplementation details are described here.The PHP PreprocessorWeb applications are inherently stateless. Preprocessing allows the HTTP server to manipulate thecontent presented based on the data found in form submissions. These are received in the form ofGET or POST requests transmitted by the web client when the user submits a form. There are often alarge number of form fields, both hidden and visible, used to maintain user state within the DEVBOXinterface; GET values appear in the site’s address bar so in order to minimize student confusion, formdata is transmitted to the server with POST requests.The PHP interpreter then regenerates the site’s HTML based on the new set of POST form vari-ables. Listing 4.1 is an exerpt from the preamble for the “Tutorials” page, seen in Figure 4.8. Ev-ery time the client browser transmits a request to the server, the values of certain elements in the$_POST[] array are analyzed in order to load file contents, hide or expose elements, and populatespecific regions of the HTML code before a response is transmitted to the user.In another portion of tutorials.php the /www/pages/tutorials diectory tree is parsedby the PHP script in order to display the current selection of tutorials on the page. The preprocessoralso accesses langtable.csv, described in Section 3.7, in order to populate the list of availableprogramming languages, save user code, and include the correct contextual highlighting script for theinterface’s editor text box.46Figure 4.8: The DEVBOX Tutorials PageListing 4.1: Code Snippet from tutorials.php1 <!DOCTYPE html>2 <?php3 i n i s e t ( ’ i nc lude pa th ’ , ’ php l i bs / ’ ) ;4 include ” Tutor iML . php ” ;5 include ” portnum . php ” ;6 i f ( isset ($ POST [ ’ lang ’ ] ) )7 {8 $lang=$ POST [ ’ lang ’ ] ;9 $ d i r = ” t u t o r i a l s / ” . $lang ;10 $ f i l e s =ar ray s l ice ( scand i r ( $ d i r ) ,2 ) ;11 }12 $page=$ POST [ ’ page ’ ] ;13 $tml=$ POST [ ’ t u t o r i a l ’ ] ;14 $ f i l e = ’ main . t x t ’ ;15 $log= ’ php log . csv ’ ;16 $date=new DateTime ( ) ;17 i f ( isset ( $tml ) )18 {194720 i f ( isset ($ POST [ ’ code ’ ] ) )21 {22 $base=$ POST [ ’ code ’ ] ;23 f i l e p u t c o n t e n t s ( $ f i l e , $base ) ;24 }25 $ t i t l e = g e t T i t l e ( $d i r , $tml ) ;26 $n pages=getPages ( $d i r , $tml ) ;27 i f ( isset ($ POST [ ’ submit ’ ] ) )28 {29 $code=getCode ( $d i r , $tml , $page ) ;30 $base=htmlspecialchars ( $base ) ;31 fsetCode ( $ f i l e , $code ) ;32 $base= f i l e ge t contents ( $ f i l e ) ;33 f i l e p u t c o n t e n t s ( $log , ’ T u t o r i a l s t a r t , ’ . date t imestamp get ( $date ) . ’ ; ’ .PHP EOL,FILE APPEND) ;34 }The Node.js ServerThe Node.js server’s purpose is to perform server-side tasks asynchronously from HTML preprocess-ing tasks in order to provide live data to the front-end. The primary activities that require this serviceare compilation and execution of the student’s code. Appendix B shows the source code for the Nodeserver.JavaScript run on the client side accesses the server’s listening port, It performs filesystem ac-tivities and executes console commands according to variables provided by the client connection. Inthis snippet, after a connection is open, the Node server sleeps until it receives a “Compile and Run”command from the client. It then saves the received code to a document on the server, executesthe Makefile script for the given language, and compile-time error messages are transmitted to theclient. If compilation is error-free, the resulting binary is run, sending program output to and recievingprogram input from the client application.4.4.2 The Front-End CodeThe front-end, or client side code, like the back-end, is divided into two components. These arethe HTML and JavaScript code. HTML is used to align, typeset and render web content within the48Figure 4.9: DEVBOX Prototype Index Pageclient browser window. HTML is static and immutable once received by the client and its level ofinteractivity is restrictive. As described in the previous subsection, the PHP preprocessor allows forchanges to the code within pages as they are reloaded, but it cannot modify content once the documenthas been transmitted. DEVBOX’s index page, as seen in Figure 4.9, is an example of a static HTMLpage.JavaScriptInline with the HTML transmitted to the client on interactive pages, several JavaScript functions pro-vide additional interactivity and functionality, like the Editor page. The JavaScript in lines 231 to 274of tutorials.pdf, listed in Appendix C, configures the editor box and manages a socket communicationwith the Node server to receive and deliver the dynamic elements of the page.49Table 4.3: TutoriML TagsTag Function‘title Line contains name of current tutorial‘n_pages Total number pages in the document‘start n Begin documentation section for page n‘end n End of page n‘codeset Reset the contents of the editor textbox to code in this section‘codereplace Replace given code with new code provided‘codeappend Add code to the end of the codebase‘codeprepend Add code to beginning of the codebase‘‘ End section4.4.3 TutoriMLProgramming tutorials commonly have two primary components: instructional documentation, andexample code. In order to simplify the process of generating material for DEVBOX’s Tutorials page, acustom file syntax was developed. For most instructional websites, it suffices to simply insert examplecode inline with the instructional material. For the split-screen interactive format used in DEVBOX,however, it becomes necessary to separate the code from the text. To simplify this process, the TutorialMarkdown Layer (TutoriML) file syntax was developed. Text is written in the popular Markdownformat and code is stored verbatim. They are separated by tags that indicate the type and functionof the contained data. A full list of TutoriML tags is found in Table 4.3. The parser is a PHP scriptincluded in the Tutorials page that scans the selected document, and, based on its tagging, inserts theprovided data into the HTML code when a tutorial’s page is accessed.The use of a custom syntax with minimized complexity is meant to allow the author to focus onwriting the material rather than on the tool used.Listing 4.2: TutoriML Syntax Example1 ‘ t i t l e 1 − I n t r o d u c t i o n to C2 ‘ n pages 133 ‘ s t a r t 14 <sub>This t u t o r i a l addapted from ” [ I n t r o d u c t i o n to C ] ( h t t p : / / www. cprogramming . com/ t u t o r i a l / c / lesson1. html ) ” by Alex A l l a i n .</sub>567 ## I n t r o to C508 Every f u l l C program begins i n s i d e a f u n c t i o n c a l l e d ” ‘ main ‘ ” . A f u n c t i o n i s s imply a c o l l e c t i o no f commands t h a t do ” something ” . The main f u n c t i o n i s always c a l l e d when the program f i r s texecutes . From main , we can c a l l o ther func t ions , whether they be w r i t t e n by us or by othersor use b u i l t−i n language fea tu res . To access the standard f u n c t i o n s t h a t comes wi th yourcompi ler ( the program t h a t i n t e r p r e t s the code and tu rns i t i n t o a program ) , you need toinc lude a header w i th the ‘# inc lude ‘ d i r e c t i v e . What t h i s does i s e f f e c t i v e l y takeevery th ing i n the header and paste i t i n t o your program . The code to the r i g h t compiles i n t oa working program .910 Try i t out . Try changing the s t r i n g i n the ‘ p r i n t f ‘ s tatement and see how i t changes the programoutput .1112 ‘ ‘13 ‘ codeset14 # inc lude <s t d i o . h>15 i n t main ( )16 {17 p r i n t f ( ” I am a l i v e ! Beware .\n ” ) ;18 r e t u r n 0 ;19 }20 ‘ ‘21 ‘ end 12223 ‘ s t a r t 224 ##Program Elements25 Let ’ s look a t the elements o f the program . The ‘# inc lude ‘ i s a ” preprocessor ” d i r e c t i v e t h a tt e l l s the compi ler to put code from the header c a l l e d ‘ s t d i o . h ‘ i n t o our program beforea c t u a l l y c rea t i ng the executable . By i n c l u d i n g header f i l e s , you can gain access to manyd i f f e r e n t func t ions−−the ‘ p r i n t f ‘ f unc t i on , f o r example , are inc luded i n ‘ s t d i o . h ‘ .2627 The next impor tan t l i n e i s ‘ i n t main ( ) ‘ . This l i n e t e l l s the compi ler t h a t there i s a f u n c t i o nnamed main , and t h a t the f u n c t i o n re tu rns an in teger , hence ‘ i n t ‘ . The ” c u r l y braces ” ( ‘{ ‘and ‘} ‘ ) s i g n a l the beginning and end of f u n c t i on s and other code blocks . I f you haveprogrammed i n Pascal , you w i l l know them as ‘BEGIN ‘ and ‘END‘ . Even i f you haven ’ tprogrammed i n Pascal , t h i s i s a good way to t h i n k about t h e i r meaning .28 ‘ ‘29 ‘ codeset30 # inc lude <s t d i o . h>31 i n t main ( )32 {5133 }34 ‘ ‘35 ‘ end 24.5 Application I/O InterfaceThe devbox_ioctl LKM and API provide an avenue of communication with the custom FPGAI/O devices for software development purposes. Listing 4.3 provides an example of an application thatmakes use of the interface provided by the driver.This application first attempts to open the character file associated with the devbox_ioctlLKM. This is done in the same way as a regular file is opened, since everything in Linux is representedas a file. Once the test application determines that the module’s character file has been successfulyopened, it queries the state of the DE-1’s switches and sets the LEDs to the same value. It then setseach of the 7-segment displays to an arbitrary sequence of bits and then writes a hexadecimal value tothem and closes the character file.Listing 4.3: FPGA I/O Interface Code Example1 // devbox_ioctl_test.c2 // (c) DEVBOX 20153 #include "devbox_ioctl_driver.h"45 int main()6 {7 // Acquire character device8 int x=open_devbox_io();910 if(x<0)11 printf("FAIL!\n"); // Acquire failed1213 else14 {15 printf("SUCCESS %x\n",x);1617 int q=devbox_get_sw(x); // Get switch state18 printf("Switches= %x\n",q);19 devbox_set_led(x,q); // Light up LEDs2021 // Set 7-seg to a raw value22 devbox_set_7seg(x,0,123);23 devbox_set_7seg(x,1,21);24 devbox_set_7seg(x,2,123);25 devbox_set_7seg(x,3,123);522627 // Write hex value to 7-segs28 devbox_7seg_write(x, 0xaf7701);29 // Release device30 close_devbox_io(x);31 }32 }Although access to the framebuffer is made trivial by its integration into the OS, as describedin Section 4.2, APIs available for drawing to the screen are cumbersome at best. A straightforwardvisual output library, involving direct access to /dev/fb0, the character device driver for the display,was developed for users to use with their programs. In Listing 4.4, the use of this fbDraw library isdemonstrated. The resulting program displays a white splash screen with the DEVBOX logo mock-upand the text from command line arguments on the connected display. The image on the computermonitor in Figure 4.3 was drawn using this program, displaying the device’s IP address and briefaccess instructions when the device has completed its boot sequence.The nomenclature and usage of the functions in the fbDraw library are straightforward andintuitive, making them easier to remember and implement. Functions like fb_fillScr() andfbBmp_draw() are self-explanitory and require a minimal number of arguments.Listing 4.4: Framebuffer Interface Code Example1 // fbPrintArg.c2 // (c) DEVBOX 20153 #include "fbDraw.h"4 #include "fbBmp2fb.h"5 #define MARGIN 567 int main(int argc, char** argv)8 {9 dev_fb fb;10 bmp bm;11 int i;12 //load bitmap13 if(fbBmp_openBmp("/usr/splash_logo.bmp", &bm))14 printf("failed to open /usr/splash_logo.bmp\n");1516 pixel cursor;17 cursor.x=10;18 cursor.y=10;19 //debug: Print fb status to console20 printf("FB status: %d\n",fb_init(&fb));21 //White background5322 fb_fillScr(&fb,255,255,255);23 //draw logo24 fbBmp_draw(&fb, &bm, 1, cursor.x, cursor.y);2526 cursor.x=10;27 cursor.y+=bm.info.height+MARGIN;28 if(argc>=2)29 {30 for(i=1;i<argc;i++)31 {32 //Print argument text33 fb_printStr(&fb,argv[i],&cursor,12,0,0,0);34 //print arg text to console35 printf("%s\n", argv[i]);36 fb_printStr(&fb," ",&cursor,12,0,0,0);37 }38 }39 else40 return -1;41 return 0;42 }4.6 Compilers and ToolsThe utility of DEVBOX hinges on the platform’s ability to compile and execute users’ code natively.This requires the build and runtime tools for each included language to be compiled for ARM proces-sors, thereby necessitating the use of open-source products. The language list for the current prototypeis very short: C, Arduino C, and Verilog. The deployment of each tool set is described below.4.6.1 C and GCCThe most common open-source compiler for C and C++ is GCC. Others, such as Clang for LLVM [4],though not as common, are equally viable candidates for the DEVBOX project. GCC was selected inpart for its build configuration flexibility.Multiple variations of ARM processors exist and may use slightly different instruction sets or haveaccess to different on-chip hardware, such as MMUs. ARM-native GCC compilers are not suppliedin a precompiled binary, but can be generated using a build tool called crosstool-NG and, in mostcases, a platform-specific configuration file can simplify the task. If no such file exists for the targetarchitecture, there is a Graphical User Interface (GUI) included for manually configuring the build.The tool is then built in such a way that ARM-compatible binaries and libraries that compile software54for ARM are generated. The full suite of build tools includes:• the C and C++ compilers,• the object linker,• the back-end assembler,• the library archiver, and• important library-building tools.Only the first three are necessary for building executable applications, but the inclusion of the otherssimplifies the prototyping process during the prototype’s development. These native library buildingtools allow for quick iteration on the prototype’s various projects by minimizing the number of filetransfers from the development machine to the DEVBOX device. Libraries can be compiled, archivedand deployed natively as they are debugged.The output of GCC’s cross-cross compilation is added to the file system on the DEVBOX proto-type and the location of the compiler’s executable binaries is appended to the OS’s PATH environmentvariable.4.6.2 Arduino C RuntimeArudino is a family of microcontroller-based devices for developing interactive and programmable“objects”. They have a common C-based programming language focused on simplifying the controlof the boards’ I/Os. Arduino C is ideal for new developers with an interest in robotics, interactivedevices and technological art forms due to its simple syntax and structure. The programming modelfor Arduino has been included in the DEVBOX prototype because it demonstrates the versatility ofthe platform, pursuant of its goal of delivering a wide variety of development learning tools spanningan extensive range of students’ interests.The structure of an Arduino program contains two primary functions:• setup()• loop()55setup() is used to initialize the I/O pins on the Arduino board as either digital input or output.Any other activities that are only performed once, such as initializing variables, are also placed in thesetup() function.The loop() function is repeated continuously while the device is on. This is the meat of anArduino application. It is where the program responds to stimulus, driving I/O pins.Listing 4.5 is a simple Arduino program that activates one of four LEDs dependent on the state ofthree input pins.Listing 4.5: Arduino C Code Example1 #include"arduinoRuntime.h"2 void setup(void)3 {4 int i;5 for(i=0;i<10;i++)6 pinMode(i, INPUT);7 for(i=10;i<14;i++)8 pinMode(i, OUTPUT);9 }1011 void loop(void)12 {13 int x=digitalRead(0);14 x|=digitalRead(1);15 x|=digitalRead(2);16 printf("%d\n",x);17 digitalWrite(10, x);1819 x=digitalRead(3);20 x|=digitalRead(4);21 x|=digitalRead(5);2223 digitalWrite(11, x);2425 x=digitalRead(6);26 x|=digitalRead(7);27 x|=digitalRead(8);2829 digitalWrite(12, x);3031 digitalWrite(13, digitalRead(9));32 }The major challenge behind integrating Arduino C into the DEVBOX platform stems from thesimple fact that most Arduino boards are built around an ATmega microcontroller and are bare-wire56programmed. This means that there is no operating system between the code and the microcon-troller. In order to emulate Arduino’s behaviour on an ARM processor running Linux, a custom RTE,ArduinoRuntime was developed into which Arduino code could be compiled and run.ArduinoRuntime consists of a porting library and an application into which the setup()and loop() functions are compiled. The porting library converts a large number of Arduino-specificfunctions to standard C and to the DEVBOX I/O interface. For instance, when pinMode(i, INPUT)is called, the function in the Arduino RTE associates the pin number i to the first available input de-vice, KEY[0], for instance. During loop(), if the state of that input is altered, the state of theemulated pin is changed accordingly by the RTE. A series of data arrays define the mode of each pinand associate the pin number with the board’s I/O. The full Arduino RTE can be found in AppendixA.The runtime application displays a graphical visualization of the Arduino Uno, one of the mostcommon of the Arduinos, and the DE-1’s pushbuttons, switches and LEDs on the connected videomonitor. As the virtual I/O pins are read and modified, the graphical output highlights the activeshield pins on image of the Uno and also reflects the state of the DE-1’s hard I/Os, as seen in Figure4.10. In this way, students are able to monitor the behaviour of an Arduino program in real time.Figure 4.10: The Arduino Visualization Screen574.6.3 Verilog Emulation and VerilatorBare-Wire VerilogA unique feature of the DEVBOX platform is the inclusion of educational materials for logic designand HDL education. Ideally, students’ HDL would be fully synthesized into an FPGA bitstream andused to program the device’s embedded FPGA. However, the tools required to do so are usually pro-prietary to the chip developer and not portable to ARM architectures. One alternative to this approachis to emulate the hardware model in software. Verilator [34] is an open-source development tool thatparses Verilog code and generates equivalent C++ classes and functions. This software representa-tion can then be compiled, along with a “harness” main() function. The harness is used to providestdin and stdout communication and scripted I/O to manipulate the hardware emulation.For the DEVBOX prototype, the harness application was designed to use the same I/O visualiza-tion used for ArduinoRuntime. Input and output wires defined in the Verilog modules are tied toDEVBOX I/Os and, as with Arduino, both the monitor and hard I/Os are manipulated to reflect thestate of the emulation. In order to do this, a PHP script creates a custom Verilog file that instantiatesthe user-developed module and ties it to the port list that the Verilator harness expects. The modulesare then converted into a C++ application and compiled into an executable binary.The script for generating the harness module was written in PHP to facilitate its inclusion inDEVBOX’s web based interface. The user defines their module’s ports and manually ties them to I/Odevices on the development board using the form in Figure 4.11 and when the user clicks the compilebutton the data from this form is handed off to the Verilog harness generation script. Listing 4.6 showsthat the script builds Verilog code from scratch based on the signal list provided to the function byPOST data from the web application. This standardizes the modules’ external signal interface andsimplifies the compilation process. The resulting Verilog code, shown in Listing 4.7, interacts withthe main C++ function, which in turn interprets the output signals from the harness module andprovides appropriate feedback from the host to the input ports.The above emulator construction method is currently limited to simple designs involving only theswitches, pushbuttons and red LEDs, but is fully integrated into the current UI mock-up. However,tools and methods are already in place for open-ended HDL development, such as a more generalized58Figure 4.11: Verilog Port Assignment Web FormLKM, whose API is designed to mimic the core functions of Altera’s Avalon Hardware AbstractionLayer (HAL).Listing 4.6: The create v harness.php script1 <?php2 function create_v_harness($sig_array)3 {4 \\ initialize variables5 $assigned[’SW’]=0;6 $assigned[’KEY’]=0;7 $assigned[’LEDR’]=0;8 $clock[’set’]=0;910 \\ get signals from input array11 foreach ($sig_array as $elem)12 {13 $elem=preg_split(’/\s+/’, $elem);14 if($elem[0]==’attach’)15 {16 $attach[]=array($elem[1], $elem[2]);17 $assigned[$elem[1]]=1;18 }19 elseif($elem[0]==’clock’)20 {21 $clock[’set’]=1;22 if($elem[3]==’count’)23 $clock[’count’]=$elem[5];24 else25 $clock[’count’]=0;26 }27 }2829 \\ Verilator preamble to deactivate fatal errors for unused signals30 $harness=’//verilator lint_off UNUSED’.PHP_EOL;3132 \\ Default top-level I/O signals33 $harness.=’module harness(CLK, CLK_EN, SW, KEY, LEDR, CLK_COUNT);’.59↪→ PHP_EOL;34 $harness.=’ input wire CLK;’.PHP_EOL.’ input wire[9:0] SW;’.PHP_EOL.’↪→ input wire[3:0] KEY;’.PHP_EOL;35 $harness.=’ output wire CLK_EN;’.PHP_EOL.’ output wire[9:0] LEDR;’.↪→ PHP_EOL;36 $harness.=’ assign CLK_EN=’.$clock[’set’].’;’.PHP_EOL;3738 \\ Begin module-specific code39 if($clock[’set’]==0)40 {41 $harness.=’ wire CLK_SINK;’.PHP_EOL.’ assign CLK_SINK=CLK;’.↪→ PHP_EOL;42 $harness.=" output wire[31:0] CLK_COUNT=32’d0;".PHP_EOL;43 }44 else45 $harness.=" output wire[31:0] CLK_COUNT=32’d".$clock[’count’].’;’.↪→ PHP_EOL;46 if($assigned[’SW’]==0)47 $harness.=’ wire[9:0]SW_SINK;’.PHP_EOL.’ assign SW_SINK=SW;’.↪→ PHP_EOL;48 if($assigned[’KEY’]==0)49 $harness.=’ wire[3:0]KEY_SINK;’.PHP_EOL.’ assign KEY_SINK=KEY;’.↪→ PHP_EOL;50 if($assigned[’LEDR’]==0)51 $harness.=" assign LEDR=10’b0;".PHP_EOL;52 $harness.=’ main u0(’.PHP_EOL;53 $i=0;54 $len=count($attach);55 foreach ($attach as $sig)56 {57 $harness.=’ .’.$sig[1].’(’.$sig[0].’)’;58 if($i!=$len-1)59 $harness.=’,’.PHP_EOL;60 else $harness.=’);’.PHP_EOL;61 $i++;62 }63 $harness.=’endmodule’.PHP_EOL;64 $harness.=’// verilator lint_on UNUSED’.PHP_EOL;65 $vf=fopen(’harness.v’,’w’);66 fwrite($vf,$harness);67 fclose($vf);68 }69 ?>Listing 4.7: The Generated Verilog Harness1 //verilator lint_off UNUSED2 module harness(CLK, CLK_EN, SW, KEY, LEDR, CLK_COUNT);3 input wire CLK;4 input wire[9:0] SW;5 input wire[3:0] KEY;606 output wire CLK_EN;7 output wire[9:0] LEDR;8 assign CLK_EN=1;9 output wire[31:0] CLK_COUNT=32’d0;10 main u0(11 .SW(SW),12 .LEDR(LEDR),13 .KEY(KEY),14 .CLK(CLK));15 endmodule16 // verilator lint_on UNUSEDAvalon InterfaceAltera’s IP modules interact using a common bus dubbed Avalon. This embedded hardware intercon-nect includes multiple interface protocols, including MM, streaming, and interrupt-based, MM beingthe most prevalent in HDL courses. Ground-level knowledge of this protocol is valuable to any studentinterested in architecting SoCs. The means to emulate the Avalon MM interface has therefore beenincluded in the DEVBOX prototype.In order to emulate Avalon’s MM interface, two components are necessary. The first component isthe MM Master port (Figure 4.12). This is the hardware that issues read and write instructions toattached devices. These peripherals, in turn, have an MM Slave port. Figure 4.13 is the block diagramfor a simple MM slave. In order for these two ports to communicate, they must adhere to a commonprotocol. Various signals must be toggled in a pre-determined pattern in order to achieve a successfuldata transfer. This handshaking process can be represented by the waveform diagram in Figure 4.14.An exerpt from Altera’s documentation [16] outlines the details of this waveform as follows:1. address, byteenable, and read are asserted after the rising edge of clk. Theslave asserts waitrequest, stalling the transfer.2. waitrequest is sampled. Because waitrequest is asserted, the cycle becomes await-state. address, read, write, and byteenable remain constant.3. The slave deasserts waitrequest after the rising edge of clk.4. readdata, response and deasserted waitrequest are sampled, completingthe transfer.61Figure 4.12: AvalonMM Master Block DiagramFigure 4.13: Avalon MM Slave Block Diagram5. address, writedata, byteenable, and write signals are asserted after therising edge of clk. The slave asserts waitrequest stalling the transfer.6. The slave deasserts waitrequest after the rising edge of clk.7. The slave captures write data ending the transfer.The DEVBOX prototype replicates this behaviour using Verilator. The MM Master is approxi-mated in Verilog, providing a module stub, much like the harness module in Figure 4.7, but containing62Figure 4.14: Avalon MM read/write Waveformsome finite state machines (FSMs) that manage the signal sequencing for read/write operations.Listings 4.8 and 4.9 are snippets from the Avalon MM Master interface used by the platform toexecute the correct read and write sequences, as visualized in Figure 4.14. Internal registers,such as cont_write and start_read are used to monitor and control the transition sequence ofthe FSM. The user’s module provides address, byteenable, and writedata asynchronouslyto the MM Master stub and asserts the start_read or start_write signals to initiate thesesequences. The harness application then emulates the behaviour of the Avalon bus, manipulatingthe slave-driven signals in Figure 4.14 while transmitting data to and from the addressed MM slavethrough the LKM. Figure 4.15 shows how the different elements in the DEVBOX Verilog emulationsuite interact to simulate an Avalon-MM Master.63Figure 4.15: Emulating Avalon-MM MasterListing 4.8: The Avalon Write FSM1 // Write Sequence2 always @ (posedge clk)3 begin4 if(!r_read && start_write)5 begin6 write<=1;7 rw_state<=2’b01;8 end9 else if(write_state==2’b01)10 begin11 write<=1;12 if(!waitrequest)13 rw_state<=2’b10;14 end15 else if(write_state==2’b10)16 begin6417 write<=1;18 rw_state<=2’b00;19 end20 else21 begin22 write<=0;23 end24 endListing 4.9: The Avalon Read FSM1 // Read Sequence2 always @ (posedge clk)3 begin4 if(!write && start_read && !readdatavalid)begin5 r_read<=1;6 rw_state<=2’b01;7 end8 else if(r_read && readdatavalid)9 begin10 r_readdata<=readdata;11 rw_state<=2’b1012 end13 else if(rw_state==2’b10)begin14 r_read<=0;15 rw_state<=2’b00;16 end17 endLikewise, a skeleton project for developing MM slave modules is in place. These stubs allow usersto explore the more intricate shared communication channels computer systems use to manage a largenumber of peripheral devices.4.7 SummaryThe many components described herein have been developed and/or deployed in order to demonstratethe ability of an embedded platform, such as DEVBOX, in delivering a Verilog development educa-tion tool. The specifications of the DE-1 SoC board align well with the envisioned hardware whilethe ARM Linux OS hosts the necessary tools, such as the HTTP daemon and compilation tools. Themock-up web interface successfully demonstrates the ability to develop and test Verilog HDL, as wellas C and Arduino, remotely and observe the results on the board’s I/O and on a video display. Thedevice drivers that have been developed for the DEVBOX prototype safely expose FPGA hardware65to the web application’s back-end software, allowing for more interactive student-developed applica-tions. The inclusion of Avalon stubs and software allow for progression into the more complex aspectsof hardware development.66Chapter 5Testing ProceduresThe viability of the DEVBOX platform for instructing pre-university logic design students hinges notonly on its ability to present tutorial material in an interactive and intuitive manner, but also on itsHDL emulation capabilities. In this chapter, various tests are described that will highlight the currentprototype’s strengths and limitations in performance, scalability, and ability to emulate university labassignments in Verilog.5.1 Verilog EmulationIn order to quantify DEVBOX’s viability as a Verilog education platform, it is necessary to identify apoint of comparison and unit of measure. The following tests compare DEVBOX’s compilation andemulation capabilities to those of a conventional desktop PC.In section 4.6.3, the use of Verilator as a Verilog emulator is described. It was selected in partbecause it proclaims itself the fastest free HDL emulator. This is important as it will be operating on asmall ARM processor with lower performance than contemporary desktop-grade processors. In orderfor DEVBOX to operate as a Verilog development tool, it must be capable of parsing, compiling,and running the HDL within an acceptable time frame. It is assumed, when measuring Verilator’sperformance on DEVBOX’s ARM Cortex-A9 dual-core processor that its lower clock frequency willhave a considerable impact. ARM’s Cortex-A9 architecture allows for variable clock speeds, reducingpower consumption during periods of minimal workload. A stress test determined that, during periods67Component ValueMake & Model Lenovo ThinkServerProcessor Intel Xeon E3-1225 V2Clock Speed 3200 MHz# Cores 4Cache Size 8.0 MBRAM 4.0 GB DDR3-1333OS Ubuntu 12.04.5 LTSKernel Version 3.2.0-76Table 5.1: Control PC Specificationsof heavy workload, the Cyclone-V SoC’s Cortex-A9 processor’s maximum clock speed is 800 MHz.The Xeon’s clock speed is 3.20 GHz, 4× faster than ARM’s.When the operating system reports the execution time of an application, it returns three values:Real: Start-to-finish clock timeUser: CPU time spent in user spaceSys: CPU time spent in kernel spaceAlthough CPU time gives a good indication of processing efficiency, the measure of real elapsedtime is the variable that most affects the user.A baseline for Verilog emulation tasks is acquired by executing them on an x86/64 desktop systemwith specifications described in Table 5.1.5.1.1 CompilationVerilog must be parsed and converted into a C++ class using Verilator’s parser and compiled in con-junction with a top-level harness function into a “Verilated” binary. Depending on the complexity ofthe design, this can be the most time-consuming step in the emulation process. Benchmarking thisprocess involves comparing the compile time for both simple and complex projects, using Verilator,on both the DE-1 SoC and the PC described above. These results are also compared against QuartusII’s single-threaded compile time for the same project on the same PC.The reference designs used to compare Verilator’s performance between processors are an open-source Motorola M68K processor, a simple counter and ten copies of the original counter combined68Verilog Project Lines of HDLM68K 6709counter 2510 counters 438Table 5.2: Test Verilog Design Complexitywithin a top-level module controlling the counters’ behaviour. As a measure of complexity, the linesof Verilog code within each design are listed in Table 5.2.Verilator makes use of thread-level parallelism in its build process by taking advantage of GNUMake’s -jobs parameter. This feature concurrently executes a specified number of independent jobsin a Makefile whose prerequisites have been met. In the case of Verilator, at least six differentsource files are generated, compiled into objects, and then linked into an executable binary. Muchof this work can be completed concurrently. In this way Verilator’s compilation stage frequentlyconsumes considerably more CPU time than real time. Ideally, acceleration will scale with the numberof cores available.For this experiment, the designs are compiled multiple times on the ARM and x86/64 cores andthen synthesized in Quartus II and real execution time is then recorded. The geometric mean of theseresults is then reported. The goal is to determine if the time elapsed in compiling with Verilator on theARM processor is tolerable in comparison.ResultsThe process of producing SRAM Object Files (sofs), bitstream files used to encode hardware de-scriptions on FPGAs, in Quartus II, Altera’s IDE, is lengthy. It consists of multiple complex stagesdesigned to optimize the performance, timing, and placement of the hardware on FPGAs and Com-plex Programmable Logic Devices (CPLDs). When emulating hardware using an application such asVerilator, the necessity for such in-depth analysis is eliminated. It suffices to approximate the Register-Transfer Level (RTL) behaviour of the HDL code. Figure 5.1 shows that, for the reference designsused for these tests, Quartus II’s processing time is considerably greater than Verilator’s on the ref-erence PC and on DEVBOX itself. In order to get a better idea of how DEVBOX’s ARM processorcompares to conventional x86/64 processors found in modern PC and server computers, the Quartus69Figure 5.1: Verilator Build Timesresults should be disregarded in further studies.The desktop processor is able to compile Verilog 20 times faster with Verilator than the 2-coreARM processor. However, it is important to note that the ARM processor under test contains only twocores, compared to the 4-core Xeon processor in the control system. Therefore, the mean per-corespeedup is only 10×.5.1.2 ExecutionOnce the Verilog is compiled into an executable binary, it is run on the host system and executiontime is measured. The harness application runs the design for a fixed number of emulated clock cy-cles. Then, using the execution time, the emulation’s Cycles per Second (CPS), or effective clockfrequency, is calculated. Comparing this metric for both the ARM and x86/64 processors provides agood representation of the Cortex A9’s effectiveness at emulating Verilator-compiled hardware mod-ules.The M68K project contains an application written in assembly and a data file as an input vectorfor its simulation. The counter modules are also provided with input to ensure that they are active70Figure 5.2: Verilator Execution Timesthroughout the simulation.The executable emulation applications compiled in the previous experiment are run multiple timesas in the compilation test. As before, the geometric mean of the resultant CPS are used to comparesystems.ResultsWhen comparing the execution speeds of Verilator-generated, or “Verilated”, emulations betweenprocessor architectures, it is important to note that the resulting applications are not multi-threaded.This means that the entire emulation is processed on a single core. Therefore, any disparity betweenthe results will be due to the difference in clock speeds and processing efficiency.The results show that the reference PC was almost 10× as effective as the ARM system at emu-lating Verilated hardware. This correlates well with the compilation findings in Figure 5.1. Despitethe slowdown in simulation speed, the ARM Cortex-A9 is still capable of delivering roughly 240kiloHertz (kHz) to the complex Motorola M68K design.715.1.3 InterpretationThe results of the tests described above are an indication of Verilator’s capabilities as a Verilog em-ulator on DEVBOX’s ARM Cortex-A9. ARM’s architecture is focused on minimizing power con-sumption. With a lower clock speed, power-optimized caches, and a variety of other optimizations, itsacrifices raw compute power for energy savings, making it ideal for portable embedded systems andapplication-specific devices. As such, it is no surprise that powerhouse processors, such as the IntelXeon processor in the control PC used in the benchmarks above, would be notably faster at executingthe necessary tasks for Verilog emulation with Verilator.The inclusion of a four-core Cortex-A9 to the system’s architecture would likely reduce Verilator’scompilation time by up to 50%, performing more “jobs” concurrently but would have no impact onemulation.Emulation at 240 kHz is respectable for the purpose of debugging and learning to code and stu-dents will not notice much lag between input and output as their code is executed.That said, more effective emulation models, such as the ZUMA embedded FPGA (eFPGA), maysoon be available for ARM processors. This will potentially improve both the speed of compilationand emulation, thus removing the discontinuity observed in these test results and taking advantageof the reconfigurable hardware. Such a tool will be a valuable addition to future iterations of theDEVBOX toolset.5.2 Verilog ScalabilityAnother indication of DEVBOX’s effectiveness at compiling and emulating Verilog natively is its ef-ficiency as designs grow in complexity or size. Using the “10 Counters” module from the previoustests, an experiment was developed to measure the processing time for both compilation and emula-tion as the number of counters increases. The test is run on the DEVBOX prototype’s ARM processor,sequentially building and executing counter designs with an increasing number of counter instantia-tions. The emulation is again run for a fixed number of clock cycles and the real and execution timesare recorded and compared.725.2.1 CompilationAs described in Section 5.1.1, Verilator parses Verilog and converts it into C++, and uses GCC to buildan executable binary. In order to dynamically modify the size of the “Counters” design, changes weremade to the Verilog module to allow for size to be defined by a precompile directive. By definingCOUNT=$COUNT at the command line, the top-level Verilog module uses the given value as a param-eter in a generate loop to instantiate $COUNT copies of the counter module. With this change inplace, a command line script easily iterates over increasingly large designs and records compilationtime.Verilator makes use of thread-level parallelism in its build process by taking advantage of GNUMake’s -jobs parameter by default. In this execution mode, all build stages, whose prerequisiteobjects are ready, are launched simultaneously. It is therefore expected that real execution timesshould be notably shorter than the CPU times.ResultsThe amount of time elapsed during Verilator compilation on an ARM core is not trivial, on the scale ofminutes. Compiling a single counter module takes only a few seconds, but when the size of the modelis increased, the compilation runtime grows. As seen in Figure 5.3, CPU time exceeds real processingtime, suggesting execution of this phase appears to be computation-bound and parallelized. Morecores on the processor will potentially have a positive effect on compile times. More advanced ARMprocessors, such as the quad-core Cortex-A15 [7], have increased multiprocessing functionality overthe Cortex-A9 and may prove more efficient at compiling larger models.The results of the compilation scalability benchmark exposes an anomaly in processing time asthe number of counter modules exceeds 500. After this point, compilation time drops significantlyand the slope of the curve is much shallower than for smaller models. We are unable to explain thisbehaviour.5.2.2 ExecutionThe DEVBOX prototype’s scalability with respect to project size is also important. Verilog emulationon the DEVBOX platform is meant, in general, for experimentation and debugging purposes, provid-73Figure 5.3: Scalability of Compilation for ARM Verilatoring a testbed for new HDL students. The performance of this system in emulating RTL behaviours forsmall designs is a determining usability factor. As project complexity increases over the course of astudent’s education, the emulation speed must be tolerable.To this end, the C++ harness from the compilation scalability test is modified to manipulate thecounters as they increase in number. the script described in Section 5.2.1 then runs the generatedexecutable after each subsequent compilation and records its runtime.Verilator has yet to optimize its RTE for concurrent processing, so real execution time is predictedto be equal to or greater than its CPU time.ResultsSimilar to the compilation results there is a similar anomaly in clock speed when the number of countermodules grows. Figure 5.4 shows the variation in CPS as the module increases in size. There is a lackof consistency in results until the number of counters exceeds 200, at which point the speed declinesmore linearly. Figure 5.5 compares the real execution time against processor time. CPU time displaysa near identical anomaly to the compilation results, dropping at 500 counters. Again, we are unable toascertain the cause.74Figure 5.4: Scalability of Execution for ARM VerilatorFigure 5.5: Real vs. CPU Execution Times755.2.3 InterpretationAnalysis of the previous results for compilation suggests that, for small hardware designs, Verilatormay not scale well. However, after a certain threshold, larger projects compile faster and scale muchmore linearly. Similarly, CPU time for execution shows the same problem, but is not as apparent withreal execution time.5.3 Course MaterialAn important benchmark for the DEVBOX prototype is its ability to implement the projects as-signed to University-level ECE students. The lab assignments from UBC’s digital logic design course,EECE353/CPEN311, will serve to demonstrate the platform’s ability to emulate Verilog for studentsof HDLs and logic design. These lab assignments range in complexity from simple adders to videogames. They use many of the on-board I/Os devices at a bare-wire level and the resultant hardware isdesigned to be interactive in nature. These assignments are ideal for exploring the software DEVBOXuses to emulate Verilog for the purpose of self-directed HDL education. They are written with Altera’sDE-2 board in mind, but can, for the most part, be adapted to the DEVBOX prototype’s board.In order to assess the platform’s viability for providing instructional materials to students, wecompleted the lab assignments from the above course in Verilog using DEVBOX, and tested themaccording to the specifications outlined in the assignment documentation. Noticeable lag or transientoutput errors were also catalogued. There are five labs, increasing in complexity throughout the cur-riculum, and each is completed using only the provided instructions and generic on-line resources.Appendix D contains the lab assignments from 2013 and 2014 chosen for this test. Assignments in-volving Quartus II or Qsys design software are omitted as these tools are not available for ARM Linux.Additionally, there are some assignments that include the use of hardware that is not available, suchas the LCD display found on the DE-2 board.Brief descriptions of each attempted lab’s goals are listed below.2013-Lab1: This assignment requires the development of a 7-segment decoder combinational circuit thatdisplays one of digits 0 through 7 on a 7-segment display based on a 3-bit input from the board’sswitches.762013-Lab2: The first portion of this assignment requires the use of an on-board LCD display and is omitted.The second half involves developing a craps dice game using an FSM and modular designhierarchy.2014-Lab2: The first half of this assignment is the same LCD display task as in the previous year. For thesecond half, a simple VGA pixel writer is designed to interact with an open source VGA adaptermodule.2014-Lab3: This assignment has the student develop a blackjack game using buttons and switches as inputand 7-segment displays and LEDs as output.2014-Lab4: For this assignment, the challenge is to develop hardware versions of line-drawing algorithmsfor the adapter module from assignment 2.A short list of modifications had to be made to support this selection of tasks on the DEVBOXprototype. First, a much larger region of physical memory addresses had to be exposed in order toaccess the entire array of MM I/O available on the FPGA. The API for this driver was simpifiedto read and write functions of variable bit-width, similar to the Avalon API. Additionally, a newharness application was required to accommodate the new interface, which necessitated a new top-level Verilog module. With these elements in place, the assignments were completed, following theinstructions in materials presented to Logic Design students.5.3.1 Results2013-Lab1:For this assignment, the character display can be easily written with a single asynchronous casestatement. The student must demonstrate a circuit where all 7-segment, or HEX, displays presentthe decimal value of a 3-bit integer selected by SW[2:0]. This circuit is then modified to displayfour different numbers on four individual HEX displays by instantiating multiple instances of a singlemodule. As a bonus task, the circuit is modified again to display the letters A through H instead ofdigits. Table 5.3 logs whether or not the task is demonstrated successfully as well as any detectable77Task Result Emulation AnomaliesTask 5: All HEX display same digit Successful notable ∆t between HEX transitionsTask 6: Independent HEX displays Successful Only 3 different values displayed dueto lack of switchesTask 7: Modified to display alpha char-actersSuccessful Same as Task 6Table 5.3: Lab 1 Assignment Resultsanomalies or variations in behaviour observed during emulation. This module’s compile time was19.45s.2013-Lab2:Due to the lack of an LCD display on the DE1-SoC board, the first task of this assignment is omittedfrom these results. For the second half, multiple modules, both complete and to be completed by thestudent, are provided in the course material. These modules are written in VHDL and were rewrittenin Verilog for the purpose of this test1.The goal of this task is to develop an FSM in HDL that adheres to the behavioural description,listed in Appendix D.1, in the lab assignment.In Table 5.4, the test results indicate that DEVBOX’s Verilog emulation was able to demonstrate allof the requirements for this lab assignment but exhibited a detectable transition delay on the physicalI/O. Also, a bug in the application caused an error that propagated through the last two states of themachine. This is possibly due to a logic error in the Verilog code itself or in the C++ harness. Thecraps module compiled in 18.55s.2014-Lab2:The first section of this assignment is identical to that of the previous year’s and has been omitted forthe same reason. The goal of the second half of this assignment is to interface with a custom VGAadapter to manipulate the pixels of the attached screen. As before, many complete and partial modulesare included in VHDL and most have been rewritten in Verilog for the purpose of this test. One1In HDL IDEs, the use of Verilog and VHDL are generally interchangeable, which means modules written in VHDLare directly portable to Verilog projects. The same cannot be said of Verilator. It is specific to Verilog and will not translateVHDL modules into C++.78State Result Emulation Anomalies1. Init: -- dice values, LEDR[0] on. Success None2. First Roll: 1-6 on HEX1 and HEX0.Total on HEX3 and HEX2.Success Delay between 7-segment transitionand LEDR transition2a. Win: LEDG on and LEDR[0] off Success LEDR[3:1] used due to lack of LEDG2b. Lose: Light up LEDR[17:1] andLEDR[0] offSuccess LEDR[9:7] used as per anomaly 1b.2c. Roll Again: Total is value to matchand copied to HEX5 and HEX4Success Delay on HEX5, HEX4 transition3. Reroll: New roll values onHEX1, HEX0. New total onHEX3, HEX2Success None3b. Match Win: Same as 2a. Logic Error LED state fails to update until nextreroll4. Game Over: Maintain state of out-puts. wait for reset.Success Due to logic error in 3b. The wrongdice value and total are displayed inbottom four HEXs in event of matchwin.Table 5.4: Lab 2 (2013) Assignment Resultshardware module, however, contains a relatively high degree of complexity and was not translated.This module is the VGA adapter mentioned above. Because it is immutable in the context of thisassignment and interfaces directly with the VGA hardware, it was possible to avoid its use for thistest.Figure 5.6 is a black-box representation of the adapter interface. The signals on the left-hand sideare driven by the student’s hardware design. The signals on the right drive the VGA DAC directly.In order to bypass this module, its behaviour was built into the C++ harness Verilator uses to drivethe emulation. The port list for this assignment’s top-level entity contained the left-hand signals asoutputs rather than those on the right-hand side, as would be expected in the original assignment. Theharness program then uses this output with the fbDraw library described in section 4.5 to emulatethe adapter’s behaviour.There are two tasks that are to be demonstrated in this assignment. The first is to fill the screen inwith a single colour. The second is an optional task where a 4×4 box is drawn at a location specifiedby the switches. Although this bonus circuit was completed and tested successfully, its complexity istrivial and has been omitted from this test. The screen resolution used is 160×120 pixels.79Figure 5.6: VGA Adapter Core as a Black BoxUpon the completion of the circuit for the main task, the following observations were made:1. The pixels were drawn in the correct order.2. The pixels were set to the correct colour.3. The entire screen was filled by the circuit.4. Total time to fill screen is approximately 40 minutes.The first three points satisfy the assignment’s requirements in that the circuit successfully fills thescreen with a single colour. The final point, however, renders the emulation of hardware-driven graph-ics unrealistic.Frame rates, measured in Hertz (Hz) or f ramessecond , indicate the time taken to redraw the entire screenand should be 24 Hz or greater for smooth video. If the Verilated circuit requires 40 minutes to fill theentire screen, the emulator’s effective frame rate is 4.167×10−4 Hz. This means it is only capable ofdrawing eight pixels every second. This module required 17.94s to compile.2014-Lab3:The goal of this lab assignment is to develop a non-trivial FSM to drive a Blackjack game. Therequired sequence of steps to successfully complete this circuit are as follows:801. Start. Give player a card.2. Give dealer a card.3. Give player a second card. If player stands, go to DealersTurn.4. Give player a third card. If player stands or goes bust, go to DealersTurn.5. Give player a fourth card.6. DealersTurn. Give dealer a second card. If dealer stands, go to Winner.7. Give dealer a third card. If dealer stands or goes bust, go to Winner.8. Give dealer a fourth card.9. Winner. Decide winner:• If both go bust, there is no winner. Go to EndGame.• If dealer >= player, or player is bust, go to DealerWins• If dealer < player, or dealer is bust, go to PlayerWins.10. DealerWins. Turn on LEDR[17:0]. Go to EndGame.11. PlayerWins. Turn on LEDG[7:0]. Go to EndGame.12. EndGame. Wait forever.The HDL developed for this test displayed no observable anomalies that could be attributableto Verilator’s effectiveness at emulating Verilog on the DE1-SoC’s ARM processor. This modulerequired the most time to compile at 23.86s.2014-Lab4:This assignment makes use of the same open-source VGA adapter used in 2014-Lab2 to implementline-drawing algorithms. Due to the slow performance experienced in the aforementioned lab, debug-ging the hardware design reached a near standstill. Development was abandoned before the require-ments of the assignment had been met.815.3.2 InterpretationThe results from the course material tests indicate that the platform is capable of emulating simple“Verilated” designs with an acceptable amount of observable anomalies in the form of delays betweenI/O transitions. However it is ineffective at emulating more complex designs such as VGA graphics.This observation compels the use of a more efficient method of Verilog hardware emulation for usein DEVBOX. In order to deliver an effective training experience, the platform must at least performthe required tasks of an early-university logic design course.82Chapter 6Future WorkThe DEVBOX platform is still in the early stages of development and there are many avenues forprogress to be explored. In this chapter some of the new components and improvements will bedescribed and discussed.6.1 Web InterfaceThe current browser-based GUI for DEVBOX is a simple mock-up of the intended suite. Many im-provements and additions can be made to improve the intuitiveness and effectiveness of the interface,as well as its look and feel.6.1.1 Editor and DebuggingThe prototype’s editor screen is a bare-bones example of the basic tools required to build and runcode. It lacks support for many of the debugging and analysis tools commonly available in mostIDEs. Breakpoint integration, auto-completion, and context-sensitive menus are all editing tools thatcan provide a much more productive learning environment. Particularly in testing Verilog, bugs canbe incredibly difficult to find if you are unable to step through execution or view the waveform of asimulation. In the next iteration of the web application these are features that should be integrated intothe Editor page.836.1.2 TutorialsThe current prototype of the Tutorials page includes a text area for displaying documentation and ascaled version of the editor. The text and code are combined into a single file to be parsed togetheras the tutorial progresses from page to page, dynamically updating the program code to coincide withthe page’s challenge. The parser, dubbed TutoriML, currently performs this task on a purely cosmeticlevel. In the future this method of combining text with code for the purpose of dynamic tutorialpresentation should be refined to a seamless mechanism to allow students to enter their own code intothe sample program without having it overwritten when moving to the next stage.A subjective test can also be performed to compare the current presentation style to an alter-nate configuration that does not require turning pages, as well as to the current browser-and-IDEtwo-window method used by students. This would ideally be conducted across multiple high schoolcampuses with a diverse cross-section of secondary students.There are only a handful of tutorials available on the prototype, and they are mostly intended onlydemonstrate the concepts of interactivity provided by TutoriML. A large body of well-written tutorialswill be required to render the Tutorials page effective. These could be adapted from free onlineresources or written specifically for the DEVBOX environment, focusing on the available hardwareI/Os. Quality Verilog training material outside of university-level courses is uncommon. Developingquality introductory tutorials for logic design, computer architecture, and HDLs should be a priorityin future iterations.6.1.3 TemplatesAnother addition to be made to the web interface is the inclusion of a Templates page. This page willhost a library of bare-bones source files outlining the procedures for certain types of programs. Thesestarting points will help new students jump ahead to the meat of the programming experience wheretangible results come often.846.2 Verilog Simulation6.2.1 ZUMA eFPGAAs discussed in Chapter 5, Verilator’s emulation performance on the DEVBOX prototype is very slowfor non-trivial solutions. While it is possible that other software-based emulators may be faster onARM processors than Verilator, another, potentially much faster, option may be available in the nearfuture. The ZUMA eFPGA is able to provide hardware accelerated HDL emulation in a similar fashionto synthesized hardware without the dependence on commercial tools such as Quartus II. An open-source bitstream generator, called “Verilog to RTL (VTR)”, synthesizes the Verilog into a file thatruns on the ZUMA architecture, like an FPGA within an FPGA, providing a considerable speedupover Verilator emulation. The ZUMA toolchain and eFPGA will be integrated into the DEVBOXplatform as it becomes available for ARM processors.6.2.2 DebuggingFuture iterations of the HDL emulation tools should include detailed debugging modes. These willallow students to observe the progression of a hardware design, monitor signal values and step throughlines of Verilog while the hardware I/Os continue to reflect the system state as they would with syn-thesized hardware. Specifically, the following need to be implemented:• Breakpoints• Signal taps• Clock- and line-stepping6.3 Community WebsitesAs the DEVBOX platform continues to evolve, the community will become increasingly important.Enticing participants to engage in the DEVBOX ecosystem will enrich the learning experience forstudents and motivate innovation among the developers. An easy to understand and welcoming userinterface with fluid and dynamic interaction models can be developed to enable source code sharing,85distribution of documentation, and general social interaction such as chat and multi-user editing of thesame code.6.4 Device PrototypeThe current DEVBOX prototype resides on a Terasic DE1-SoC development board which does notcontain all of the necessary hardware elements that the concept requires. Future design and develop-ment of the final device will include these missing elements, such as WiFi, Arduino Shield GeneralPurpose I/Os (GPIOs), and HDMI output.86Chapter 7ConclusionDEVBOX is a versatile development education platform intended to accommodate students and en-thusiasts with a broad range of experience in multiple programming languages. The viability of thisplatform as a tool for introducing Verilog to students early in their academic career is explored in thisthesis. By providing a platform for a hands-on independent learning tool for HDL and logic designwith no dependence on lengthy downloads, software installation or driver conflicts, DEVBOX aimsto eliminate the barrier-to-entry and intimidation factor faced by prospective students of computerarchitecture, SoC development, and logic design.A large body of work has been done to facilitate the grade school to early university education ofcomputer programming students by way of VPLs, laptops, and embedded computer systems preloadedwith development tools and more intuitive course and tutorial material. In contrast, very little hasbeen done to date toward improving the learning experience in digital logic and HDLs. The subjectmatter is generally considered to be prohibitively complicated, and left to sophomore engineeringcourses. Many studies have shown that early introduction to computer programming and related sub-jects greatly improves success rates among first year students in technology-related fields, and thesame might be inferred with regard to Verilog.This thesis proposes the use of an embedded system with hardware and software tailored towardself-directed programming instruction, with a zero-install, zero-setup configuration, such as the DEV-BOX platform described in Chapter 3. Such a platform is capable of delivering the instruction and87development material required for early HDL education. This includes tutorials, compilation andemulation tools, visual feedback and hard I/O integration.DEVBOX was originally proposed as an education tool for prospective software developers, buthas shown potential for delivering the necessary materials for early logic design education. LearningHDL can be greater challenge for many computer science and ECE students than learning softwareprogramming languages. Introducing the concepts and syntax involved in hardware description priorto university at a pace determined by the student will have a positive impact on student success ratesin early-year logic design courses.A prototypical model of DEVBOX has been developed, as described in Chapter 4, that is capableof providing the required elements described above for not only Verilog HDL, but also for C andArduino C programming languages. It natively compiles these three languages and runs the generatedprograms internally, receiving input from and exporting output to the user over a local network andon-board I/O devices. A browser-based mock-up web application provides a GUI through whichusers can access the provided resources. The “Tutorials” and “Editor” pages are both functional anddemonstrate the minimal desired behaviour of these interfaces.By creating a prototype device that does not require the installation of specialized software or theuse of a specific operating system, and requires access only to common household resources, such asWiFi and an HDMI-ready display, the development of the DEVBOX prototype id s viable candidatefor producing a portable and easy-to-use development education platform. The UI mock-up usesasynchronous javaScript, PHP, and Node.js to provide a dynamic development environment. Tutorialcontent is also delivered in a dynamic way, using the custom-developed TutoriML syntax and parserto allow users to test and modify code as they navigate through their sessions.The DEVBOX prototype simulates Verilog by way of the Verilator HDL simulator and makesuse of the device’s hard I/Os in the same way synthesized modules would on an FPGA. A series oftests has unveiled the strengths and shortcomings of the DEVBOX prototype in simulating Verilogand providing an instructional environment for logic design and HDL. These tests have demonstratedthat, despite reliably emulating simple Verilog modules in an ARM Linux environment, it lacks theefficiency to perform more complex tasks. For example, if a “Verilated” VGA adapter were to render88a single High Definition (HD) frame, the process would take approximately three days.More effective emulation methods are currently being researched and ported to the ARM Instruc-tion Set Architectures (ISAs) that may increase the speed and efficiency with which students’ designsare executed. These eFPGAs have the potential to drastically increase emulation speed. It applies anopen FPGA framework over top of the Cyclone V-SoC’s proprietary gate array and compiles Veriloginto this framework with open source software.Based on the current progress and test results described in this document, an embedded SoC sys-tem such as the one described for the DEVBOX platform is capable of delivering the tools necessaryfor early logic design and HDL education. Despite emulation efficiency concerns related to morecomplex designs, such as multimedia and DSP, the concept devised herein has been successfully pro-totyped and proven to provide a platform for a zero-install, interactive, and effective HDL educationecosystem.89Bibliography[1] Arduino - Home. URL https://www.arduino.cc/. [Last accessed 2015-09-22]. → pages 10[2] Bart0vds’s Profile - Member List - Minecraft Forum. URLhttp://www.minecraftforum.net/members/Bart0vds/reputation. [Last accessed 2015-07-26]. →pages 2[3] BeagleBoard.org - community supported open hardware computers for making. URLhttp://beagleboard.org/. [Last accessed 2015-09-22]. → pages 9[4] ”clang” C Language Family Frontend for LLVM. URL http://clang.llvm.org/. [Last accessed2015-10-13]. → pages 54[5] Code::Blocks, . URL http://www.codeblocks.org/. [Last accessed 2016-01-22]. → pages 8[6] Codeboard the IDE for the classroom, . URL https://codeboard.io/. [Last accessed2015-10-13]. → pages 6, 7[7] Cortex-A15 Processor - ARM, . URLhttp://www.arm.com/products/processors/cortex-a/cortex-a15.php. [Last accessed2015-11-30]. → pages 73[8] Eclipse - The Eclipse Foundation open source community website. URLhttp://www.eclipse.org/. [Last accesed 2016-01-22]. → pages 8[9] Minecraft. URL https://minecraft.net/. [Last accessed 2015-07-26]. → pages 2[10] One Laptop per Child. URL http://one.laptop.org/. [Last accessed 2015-09-22]. → pages 8[11] Raspberry Pi - Teach, Learn, and Make with Raspberry Pi. URL https://www.raspberrypi.org/.[Last accessed 2015-09-22]. → pages 9[12] Yocto Project | Open Source embedded Linux build system, package metadata and SDKgenerator. URL https://www.yoctoproject.org/. [Last accessed 2016-01-22]. → pages 44[13] AMBA Specifications - ARM. URLhttp://www.arm.com/products/system-ip/amba-specifications.php. [Last accessed 2015-09-22].→ pages 37[14] Cyclone V - Overview. URLhttps://www.altera.com/products/fpga/cyclone-series/cyclone-v/overview.html. [Last accessed2015-09-22]. → pages 3690[15] Node.js. URL https://nodejs.org/en/. [Last accessed 2015-05-27]. → pages 45[16] Altera Corporation. Avalon Interface Specifications, Mar. 2015. URL https://www.altera.com/content/dam/altera-www/global/en US/pdfs/literature/manual/mnl avalon spec.pdf. [Lastaccessed 2015-11-12]. → pages 61[17] M. D. L. n. Cifredo-Chacn, n. Quirs-Olozbal, and J. M. Guerrero-Rodrguez. Computerarchitecture and FPGAs: A learning-by-doing methodology for digital-native students:COMPUTER ARCHITECTURE AND FPGAs. Computer Applications in EngineeringEducation, 23(3):464–470, May 2015. ISSN 10613773. doi:10.1002/cae.21617. URLhttp://doi.wiley.com/10.1002/cae.21617. → pages 4, 15[18] M. Conway, S. Audia, T. Burnette, D. Cosgrove, K. Christiansen, R. Deline, J. Durbin,R. Gossweiler, S. Koga, C. Long, and others. Alice: Lessons Learned from Building a 3dSystem For Novices. 1999. URLhttp://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.43.2242&rep=rep1&type=pdf. →pages 5[19] S. Cooper, W. Dann, and R. Pausch. Alice: a 3-D tool for introductory programming concepts.In Journal of Computing Sciences in Colleges, volume 15, pages 107–116. Consortium forComputing Sciences in Colleges, 2000. URL http://dl.acm.org/citation.cfm?id=364161. →pages 5[20] Y.-C. Hung. The Effect of Problem-Solving Instruction on Computer Engineering Majors’Performance in Verilog Programming. IEEE Transactions on Education, 51(1):131–137, 2008.ISSN 0018-9359. doi:10.1109/TE.2007.906912. URLhttp://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4448425. → pages 15[21] B. Isong. A Methodology for Teaching Computer Programming: first year students perspective.International Journal of Modern Education and Computer Science, 6(9):15–21, Sept. 2014.ISSN 20750161, 2075017X. doi:10.5815/ijmecs.2014.09.03. URLhttp://www.mecs-press.org/ijmecs/ijmecs-v6-n9/v6n9-3.html. → pages 13[22] L. Jeniric. Teaching Introductory Programming. ijacsa, 5(6):60–69, July 2014.doi:10.14569/IJACSA.2014.050611. → pages 13[23] S. K. R. K. and S. Kode. Enhancing the Learning Experience by Addressing the Needs of theLearner Through Customization and Personalization in the Learning by Doing Methodology.pages 274–275. IEEE, July 2010. ISBN 978-1-4244-7144-7. doi:10.1109/ICALT.2010.80. URLhttp://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5571306. → pages 4[24] Z. Keaton. Kano Launches New Computer Kit. Techcrunch Disrupt 2015, May 2015. URLhttps://dl.dropboxusercontent.com/content link/bEkGhO87y0IH0iH1WgQNfZ3h71tmaQ00OJkk9Vr4eqNZeYGVOmPMLXn3GJXwJjqb?dl=1.→ pages 10[25] M. Klling. The Greenfoot Programming Environment. ACM Transactions on ComputingEducation, 10(4):1–21, Nov. 2010. ISSN 19466226. doi:10.1145/1868358.1868361. URLhttp://portal.acm.org/citation.cfm?doid=1868358.1868361. → pages 691[26] T. Koulouri, S. Lauria, and R. D. Macredie. Teaching Introductory Programming: AQuantitative Evaluation of Different Approaches. ACM Transactions on Computing Education,14(4):1–28, Dec. 2014. ISSN 19466226. doi:10.1145/2662412. URLhttp://dl.acm.org/citation.cfm?doid=2698235.2662412. → pages 12[27] G. Licea, R. Jurez-Ramrez, C. Gaxiola, L. Aguilar, and L. G. Martnez. Teachingobject-oriented programming with AEIOU: OBJECT-ORIENTED PROGRAMMING.Computer Applications in Engineering Education, 22(2):309–319, June 2014. ISSN 10613773.doi:10.1002/cae.20556. URL http://doi.wiley.com/10.1002/cae.20556. → pages 12[28] J. Maloney, L. Burd, Y. Kafai, N. Rusk, B. Silverman, and M. Resnick. Scratch: a sneakpreview [education]. In Creating, Connecting and Collaborating through Computing, 2004.Proceedings. Second International Conference on, pages 104–109. IEEE, 2004. URLhttp://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=1314376. → pages 5[29] J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond. The Scratch ProgrammingLanguage and Environment. ACM Transactions on Computing Education, 10(4):1–15, Nov.2010. ISSN 19466226. doi:10.1145/1868358.1868363. URLhttp://portal.acm.org/citation.cfm?doid=1868358.1868363. → pages 2, 5[30] Nobuyuki Tachi, Susumu Yamazaki, and Taku Jiromaru. An Education Program on EmbeddedSoftware Development Using Open Source Hardware Aiming to Learn How to Learn NewTechnologies (abst.). J.of JSEE, 62(4):4–38, 2014. URLhttps://www.jstage.jst.go.jp/article/jsee/62/4/62 4 33/ pdf. → pages 11[31] T. Preston-Werner. How we turn $199 Chromebooks into Ubuntu-based code learningmachines for kids, Aug. 2014. URLhttp://blog.codestarter.org/how-we-turn-199-chromebooks-into-ubuntu-based/. [Last accessed2015-05-27]. → pages 8[32] M. Resnick, J. Maloney, A. Monroy-Hernndez, N. Rusk, E. Eastmond, K. Brennan, A. Millner,J. Silver, B. Silverman, and Y. Kafai. Scratch: Programming for all. Communications of theACM, 52(11), 2009. URLhttp://static.elitesecurity.org/uploads/2/4/2462619/communications200911-xBSrY7lmop.pdf.→ pages 5[33] E. Troger, M. Brush, C. Wendling, F. Lanitz, N. Treleaven, and D. Hopf. Geany : Home Page,Oct. 2008. URL http://www.geany.org/. [Last accessed 2015-06-24]. → pages 11[34] Wilson Snyder. Intro - Verilator - Veripool, 2015. URL http://www.veripool.org/wiki/verilator.[Last accessed 2015-10-16]. → pages 5892Appendix AArduino Runtime Source1 //arduinoRuntime.h2 //Keith Lee3 //Jan 20 ,201545 #include"arduinoRuntime.h"6 #define AIMAGE "./aimage.bmp"789 static int fd;101112 // Arduino Runtime main loop1314 int main()15 {16 dev_fb fb;17 bmp bm;1819 setbuf(stdout,NULL);2021 if(fbBmp_openBmp(AIMAGE, &bm))22 {23 printf("\nArduinoRuntime error: Failed to initialize Arduino Image\↪→ n");24 return -1;25 }2627 fb_init(&fb);282930 //Begin mapping to hardware3132 reset();33 fb_fillScr(&fb,255,255,255);9334 fbBmp_draw(&fb, &bm, 1, OFFSET,OFFSET);35 fd=open_devbox_io() ;36 printf("%d\n",fd);37 updateState(&fb, fd);3839 setup();40 updateState(&fb, fd);41 close_devbox_io(fd);4243 //Call user’s loop function44 while(1)45 {46 loop();47 if((fd=open_devbox_io())==-1)48 {49 printf("ERROR: Could not open io\n");50 return -1;51 }52 updateState(&fb, fd);53 close_devbox_io(fd);54 }5556 //Clean up5758 fb_close(&fb);596061 return 0;62 }6364 void pinMode(int pin, int mode)65 {6667 if(pin>13)68 return;69 if(mode==OUTPUT)70 {71 d_pin_mode[pin]=(mode<<8)|_n_output;72 if(_n_output<10)73 ledr[_n_output]=d_pin[pin];74 _n_output++;75 }76 else77 {78 d_pin_mode[pin]=(mode<<8)|_n_input;79 if(_n_input<4)80 d_pin[pin]=keys[_n_input];81 else82 d_pin[pin]=switches[_n_input-4];83 _n_input++;84 }85 //printf("o: %d\ni: %d\n\n",_n_output, _n_input);9486 }8788 void drawPinState(dev_fb* fb)89 {90 pixel px={PIN13_8_STARTX+OFFSET,PIN_STARTY+OFFSET};91 unsigned char color[3];92 int i;93 //Set D_PINS94 color[1]=color[2]=0;95 for(i=13;i>=0;i--)96 {97 //printf("%d: %d\n", i, d_pin[i]);98 if(d_pin[i]!=0)99 color[0]=255;100 else101 color[0]=0;102103 fb_fillBox(fb, px, PIN_DIMX, PIN_DIMY, color[0], color[1], color↪→ [2]);104105 if(i == 8)106 {107 px.x=PIN7_0_STARTX+OFFSET;108 px.y=PIN_STARTY+OFFSET;109 }110 else px.x+=PIN_GAP+PIN_DIMX;111 }112113 //Set A_PINS114 px.x=A_PINS_STARTX+OFFSET;115 px.y=A_PINS_STARTY+OFFSET;116 color[1]=color[2]=0;117 for(i=5;i>=0;i--)118 {119 color[0]=a_pin[i];120 fb_fillBox(fb, px, PIN_DIMX, PIN_DIMY, color[0], color[1], color↪→ [2]);121 px.x+=PIN_GAP+PIN_DIMX;122 }123 }124125 void drawLedState(dev_fb* fb)126 {127 int i;128 pixel px={LEDR_STARTX+OFFSET, LEDR_STARTY+OFFSET};129 unsigned char color[3];130 color[1]=color[2]=0;131 for(i=9;i>=0;i--)132 {133 if(led[i])134 color[0]=255;135 else95136 color[0]=0;137138 fb_fillBox(fb, px, LEDR_DIMX, LEDR_DIMY, color[0], color[1], color↪→ [2]);139 px.x+=LEDR_GAP;140 }141 }142143 void drawKeyState(dev_fb* fb)144 {145 int i;146 pixel px={KEY_STARTX+OFFSET, KEY_STARTY+OFFSET};147 unsigned char color[3];148 color[0]=color[1]=color[2]=0;149 for(i=3;i>=0;i--)150 {151 if(keys[i])152 color[0]=255;153 else154 color[0]=0;155156 fb_fillBox(fb, px, KEY_DIMX, KEY_DIMY, color[0], color[1], color↪→ [2]);157 px.x+=KEY_GAP;158 }159160 }161162 void drawSwState(dev_fb* fb)163 {164 int i;165 pixel px={SW_STARTX+OFFSET, SW_STARTY+OFFSET};166 unsigned char top_color[3], bottom_color[3];167 top_color[1]=top_color[2]=bottom_color[1]=bottom_color[2]=0;168 for(i=9;i>=0;i--)169 {170 if(switches[i])171 {172 top_color[0]=255;173 bottom_color[0]=0;174 }175 else176 {177 top_color[0]=0;178 bottom_color[0]=255;179 }180 fb_fillBox(fb, px, SW_DIMX, SW_DIMY/2, top_color[0], top_color[1],↪→ top_color[2]);181 px.y+=(SW_DIMY/2)+1;182 fb_fillBox(fb, px, SW_DIMX, SW_DIMY/2, bottom_color[0],↪→ bottom_color[1], bottom_color[2]);183 px.y=SW_STARTY+OFFSET;96184 px.x+=SW_GAP;185 }186 }187188 void getIo(int fd)189 {190 int i;191 unsigned short input_val=devbox_get_sw(fd) & 0x3ff;192193 for(i=0;i<10;i++)194 {195 switches[i]=input_val&1;196 input_val=input_val>>1;197 }198 input_val=˜(devbox_get_key(fd) & 0xf);199 for(i=0;i<4;i++)200 {201 keys[i]=input_val&1;202 input_val=input_val>>1;203 }204205 }206207 void setIo(int fd)208 {209 int i;210 unsigned int output_val=0;211 unsigned char bit_val;212 for(i=0;i<10;i++)213 {214 bit_val=(ledr[i]>0)?1:0;215 output_val=output_val|(bit_val<<i);216 }217 devbox_set_led(fd,output_val);218219 }220221 void setPins()222 {223 int i;224 int n_input;225 for(i=0;i<14;i++)226 {227 if(d_pin_mode[i]>>8==INPUT)228 {229 n_input=d_pin_mode[i]&0xff;230 if(n_input<4)231 d_pin[i]=keys[n_input];232 else233 d_pin[i]=switches[n_input-4];234 }235 }97236 }237238 void getPins()239 {240 int i;241 int n_output;242 for(i=0;i<14;i++)243 {244 if(d_pin_mode[i]>>8==OUTPUT)245 {246 n_output=d_pin_mode[i]&0xff;247 if(n_output<10)248 led[n_output]=d_pin[i];249 }250251 }252 }253254255 void updateState(dev_fb* fb, int fd)256 {257 getIo(fd);258 setPins();259 setIo(fd);260 getPins();261 drawPinState(fb);262 drawLedState(fb);263 drawKeyState(fb);264 drawSwState(fb);265266 }267268 void reset()269 {270 int i;271 for (i=0;i<32;i++)272 {273 if(i<4)274 keys[i]=0;275 if(i<6)276 {277 a_pin[i]=0;278 seg7[i]=0;279 }280 if(i<10)281 {282 led[i]=0;283 switches[i]=0;284 }285 if(i<14)286 {287 d_pin[i]=0;98288 d_pin_mode[i]=0;289 }290 gpio0[i]=0;291 }292 _n_input=0;293 _n_output=0;294 }295296297298299300301302303304305306307308309310311312 void digitalWrite(int pin, int value)313 {314 if(pin<14)315 d_pin[pin]=value;316 }317318 int digitalRead(int pin)319 {320 return d_pin[pin];321 }322323 void randomSeed(long seed)324 {325 srand(seed);326 }327328 int a_random(int max)329 {330 return (rand()%max);331 }332333 char lowByte(short x)334 {335 return x&0xff;336 }337338 char highByte(short x)339 {99340 return (x&0xff00)>>8;341 }342343 char bitRead(int x, char n)344 {345 int bitmask=1<<n;346 if(x&bitmask)347 return 1;348 else return 0;349 }350351352353 void delay(int ms)354 {355 usleep(ms<<3);356 }357358 void delayMicroseconds(int us)359 {360 usleep(us);361 }100Appendix BNode.js Server Source1 var app = require(’express’)();2 var http = require(’http’).Server(app);3 var io = require(’socket.io’)(http);4 var cp = require(’child_process’);5 var fs = require(’fs’);6 var cors = require(’cors’);7 var run;8 app.get(’/’, function(req, res){9 res.send(’<h1>DEVBOX ASYNC</h1><br> Direct access to port denied.’);10 });11 io.on(’connection’, function(socket){12 socket.on(’disconnect’, function(){13 if(typeof run != "undefined") run.kill();14 else console.log(’run on connect’);15 });1617 socket.on(’candr’, function(data){18 var _code=-1;19 switch(data[’lang’])20 {21 case ’c’:22 case ’arduino’:23 console.log(’begin save\n’);24 fs.writeFileSync(’main.c’, data[’code’]);25 break;26 case ’verilog’:27 fs.writeFileSync(’main.v’, data[’code’]);28 break;29 default:30 console.log(’Compile: Unknown language’);31 break;32 }33 var mk=cp.spawn("make",[data[’lang’]]);34 mk.on(’error’, function (err) {10135 console.log(’spawn error:’, err);36 socket.emit(’compile’, ’There was a problem running the compiler↪→ . Please try again.\n’);37 });38 mk.stdout.setEncoding(’utf-8’);39 mk.stdout.on(’data’,function(data){40 socket.emit(’compile’, data);41 });42 mk.stderr.setEncoding(’utf-8’);43 mk.stderr.on(’data’, function(data){44 socket.emit(’compile’, data);45 });46 mk.on(’exit’, function(code){47 console.log(’MAKE exited with code ’+code+’\n’);48 if(code==0){49 run = cp.spawn("./main");50 run.on(’error’,function(err){51 console.log(’spawn error:’,err);52 socket.emit(’compile’, ’There was a problem running the↪→ program. Please try again.\n’);53 });54 run.stdout.setEncoding(’utf-8’);55 run.stdin.setEncoding(’utf-8’);56 run.stdout.on(’data’,function(data){57 socket.emit(’run’, data);58 });59 run.on(’exit’, function(code){60 socket.emit(’run’,’\n---program finished, returned ’+code+↪→ ’---\n’);61 run=undefined;62 });63 }64 else socket.emit(’compile’, ’Compile failed: Cannot run’);65 });66 });67 socket.on(’kill’, function(){68 if(typeof run != ’undefined’){69 if(run.constructor.name == "ChildProcess"){70 run.kill();71 }72 }73 });7475 socket.on(’error’,function(error){76 console.log(’Socket error: ’+error);77 });78 socket.on(’input’,function(data){79 in_data=unescape(data);80 if(typeof run != ’undefined’){81 run.stdin.write(in_data+’\n’);82 }83 else console.log(’runtime: Not running on input’);10284 });85 });86 var port=80;87 if(process.argv.length>2 && !isNaN(process.argv[2]))88 port=port+parseInt(process.argv[2]);89 else port=port+1;90919293 http.listen(port, function(){94 console.log(Date.now() / 1000+’: listening on *:’+port);95 });103Appendix CTutorials.php Source1 <!DOCTYPE html>2 <?php3 ini_set(’include_path’,’phplibs/’);4 include "TutoriML.php";5 include "portnum.php";6 if(isset($_POST[’lang’]))7 {8 $lang=$_POST[’lang’];9 $dir="tutorials/".$lang;10 $files=array_slice(scandir($dir),2);11 }12 $page=$_POST[’page’];13 $tml=$_POST[’tutorial’];14 $file=’main.txt’;15 $log=’php_log.csv’;16 $date=new DateTime();17 if(isset($tml))18 {1920 if(isset($_POST[’code’]))21 {22 $base=$_POST[’code’];23 file_put_contents($file, $base);24 }25 $title=getTitle($dir, $tml);26 $n_pages=getPages($dir, $tml);27 if(isset($_POST[’submit’]))28 {29 $code=getCode($dir, $tml, $page);30 $base=htmlspecialchars($base);31 fsetCode($file, $code);32 $base=file_get_contents($file);33 file_put_contents($log,’Tutorial_start, ’.date_timestamp_get(↪→ $date).’;’.PHP_EOL, FILE_APPEND);10434 }3536 if(isset($_POST[’next’]) || isset($_POST[’prev’]))37 {38 $getPage="";3940 }41 if(isset($_POST[’next’]))42 {43 if($page<$n_pages)44 {45 $page=$page+1;46 file_put_contents($log, ’Next ’.$page.’, ’.date_timestamp_get↪→ ($date).’;’.PHP_EOL, FILE_APPEND);47 $code=getCode($dir, $tml, $page);48 fsetCode($file, $code);49 }50 if($page==$n_pages)51 file_put_contents($log, ’Tutorial_end, ’.date_timestamp_get(↪→ $date).’;’.PHP_EOL, FILE_APPEND);52 $base=file_get_contents($file);53 }5455 if(isset($_POST[’prev’]) )56 {57 if($page>1){58 $page=$page-1;59 file_put_contents($log, ’Prev ’.$page.’, ’.date_timestamp_get↪→ ($date).’;’.PHP_EOL, FILE_APPEND);60 }61 if($page==1)62 file_put_contents($log, ’Tutorial_first, ’.date_timestamp_get↪→ ($date).’;’.PHP_EOL, FILE_APPEND);63 $base=file_get_contents($file);64 }65 $desc=getDesc($dir, $tml, $page);6667 }68 else69 file_put_contents($log, ’action, timestamp;’.PHP_EOL);7071727374 if(!isset($n_pages))75 $n_pages=1;767778 function insertVars($page, $tml, $base, $lang)79 {80 if($base!=0)10581 echo(’<input type="hidden" name="code" value="’.$base.’"></input↪→ >’.PHP_EOL);8283 echo(’<input type="hidden" id="_lang" name="lang" value="’.$lang.’↪→ "></input>’.PHP_EOL);84 echo(’<input type="hidden" name="selected" value="true"></input>’.↪→ PHP_EOL);85 echo(’<input type="hidden" id="tut" name="tutorial" value="’.$tml.’↪→ "></input>’.PHP_EOL);86 echo(’<input type="hidden" name="page" value="’.$page.’"></input>’.↪→ PHP_EOL);87 }88 ?>89 <html>90 <head>91 <script src="codemirror-4.2/lib/codemirror.js"></script>92 <link rel="stylesheet" href="codemirror-4.2/lib/codemirror.css">93 <link rel="stylesheet" href="codemirror-4.2/theme/eclipse.css">94 <script src="codemirror-4.2/mode/clike/clike.js"></script>95 <script src="codemirror-4.2/mode/verilog/verilog.js"></script>96 <script src=socket.io.js></script>9798 <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"↪→ >99100 <style type="text/css">101 .CodeMirror {border: 1px solid black}102 div.left103 {104 width:49.5%;105 height:100%;106 float:left;107108 }109 div.right110 {111 width:50%;112 height:100%;113 float:right;114115 }116 </style>117118 <title>DEVBOX Tutorials</title>119 <script type="text/javascript">120121122 </script>123 </head>124 <body>125 <font size="22"><a href="index.html"><img style="width: 209px;↪→ vertical-align: middle;" alt="DEVBOX" title="DEVBOX Logo"106126 src="DevBoxLogoTest418x146.png"></a> TUTORIALS</font>127 <br>128129 <div>130 <form id="setlang" method="post" action="">131 <label for="lang">Select Language: </label>132 <select id="lang" name="lang" size=1 onchange="this.form.submit()">133 <option disabled selected>-language-</option>134 <option id="c" value="c">C</option>135136 </select>137 </form>138139 <?php140141 if(isset($lang))142 { ?>143 <form id="choose" method="post" action="" name="choose">144 <label for="tutorial">Select Tutorial: </label>145 <?php echo(’<input type="hidden" id="_lang" name="lang" value="’↪→ .$lang.’"></input>’);146 echo(’<input type="hidden" id="portnum" value="’.$portnum.’"></↪→ input>’);147 if(!isset($_POST[’selected’]))148 echo(’<select id="tutorial" name="tutorial" size="’.count(↪→ $files).’">’);149 else150 echo(’<select id="tutorial" name="tutorial" size="1">’);151 foreach($files as $tmlx)152 {153 $file=unfile($tmlx);154 echo(’<option id="’.$tmlx.’" value="’.$tmlx.’">’.$file.’</↪→ option>’);155 }156 ?>157 </select>158 <input type="hidden" name="selected" id="selected" value="true"↪→ ></input>159 <input type="hidden" name="page" id="page" value=1></input>160161162 <button name="submit">GO</button>163164 <?php } ?>165 </form>166 </div>167 <br>168169170 <?php if(isset($tml))171 {172 ?>107173 <h1><?php echo($title);?></h1>174 <div id="description" class="left">175 <?php echo($desc); ?>176 <br><br><form id="turnpage" name="turnpage" action="" method="↪→ post">177 <div style="float: center; text-align: center;">178 <?php179 echo($page.’/’.$n_pages);180 ?> </div>181 <button name="prev" style="float: left;"> &lt;&lt; Prev</↪→ button>182 <button name="next" style="float: right;"> Next &gt;&gt;</↪→ button>183184 <?php insertVars($page, $tml,$base, $lang); ?>185 </form>186 </div>187 <div id="thecode" class="right">188 <h1> Example Code </h1>189 <form id="code_entry" method="post" action="" name="code_entry"↪→ accept-charset="utf-8" >190 <textarea rows="15" id="code" name="code"><?php echo($base);↪→ ?></textarea>191 <br>192 <button name="candr" id="candr" type="button"onclick="cr(↪→ document.getElementById(’_lang’).value, document.↪→ getElementById(’page’).value);">Compile &amp; Run</↪→ button>193 <button name="kill" type="button" onclick="kp();">Stop↪→ Program</button>194 <?php insertVars($page, $tml, 0, $lang); ?>195 </form>196197198 <label>Compiler Output</label><br><textarea cols="60" rows="5"↪→ id="comp_out" name="comp_out" readonly></textarea><br>199 <label>Program Output</label><br><textarea cols="60" rows="5" id↪→ ="prog_ex" name="prog_ex" readonly></textarea><br>200 <label>Enter your program input here</label><br><input id="input↪→ " type="text" cols="40"></input>201 <button type="button" onclick="scanf(escape(document.↪→ getElementById(’input’).value));">Submit</button>202 <br>203204 </div>205 <script type="text/javascript">206 var lang=document.getElementById("_lang");207 var hilite="text/x-csrc"208 switch(lang.value)209 {210 case "verilog":211 hilite="text/x-verilog"108212 break;213 case "arduino":214 case "c":215 default:216 break;217 }218219220221222 var selected=document.getElementById("tut");223 var optn=document.getElementById(selected.value);224 optn.setAttribute(’selected’,’selected’);225 selected=document.getElementById("_lang");226 optn=document.getElementById(selected.value);227 optn.setAttribute(’selected’,’selected’);228229 </script>230 <?php } ?>231 <script type="text/javascript">232 var selected=document.getElementById("_lang");233 var optn=document.getElementById(selected.value);234 optn.setAttribute(’selected’,’selected’);235 var text_area=document.getElementById("code");236 var editor=CodeMirror.fromTextArea(text_area,{theme: "eclipse",237 lineNumbers: true,238 mode: hilite,239 indentUnit: 3,240 tabSize: 3,241 indentWithTabs: true,242 pollInterval: 0,243 });244 var portnum = document.getElementById(’portnum’).value;245 var socket=io(document.domain+’:’+portnum);246 socket.connect();247248 socket.on(’compile’, function(data){249 var c_out=document.getElementById(’comp_out’);250 c_out.innerHTML+=data;251 });252 socket.on(’run’, function(data){253 var r_out=document.getElementById(’prog_ex’)254 r_out.innerHTML+=data;255 r_out.scrollTop=r_out.scrollHeight;256 });257 function cr(lang, page)258 {259 socket.emit(’candr’,{lang: lang, code: editor.doc.getValue(),↪→ page: page});260 document.getElementById(’compile_out’).innerHTML="";261 document.getElementById(’program_out’).innerHTML="";262 }109263264 function kp()265 {266 socket.emit(’kill’);267 }268269 function scanf(data)270 {271 socket.emit(’input’, data);272 document.getElementById(’input’).value=’’;273 }274 </script>275 </body>276 </html>110Appendix DLogic Design VHDL AssignmentsD.1 2013 Cohort111DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING UNIVERSITY OF BRITISH COLUMBIA EECE 353 – Digital Systems Design  Lab 1: Combinational Logic  Lab: MCLD358  TAs: Aaron Severance, Michael Yue, Dongdong Li  In this lab, you will become familiar with the software and hardware we will be using in the labs, and use the hardware and software to implement a simple combinational logic circuit.  You will also be introduced to VHDL, which is a common way of specifying digital circuits.  Even though we haven’t talked much about VHDL in class yet, you’ll still be able to do this lab if you follow the instructions in this handout.    We will be using two pieces of software for most of this course: Quartus II, which is produced by Altera, and ModelSim, which is produced by Mentor Graphics.  There are several versions of ModelSim available; we will be using one that has been modified by Altera for use with Quartus II.  You can download these programs as described below (they are free), or use them on the departmental computers in the lab.   PHASE ONE: SETUP AND SIMULATION  TASK 0: Install Quartus II and the Altera version of ModelSim on your home PC, laptop, or find a place you can run the software (it will be available on most of the computers available throughout the department). • Visit http://help.ece.ubc.ca/Altera for download links and installation information. • In EECE 353, we will use version 13.0 SP1 of Quartus II. This version is installed in the lab. • If you are taking EECE 381 concurrently, you might use version 12.0 SP2 for both courses.  TASK 1: Download the “Digital System Design using Altera Quartus II and ModelSim” tutorial document located in the Lab 1 folder of Connect. Section 1 will help you with installing the tools. Work through Sections 2 and 3 of the tutorial document.  This will introduce you to Quartus II and ModelSim, which are the tools we will use throughout the course.  TASK 2:  You are going to design and simulate a combinational circuit using VHDL.  Don’t worry about not knowing much VHDL yet; you will be given skeleton files with most of the hard work done.  You’ll be guided to make some fairly minor changes to these files.  The circuit you will design is a combinational circuit with three inputs named sw(0), sw(1) and sw(2),  and seven outputs named hex0(6) downto hex0(0).  The inputs will be connected to switches, and the output will be connected to a LED hex display as shown below.    hex0(5)hex0(6)hex0(4)hex0(3)hex0(0)hex0(1)hex0(2)Your circuithex0(6)hex0(5)hex0(4)hex0(3)hex0(2)hex0(1)hex0(0)sw(2)sw(1)sw(0) 112The operation of this circuit is that it will convert a three bit binary number into seven signals that control an LED display, as shown below:  000001010011100101110111sw(2 downto 0) Output sw(2 downto 0) Output  Each input to the LED (output of your circuit) controls one segment; if the input is 0, the segment is on while if the input is 1, the segment is off (this is called active-low signaling).  The correspondence between LED input signals and the various segments in the display are shown in the diagram on the first page of this handout.  So, for example, if hex(0) is a 0, then the top horizontal segment will be on.  To specify this circuit, you should download the skeleton files converter.vhd and converter_tb.vhd from the course site (in the “Labs/Lab  1” folder).  The first file, converter.vhd is where the functionality of the block will be described.  The second file, converter_tb.vhd is a testbench file contains the instructions the simulator will use to exercise (stimulate) your design during simulation.  In this lab, the complete converter_tb.vhd  is given to you; you won’t have to modify the testbench file.  All of your changes will be in the file converter.vhd .  The only part of converter.vhd you need to modify is the part that describes the logic functionality of your block.  If you look near the end of your file, you will see a block of code that looks like this:         case SW is            when "000" => HEX0 <= "1000000";            when "001" => HEX0 <= "1111001";            when "010" => HEX0 <= "insert a string of 7 bits here";            when "011" => HEX0 <= "insert a string of 7 bits here";            when "100" => HEX0 <= "insert a string of 7 bits here";            when "101" => HEX0 <= "insert a string of 7 bits here";            when "110" => HEX0 <= "insert a string of 7 bits here";            when others => HEX0 <= "insert a string of 7 bits here";        end case;  This code describes a CASE statement that is a common way of specifying combinational logic in VHDL (you might have seen CASE or SWITCH statements in software languages).  This block describes how the output signal HEX0 depends SW.    113The first thing to note is that SW is used as a short-form for the collection (or 3-bit bus) of signals SW(2), SW(1), and SW(0).  When we say SW is equal to “011”, we really mean that SW(2) is equal to “0” (the first digit of “011”), SW(1) is equal to “1” (the second digit of “011”), and SW(0) is equal to “1” (the third digit of  “011”).  It is not a mistake that the indices count “down” through the bus (ie. the first digit is the highest numbered or most-significant bit); this is a common design pattern we will talk more about later. Similarly, we use HEX0 to refer to the 7-bit bus consisting of signals HEX0(6) downto HEX0(0).  So, if HEX0=”1000000”, then  HEX0(6) is equal to 1 (the first digit of “1000000”), HEX0(5) is equal to 0 (the second digit of “1000000” and so on).    The second thing to note is the structure of the CASE statement itself.  The first line indicates the selection criteria for this CASE statement (this will become clear in the following discussion).  The remaining lines in the case statement indicate an action that should occur for each value of the selection criteria.  So for example, the first "when" line indicates that when the selection criteria SW is "000", the output HEX0 should be assigned the value "1000000".  If we compare this to the second figure in this handout, we can see that when SW is 000, the output should display a pattern with the middle horizontal segment off, but all other segments on (this looks like a “0” on the display).  Remembering that a segment is “off” when its control line is 1, and “on” when its control line is 0, we can see that the pattern “1000000” will turn off the middle segment (bit HEX0(6)) and turn on all the other segments (bits HEX0(5) through HEX0(0)), causing the display to show a “0”.  Similarly, the second “when” line indicates that the SW is “001”, the output HEX0 should be assigned a value “1111001”.  From the handout figure, this means that bits HEX0(6), HEX0(5), HEX0(4), HEX0(3), and HEX0(0) should be off, while HEX0(2) and HEX0(1) should be on.  This will display a “1” on the display.    The remaining 6 lines in the case statement correspond to each of the other 6 possible values of SW.  Your task is to fill in the value assigned to HEX0 for each of these 6 lines (to be more explicit, replace each string “insert a string of 7 bits here” with 7 bits corresponding to the display pattern for each line).  Remember that each string of 7 bits should be surrounded by quotes, and don’t forget the semicolon at the end of each line.  Note that the selection criteria for the last line is labeled “others” rather than “111”; we’ll talk more about the reasoning behind this later in the course.    Make sure you add your name and student number to the top of the converter.vhd file.  TASK 3:  Using ModelSim, simulate your design (as you learned when you worked through Section 2 of the tutorial document).  The supplied testbench converter_tb.vhd will apply each of the 8 possible input values to the inputs (one value every 5 ns).  Using the waveform viewer, you can determine whether your design is correct.  Note that there are two possible errors you might run into here.  First, if you have made syntax errors, (such as forgetting the quotes or semicolons, or getting the wrong number of digits, for example) you will get error messages saying your design could not be loaded or simulated.  In that case, you won’t be able to view a waveform; you have to fix the syntax error before proceeding.  Once your syntax is correct, and you can simulate your design, it is possible that you see the wrong pattern of 1’s and 0’s in your output waveforms.  In that case, check the assignment statements to make sure you didn’t write in the wrong values of 0’s and 1’s, or didn’t accidently swap the order of bits within a bus.  Once your simulation works, create a bit-mapped image of the simulation as described in the tutorial document.       114PHASE TWO: REAL HARDWARE  In this part of the lab, you will download the circuit you designed earlier on the Altera Cyclone II.  The input and output pins of this FPGA are tied to the various lights and switches and other devices.   TASK 4:  Compile your design using Quartus II and be sure you don’t have any synthesis errors.  If you do, you will need to fix them.  For this lab, it is most likely that any errors would have been uncovered during your ModelSim simulation, however, in future labs, there is a large class of errors that might be encountered here (unsynthesizable code such as “inferred latches”).  If you are getting errors at this point, talk to your TA.  TASK 5:  Read Section 4 of the tutorial document, which describes how to download your design onto the FPGA board.  As described in the tutorial download your 7-segment LED Driver circuit you designed in the preparation.  BE SURE that you set the pin assignments before compiling your design (not doing so could damage the board!).  If you have any questions about how to do this, please talk to the TA.  Be prepared to demonstrate your working design for both TASK 5 and TASK 6 to the TA.  TASK 6:  Extend your design so that it displays 4 different digits. To do this, you will have to add extra outputs for displays HEX3, HEX2, and HEX1 as well as extra inputs for a total of 12 switches. DO NOT SIMPLY COPY YOUR CASE STATEMENT FOUR TIMES! Instead, use design hierarchy to create and connect four instances of the converter component you developed for Task 5.  Be prepared to demonstrate your working design for both TASK 5 and TASK 6 to the TA.   TASK 7 (optional):  If you finish early, play with the software and figure out what else it can do.  One thing you can do is to modify the converter.vhd file so it displays the characters below. Next, you can extend the converter from 3 input switches to 4 input switches, allowing you to display both sets of characters, or you could display the set of 16 hexadecimal characters: 0 1 2 3 4 5 6 7 8 9 A B C D E F. The better you understand the software, the easier you will find the rest of the labs in this course.    000001010011100101110111sw(2 downto 0) Output sw(2 downto 0) Output  115DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING UNIVERSITY OF BRITISH COLUMBIA EECE 353 – Digital Systems Design  Lab 2: Finite State Machines   In this lab, you will create two types of finite state machines (FSMs). The first FSM will be a simple controller for the LCD display on the Altera board. The second FSM will implement the dice game of craps – it has more complex next-state logic than the LCD controller. Both FSMs will be described using VHDL.  PART 1: LCD CONTROLLER  The system you will build will cycle through and display the first five characters of your name.  Each cycle, the LCD will display one character.  The clock comes from pushbutton switch key0.  Every time you depress the switch, another character appears.  So if your name is “Abcde”, the LCD would display an “A” in the first cycle, add a “b” in the second cycle (so the display is "Ab"), add a “c” in the third cycle (so the display is "Abc"), etc.  On the sixth cycle, it would cycle back to “A” and start again.  Each character is displayed to the right of the previous characters, so after 12 cycles (for example), the LCD would display “AbcdeAbcdeAb”.    There is also a reset input; this will be controlled by the pushbutton switch key3.  When this pushbutton switch is lowered, the system resets immediately.  After a reset (and at the start), the state machine takes 6 cycles before starting with the first cycle of your name (this is due to the need to reset the LCD display; this will become clear later).  The following diagram shows the overall system you will build:   Pushbutton switchkey(0)Pushbutton switchkey(3)State MachineresetbclkLCD lcd_rwlcd_onlcd_blon0 1 1lcd_enlcd_datalcd_rs8      116  How to use the LCD:  To do this assignment, you have to know a bit about how the LCD works and how to interface with it.  The LCD has five single-bit control inputs, and one 8-bit wide input bus.  The five control inputs are as follows:   lcd_on : '1' turns the LCD on.  In this lab, this should always be '1'.  lcd_blon : '1' turns the backlight on.  In this lab, this should always be '1'.  lcd_rw : whether you want to read or write to the internal registers.  In this lab, we will    only be writing, meaning this should always be '0'.  lcd_en : this enable signal is used to latch in data and instructions (see below).  lcd_rs :  this tells the LCD the lcd_data bus has characters or instructions (see below).  The 8-bit bus is called lcd_data and is used to send instructions or characters to the LCD display.  You can communicate with the LCD using either instructions (to set the LCD in a certain mode or tell it to do something like clear the display) or using characters (in which case the character is displayed on the screen).  Each cycle, you can send either one instruction or one character on the 8-bit bus.  If you are sending an instruction, the lcd_rs signal should be set to 0, and if you are sending a character, the lcd_rs signal should be set to 1.  The data bus is sampled on the falling edge of the lcd_en signal.  In this lab, we will drive lcd_en with the system clock (which comes from one of the pushbuttons).  It is important to remember that the LCD instruction or character is accepted on the falling edge of this clock (this is different than the state machine, which changes states on the rising edge of the clock).  So, to be clear, to send an instruction or character, you would do the following.  First, lcd_on, lcd_blon, lcd_rw should be fixed as described above.  lcd_en would initially be 1.  You would then drive lcd_rs with a 0 (if you want to send an instruction) or 1 (if you want to send a character).  At the same time, you would drive either the instruction code or character code (either of which is 8 bits) on lcd_data.  Then, lcd_en would drop to 0, and the LCD would either accept and execute the instruction, or accept and display the character.  There are several instructions that the LCD accepts.  This handout will not describe them in detail.  Instead, this handout will indicate a sequence of instructions that will set up the LCD properly.  To set up the LCD, you should send the following instructions, in this order, once per cycle:   00111000  (hex "38")  00001100  (hex "0C")  00000001  (hex "01")  00000110  (hex "06")  10000000  (hex "80")  In fact, the first instruction (00111000) should be sent twice, since depending on how you implement the reset, you might miss the first one.  Therefore, resetting the LCD will require 6 cycles.  If you want to understand what these instructions mean, you can consult the LCD datasheet, which is on the Connect site.  Once you have set up the LCD as described above, you can send characters, one character per cycle.  The following diagram shows the character encoding.   117 Character Code  Character Code  Character Code Binary Hex Binary Hex Binary Hex Space 00100000 20 @ 01000000 40 ` 01100000 60 ! 00100001 21 A 01000001 41 a 01100001 61 " 00100010 22 B 01000010 42 b 01100010 62 # 00100011 23 C 01000011 43 c 01100011 63 $ 00100100 24 D 01000100 44 d 01100100 64 % 00100101 25 E 01000101 45 e 01100101 65 & 00100110 26 F 01000110 46 f 01100110 66 ' 00100111 27 G 01000111 47 g 01100111 67 ( 00101000 28 H 01001000 48 h 01101000 68 ) 00101001 29 I 01001001 49 i 01101001 69 * 00101010 2A J 01001010 4A j 01101010 6A + 00101011 2B K 01001011 4B k 01101011 6B , 00101100 2C L 01001100 4C l 01101100 6C - 00101101 2D M 01001101 4D m 01101101 6D . 00101110 2E N 01001110 4E n 01101110 6E / 00101111 2F O 01001111 4F o 01101111 6F 0 00110000 30 P 01010000 50 p 01110000 70 1 00110001 31 Q 01010001 51 q 01110001 71 2 00110010 32 R 01010010 52 r 01110010 72 3 00110011 33 S 01010011 53 s 01110011 73 4 00110100 34 T 01010100 54 t 01110100 74 5 00110101 35 U 01010101 55 u 01110101 75 6 00110110 36 V 01010110 56 v 01110110 76 7 00110111 37 W 01010111 57 w 01110111 77 8 00111000 38 X 01011000 58 x 01111000 78 9 00111001 39 Y 01011001 59 y 01111001 79 : 00111010 3A Z 01011010 5A z 01111010 7A ; 00111011 3B [ 01011011 5B ( 01111011 7B < 00111100 3C ¥ 01011100 5C | 01111100 7C = 00111101 3D ] 01011101 5D ) 01111101 7D > 00111110 3E ^ 01011110 5E → 01111110 7E ? 00111111 3F _ 01011111 5F ← 01111111 7F   So, for example, if you wanted to display an "a", you would send 01100001 on the lcd_data bus.  Note that the table above includes both binary and hexadecimal (base-16) for each code; computer engineers like to talk in hexadecimal, since it is more convenient than binary.  Other characters are available, and you can even design your own characters.  See the datasheet on the web site if you want more information.  There are stringent timing requirements that must be met using the LCD.  However, in this lab, we are using the pushbutton switch as a clock, and it is not possible for you to push the button so fast that you are in danger of violating any of these minimum times.  All that matters for this lab is that you need to make sure that the control lines are steady when the clock (led_en) switches from high to low.  If you want more information on the LCD, see the datasheet on Connect.   Design a state machine to implement the circuit as described on the first page of this handout.  The state diagram might be something like this (if your name is "Steve"):  118 Send x38Send x38Send x0CSend x01Send x06Send x80Send 'S'Send  't'Send 'e'Send 'v'Send 'e'resetb(asynchronous)   Upon reset, the state machine cycles through the first six states regardless of the input.  The reset is asynchronous; review the course notes to make sure you remember what this means.  The reset is also active low, meaning that a "0" means reset, and a "1" means normal operation (this makes it easier to use the pushbutton switch).  The state machine is positive-edge triggered; this means that the transition from one state to the next occurs on the rising edge of the clock.  The outputs of the state machine are the signals lcd_rs and lcd_data; given the discussion on the previous pages, you should be able to figure out what should be driven on these signals each cycle.  Note that this is a Moore state machine, meaning the output depends only on the current state.  Simulate your design using ModelSim, and make sure that it works as expected, before coming into the lab.  A very simple testbench is provided on Connect.  This testbench resets the system, and toggles the clock.   The clock cycle in this testbench is set to 6 ns, so I would suggest selecting a run-time length of 80 ns to ensure you see all the state transitions.  Don’t forget to Zoom Full to see the whole thing, however, you’ll probably have to Zoom in to see enough detail to convince you it is working.  Manually observe the waveform and make sure it matches what you expect.  Hint: Earlier I mentioned that the LCD accepts data on the falling edge of the clock.  Don't be confused.  In the state machine you design here, the state changes (and hence output changes) all happen on the rising clock edge.  This is a normal state machine, just like we discuss in class.    Testing on the DE2  1. Download the circuit you designed onto your DE2 board.  Again, remember to use the pin assignments file from Lab 1.  Cycle through the states and show that it operates as expected.  Test the reset button to make sure that works too.  You will probably find it easier to see what is going on by wiring the state bits (probably called something like "present_state" or "current_state" in your VHDL code) to the green LEDs so you can easily see what state you are in.  Interestingly, this highlights a fundamental limitation of debugging directly on hardware -- you can not automatically see any of the internal signals unless you have manually connected them to an output before compilation.  2. Be prepared to demonstrate a working LCD design to the TA in the lab during marking. The TA may ask you to make small changes to your VHDL code. You may wish to make the modification in either ModelSim or Quartus II, but you will need to demonstrate the working design on the DE2 board to earn full performance marks.  Note that the TA will ask to see your code, and will ask questions about it.  You should be able to answer these questions to get full marks.  119PART 2: CRAPS DICE GAME  You will build a game controller craps.vhd and two types of 7-segment display converters to play the dice game of craps. The dice.vhd module is provided to you. Game play is described below.   1. Initially, display the initial dice values as ‘--’ on the 7-segment displays. Light up LEDR0 to indicate the user can press the play button to roll the dice. 2. The player is making his first roll. He presses key0 to roll both dice, with values 1 to 6 of each die appearing on HEX1 and HEX0 and the total appearing on HEX5 and HEX4. When key0 is released, evaluate the total of the two dice as follows: a. If the player rolls a 7 or 11, the player wins. Light up the green LEDs and go to step 4. b. If the player rolls a 2, 3 or 12, the player loses. Light up red LEDs(17..1) and go to step 4. c. Since this is the first roll for the player, the total value of the dice is the new target to match. Display this matching value on HEX7 and HEX6. Light up LEDR0 to indicate roll again, and go to step 3. 3. The player is now on his second or further rolls. Like step 2, the player presses key0 to roll both dice, display the dice values and their total on HEX3 to HEX0. When key0 is released, evaluate the total of the two dice as follows: a. If the player rolls a 7, the player wins. Light up the green LEDs and go to step 4. b. If the player total matches the target value memorized from step 2, the player wins. Light up the green LEDs and go to step 4. c. Otherwise, the player has neither won nor lost but must roll again. Light up LEDR0 to indicate roll again and restart this step. 4. The game is over. Be sure to keep indicating win or lose using the red or green LEDs, and leave the last dice, total, and match values so the user can confirm the win or loss. Further presses of key0 should not change the LEDs or 7-segment displays. LEDR0 should be off. The player must press key3 to reset the game and return to step 1.  This part is much harder than it appears. Start early. You will have to practice getting everything right with clocks, sensitivity lists, reset, and gameplay. On Connect, we are providing a golden solution in craps00.sof which you can download to your board. Your solution must match the gameplay of this solution exactly; if you are not sure how something should work, try it out. Note: if we have to correct the golden solution, we will increment the filename, Thus, craps01.sof will be the next version.    LEDG(7 to 0)LEDR(17 to 1)HEX0HEX1conv-erterconv-erterLEDR0WIN LOSE ROLLAGAIN DIE1 DIE07 74 3 38 17craps4CLOCK_50 KEY(3) KEY(0)RESETb PLAYread_dicediceCLOCK_50totaldie1die0totalwinloseroll_againresetbplayresetbHEX4HEX5converter2TOTAL7 7HEX6HEX7converter2MATCH7 74match120D.2 2014 Cohort121DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING UNIVERSITY OF BRITISH COLUMBIA EECE 353 – Digital Systems Design  Lab 2: Finite State Machines   In this lab, you will create two types of finite state machines (FSMs). The first FSM will be a simple controller for the LCD display on the Altera board. The second FSM will fill the VGA screen with colours using a VGA controller. Both FSMs will be described using VHDL.  WEEK 1: LCD CONTROLLER  The first system you will build will cycle through and display the first five characters of your name.  Each cycle, the LCD will display one character.  The clock comes from pushbutton switch key0.  Every time you depress the switch, another character appears.  So if your name is “Abcde”, the LCD would display an “A” in the first cycle, add a “b” in the second cycle (so the display is "Ab"), add a “c” in the third cycle (so the display is "Abc"), etc.  On the sixth cycle, it would cycle back to “A” and start again.  Each character is displayed to the right of the previous characters, so after 12 cycles (for example), the LCD would display “AbcdeAbcdeAb”.    There is also a reset input; this will be controlled by the pushbutton switch key3.  When this pushbutton switch is lowered, the system resets immediately.  After a reset (and at the start), the state machine takes 6 cycles before starting with the first cycle of your name (this is due to the need to reset the LCD display; this will become clear later).  The following diagram shows the overall system you will build:   Pushbutton switchkey(0)Pushbutton switchkey(3)State MachineresetbclkLCD lcd_rwlcd_onlcd_blon0 1 1lcd_enlcd_datalcd_rs8       122 How to use the LCD:  To do this assignment, you have to know a bit about how the LCD works and how to interface with it.  The LCD has five single-bit control inputs, and one 8-bit wide input bus.  The five control inputs are as follows:   lcd_on : '1' turns the LCD on.  In this lab, this should always be '1'.  lcd_blon : '1' turns the backlight on.  In this lab, this should always be '1'.  lcd_rw : whether you want to read or write to the internal registers.  In this lab, we will    only be writing, meaning this should always be '0'.  lcd_en : this enable signal is used to latch in data and instructions (see below).  lcd_rs :  this tells the LCD the lcd_data bus has characters or instructions (see below).  The 8-bit bus is called lcd_data and is used to send instructions or characters to the LCD display.  You can communicate with the LCD using either instructions (to set the LCD in a certain mode or tell it to do something like clear the display) or using characters (in which case the character is displayed on the screen).  Each cycle, you can send either one instruction or one character on the 8-bit bus.  If you are sending an instruction, the lcd_rs signal should be set to 0, and if you are sending a character, the lcd_rs signal should be set to 1.  The data bus is sampled on the falling edge of the lcd_en signal.  In this lab, we will drive lcd_en with the system clock (which comes from one of the pushbuttons).  It is important to remember that the LCD instruction or character is accepted on the falling edge of this clock (this is different than the state machine, which changes states on the rising edge of the clock).  So, to be clear, to send an instruction or character, you would do the following.  First, lcd_on, lcd_blon, lcd_rw should be fixed as described above.  lcd_en would initially be 1.  You would then drive lcd_rs with a 0 (if you want to send an instruction) or 1 (if you want to send a character).  At the same time, you would drive either the instruction code or character code (either of which is 8 bits) on lcd_data.  Then, lcd_en would drop to 0, and the LCD would either accept and execute the instruction, or accept and display the character.  There are several instructions that the LCD accepts.  This handout will not describe them in detail.  Instead, this handout will indicate a sequence of instructions that will set up the LCD properly.  To set up the LCD, you should send the following instructions, in this order, once per cycle:   00111000  (hex "38")  00001100  (hex "0C")  00000001  (hex "01")  00000110  (hex "06")  10000000  (hex "80")  In fact, the first instruction (00111000) should be sent twice, since depending on how you implement the reset, you might miss the first one.  Therefore, resetting the LCD will require 6 cycles.  If you want to understand what these instructions mean, you can consult the LCD datasheet, which is on the Connect site.  Once you have set up the LCD as described above, you can send characters, one character per cycle.  The following diagram shows the character encoding.    123Character Code  Character Code  Character Code Binary Hex Binary Hex Binary Hex Space 00100000 20 @ 01000000 40 ` 01100000 60 ! 00100001 21 A 01000001 41 a 01100001 61 " 00100010 22 B 01000010 42 b 01100010 62 # 00100011 23 C 01000011 43 c 01100011 63 $ 00100100 24 D 01000100 44 d 01100100 64 % 00100101 25 E 01000101 45 e 01100101 65 & 00100110 26 F 01000110 46 f 01100110 66 ' 00100111 27 G 01000111 47 g 01100111 67 ( 00101000 28 H 01001000 48 h 01101000 68 ) 00101001 29 I 01001001 49 i 01101001 69 * 00101010 2A J 01001010 4A j 01101010 6A + 00101011 2B K 01001011 4B k 01101011 6B , 00101100 2C L 01001100 4C l 01101100 6C - 00101101 2D M 01001101 4D m 01101101 6D . 00101110 2E N 01001110 4E n 01101110 6E / 00101111 2F O 01001111 4F o 01101111 6F 0 00110000 30 P 01010000 50 p 01110000 70 1 00110001 31 Q 01010001 51 q 01110001 71 2 00110010 32 R 01010010 52 r 01110010 72 3 00110011 33 S 01010011 53 s 01110011 73 4 00110100 34 T 01010100 54 t 01110100 74 5 00110101 35 U 01010101 55 u 01110101 75 6 00110110 36 V 01010110 56 v 01110110 76 7 00110111 37 W 01010111 57 w 01110111 77 8 00111000 38 X 01011000 58 x 01111000 78 9 00111001 39 Y 01011001 59 y 01111001 79 : 00111010 3A Z 01011010 5A z 01111010 7A ; 00111011 3B [ 01011011 5B ( 01111011 7B < 00111100 3C ¥ 01011100 5C | 01111100 7C = 00111101 3D ] 01011101 5D ) 01111101 7D > 00111110 3E ^ 01011110 5E → 01111110 7E ? 00111111 3F _ 01011111 5F ← 01111111 7F   So, for example, if you wanted to display an "a", you would send 01100001 on the lcd_data bus.  Note that the table above includes both binary and hexadecimal (base-16) for each code; computer engineers like to talk in hexadecimal, since it is more convenient than binary.  Other characters are available, and you can even design your own characters.  See the datasheet on the web site if you want more information.  There are stringent timing requirements that must be met using the LCD.  However, in this lab, we are using the pushbutton switch as a clock, and it is not possible for you to push the button so fast that you are in danger of violating any of these minimum times.  All that matters for this lab is that you need to make sure that the control lines are steady when the clock (led_en) switches from high to low.  If you want more information on the LCD, see the datasheet on Connect.   Design a state machine to implement the circuit as described on the first page of this handout.  The state diagram might be something like this (if your name is "Steve"):   124Send x38Send x38Send x0CSend x01Send x06Send x80Send 'S'Send  't'Send 'e'Send 'v'Send 'e'resetb(asynchronous)   Upon reset, the state machine cycles through the first six states regardless of the input.  The reset is asynchronous; review the course notes to make sure you remember what this means.  The reset is also active low, meaning that a "0" means reset, and a "1" means normal operation (this makes it easier to use the pushbutton switch).  The state machine is positive-edge triggered; this means that the transition from one state to the next occurs on the rising edge of the clock.  The outputs of the state machine are the signals lcd_rs and lcd_data; given the discussion on the previous pages, you should be able to figure out what should be driven on these signals each cycle.  Note that this is a Moore state machine, meaning the output depends only on the current state.  Simulate your design using ModelSim, and make sure that it works as expected, before coming into the lab.  A very simple testbench is provided on Connect.  This testbench resets the system, and toggles the clock.   The clock cycle in this testbench is set to 6 ns, so I would suggest selecting a run-time length of 80 ns to ensure you see all the state transitions.  Don’t forget to Zoom Full to see the whole thing, however, you’ll probably have to Zoom in to see enough detail to convince you it is working.  Manually observe the waveform and make sure it matches what you expect.  Hint: Earlier I mentioned that the LCD accepts data on the falling edge of the clock.  Don't be confused.  In the state machine you design here, the state changes (and hence output changes) all happen on the rising clock edge.  This is a normal state machine, just like we discuss in class.    Testing on the DE2  1. Download the circuit you designed onto your DE2 board.  Again, remember to use the pin assignments file from Lab 1.  Cycle through the states and show that it operates as expected.  Test the reset button to make sure that works too.  You will probably find it easier to see what is going on by wiring the state bits (probably called something like "present_state" or "current_state" in your VHDL code) to the green LEDs so you can easily see what state you are in.  Interestingly, this highlights a fundamental limitation of debugging directly on hardware -- you can not automatically see any of the internal signals unless you have manually connected them to an output before compilation.  2. In the first week, you must get the LCD controller fully working. The TA will give you up to 5 marks for the correct operation of your LCD controller.     125WEEK 2: VGA CONTROLLER  In this part of the lab, you will get more experience creating state machines.  Compared to Week 1, the FSM you will implement will be slightly more complex.  You will also learn how to use an embedded components that we will give you; this is common practice in industrial design – taking predesigned components that are either purchased or written by another group and incorporating them into your own design.   The embedded component we will give you is a VGA Adapter core, which continuously draws to a VGA screen. You will design a VGA PixelWriter. It tells the VGA Adapter core to change the colour of specific pixels. Together, the PixelWriter and Adapter Core form the VGA Controller.  Note: those of you taking EECE 381 – in that course, you are using C software to write to a VGA display.  This is fundamentally different, since here you will use hardware to interface to a very different sort of VGA core.  If you are not taking EECE 381 don’t worry, this is different enough that you are not at a disadvantage.  The top level diagram of your lab, lab2vga.vhd , is as follows.  The VGA Adapter core is the part given to you, so all the excitement will be in the block labeled “your circuit”.  This handout first explains how to use the VGA Adapter core, and then specifies what your circuit should do.  Top Level Design - lab4.vhdYour circuitVGA CoreVGA_RVGA_GVGA_BVGA_HSVGA_VSVGA_CLKVGA_BLANKVGA_SYNCcolour(2..0)x(7..0)y(7..0)plotresetnclockKEY(3)CLOCK_50KEY(0) To VGASW(17..3) Figure 1: Overall block diagram. The top-level file is lab2vga.vhd.   Task 1:  Understand the VGA Adapter Core  The VGA Adapter core was created at the University of Toronto for a course similar to EECE 353.  The following describes enough for you to use the core; more details can be found on University of Toronto’s web page: http://www.eecg.utoronto.ca/~jayar/ece241_07F/vga       Some of the following figures have been taken from that website (with permission!).  In order to save on the limited memory on DE2 board, the VGA Adapter core has been setup to display a grid of 160x120 pixels, with the interface shown in Figure 2:  126Outputs To DAC & Monitor (You do not need to control these) Inputs From your circuit (You will be working with these)   Figure 2: VGA Adapter core as a black box Inputs: Resetn Active low reset signal.  Digital circuits with state elements should always contain a reset. Clock Clock signal. The VGA Adapter core must be fed with a 50MHz clock to function correctly. colour(2 downto 0) Pixel colour (3 bits). Sets the colour of the pixel to be drawn. The three bits indicate the presence of Red, Green and Blue components for a total of 8 colour combinations. x(7 downto 0) X coordinate of pixel to be drawn (8 bits) – supported values 0 ≤ x < 160. y(6 downto 0) Y coordinate of pixel to be drawn (7 bits) – supported values 0 ≤ x < 120. Plot Active high plot signal. Raise this signal to cause the pixel at (x,y) to be set to the specified colour on the next rising clock edge. Outputs:  VGA_CLK VGA clock signal.  VGA_R(9 downto 0) VGA_G(9 downto 0) VGA_B(9 downto 0) Red, Green, Blue components of display (10 bits). These signals are connected to the Digital-to-Analog Converter (DAC) on the DE2 board before transmitting to the monitor. VGA_HS VGA_VS VGA_SYNC VGA_BLANK VGA control signals.    Note that you will connect the outputs of the VGA Adapter core directly to appropriate output pins of the FPGA.  You can picture the VGA screen as a grid of pixels shown in Figure 3. The X/Y position (0,0) is located on the top-left corner and (159,119) pixel located at the bottom-right corner. The role of the VGA Adapter core is to continuously draw the same thing on the screen at a regular rate, eg 60 Hz. To do this, it has an internal memory that stores the colour of each pixel. Your VGA PixelWriter will write new pixel colours to the VGA Adapter core, such that on the next screen refresh it will display a slightly different screen.  127 Figure 3: VGA Adapter core’s display grid   To set the colour of a pixel, you drive the x input with the x position of the pixel, drive the y input with the y position of the pixel, and colour with the colour you wish to use.  You then raise input plot.  At the next rising clock edge, the pixel colour is accepted by the VGA Adapter core’s memory. Starting on the next screen redraw, the pixel will take on the new colour.  In the following timing diagram (from the UofT Website), two pixels are changed: one at (15, 62) and the other at (109,12).  As you can see, the fix pixel drawn is red and is placed at (15, 62). The second is a yellow pixel at (109, 12).  It is important to note that, at most, one pixel can be changed on each cycle.  Thus, if you want to change the colour of m pixels, you need m cycles.    Figure 4: Timing Diagram   The source code for the VGA Adapter core consists of multiple files and is provided on the EECE 353 Connect site.  This core is written in Verilog, not VHDL.  That is ok: when making a structural description, you can include Verilog modules just as you can VHDL modules (this “mixed language” design approach is common in industry).  The Verilog files describing the VGA Adapter core can be included into Altera Quartus II project just like the VHDL files. If you read them, you would notice that the “module” definition in Verilog is similar to “entity” in VHDL. This means you can instantiate modules in the Verilog files as components in your VHDL files.     128Task 1:  Get VGA Adapter Core to Work  To help you understand the VGA Adapter core, we have created a vga_demo.vhd file. This file does nothing but connect the VGA Adapter core I/O to switches so you can experiment.  We suggest you download this file, understand it, and try it out. It will you understand how the inputs of the core work.    Note that this file is only used for you to understand the core; you will not use it when constructing your circuit for this lab. This task is not worth any marks, but you should do it to ensure that everything else is working before starting the main task below.  Task 2:  Fill the Screen  You will create a new component that acts as a VGA PixelWriter. It will contain a simple FSM to fill the screen with colours. This is done by writing to one pixel at a time in the VGA Adapter core.  Each row will be set to a different colour (repeating every 8 rows).  Since you can only set one pixel at a time, you will need a FSM that does something like this:    for y = 0 to 119 {    for x = 0 to 159 {     set pixel (x, y) to colour ( y mod 8)     }   }  Create an FSM that implements the above algorithm.  The top-level file lab2vga.vhd is available on the Connect site.  Your design should have an asynchronous reset which will be driven by KEY(3).  You don’t need to use KEY(0) or any of the switches in this task.  Note that your circuit will be clocked by CLOCK_50 (this is different than week 1, where you were clocking using a key).  Test your design on the DE2.  You need your DE2 board with a USB cable, a VGA cable, and a VGA-capable display.  In the MCLD358 lab, a VGA cable and LCD display are provided.  Download the lab 4 files containing: vga_adapter.v, vga_controller.v, vga_address_translator.v and vga_demo.vhd from the Connect site.  Add these files to a new Quartus II project, import your pin assignments, then compile and program the design onto your DE2 board.    Use the VGA cable to connect your DE2 board to the VGA display. Most new LCD displays have multiple inputs, including DVI (digital) and VGA (analog). The LCD displays in MCLD358 use the DVI input for the PC, while the VGA input is connected to a VGA cable for you to use. You can switch between the inputs using the display’s input select button.  Note: the VGA connection on your laptop is an OUTPUT, so do not connect your laptop’s VGA port to your DE2 board.  Hint: Modelsim will be very useful for debugging. Start by looking at your x and y counters.  Task 3:  Challenge Circuit  Modify your circuit to draw a 4x4 square at an <x,y> location specified by the switches. When the switches change, erase the whole screen (draw it black), then draw the square.  Technical grading: 2 marks (setting colour of 1 or more lines, single colour)   2 marks (setting entire screen colour, varying colours)   1 mark (challenge circuit) 129EECE 353 – Lab 3 1 University of British Columbia Electrical and Computer Engineering EECE 353  Laboratory 3 - Digital Systems Design  Learning Objectives 1. Design a non-trivial finite state machine and express it in VHDL. 2. Build complex combinational functions in VHDL. 3. Generate random numbers in hardware. 4. Interact with a clock.  Abstract In this lab, you will design a one-player Blackjack card game using your DE2 board. The main part will be a complex FSM used to control the sequence of dealing cards to one player and the dealer. You will also develop a combinational function to drive the 7-segment display to indicate Jack, Queen, King and Ace cards, and a combinational function to count the value of a hand, where Aces can be either 1 or 11. As well, you will have a sequential part that determines the next card to be drawn. To solve this problem, you will use a variety of techniques in programming with VHDL: FSMs, combinational logic, and variables.  Organization You will create a single design, consisting of multiple VHDL files. The top-level filename you must use is blackjack.vhd, with lower-level entities organized as described below.   The top-level file will be provided to you. You must create the other files. A block diagram of the top-level design, which will be created inside blackjack.vhd, is shown below. BlackJack.vhdDataPath.vhd FSM.vhdCard7Seg.vhdScoreHand.vhdDealCard.vhd 130EECE 353 – Lab 3 2   Requirements The functional specification of the lab requirements is as follows: 1. Each card is represented by a 4-bit value. Ignore suites (hearts, diamonds, clubs, spades). Each value indicates: • 0 is “no card” • 2 through 10 are themselves • 1 is Ace, 11 is Jack, 12 is Queen, and 13 is King • 14, 15 are not used 2. The dealer and player can each hold a hand of up to 4 cards. No more than 4 cards are allowed per player. To remember an entire hand, you will need 16 bits. You will need separate register memories for both player and dealer hands. 3. Display the cards in a hand on the 7-segment display. At all times: • Hex3-Hex0:  display the player hand • Hex7-Hex4:  display the dealer hand 4. Each card is a 4-digit number that is displayed as a singe digit on the 7-segment display. Write card7seg.vhd to convert a 4-bit card value into an appropriate LED display pattern as follows: • The value 0 is “no card” and should be displayed as a blank (all LEDs off) • Ace as “A”, 10 as “0”, Jack as “J”, Queen as “q”, and King as “H” • 2 through 9 as themselves, making sure the numeral 9 appears differently than “q” 5. As a player, during your turn you can request either “hit” for another card, or “stand” for no more cards. Card7Seg7HEX3Card7Seg7HEX2Card7Seg7HEX1Card7Seg7HEX0Card7Seg7HEX7Card7Seg7HEX6Card7Seg7HEX5Card7Seg7HEX4PlayerHand:DealerHand:DataPathFSM16 164 4 4 44 4 4 4playerCards dealerCardsnewPlayerCard4newDealerCard4dealerStands dealerWins playerWins dealerBust playerBustredLED greenLEDclockresetnextStepclockresetplayerStands131EECE 353 – Lab 3 3 • SW0 = ‘0’ indicates “hit”. SW0 = ‘1’ indicates “stand”. 6. The dealer must always follow the house rules (regardless of the player’s hand): • If the current dealer hand totals 16 or less, the dealer takes another card • If the current dealer hand totals 17 or more, the dealer stands 7. Counting a hand is done in scorehand.vhd. You will need two instances of this component, one to count the dealer hand and one to count the player hand. This component takes a complete hand (16-bit value) as inputs, counts the cards, and produces a 5-bit total for the output. There are two additional 1-bit outputs: “stand” indicates the hand >= 17, and “bust” indicates the hand > 21. This routine must be written entirely in combinational logic (with no clock). To simplify things, the use of VARIABLE types is suggested. When counting, use a larger number of bits internally (6 bits is enough to represent the maximum possible sum of 44), but the final result should be reduced to 5 bits. Remember than each Ace takes on the value of ‘1’ or ‘11’, as needed, to give the maximum possible hand value that is still less than or equal to 21. The logic for counting is complex, so make sure you give yourself enough time to think about it and do plenty of testing! The use of a testbench and ModelSim is strongly encouraged. • The Jack, Queen, and King each represent a value of 10. • Each Ace represents the value of 11 or 1, individually as needed, to give a maximum possible hand total value that is less than or equal to 21. • If the final total hand value is >= 17, the stand output should be ‘1’. • If the final total hand value > 21, the hand is bust. In this case, force the hand value to 31 (all outputs will be ‘1’; this helps simplify testing if you are displaying on LEDs). 8. All of your sequential logic (FSMs, registers) must use CLOCK_50 as the only clock. Use KEY0 as a combinational input where pressing the key tells the game to take the “next step”. As KEY0 is pressed, the game makes forward progress. Your FSM may sequence through several states (clock cycles) to accomplish the current step, and then pause until the user presses KEY0 again. Usually, KEY0 means a new card will be given out (either to the dealer or the player). Hint: You may find it easier to design a small FSM that waits for KEY0 to go from 1 to 0, and in response emits a pulse that is only a single clock cycle wide. 9. The required sequence of steps are: a. Start. Give player a card. b. Give dealer a card. c. Give player a second card. If player stands, go to DealersTurn. d. Give player a third card. If player stands, or goes bust, go to DealersTurn. e. Give player a fourth card. f. DealersTurn. Give dealer a second card. If dealer stands, go to Winner. g. Give dealer a third card. If dealer stands, or goes bust, go to Winner. h. Give dealer a fourth card. i. Winner. Decide winner: • If both go bust, there is no winner, go to EndGame. • If dealer >= player, or player is bust, go to DealerWins. • If dealer <   player, or dealer is bust, go to PlayerWins. j. DealerWins. Turn on LEDR[17:0]. Go to EndGame. k. PlayerWins. Turn on LEDG[7:0]. Go to EndGame. l. EndGame. Wait forever. 132EECE 353 – Lab 3 4 10. To give the dealer or player a new random card, we will use a few simple tricks. First, assume we are dealing from an infinite deck, so it is equally likely to generate any card, no matter which cards have already been given out. Second, assume that when the player presses the “next step” key, an unpredictable amount of time has passed, representing a random delay. During this random delay interval, your dealcard.vhd should be continuously counting from the first card (Ace=1) to the last card (King=13), and then wrapping around to Ace=1 at a very high rate (eg, 50MHz). To obtain a random card, we simply sample the current value of this counter during one clock cycle after a random delay, ie when the user presses “next step”. 11. Use KEY3 to reset the game and go to Start at any point.  DO NOT USE KEY0 AS A CLOCK SIGNAL! Your design must use only CLOCK_50 as the clock that controls all memory elements and advances you from state to state. You will lose marks if you do not follow this instruction.   Week 1 Tasks During your first week, you will get marks as follows: • Datapath Part (3 marks) o 1 mark for creation and testing of card7seg.vhd o 1 mark for creation and testing of dealcard.vhd o 1 mark for creation and testing of a simple version of scorehand.vhd, where you assume an Ace=10/Jack=11/Queen=12/King=13. • FSM Part (2 marks) o 2 marks for creation and testing of a simple version of fsm.vhd that deals only 2 random cards per player. The simple FSM should not worry about a winner, or a hand going bust. It must wait for KEY0 to be pressed once to deal each card, otherwise you will not get a random card. It should also respond to KEY3, which will reset the game. Note: to simplify TA marking, please do exactly as requested.  Week 2 Tasks The changes from Week 1 should be obvious, but to highlight the requirements once more: • (2 marks) Complete scorehand.vhd to treat Jack/Queen/King all as 10 and its treatment of each Ace to be either 1 or 11, as required, to get a maximum score of 21 without going bust. Note that a hand containing two Aces could treat one Ace=1 and another Ace=11 to get a perfect score of 21, whereas a hand with two Aces and a 10 would treat both Ace=1 to get a score of 12. • (1 mark) Create datapath.vhd and integrate the multiple components together. Test it. • (2 marks) Create the full fsm.vhd and test it.  Sample Design and Testing Process Develop your solution by breaking it down piecewise. Build a small, simple piece and test it. Continue building and testing each piece one-by-one as you go along (do not leave all testing until the end!). 1. Inside blackjack.vhd, connect one instance of card7seg.vhd to SW[3:0] and HEX0. Write the decoder in card7seg.vhd. Compile and test for all card values. 133EECE 353 – Lab 3 5 2. Create datapath.vhd and connect it inside blackjack.vhd to the card7seg.vhd components. 3. Create dealcard.vhd to continuously shuffle the deck and provide a new card every clock cycle on its output. Include it in datapath.vhd to deal one new card and display it on HEX0 every time you press KEY0. Repeating KEY0 presses should give a random card sequence. 4. Write a simplified scorehand.vhd by treating Ace/Jack/Queen/King as 10/11/12/13 (this is to keep things simple at first; you will fix it later). At first, connect it to sixteen switches SW[15:0] and verify that it works as expected. While testing, continuously display the player’s hand on HEX[3:0], and the hand total on LEDR[4:0]. 5. Modify blackjack.vhd to add the simple FSM. Create the simple fsm.vhd, having it build dealer and player hands of 2 cards each. Display both hands on 7-segment displays. Display the score of the player and dealer hands on LEDR[4:0] and LEDG[4:0]. Compile and test. Completing the above is sufficient for week 1. 6. Modify scorehand.vhd to count Jack, Queen, and King as 10. If hand total exceeds 21, force hand total to be 31. Calculate “stand” and “bust” outputs; for testing this step only, temporarily display “stand” and “bust” on any green LED. Compile and test. 7. Modify datapath.vhd and/or fsm.vhd to use newPlayerCard[3:0] and newDealerCard[3:0] control signals. These signals indicate when each card should be sampled from dealcard.vhd 8. Modify blackjack.vhd and/or fsm.vhd to calculate and display the winner, reset the hands, and restart. Indicate the winner as required using LEDG. Compile and test. 9. Modify blackjack.vhd and/or fsm.vhd, checking “stand” and “bust” for player and dealer. The player’s “stand” signal comes from SW0, the dealer’s comes from scorehand.vhd. Compile and test. 10. Modify scorehand.vhd to count Ace as 11 or 1, as required. 11. Make sure all requirements are met.  Lab Demonstration Demonstrate your BlackJack game to the TA. A golden solution will be provided so you can verify the instructions above – your solution should behave exactly the same.  VHDL Specifications Use the top-level input/output specifications below. Do not add or remove any signals.  COMPONENT BLACKJACK IS  PORT(   CLOCK_50 : in std_logic;                  -- A 50MHz clock      SW   : in  std_logic_vector(17 downto 0); -- SW(0) = player stands   KEY  : in  std_logic_vector(3 downto 0);  -- KEY(3) reset, KEY(0) advance      LEDR : out std_logic_vector(17 downto 0); -- red LEDs: dealer wins      LEDG : out std_logic_vector(7 downto 0);  -- green LEDs: player wins       HEX7 : out std_logic_vector(6 downto 0);  -- dealer: fourth card      HEX6 : out std_logic_vector(6 downto 0);  -- dealer: third card      HEX5 : out std_logic_vector(6 downto 0);  -- dealer: second card      HEX4 : out std_logic_vector(6 downto 0)   -- dealer: first card       HEX3 : out std_logic_vector(6 downto 0);  -- player: fourth card      HEX2 : out std_logic_vector(6 downto 0);  -- player: third card      HEX1 : out std_logic_vector(6 downto 0);  -- player: second card      HEX0 : out std_logic_vector(6 downto 0)   -- player: first card ); END; 134  DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING UNIVERSITY OF BRITISH COLUMBIA EECE 353 – Digital Systems Design  Lab 4: VGA Controller / Drawing Lines   In this lab, you will will be designing your own hardware to draw lines on the VGA screen. To get started, you will use the VGA Adapter Core from Lab 2. To add the line-drawing algorithm, you will get more experience creating datapaths and state machines than you did in Lab 3.  The top level diagram of your lab is identical to the one from Lab 2.  The VGA Adapter Core is the part given to you, so all the excitement will be in the block labeled “your circuit”. Please review Lab 2. Top Level Design - lab4.vhdYour circuitVGA CoreVGA_RVGA_GVGA_BVGA_HSVGA_VSVGA_CLKVGA_BLANKVGA_SYNCcolour(2..0)x(7..0)y(7..0)plotresetnclockKEY(3)CLOCK_50KEY(0) To VGASW(17..3) Figure 1: Overall block diagram. The top-level file is lab4vga.vhd.  Week 1:  Simple Line Algorithm  The Simple Line algorithm draws a diagonal line across the screen.  The basic algorithm is as follows  function line()  dx := 0  dy := 0  loop   setPixel(x0,y0)   if x0 < 160 then    x0 := x0 + dx   end if   if y0 < 120 then    y0 := y0 + dy   end if  end loop end function  In the algorithm above, the setPixel() step will visit a pixel and change its colour. The setPixel() function is only called exactly once per pixel on the line (no more, no less).  135Week 2:  Bresenham Line Algorithm  The Bresenham Line algorithm is a hardware (or software!) friendly algorithm to draw lines between arbitrary points on the screen.  The basic algorithm is as follows (taken from Wikipedia):  function line(x0, y0, x1, y1)  dx := abs(x1-x0)  dy := abs(y1-y0)  if x0 < x1 then sx := 1 else sx := -1  if y0 < y1 then sy := 1 else sy := -1  err := dx-dy  loop   setPixel(x0,y0)   if x0 = x1 and y0 = y1 exit loop   e2 := 2*err   if e2 > -dy then    err := err – dy    x0 := x0 + sx   end if   if e2 < dx then    err := err + dx    y0 := y0 + sy   end if  end loop end function  The algorithm is efficient: it contains no multiplication or division, and the setPixel() function is only called exactly once per pixel on the line (no more, no less).  Your circuit must behave as follows.  1. The switch KEY(3) is an asynchronous reset.  When the machine is reset, it will start clearing the screen (hint: the circuit from Lab 2 can be used to clear the screen by changing the colour of each pixel to Black).  Of course, clearing the screen will take at least 160*120 cycles.   2. WEEK1: Once the screen is cleared, initialize the <x0> and <y0> values to 0.  3. WEEK2: Once the screen is cleared, the user will set switches 17 downto 3 to indicate a point on the screen, and switches 2 downto 0 to indicate a colour.  Specifically, SW(17 downto 10) will be used to encode the x coordinate of the point and SW(9 downto 3) will encode the y coordinate of the point.  Finally, SW(2 downto 0) will indicate one of 8 possible colours used to draw the line.  4. When the user presses KEY(0), the circuit will draw a line. For WEEK 1, draw the diagonal. For WEEK 2, draw from the centre of the screen (location 80,60) to the position specified by the user.  Of course, this will take multiple cycles; the number of cycles depends on the length of the line.  5. WEEK 2: Once the line is done, the circuit will go back to step 3, allowing the user to choose another point.  Note that the screen is not cleared between iterations.  At any time user can press KEY(3), the asynchronous reset, to go back to the start and clear the screen.  It is important to note that you are using CLOCK_50, the 50MHz clock, to clock your circuit.  Unlike Lab 3, we are not designing the datapath or FSM for you here.  You must clearly distinguish the datapath from the FSM in your VHDL code.  136  Challenge Circuit:  (1 mark)  Challenge tasks are tasks that you should only perform if you have extra time, are keen, and want to show off a little bit.  This challenge task is only worth 1 mark.  If you don’t demo the challenge task, the maximum score you can get on this lab is 9/10 (which is still an A+).   This challenge task is actually fairly easy.  A. In the original circuit, you always connect the centre of the screen (80,60) to the point specified by the user.  Modify your circuit such that, instead of starting from the centre, it starts from the point specified by the user in the previous iteration.  So for the first iteration, if the user specifies point (x0, y0), a line is drawn from the middle of the screen to (x0, y0).  Then, in the second iteration, if the user specifies point (x1,y1), a line is drawn from (x0,y0) to (x1,y1).  In iteration i, a line is drawn from point (x i-1,y i-1) to (x i,y i).    B. (optional) Rather than taking the point from the switches, choose each point and colour pseudo-randomly (using a Linear Feedback Shift Register).  Draw the lines quickly without waiting for KEY(0) between lines.  Note that you will have to add some delay, or the screen will fill up too quickly for you to see.   Week 1 Grading: 2 marks (initializing screen black)   2 marks (structure of FSM and Datapath; clear separation of code)   1 mark (drawing diagonal)  Week 2 Grading: 2 marks (drawing lines works for typical/easy cases)   2 marks (drawing lines works for all cases)   1 mark (challenge circuit)   137

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0223892/manifest

Comment

Related Items