This document describes the VHDL implementation of a MIPS processor subset. It begins with a simple single-cycle implementation and expands it to a multicycle design using pipelining. The design is broken into modules for the ALU, memory, control unit, and datapath. VHDL code and testbenches are provided to verify the correct execution of arithmetic, memory, and branch instructions. The goal is to understand hardware implementation by designing a basic processor in VHDL according to guidelines from the textbook "Computer Organization & Design."
How to Apply Functional Safety to Autosar ECU'sRenesas America
Here's a walkthrough on how you can apply functional safety to Autostar ECU's. These functional safety features apply to ISO26262, AUTOSAR, and MICROSAR. We map out safety requirements, monitoring approaches, and a couple different interface scenarios. Finally we will finish up with E2E protection.
micro-ROS: Developing ROS 2 professional applications based on MCUseProsima
These slides, presented during the ROS-Industrial Americas meeting, provide an insight on the micro-ROS architecture and features, as well as an update on its latest updates.
Tizimlar va signallarni qayta ishlash_3-ma'ruza (Systems and Digital Signal P...Mukhriddin Mukhiddinov
Fanning nazariy konsepsiyalari asosan o‘rganiladigan barcha
konsepsiyalarga erishish uchun sekin-asta murakkablashib boradigan mashq va masalalarni bajarish orqali o‘rganiladi.
Talabalar “Tizimlar va signallarni qayta ishlash” fanida signallarga ishlov berishning asosiy tushunchalari va qo’llanish sohalari, signallarni va signal xususiyatlarini tasniflash, uzluksiz signallarni diskretlash va qayta tiklash, analog signallarni raqamliga konvertatsiyalash, diskret-vaqt signallari va tizimlari (LTI), Z-o’zgartirish va uni qo'llash, diskret vaqt signallarining chastotasini tahlil qilish (DFT va FFT), raqamli filtrlarni loyihalash va filtrlashning asoslari (FIR va IIR), signallarga ishlov berishning usullari (basizli splayn), audioga ishlov berishning asoslari (vayvlet o’zgartirish), tasvirga ishlov berishning asoslari filtrlash hamda siqish kabi nazariy tushunchalarni amaliy mashg’ulotlarda dasturlarini yaratishni
o’rganishadi.
Traffic Violation Detector using Object Detection that helps to detects the vehicle number plate that is violating traffic rules and by that number the admin finds the details of the car owner and send a penalty charge sheet to the owner home.
How to Apply Functional Safety to Autosar ECU'sRenesas America
Here's a walkthrough on how you can apply functional safety to Autostar ECU's. These functional safety features apply to ISO26262, AUTOSAR, and MICROSAR. We map out safety requirements, monitoring approaches, and a couple different interface scenarios. Finally we will finish up with E2E protection.
micro-ROS: Developing ROS 2 professional applications based on MCUseProsima
These slides, presented during the ROS-Industrial Americas meeting, provide an insight on the micro-ROS architecture and features, as well as an update on its latest updates.
Tizimlar va signallarni qayta ishlash_3-ma'ruza (Systems and Digital Signal P...Mukhriddin Mukhiddinov
Fanning nazariy konsepsiyalari asosan o‘rganiladigan barcha
konsepsiyalarga erishish uchun sekin-asta murakkablashib boradigan mashq va masalalarni bajarish orqali o‘rganiladi.
Talabalar “Tizimlar va signallarni qayta ishlash” fanida signallarga ishlov berishning asosiy tushunchalari va qo’llanish sohalari, signallarni va signal xususiyatlarini tasniflash, uzluksiz signallarni diskretlash va qayta tiklash, analog signallarni raqamliga konvertatsiyalash, diskret-vaqt signallari va tizimlari (LTI), Z-o’zgartirish va uni qo'llash, diskret vaqt signallarining chastotasini tahlil qilish (DFT va FFT), raqamli filtrlarni loyihalash va filtrlashning asoslari (FIR va IIR), signallarga ishlov berishning usullari (basizli splayn), audioga ishlov berishning asoslari (vayvlet o’zgartirish), tasvirga ishlov berishning asoslari filtrlash hamda siqish kabi nazariy tushunchalarni amaliy mashg’ulotlarda dasturlarini yaratishni
o’rganishadi.
Traffic Violation Detector using Object Detection that helps to detects the vehicle number plate that is violating traffic rules and by that number the admin finds the details of the car owner and send a penalty charge sheet to the owner home.
This is a high level overview of NLP and deep learning. This presentation contains information for beginners of NLP and those who wish to learn deep learning for NLP . Some slides are loaded with text for the information seekers.
This is a collection of material from various books and research papers. I have included some references in some of the slides, but did not include many. I sincerely apologize for missing those. I will soon add a separate PDF containing all the references used.
This is NOT meant to be a business presentation
Advanced driver assistance systems are designed to increase car safety more generally road safety.
Basically Advanced driver assists(ADS) systems helps the driver in the driving process and enables safe, relaxed driving. It makes sense to get your new car with driver assist features if you find it at a reasonable price as it helps you drive easily and safely in everyday use.
UWB is RTLS (Real Time Location System)
* It is one of the most recent location technologies
* It is extremely precise 10-30cm.
* Tags are quite expensive
* It’s a technology that works well in “empty” environments, without people or assets moving around. Interference can play an important role and significantly affect the accuracy.
The OMG DDS (Data Distribution Service) is a standard for data
distribution which is widely used as the foundation for operational
systems such as air traffic control and management, combat systems,
distributed telemetry and control, etc. On the other hand, HLA (High
Level Architecture) is a communication and coordination standard which
is widely adopted in the distributed simulation community.
DDS is increasingly gaining adoption in distributed simulation,
especially for those systems that require high throughput, low
latencies and scalability. In addition, the use of DDS in simulation
provides native interoperability between operational and simulated
systems, thus eliminating integration overhead and complexities.
This presentation introduces DDS and HLA, provide an apple-to-apple
comparison between the two standards and show how DDS and HLA systems
can be seamlessly integrated together.
Alain Legault, VP IP Products at Hardent, discusses how the combination of VDC-M and MIPI DSI-2℠ can support the development of sophisticated mobile, AR/VR and automotive displays, provides an overview of the VDC-M algorithm and use cases.
Slides from our 04 Feb 2016 Meetup.
http://www.meetup.com/FW-Dev/events/228176322/
An overview of the automotive CAN Bus, On Board Diagnostics (OBD), Tire Pressure Monitoring System (TPMS) and how car companies can cheat on emissions testing. We'll also do a demonstration of how to interface an Arduino to a car using a cheap CAN bus controller
For the full video of this presentation, please visit:
https://www.edge-ai-vision.com/2020/12/driver-monitoring-systems-present-and-future-a-presentation-from-xperi/
For more information about edge AI and computer vision, please visit:
https://www.edge-ai-vision.com
Petronel Bigioi, CTO for Imaging at XPERI, presents the “Driver Monitoring Systems: Present and Future” tutorial at the September 2020 Embedded Vision Summit.
Monitoring drivers and passengers inside of vehicles is an increasingly critical capability. For example, driver monitoring is required in order for cars to obtain a top safety rating from NCAP. This presentation introduces XPERI’s driver and in-cabin monitoring solutions and examines real-world use-cases in which these solutions are being deployed.
Bigioi illustrates the evolution of these technologies as they have been used in conventional cars, as they are increasingly being used in cars with partial self-driving capability, and how they are likely to be used in fully automated vehicles. This goes well beyond driver monitoring to include new types of safety features as well as non-safety uses such as entertainment, personalization, human-machine interfaces and even monitoring occupant health.
This is a high level overview of NLP and deep learning. This presentation contains information for beginners of NLP and those who wish to learn deep learning for NLP . Some slides are loaded with text for the information seekers.
This is a collection of material from various books and research papers. I have included some references in some of the slides, but did not include many. I sincerely apologize for missing those. I will soon add a separate PDF containing all the references used.
This is NOT meant to be a business presentation
Advanced driver assistance systems are designed to increase car safety more generally road safety.
Basically Advanced driver assists(ADS) systems helps the driver in the driving process and enables safe, relaxed driving. It makes sense to get your new car with driver assist features if you find it at a reasonable price as it helps you drive easily and safely in everyday use.
UWB is RTLS (Real Time Location System)
* It is one of the most recent location technologies
* It is extremely precise 10-30cm.
* Tags are quite expensive
* It’s a technology that works well in “empty” environments, without people or assets moving around. Interference can play an important role and significantly affect the accuracy.
The OMG DDS (Data Distribution Service) is a standard for data
distribution which is widely used as the foundation for operational
systems such as air traffic control and management, combat systems,
distributed telemetry and control, etc. On the other hand, HLA (High
Level Architecture) is a communication and coordination standard which
is widely adopted in the distributed simulation community.
DDS is increasingly gaining adoption in distributed simulation,
especially for those systems that require high throughput, low
latencies and scalability. In addition, the use of DDS in simulation
provides native interoperability between operational and simulated
systems, thus eliminating integration overhead and complexities.
This presentation introduces DDS and HLA, provide an apple-to-apple
comparison between the two standards and show how DDS and HLA systems
can be seamlessly integrated together.
Alain Legault, VP IP Products at Hardent, discusses how the combination of VDC-M and MIPI DSI-2℠ can support the development of sophisticated mobile, AR/VR and automotive displays, provides an overview of the VDC-M algorithm and use cases.
Slides from our 04 Feb 2016 Meetup.
http://www.meetup.com/FW-Dev/events/228176322/
An overview of the automotive CAN Bus, On Board Diagnostics (OBD), Tire Pressure Monitoring System (TPMS) and how car companies can cheat on emissions testing. We'll also do a demonstration of how to interface an Arduino to a car using a cheap CAN bus controller
For the full video of this presentation, please visit:
https://www.edge-ai-vision.com/2020/12/driver-monitoring-systems-present-and-future-a-presentation-from-xperi/
For more information about edge AI and computer vision, please visit:
https://www.edge-ai-vision.com
Petronel Bigioi, CTO for Imaging at XPERI, presents the “Driver Monitoring Systems: Present and Future” tutorial at the September 2020 Embedded Vision Summit.
Monitoring drivers and passengers inside of vehicles is an increasingly critical capability. For example, driver monitoring is required in order for cars to obtain a top safety rating from NCAP. This presentation introduces XPERI’s driver and in-cabin monitoring solutions and examines real-world use-cases in which these solutions are being deployed.
Bigioi illustrates the evolution of these technologies as they have been used in conventional cars, as they are increasingly being used in cars with partial self-driving capability, and how they are likely to be used in fully automated vehicles. This goes well beyond driver monitoring to include new types of safety features as well as non-safety uses such as entertainment, personalization, human-machine interfaces and even monitoring occupant health.
8 Bit ALU design is a combinational circuit which adds two binary numbers of 8 bit lenth.Which is more useful for both bachelor as well as masters students.
Designing of 8 BIT Arithmetic and Logical Unit and implementing on Xilinx Ver...Rahul Borthakur
The main objective of this project was to design and verify different operations of Arithmetic and Logical Unit (ALU). To implement ALU, the coding was written in VHDL (VHSIC Hardware Description Language) and verified in ModelSim. The device was configured and using FPGA (Field-programmable gate array) verification, debugging was done.
Computer Architecture – An IntroductionDilum Bandara
Overview on high-level design of internal components of a computer. Cover step-by-step execution of a program through ALU while accessing & updating registers
The use of synchrophasors for monitoring and improving the stability of power transmission networks is gaining in significance all over the world. The aim is to monitor the system state, to intensify awareness for system stability and to make optimal use of existing lines. This way, system stability can be improved overall and even the transmission performance can be increased. The data from so many PMU’s and PDC’s needs to be collected and directed to proper channels for its efficient use. Thus we need to develop an efficient, flexible and hybrid data concentrator that can serve this purpose. Besides accepting the data from PMU’s, PDC should be able to accept the data also from other PDC. We have designed such a PDC (iPDC) that accepts data from PMU & PDC that are IEEEC37.118 standard compliant.
WAMS architecture with iPDC and PMU at different levels. This architecture enables iPDC to receive data either from a PMU or other iPDC. Both PMU and iPDC from whom the data is being received should be IEEE C37.118 synchrophasor standard compliant. It is hybrid architecture.
iPDC Design
The client server architecture is common in networks when two peers are communicating with each other. Of the two peers (PMU and iPDC) that are communicating with each other in WAMS one acts as a client and the other as a server. Since PMU saves the requests coming
from iPDC by sending data or configuration frames it acts as a server. It listens for command frames from iPDC. PMU-iPDC communication can be either over TCP or UDP communication protocols. On receiving command frames, PMU replies to the iPDC with data or configuration frames according to the type of request.
iPDC functionality is bifurcated as server and client. iPDC as a Client - When iPDC receives data or configuration frames its acts as a client. When acting as a client, it creates a new thread for each PMU or a PDC from whom it is going to receive data/configuration frames. This thread would establish connection between the two communication entities. It handles both TCP and UDP connections. The first frame that the server (PMU/PDC) would receive is the command for sending the configuration frame. When the server replies with the configuration frame, iPDC (client) would generate another request to start sending the data frames. On receiving
such a command frame, the server starts sending the data frames. If there is some change in the status bits of data frame which the client (iPDC) notices, it would take an action. For example if it notices a bit 10 has been set, it would internally send a command to server to send the latest configuration frame.
iPDC as a Server- When iPDC receives command frames from another PDC it would acts as a server. There would be two reserved ports one for UDP and other for TCP on which the PDC would receive command frame requests. Thus PDC now plays the role of PMU waiting
for command frames.
iPDC-v1.3.0 - A Complete Technical Report including iPDC, PMU Simulator, and ...Nitesh Pandit
iPDC is a free Phasor Data Concentrator based on IEEEC37.118 synchrophasor standard. It also has Database Server for iPDC and PMU Simulator modules.
The objective of iPDC project is to create a IEEE C37.118 Synchrophasor standardized Phasor Data Concentrator and PMU Simulator, on which research students and others can develop and test their algorithms and applications. The purpose of iPDC released as a Free Software to its availability for users without any restriction regarding its usage and modification. And to get the contribution from users and developers all around the world.
iPDC do the time alignment and combining of the received data into frames as per IEEEC37.118 and can send to other iPDCs, and applications. iPDC can also archive received data in the MySQL database on local/remote machine. PMU Simulator is also IEEEC37.118 std compliant. Software is built to be working on Linux platform.
I Pdc V1.3.0 A Complete Technical Report Including I Pdc, Pmu Simulator, An...Nitesh Pandit
iPDC is a free Phasor Data Concentrator that collects data from PMUs, and PDC/iPDC that are IEEEC37.118 Synchrophasors std compliant. iPDC do the time alignment and combining of the received data into frames as per IEEEC37.118 and can send to other iPDCs, and applications. iPDC can also archive received data in the MySQL database on local/remote machine. PMU Simulator is also IEEEC37.118 std compliant. Software is built to be working on Linux platform.
iPDC is a free Phasor Data Concentrator based on IEEEC37.118 synchrophasor standard. It also has Database Server for iPDC and PMU Simulator modules.
The objective of iPDC project is to create a IEEE C37.118 Synchrophasor standardized Phasor Data Concentrator and PMU Simulator, on which research students and others can develop and test their algorithms and applications. The purpose of iPDC released as a Free Software to its availability for users without any restriction regarding its usage and modification. And to get the contribution from users and developers all around the world.
The use of synchrophasors for monitoring and improving the stability of power transmission networks is gaining in significance all over the world. The aim is to monitor the system state, to intensify awareness for system stability and to make optimal use of existing lines. This way, system stability can be improved overall and even the transmission performance can be increased. The data from so many PMU’s and PDC’s needs to be collected and directed to proper channels for its efficient use. Thus we need to develop an efficient, flexible and hybrid data concentrator that can serve this purpose. Besides accepting the data from PMU’s, PDC should be able to accept the data also from other PDC. We have designed such a PDC (iPDC) that accepts data from PMU & PDC that are IEEEC37.118 standard compliant.
WAMS architecture with iPDC and PMU at different levels. This architecture enables iPDC to receive data either from a PMU or other iPDC. Both PMU and iPDC from whom the data is being received should be IEEE C37.118 synchrophasor standard compliant. It is hybrid architecture.
iPDC Design
The client server architecture is common in networks when two peers are communicating with each other. Of the two peers (PMU and iPDC) that are communicating with each other in WAMS one acts as a client and the other as a server. Since PMU saves the requests coming
from iPDC by sending data or configuration frames it acts as a server. It listens for command frames from iPDC. PMU-iPDC communication can be either over TCP or UDP communication protocols. On receiving command frames, PMU replies to the iPDC with data or configuration frames according to the type of request.
iPDC functionality is bifurcated as server and client. iPDC as a Client - When iPDC receives data or configuration frames its acts as a client. When acting as a client, it creates a new thread for each PMU or a PDC from whom it is going to receive data/configuration frames. This thread would establish connection between the two communication entities. It handles both TCP and UDP connections. The first frame that the server (PMU/PDC) would receive is the command for sending the configuration frame. When the server replies with the configuration frame, iPDC (client) would generate another request to start sending the data frames. On receiving
such a command frame, the server starts sending the data frames. If there is some change in the status bits of data frame which the client (iPDC) notices, it would take an action. For example if it notices a bit 10 has been set, it would internally send a command to server to send the latest configuration frame.
iPDC as a Server- When iPDC receives command frames from another PDC it would acts as a server. There would be two reserved ports one for UDP and other for TCP on which the PDC would receive command frame requests. Thus PDC now plays the role of PMU waiting
for command frames.
Mobile networking technologies are the most ubiquitously spread among mankind and with
the technological advances of mobile clients are becoming a prime target for innovative
3D graphics applications.
Our research, presented in this thesis, focuses on new methods of reducing polygonal
models and other commonly used graphical structures in order to bring 3D computer
graphics to devices with limited processor speeds and memory, such as mobile phones.
These environments bring new challenges in algorithm efficiency and data reduction. We
concentrated our effort in three areas: 1. Facial animation on mobile phones, 2. Cooperative
computer graphics in distributed environments and 3. Procedurally generated cities and
buildings.
The aim of the thesis is to be a multidisciplinary publication that combines research
results from fields of computer graphics and mobile networking. We focused on novel
ways to utilize the properties of distributed mobile environments to perform graphical tasks
and overcome various problems in distributed graphical applications caused by occasional
unreliable mobile device network connections.
Ensuring Distributed Accountability in the CloudSuraj Mehta
Ensuring distributed accountability for data sharing in the cloud is in short nothing
but a novel highly decentralized information accountability framework to keep track
of the actual usage of the users' data in the cloud. Cloud computing enables highly
ecient services that are easily consumed over the internet.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
Mips implementation
1. University of Ulster at Jordanstown
University of Applied Sciences, Augsburg
Master of Engineering
VLSI Design Project Report
Processor
Implementation
in VHDL
According to Computer Organisation & Design
by David A. Patterson and John L. Hennessy
Author(s): M. Linder
M. Schmid
Supervisor(s): J. Färber
A. Eder
Submitted: 06/07/07
2. Document Revision History, Designers
Department of Electrical Engineering
Document Revision History
Rev. Date Author Description
0.1 15/05/2007 M. Schmid First draft release
0.2 15/05/2007 M. Linder Features of the project
0.3 29/05/2007 M. Linder Target Spec. (2.1, 2.2)
0.4 10/06/2007 M. Linder Target Spec. (2.3)
0.5 30/06/2007 M. Linder - include jump instruction to Target Spec.
- Module Spec. of Control
0.6 02/07/2007 M. Linder Module Spec. of Data
0.6.1 02/07/2007 M. Schmid Module Spec. of ALU and Memory
0.6.2 03/07/2007 M. Schmid Design Tasks
0.7 04/07/2007 M. Linder - Module Spec. of Datapath
- Synthesis Results
- References
0.8 05/07/2007 M. Linder, M. Schmid - Synthesis Results
- Source Code
- Conclusion
1.0 05/07/2007 M. Linder, M. Schmid Final release
Designer(s)
M. Linder michael-linder@web.de
M. Schmid martin-werner.schmid@gmx.de
Contact
Michael Linder
Angerstraße 8a
86356 Neusäß, Germany
Phone: +49 (0) 176 22 93 58 30
Mail: michael-linder@web.de
Martin Schmid
Fichtenstraße 2
86500 Kutzenhausen, Germany
Phone: +49 (0) 160 92 94 91 54
Mail: martin-werner.schmid@gmx.de
M. Linder, M. Schmid II
3. Contents
Department of Electrical Engineering
Contents
1 Introduction................................................................................ 1
1.1 Starting from a Simple Implementation Scheme...................................1
1.2 Using Multicycle Implementations.........................................................2
1.3 Enhancing Performance with Pipelining................................................2
2 Target Specification................................................................... 3
2.1 Building a Datapath............................................................................... 3
2.1.1 Major Components.................................................................................... 3
2.1.2 Components for Arithmetic and Logic Functions....................................... 4
2.1.3 Load word (lw) and store word (sw) instructions........................................ 5
2.1.4 Branch on equal instruction....................................................................... 6
2.1.5 Jump Instruction........................................................................................ 6
2.2 Simple Implementation Scheme............................................................7
2.2.1 Creating a Single Datapath....................................................................... 7
2.2.2 ALU Control............................................................................................... 8
2.2.3 Main Control.............................................................................................. 9
2.2.4 Disadvantages of a Single-Cycle Implementation................................... 10
2.3 Multicycle Implementation...................................................................11
2.3.1 Additions and Changes in the Scheme.................................................... 11
2.3.2 Execution of Instructions in Clock Cycles................................................ 14
2.3.3 Defining the Control by a Finite State Machine........................................ 18
3 Design Tasks............................................................................ 21
4 Module Specification............................................................... 22
4.1 ALU......................................................................................................22
4.1.1 Functional Description............................................................................. 22
4.1.2 Block Diagram......................................................................................... 23
4.1.3 Simulation Results................................................................................... 26
4.1.4 Design Files............................................................................................. 26
4.2 Memory................................................................................................27
4.2.1 Functional Description............................................................................. 27
4.2.2 Block Diagram......................................................................................... 28
4.2.3 Simulation Results................................................................................... 28
4.2.4 Design Files............................................................................................. 29
M. Linder, M. Schmid III
5. Contents
Department of Electrical Engineering
7.2 Annotations to “Computer Organization & Design” [PaHe98].............50
7.3 Further work on the project..................................................................51
8 Appendix................................................................................... 52
8.1 Design files..........................................................................................52
8.1.1 Project Entities........................................................................................ 52
8.1.2 Project Architectures............................................................................... 58
8.1.3 Package.................................................................................................. 79
8.1.4 Testbenches............................................................................................ 80
8.2 References...........................................................................................91
M. Linder, M. Schmid V
6. Contents
Department of Electrical Engineering
List of Figures
Figure 1.1: Simple block diagram with datapaths [PaHe98] p. 352....................... 1
Figure 1.2: Multicycle Datapath [PaHe98] p. 414...................................................2
Figure 1.3: Pipelined Version of the Datapath [PaHe98], p. 452........................... 2
Figure 2.1: Instruction Memory, Program Counter and Adder [PaHe98], p 344....3
Figure 2.2: Datapath for fetching instructions and incrementing the PC
[PaHe98] p. 345......................................................................................................3
Figure 2.3: Register and ALU [PaHe98] p. 346......................................................4
Figure 2.4: Datapath for R-type Instructions [PaHe98] p. 347...............................4
Figure 2.5: Data Memory and Sign extension unit [PaHe98] p. 348......................5
Figure 2.6: Load or Store Word instruction field.....................................................5
Figure 2.7: Datapath for Load Word and Store Word [PaHe98] p. 348.................5
Figure 2.8: Datapath for a branch instruction [PaHe98] p. 350..............................6
Figure 2.9: Completed Simple Datapath [PaHe98] p. 353.....................................7
Figure 2.10: MIPS field...........................................................................................8
Figure 2.11: Table for ALU Control.........................................................................8
Figure 2.12: Datapath with ALU Control Unit [PaHe98] p. 358..............................9
Figure 2.13: Meaning of the main control signals [PaHe98] p. 359....................... 9
Figure 2.14: The simple datapath with the control unit [PaHe98] p. 360.............10
Figure 2.15: Truth table of the main control unit [PaHe98] p. 361.......................10
Figure 2.16: Abstract view of a multicycle desing [PaHe98] p. 378..................... 11
Figure 2.17: Complete Datapath for multicycle design [PaHe98] p. 383............. 13
Figure 2.18: Actions of 1-bit control signals [PaHe98] p. 384..............................14
Figure 2.19: Actions of 2-bit control signals [PaHe98] p. 384..............................14
Figure 2.20: Summary of the multicycle steps [PaHe98] p. 389..........................18
Figure 2.21: Complete finite state machine control [PaHe98] p. 396.................. 19
Figure 2.22: Setting of Control Signals.................................................................20
Figure 4.1: ALU 1/3...............................................................................................23
Figure 4.2: ALU 2/3...............................................................................................24
Figure 4.3: ALU 3/3...............................................................................................25
Figure 4.4: Simulation Results of ALU..................................................................26
Figure 4.5: Memory...............................................................................................28
M. Linder, M. Schmid VI
7. Contents
Department of Electrical Engineering
Figure 4.6: Simulation Results of Memory (registered outputs)...........................28
Figure 4.7: Simulation Results of Memory (unregistered outputs).......................29
Figure 4.8: Control Finite State Machine..............................................................31
Figure 4.9: Control FSM........................................................................................32
Figure 4.10: ALU Control......................................................................................32
Figure 4.11: Control..............................................................................................33
Figure 4.12: Simulation Results of the Control FSM............................................33
Figure 4.13: Instruction Fetch...............................................................................34
Figure 4.14: Instruction Decode............................................................................35
Figure 4.15: Execution..........................................................................................37
Figure 4.16: Memory Writeback........................................................................... 40
Figure 4.17: Processing Unit (Datapath & Controlpath).......................................43
Figure 4.18: Processing Unit & Memory...............................................................43
Figure 5.1: Analysis & Synthesis Summary..........................................................45
Figure 5.2: Analysis & Synthesis Settings............................................................46
Figure 5.3: Compilation History............................................................................ 46
Figure 6.1: Simulation Results of MIPS and Memory.......................................... 49
M. Linder, M. Schmid VII
9. Contents
Department of Electrical Engineering
VHDLSource 8.32: a_memory_behave.vhd.........................................................75
VHDLSource 8.33: a_mips.vhd............................................................................77
VHDLSource 8.34: a_procmem.vhd.....................................................................78
VHDLSource 8.35: p_procmem_definitions.vhd.................................................. 79
VHDLSource 8.36: t_alu_fileio.vhd.......................................................................83
VHDLSource 8.37: t_memory.vhd........................................................................86
VHDLSource 8.38: t_procmem.vhd......................................................................87
M. Linder, M. Schmid IX
10.
11. 1 Introduction
Department of Electrical Engineering
1 Introduction
“The performance of software systems is dramatically affected by how well soft-
ware designers understand the basic hardware technologies at work in a sys-
tem.” According to the book “Computer Organization & Design” written by David
A. Patterson and John L. Hennessy the hardware and behaviour of a micropro-
cessor is implemented in VHDL.
1.1 Starting from a Simple Implementation Scheme
In the first section starting from a simple implementation scheme of a MIPS sub-
set the basic hardware of the microcontroller´s datapath and its control is devel-
oped step by step and implemented in VHDL. Testbenches will verify the correct
implementation of the arithmetic-logical instructions (add, sub, and, or and slt),
the memory-reference instructions (load word and store word) and the branch in-
structions (beq and jump).
Figure 1.1: Simple block diagram with datapaths [PaHe98] p. 352
M. Linder, M. Schmid, 07/07 1
12. 1.2 Using Multicycle Implementations
Department of Electrical Engineering
1.2 Using Multicycle Implementations
Figure 1.2: Multicycle Datapath [PaHe98] p. 414
Establishing that the efficiency of a long single-cycle implementation is not likely
to be very good the processor´s speed is improved by using multicycle imple-
mentations. Then, instructions are allowed to take different numbers of clock cy-
cles and functional units can be shared within the execution of single instruc-
tions.
1.3 Enhancing Performance with Pipelining
In order to enhance the performance and to get very fast processors another im-
plementation technique called pipelining is introduced. Multiple instructions are
overlapped in execution so that some stages are working in parallel.
Figure 1.3: Pipelined Version of the Datapath [PaHe98], p. 452
2 M. Linder, M. Schmid, 07/07
13. 2 Target Specification
Department of Electrical Engineering
2 Target Specification
2.1 Building a Datapath
2.1.1 Major Components
At first we look at the elements required to execute the MIPS instructions and
their connection.
The first element needed is a place to store the program instructions. This In-
struction Memory is used to hold and supply instructions given an address.
The address must be kept in the Program Counter (PC), and in order to incre-
ment the PC to the address of the next instruction, we also need an Adder.
All these elements are shown in figure 2.1.
Figure 2.1: Instruction Memory, Program Counter and Adder [Pa-
He98], p 344
After fetching one instruction from the instruction memory, the program counter
has to be incremented so that it points to the address of the next instruction 4
bytes later.
This is realised by the datapath shown in figure 2.2.
Figure 2.2: Datapath for fetching instructions and incrementing the PC
[PaHe98] p. 345
M. Linder, M. Schmid, 07/07 3
14. 2.1 Components for Arithmetic and Logic Functions
Department of Electrical Engineering
2.1.2 Components for Arithmetic and Logic Functions
The instructions we use all read two registers, perform an ALU operation and
write back the result.
These arithmetic-logical instructions are also called R-type instructions
([PaHe98] p. 154). This instruction class considers add, sub, slt, and and or.
The 32 registers of the processor are stored in a Register File. To read a data-
word two inputs and two outputs are needed. The inputs are 5 bits wide and
specify the register number to be read, the outputs are 32 bits wide and carry the
value of the register.
To write the result back two inputs are needed: one to specify the register num-
ber and one to supply the data to be written. The Register is shown in Figure 2.3.
Figure 2.3: Register and ALU [PaHe98] p. 346
To process the data from the Register, an ALU with two data inputs is used.
Figure 2.4 shows the combination of Register and ALU to operate on R-type in-
structions.
Figure 2.4: Datapath for R-type Instructions [PaHe98] p. 347
4 M. Linder, M. Schmid, 07/07
15. 2.1 Load word (lw) and store word (sw) instructions
Department of Electrical Engineering
2.1.3 Load word (lw) and store word (sw) instructions
Two more elements are needed to implement the sw- and lw-instructions: the
Data Memory and the Sign Extension Unit.
Figure 2.5: Data Memory and Sign extension unit [PaHe98] p. 348
The sw- and lw-instructions compute a memory address by adding a register val-
ue to the 16-bit signed offset field contained in the instruction.
Because the ALU has 32-bit values, the instruction offset field must be sign ex-
tended from 16 to 32 bits simply by concatenating the sign-bit 16 times to the
original value.
The instruction field for a lw- or sw-instruction is shown in figure 2.6:
op rs rt address
6 bits 5 bits 5 bits 16 bits
Figure 2.6: Load or Store Word instruction field
Figure 2.7: Datapath for Load Word and Store Word [PaHe98] p. 348
M. Linder, M. Schmid, 07/07 5
16. 2.1 Branch on equal instruction
Department of Electrical Engineering
2.1.4 Branch on equal instruction
The beq instruction has three operands, two registers that are compared for
equality, and a 16-bit offset used to compute the branch target address relative
to the branch instruction address.
Figure 2.8: Datapath for a branch instruction [PaHe98] p. 350
Figure 2.8 shows the datapath for a branch on equal instruction. This datapath
must do two operations: compare the register contents and compute the branch
target.
Therefore two things must be done: The address field of the branch instruction
must be sign extended from 16 bits to 32 bits and must be shifted left 2 bits so
that it is a word offset.
The branch target address is computed by adding the address of the next in-
struction (PC + 4) to the before computed offset.
2.1.5 Jump Instruction
The jump instruction is similar to the branch instruction, but computes the target
PC differently and not conditional.
The destination address for a jump is formed by concatenating the upper 4 bits
of the current PC + 4 to the 26-bit address field in the jump instruction (see figure
2.10 on page 8) and adding “00” as the last two bits.
6 M. Linder, M. Schmid, 07/07
17. 2.2 Simple Implementation Scheme
Department of Electrical Engineering
2.2 Simple Implementation Scheme
The simplest possible implementation of the MISP Processor contains the datap-
ath segments explained above added by the required control lines.
2.2.1 Creating a Single Datapath
The simplest datapath might attempt to execute all instructions in one clock cy-
cle. This means that any element can be used only once per instruction. So
these elements have to be duplicated.
If possible datapath elements can be shared by different instruction flows. There-
fore multiple connections to the input must be realised. This is commonly done
by a multiplexer.
Figure 2.9 shows the combined datapath including a memory of instructions and
one for data, the ALU, the PC-unit and the mentioned multiplexers.
Figure 2.9: Completed Simple Datapath [PaHe98] p. 353
M. Linder, M. Schmid, 07/07 7
18. 2.2 ALU Control
Department of Electrical Engineering
2.2.2 ALU Control
The MIPS field that contains the information about the instruction has the follow-
ing structure:
op rs rt rd shamt funct
6 bits 5 bits 5 bits 5 bits 5 bits 6 bits
Figure 2.10: MIPS field
The meaning of the fields are:
• op: basic operation
• rs: first register source
• rt: second register source
• rd: register destination
• shamt: shift amount
• funct: function
Instruction Instruction Desired ALU control
opcode ALUOp operation Funct field ALU action input
LW 00 load word XXXXXX add 010
SW 00 store word XXXXXX add 010
Branch equal 01 branch equal XXXXXX subtract 110
R-type 10 add 100000 add 010
R-type 10 subtract 100010 subtract 110
R-type 10 AND 100100 and 000
R-type 10 OR 100101 or 001
R-type 10 set on less than 101010 set on less than 111
Figure 2.11: Table for ALU Control
Figure 2.11 shows in the last column the 3-bit ALU control input.
It depends on the 6-bit funct field of the MIPS instruction and the 2-bit ALUOp
signal generated form the Main Control Unit (see Chapter 2.2.3).
Figure 2.12 shows the datapath including the ALU Control Unit.
8 M. Linder, M. Schmid, 07/07
19. 2.2 ALU Control
Department of Electrical Engineering
Figure 2.12: Datapath with ALU Control Unit [PaHe98] p. 358
2.2.3 Main Control
The main control unit generates the control bits for the multiplexers, the data
memory and the ALU control unit.
The input of the main control unit is the 6-bit op-field of the MIPS instruction field
(see figure 2.9 on page 7).
Figure 2.13 shows the meaning of the several control signals.
Signal name Effect when deasserted Effect when asserted
RegDst The register destination number for the Write re- The register destination number for the Write re-
gister comes from the rt field (bits 20-16). gister comes from the rd field (bits 15-11).
RegWrite None The register on the Write register input is written
with the value on the Write data input.
ALUSrc The second ALU operand comes from the se- The second ALU operand is the sign-extended,
cond register file output (Read data 2). lower 16 bits of the instruction.
PCSrc The PC is replaced by the output of the adder The PC is replaced by the output of the adder
that computes the value of PC + 4. that computes the branch target.
MemRead None Data memory contents designated by the ad-
dress input are put on the Read data output.
MemWrite None Data memory contents designated by the ad-
dress input are replaced by the value on the Wri-
te data input.
MemtoReg The value fed to the register Write data input co- The value fed to the register Write data input co-
mes from the ALU. mes from the data memory.
Figure 2.13: Meaning of the main control signals [PaHe98] p. 359
M. Linder, M. Schmid, 07/07 9
20. 2.2 Main Control
Department of Electrical Engineering
The connection of the main control unit is shown in figure 2.14. This and the
meaning of the signals described in figure 2.13 leads directly to the truth table for
the main control unit shown in figure 2.15.
Figure 2.14: The simple datapath with the control unit [PaHe98] p. 360
Memto- Reg Mem Mem
Instruction RegDst ALUSrc Reg Write Read Write Branch ALUOp1 ALUOp2
R-format 1 0 0 1 0 0 0 1 0
lw 0 1 1 1 1 0 0 0 0
sw X 1 X 0 0 1 0 0 0
beq X 0 X 0 0 0 1 0 1
Figure 2.15: Truth table of the main control unit [PaHe98] p. 361
2.2.4 Disadvantages of a Single-Cycle Implementation
In modern designs a single cycle implementation of a processor is not used, be-
cause it is inefficient.
A clock cycle must have the same length for every instruction and therefore it is
determined by the longest possible path. Almost this is the path of the load word
instruction which uses five functional units in series: the instruction memory, the
register file, the ALU, the data memory and the register file again.
However a single cycle implementation can be used for a small instruction set.
But if the machine gets more powerful there can be used thousands of functional
units and then the longest path causes the cycle time.
10 M. Linder, M. Schmid, 07/07
21. 2.3 Multicycle Implementation
Department of Electrical Engineering
2.3 Multicycle Implementation
To avoid the disadvantages of the single cycle implementation described in the
section before, a multicycle implementation is used.
This technique divides each instruction into steps and each step is executed in
one clock cycle.
The multicycle implementation allows a functional unit to be used more than
once in a instruction, so that the number of functional units can be reduced.
The major advantage of a multicycle design is the ability to share functional units
within an execution.
2.3.1 Additions and Changes in the Scheme
Figure 2.16 shows a abstract design of a multicycle datapath.
Figure 2.16: Abstract view of a multicycle desing [PaHe98] p. 378
Comparing to the single-cycle datapath the differences are that only one memory
unit is used for instructions and data, there is only one ALU instead of an ALU
and two adders and several output registers are added to hold the output value
of a unit until it is used in a later clock cycle.
The instruction register (IR) and the memory data register (MDR) are added to
save the output of the memory. The registers A and B hold the register operands
read form the register file and the ALUOut holds the output of the ALU.
With exception of the IR all these registers hold data only between a pair of
adjacent clock cycles.
M. Linder, M. Schmid, 07/07 11
22. 2.3 Additions and Changes in the Scheme
Department of Electrical Engineering
Because the IR holds the value during the whole time of the execution of a
instruction, it requires a write control signal.
The reduction from former three ALUs to one causes also the following changes
in the datapath:
An additional multiplexer is added for the first ALU input to choose between the
A register and the PC.
The multiplexer at the second ALU input is changed from a two-way to a four-
way multiplexer. The two new inputs are a constant 4 to increment the PC and
the sign-extended and shifted offset field for the branch instruction.
In order to handle branches and jumps more additions in the datapath are
required.
The three cases of R-type instructions, branch instruction and jump instruction
cause three different values to be written into the PC:
• The output of the ALU which is PC + 4 should be stored directly to the PC.
• The register ALUOut after computing the branch target address.
• The lower 26 bits of the IR shifted left by two and concatenated with the
upper 4 bits of the incremented PC, when the instruction is jump.
If the instruction is branch, the write signal for the PC is conditional. Only if the
the two compared registers are equal, the computed branch address has to be
written to the PC.
Therefore the PC needs two write signals, which are PCWrite if the write is
unconditional (value is PC + 4 or jump instruction) and PCWriteCond if the write
is conditional.
12 M. Linder, M. Schmid, 07/07
23. 2.3 Additions and Changes in the Scheme
Department of Electrical Engineering
Figure 2.17 shows the completed datapath for a multicycle implementation
including the whole control.
It also shows that the write signal for the PC is combined form the ALU zero bit
and the two write signals PCWrite and PCWriteCond by an AND gate and OR
gate.
Figure 2.17: Complete Datapath for multicycle design [PaHe98] p. 383
M. Linder, M. Schmid, 07/07 13
24. 2.3 Execution of Instructions in Clock Cycles
Department of Electrical Engineering
2.3.2 Execution of Instructions in Clock Cycles
The execution of an instruction is broken into clock cycles, that means that each
instruction is divided into a series of steps.
Therefore the setting of the control signals are shown in figures 2.18 and 2.19.
Signal name Effect when deasserted Effect when asserted
RegDst The register file destination number for the Write The register file destination for the Write register
register comes from the rt field comes from the rd field
RegWrite None The general-purpose register selected by the Wri-
te register number is written with the value of the
Write data input.
ALUSrcA The first ALU operand is the PC The first ALU operand comes from the A register
MemRead None Content of memory at the location specified by the
Address input is put on Memory data output.
MemWrite None Memory contents at the location specified by the
Address input is replaced by value on Write data
input.
MemtoReg The value fed to the register file Write data input The value fed to the register file Write data input
comes from ALUOut. comes from the MDR.
IorD The PC is used to supply the address to the me- ALUOut is used to supply the address to the me-
mory unit. mory unit.
IRWrite None The output of the memory is written into the IR.
PCWrite None The PC is written; the source is controlled by
PCSource.
PCWriteCond None The PC is written if the Zero output from the ALU
is also active.
Figure 2.18: Actions of 1-bit control signals [PaHe98] p. 384
Signal name Value Effect
ALUOp 00 The ALU performs an add operation.
01 The ALU performs an subtract operation.
10 The function field of the instruction determines the ALU operation.
ALUSrcB 00 The second input to the ALU comes from the B register.
01 The second input to the ALU is the constant 4.
10 The second input to the ALU is the sign-extended, lower 16 bits of the IR.
11 The second input to the ALU is the sign-extended, lower 16 bits of the IR shifted left
2 bits.
PCSource 00 Output of the ALU (PC + 4) is sent to the PC for writing.
01 The contents of ALUOut (the branch target address) are sent to the PC for writing.
10 The jump target address (IR[25-0] shifted left 2 bits and concatenated with
PC +4[31-28]) is sent to the PC for writing.
Figure 2.19: Actions of 2-bit control signals [PaHe98] p. 384
14 M. Linder, M. Schmid, 07/07
25. 2.3 Execution of Instructions in Clock Cycles
Department of Electrical Engineering
The execution of an instruction is divided into maximal five steps.
Different elements of the datapath can work in parallel during one clock cycle,
whereas others can only be used in series.
So there must be sure, that after one step the values computed are stored either
in the memory or in one of the registers.
The operation steps are:
1. Instruction fetch step
Fetch the instruction from the memory and computed the address of the
sequential instruction:
IR = Memory[PC]
PC = PC + 4
Control signal setting:
MemRead = 1
IRWrite = 1
IorD = 0
ALUSrcA = 1
ALUSrcB = 01
ALUOp = 00
PCSource = 00
PCWrite = 1
2. Instruction decode and register fetch step
It is still unknown what the instruction is, so there can only be performed
actions that are applicable for all instructions or are not harmful.
The registers indicated by the rs and rd field of the instruction are read
and store into the A and B register, and the potential branch target is
computed and stored into the ALUOut register.
A = Reg[IR[25-21]]
B = Reg[IR[20-16]]
ALUOut = PC + (sign-extend (IR[15-0]) << 2)
Control signal setting:
ALUSrcA = 0
ALUSrcB = 11
ALUOp = 00
M. Linder, M. Schmid, 07/07 15
26. 2.3 Execution of Instructions in Clock Cycles
Department of Electrical Engineering
3. Execution, memory address computation or branch completion
In this step the instruction is known and the operation depends on what
the instruction is. One of these four functions is executed:
1. Memory reference:
ALUOut = A + sign-extend(IR[15-0])
Control signal setting:
ALUSrcA = 1
ALUSrcB = 10
ALUOp = 00
2. Arithmetic-logical instruction:
ALUOut = A op B
Control signal setting:
ALUSrcA = 1
ALUSrcB = 00
ALUOp = 10
3. Branch:
if (A == B) PC = ALUOut
Control signal setting:
ALUSrcA = 1
ALUSrcB = 00
ALUOp = 01
PCWriteCond = 1
PCSource = 01
4. Jump:
PC = PC[31-28] & (IR[25-0] << 2)
Control signal setting:
PCWrite = 1
16 M. Linder, M. Schmid, 07/07
27. 2.3 Execution of Instructions in Clock Cycles
Department of Electrical Engineering
4. Memory access or R-type instruction completion step
In this step a load or store instruction accesses memory or a arithmetic-
logical instruction writes its result.
1. Memory reference:
MDR = Memory [ALUOut]
or
Memory [ALUOut] = B
Control signal setting:
MemRead = 1 or MemWrite = 1
IorD = 1
2. Arithmetic-logical instruction:
Reg[IR[15-11]] = ALUOut
Control signal setting:
RegDst = 1
RegWrite = 1
MemtoReg = 0
5. Memory read completion step
The load instruction is completed by writing back the value from the
memory:
Reg[IR[20-16]] = MDR
Control signal setting:
MemtoReg = 1
RegWrite = 1
RegDst = 0
These five steps are summarised in figure 2.20.
M. Linder, M. Schmid, 07/07 17
28. 2.3 Execution of Instructions in Clock Cycles
Department of Electrical Engineering
Step name Action for R-type Action for memory- Action for Action for
instructions reference instructions branches jumps
Instruction fetch IR = Memory[PC]
PC = PC + 4
Instruction decode A = Reg[IR[25-21]]
register fetch B = Reg[IR[20-16]]
ALUOut = PC + (sign-extend(IR[15-0] << 2)
Execution, address ALUOut = A op B ALUOut = A + sign-extend if (A == B) then PC = PC[31-28] ||
computation, (IR[15-0]) PC = ALUOut (IR[25-0] << 2)
branch/jump completi-
on
Memory access or R- Reg[IR[15-11]] = Load: MDR = Memory[ALUOut]
type completion ALUOut or
Store: Memory[ALUOut] = B
Memory read comple- Load: Reg[IR[20-16]] = MDR
tion
Figure 2.20: Summary of the multicycle steps [PaHe98] p. 389
2.3.3 Defining the Control by a Finite State Machine
In the single step implementation the control was defined by simple truth tables
that set the control signals depending on the instruction.
This does not work for a mulitcycle datapath.
The control is more complex, because it must specify both the signals to be set
in any step and the next step in the sequence.
Therefore a finite state machine is used.
Figure 2.21 shows the finite state machine for the control of the multicycle
datapath implementation.
18 M. Linder, M. Schmid, 07/07
29. 2.3 Defining the Control by a Finite State Machine
Department of Electrical Engineering
Figure 2.21: Complete finite state machine control [PaHe98] p. 396
The setting of the control signals is also shown in figure 2.21.
All unused signals have to be deasserted or keep their value during the next
states until they are set again.
All signal settings in all states is shown in figure 2.22.
M. Linder, M. Schmid, 07/07 19
31. 3 Design Tasks
Department of Electrical Engineering
3 Design Tasks
• Block Diagram of first hierarchy levels
• Register Transfer Level Models implemented in pure VHDL
• VHDL Testbench of important RTL Models
• Implementation in Altera Target Technology
• Prototype Testing
• Simulation Tool: ModelSim
• Synthesis Tool: Altera Quartus
• Milestone Presentations
• Design Project Report in OpenOffice Document Format
• Design Directory Structure is mandatory according to the following table:
Object Description
toplevel Root directory for a VHDL design project
toplevel/src directory for VHDL source code
toplevel/work directory for VHDL working library, contains compiled object code of
ModelSim VHDL compiler
toplevel/simulation simulation results
toplevel/stimuli stimuli files of extended simulation runs should be stored in
this directory
toplevel/pnr data produced after a place&route run can be found in this directory
toplevel/scripts scriptfiles for automated batch processing of the design steps
should be placed here
toplevel/log log files of the different design steps
toplevel/doc directory for project documentation, data sheets, etc.
M. Linder, M. Schmid, 07/07 21
32. 4 Module Specification
Department of Electrical Engineering
4 Module Specification
4.1 ALU
4.1.1 Functional Description
The arithmetic-logic unit (ALU) performs basic arithmetic and logic operations
which are controlled by the opcode. The result of the instruction is written to the
output. An additional zero-bit signalizes an high output if the result equals zero.
At the present time, the basic arithmetic operations add and sub and the logic
operations and, or and slt can be applied to inputs. The inputs are 32 bit wide
with type unsigned. A detection of overflow or borrow is not supported at the mo-
ment.
22 M. Linder, M. Schmid, 07/07
33. 4.1 Block Diagram
Department of Electrical Engineering
4.1.2 Block Diagram
Figure 4.1: ALU 1/3
M. Linder, M. Schmid, 07/07 23
34. 4.1 Block Diagram
Department of Electrical Engineering
Figure 4.2: ALU 2/3
24 M. Linder, M. Schmid, 07/07
36. 4.1 Simulation Results
Department of Electrical Engineering
4.1.3 Simulation Results
Figure 4.4: Simulation Results of ALU
4.1.4 Design Files
File Name File Type Description
e_alu.vhd VHDL Source Files Arithmetic-logic unit
a_alu_behave.vhd
t_alu.vhd VHDL Testbench File Testbench for single operations
t_alu_fileio.vhd VHDL Testbench File Testbench using file I/O
26 M. Linder, M. Schmid, 07/07
37. 4.2 Memory
Department of Electrical Engineering
4.2 Memory
4.2.1 Functional Description
Data is synchronously written to or read from the memory with a data bus width
of 32 bit. The memory consists of four ram blocks with 8 bit data width each.
A control signal enables the memory to be written, otherwise data is only read. In
order to store data to the memory the data word is subdivided into four bytes
which are separately written to the ram blocks. Vice versa, the single bytes are
concatenated to get the data word back again.
At the moment, it is only possible to read and write data words. An addressing of
half-words or single bytes is not allowed. In order to write or read data words, all
ram blocks have to be selected. Hence, the lowest two bit are not examined for
chip-select logic.
Data is addressed by the MIPS-processor with an address width of 32 bit, while
the address width of a ram block is 8 bit each. All ram blocks are connected to
the same address, namely from mem_address(9 downto 2). Since we do not use
the full address width for addressing and chip selects, data words are addressed
by multiple addresses.
Unfortunately, some problems occurred during simulation of the memory unit.
According to the MIPS design shown in literature [PaHe98], there should be im-
plemented a memory unit with an unregistered output. The Altera Quartus
MegaWizard Plug-In Manager yielded a ram block with a synchronous output
(a_ram_syn.vhd) , although the output was defined as unregistered.
In order to get an unregistered memory output, another ram block was defined in
VHDL code (a_ram_rtl.vhd). There, the output directly yields the data being ad-
dressed by the unregistered input address. Unfortunately, the synthesizer does
not support memory initialisation files in the RTL-code for setting data to the
memory. Hence, it was not possible to implement the memory in real hardware.
M. Linder, M. Schmid, 07/07 27
38. 4.2 Block Diagram
Department of Electrical Engineering
4.2.2 Block Diagram
Figure 4.5: Memory
4.2.3 Simulation Results
Figure 4.6 shows the simulation results with registered data output.
Figure 4.6: Simulation Results of Memory (registered outputs)
28 M. Linder, M. Schmid, 07/07
39. 4.2 Simulation Results
Department of Electrical Engineering
Figure 4.7 shows the simulation results with unregistered output. Note that the
simulation contains unknown values, because the memory initialisation files are
not supported.
Figure 4.7: Simulation Results of Memory (unregistered outputs)
4.2.4 Design Files
File Name File Type Description
e_ram.vhd VHDL Source Files Ram block used as component for
a_ram_rtl.vhd memory instantiation
a_ram_syn.vhd
a_ram_lpm.vhd
e_memory.vhd VHDL Source Files Instantiation and connection of ram
a_memory_behave.vhd blocks
t_memory.vhd VHDL Testbench Files Test memory read. write and address
./simulation/ram0_256x8.hex Intel Hex Format Files Used for memory initialisation
./simulation/ram1_256x8.hex (a_ram_syn.vhd)
./simulation/ram2_256x8.hex
./simulation/ram3_256x8.hex
M. Linder, M. Schmid, 07/07 29
40. 4.3 Control
Department of Electrical Engineering
4.3 Control
4.3.1 Functional Description
The control of the processor is realised by a Finite State Machine described in
section 2.3.3.
The input to the State Machine are the upper 6 bits of the function field contain-
ing the instruction.
The outputs of the state machine are the control signals of the single functional
units of the processor implementation especially the multiplexers of the datapath.
The Operation Code of the ALU is stored in a truth table and the corresponding
Opcode is produced depending on the ALUOp signal of the state machine and
the lower 6 bits of the function field containing the information which of the arith-
metic or logic instruction is to use.
30 M. Linder, M. Schmid, 07/07
41. 4.3 State Diagram
Department of Electrical Engineering
4.3.2 State Diagram
ErrorState
Figure 4.8: Control Finite State Machine
An additional Error State is inserted which is a deadlock. If any unknown instruc-
tion occurs the Error State is entered.
M. Linder, M. Schmid, 07/07 31
42. 4.3 Block Diagram
Department of Electrical Engineering
4.3.3 Block Diagram
Figure 4.9: Control FSM
Figure 4.10: ALU Control
32 M. Linder, M. Schmid, 07/07
43. 4.3 Block Diagram
Department of Electrical Engineering
Figure 4.11: Control
4.3.4 Simulation Results
Figure 4.12: Simulation Results of the Control FSM
4.3.5 Design Files
File Name File Type Description
e_control_ControlFSM.vhd VHDL Source Files Finite State Machine for Control
a_control_ControlFSM.vhd
e_control_ALUControl.vhd VHDL Source Files Truth Tabel for ALU Control
a_control_ALUControl.vhd
e_control.vhd VHDL Source Files Controlpath
a_control.vhd
M. Linder, M. Schmid, 07/07 33
44. 4.4 Data Path
Department of Electrical Engineering
4.4 Data Path
The datapath is divided into four sections with respect to the pipelining structure
of a processor. The four parts are the Instruction Fetch, Instruction Decode, Exe-
cution and Memory Writeback.
These sections are synthesized of their own and then combined to the Data
Block.
4.4.1 Instruction Fetch
4.4.1.1 Functional Description
The Instruction Fetch Block contains the PC the Instruction Register and the
Memory Data Register.
This part provides the data and instruction form the memory.
4.4.1.2 Block Diagram
Figure 4.13: Instruction Fetch
34 M. Linder, M. Schmid, 07/07
45. 4.4 Instruction Fetch
Department of Electrical Engineering
4.4.1.3 Design Files
File Name File Type Description
e_pc.vhd VHDL Source Files Program Counter
a_pc_behave.vhd
e_tempreg.vhd VHDL Source Files Temporary Memory Data Register
a_tempreg_behave.vhd
e_instreg.vhd VHDL Source Files Instruction Register
a_instreg_behave.vhd
e_data_fetch.vhd VHDL Source Files Instruction Fetch Block
a_data_fetch_behave_vhd
4.4.2 Instruction Decode
4.4.2.1 Functional Description
The Instruction Decode Block writes the instruction of the Instruction Register to
the Register File and computes the second operand for a Branch Instruction or a
sw- or lw-instruction.
4.4.2.2 Block Diagram
Figure 4.14: Instruction Decode
M. Linder, M. Schmid, 07/07 35
46. 4.4 Instruction Decode
Department of Electrical Engineering
4.4.2.3 Design Files
File Name File Type Description
e_regfile.vhd VHDL Source Files Register File
a_regfile_behave.vhd
e_tempreg.vhd VHDL Source Files Temporary Memory Data Register
a_tempreg_behave.vhd
e_data_decode.vhd VHDL Source Files Data Decode Block
a_data_decode_behave.vhd
4.4.3 Execution
4.4.3.1 Functional Description
The Execution contains the ALU as main element and computes the desired re-
sult of the instruction.
It also computes the jump target address and provides it for the Memory Write-
back Block.
The operands loaded to the ALU are chosen by two multiplexers which are sen-
sible to the signals ALUSrcA and ALUSrcB.
36 M. Linder, M. Schmid, 07/07
47. 4.4 Execution
Department of Electrical Engineering
4.4.3.2 Block Diagram
Figure 4.15: Execution
M. Linder, M. Schmid, 07/07 37
48. 4.4 Execution
Department of Electrical Engineering
4.4.3.3 Design Files
File Name File Type Description
e_alu.vhd VHDL Source Files ALU
a_alu_behave.vhd
e_data_execution.vhd VHDL Source Files Execution Block
a_data_execution.vhd
38 M. Linder, M. Schmid, 07/07
49. 4.4 Memory Writeback
Department of Electrical Engineering
4.4.4 Memory Writeback
4.4.4.1 Functional Description
The Memory Writeback Block consists of the ALUOut register and a multiplexer
with source signal PCSource.
This block leads the result of the computation either back to memory or to the
register file.
The multiplexer leads back the next PC value depending on the PCSource sig-
nal.
M. Linder, M. Schmid, 07/07 39
50. 4.4 Memory Writeback
Department of Electrical Engineering
4.4.4.2 Block Diagram
Figure 4.16: Memory Writeback
40 M. Linder, M. Schmid, 07/07
51. 4.4 Memory Writeback
Department of Electrical Engineering
4.4.4.3 Design Files
File Name File Type Description
e_tempreg.vhd VHDL Source Files Temporary ALUOut Register
a_tempreg_behave.vhd
e_data_memwriteback.vhd VHDL Source Files Memory Writeback Block
a_data_memwriteback.vhd
M. Linder, M. Schmid, 07/07 41
52. 4.4 Data Path
Department of Electrical Engineering
4.4.5 Data Path
4.4.5.1 Block Diagram
4.4.5.2 Design Files
File Name File Type Description
e_data.vhd VHDL Source Files Datapath
a_data_vhd
e_data_fetch.vhd VHDL Source Files Data Fetch Block
a_data_fetch.vhd
e_data_decode.vhd VHDL Source Files Data Decode Block
a_data_decode.vhd
e_data_execution.vhd VHDL Source Files Data Execution Block
a_data_execution.vhd
e_data_memwriteback.vhd VHDL Source Files Memory Writeback Block
a_data_memwriteback.vhd
e_tempreg.vhd VHDL Source Files Temporary ALUOut Register
a_tempreg_behave.vhd
e_alu.vhd VHDL Source Files ALU
a_alu_behave.vhd
e_regfile.vhd VHDL Source Files Register File
a_regfile_behave.vhd
e_pc.vhd VHDL Source Files Program Counter
a_pc_behave.vhd
e_instreg.vhd VHDL Source Files Instruction Register
a_instreg_behave.vhd
42 M. Linder, M. Schmid, 07/07
53. 4.5 Processor and Memroy
Department of Electrical Engineering
4.5 Processor and Memroy
4.5.1 Functional Description
The both parts Datapath and Controlpath are combined to the processing unit.
Together with the Memory the whole processor is completed.
4.5.2 Block Diagram
Figure 4.17: Processing Unit (Datapath & Controlpath)
Figure 4.18: Processing Unit & Memory
M. Linder, M. Schmid, 07/07 43
54. 4.5 Design Files
Department of Electrical Engineering
4.5.3 Design Files
File Name File Type Description
e_control_ControlFSM.vhd VHDL Source Files Finite State Machine for Control
a_control_ControlFSM.vhd
e_control_ALUControl.vhd VHDL Source Files Truth Tabel for ALU Control
a_control_ALUControl.vhd
e_control.vhd VHDL Source Files Controlpath
a_control.vhd
e_data.vhd VHDL Source Files Datapath
a_data.vhd
e_data_fetch.vhd VHDL Source Files Data Fetch Block
a_data_fetch.vhd
e_data_decode.vhd VHDL Source Files Data Decode Block
a_data_decode.vhd
e_data_execution.vhd VHDL Source Files Data Execution Block
a_data_execution.vhd
e_data_memwriteback.vhd VHDL Source Files Memory Writeback Block
a_data_memwriteback.vhd
e_tempreg.vhd VHDL Source Files Temporary ALUOut Register
a_tempreg_behave.vhd
e_alu.vhd VHDL Source Files ALU
a_alu_behave.vhd
e_regfile.vhd VHDL Source Files Register File
a_regfile_behave.vhd
e_pc.vhd VHDL Source Files Program Counter
a_pc_behave.vhd
e_instreg.vhd VHDL Source Files Instruction Register
a_instreg_behave.vhd
e_ram.vhd VHDL Source Files Ram block used as component for
a_ram_rtl.vhd memory instantiation
a_ram_syn.vhd
a_ram_lpm.vhd
t_procmem.vhd VHDL Testbench Files Testbench for testing the processor
t_procmem_init.vhd
44 M. Linder, M. Schmid, 07/07
55. 5 Synthesis Results
Department of Electrical Engineering
5 Synthesis Results
+------------------------------------------------------------------------------+
; Analysis & Synthesis Summary ;
+------------------------------------+-----------------------------------------+
; Analysis & Synthesis Status ; Successful - Thu Jul 05 11:15:33 2007 ;
; Quartus II Version ; 7.0 Build 33 02/05/2007 SJ Full Version ;
; Revision Name ; procmem ;
; Top-level Entity Name ; procmem ;
; Family ; Cyclone II ;
; Total logic elements ; 0 ;
; Total combinational functions ; 0 ;
; Dedicated logic registers ; 0 ;
; Total registers ; 0 ;
; Total pins ; 2 ;
; Total virtual pins ; 0 ;
; Total memory bits ; 0 ;
; Embedded Multiplier 9-bit elements ; 0 ;
; Total PLLs ; 0 ;
+------------------------------------+-----------------------------------------+
Figure 5.1: Analysis & Synthesis Summary
+--------------------------------------------------------------------------------------------------------------+
; Analysis & Synthesis Settings ;
+--------------------------------------------------------------------+--------------------+--------------------+
; Option ; Setting ; Default Value ;
+--------------------------------------------------------------------+--------------------+--------------------+
; Device ; EP2C20F484C7 ; ;
; Top-level entity name ; procmem ; procmem ;
; Family name ; Cyclone II ; Stratix ;
; Restructure Multiplexers ; Auto ; Auto ;
; Create Debugging Nodes for IP Cores ; Off ; Off ;
; Preserve fewer node names ; On ; On ;
; Disable OpenCore Plus hardware evaluation ; Off ; Off ;
; Verilog Version ; Verilog_2001 ; Verilog_2001 ;
; VHDL Version ; VHDL93 ; VHDL93 ;
; State Machine Processing ; Auto ; Auto ;
; Safe State Machine ; Off ; Off ;
; Extract Verilog State Machines ; On ; On ;
; Extract VHDL State Machines ; On ; On ;
; Ignore Verilog initial constructs ; Off ; Off ;
; Add Pass-Through Logic to Inferred RAMs ; On ; On ;
; DSP Block Balancing ; Auto ; Auto ;
; NOT Gate Push-Back ; On ; On ;
; Power-Up Don't Care ; On ; On ;
; Remove Redundant Logic Cells ; Off ; Off ;
; Remove Duplicate Registers ; On ; On ;
; Ignore CARRY Buffers ; Off ; Off ;
; Ignore CASCADE Buffers ; Off ; Off ;
; Ignore GLOBAL Buffers ; Off ; Off ;
; Ignore ROW GLOBAL Buffers ; Off ; Off ;
; Ignore LCELL Buffers ; Off ; Off ;
; Ignore SOFT Buffers ; On ; On ;
; Limit AHDL Integers to 32 Bits ; Off ; Off ;
; Optimization Technique -- Cyclone II ; Balanced ; Balanced ;
; Carry Chain Length -- Stratix/Stratix GX/Cyclone/MAX II/Cyclone II ; 70 ; 70 ;
; Auto Carry Chains ; On ; On ;
; Auto Open-Drain Pins ; On ; On ;
; Perform WYSIWYG Primitive Resynthesis ; Off ; Off ;
; Perform gate-level register retiming ; Off ; Off ;
; Allow register retiming to trade off Tsu/Tco with Fmax ; On ; On ;
; Auto ROM Replacement ; On ; On ;
; Auto RAM Replacement ; On ; On ;
; Auto Shift Register Replacement ; On ; On ;
; Auto Clock Enable Replacement ; On ; On ;
; Allow Synchronous Control Signals ; On ; On ;
; Force Use of Synchronous Clear Signals ; Off ; Off ;
; Auto RAM to Logic Cell Conversion ; Off ; Off ;
; Auto Resource Sharing ; Off ; Off ;
; Allow Any RAM Size For Recognition ; Off ; Off ;
; Allow Any ROM Size For Recognition ; Off ; Off ;
; Allow Any Shift Register Size For Recognition ; Off ; Off ;
; Ignore translate_off and synthesis_off directives ; Off ; Off ;
; Show Parameter Settings Tables in Synthesis Report ; On ; On ;
; Ignore Maximum Fan-Out Assignments ; Off ; Off ;
M. Linder, M. Schmid, 07/07 45
57. 6 Results of Prototype Testing
Department of Electrical Engineering
6 Results of Prototype Testing
6.1 Description
For the first test of the completed processor and the memory a simple addition of
two numbers was done.
Therefore at first the memory has to be loaded with the instructions and data by
using *.mif-files to write the information into the memory blocks before starting
the simulation.
The instructions written into the memory are:
Memory Instruction Field
Address Instruction op rs rt rd shamt funct
000 lw $s0, 128($zero) 100011 00000 10000 0000000010000000
004 lw $s1, 132($zero) 100011 00000 10001 0000000010000100
008 add $s2, $s0, $s1 000000 10000 10001 10010 00000 100000
012 sw $s2, 136($zero) 101011 00000 10010 0000000010001000
016 sub $s3, $s1, $s0 000000 10001 10000 10011 00000 100010
020 sw $s3, 140($zero) 101011 00000 10011 0000000010001100
024 and $s4, $s1, $s0 000000 10001 10000 10100 00000 100100
028 sw $s4, 144($zero) 101011 00000 10100 0000000010010000
032 or $s5, $s1, $s0 000000 10001 10000 10101 00000 100101
036 sw $s5, 148($zero) 101011 00000 10101 0000000010010100
040 slt $s6, $s1, $s0 000000 10000 10001 10110 00000 101010
044 sw $s6, 152($zero) 101011 00000 10110 0000000010011000
048 beq $s0, $s4, 56 000100 10000 10100 0000000000000001
052 UNDEFINED UUUUUU UUUUU UUUUU UUUUU UUUUU UUUUUU
056 j8 000010 00000000000000000000000010
The data written to the memory are:
Memory
Address Data (dec) Data (bin)
128 379 00000000 00000000 00000001 01111011
132 383 00000000 00000000 00000001 01111111
M. Linder, M. Schmid, 07/07 47
58. 6.1 Description
Department of Electrical Engineering
The expected values stored back into the memory are:
Memory
Address Data (dec) Data (bin)
136 762 00000000 00000000 00000010 11111010
140 4 00000000 00000000 00000000 00000100
144 379 00000000 00000000 00000001 01111011
148 383 00000000 00000000 00000001 01111111
152 1 00000000 00000000 00000000 00000001
The simulation starts at memory address 000 with a load word instruction. The
value of memory address 128 is written into register $s0. The PC is incremented
and the next instruction of memory address 004 is executed. It is also an load
word instruction which loads the value of memory address 132 to register $s1.
Then an add instruction follows which adds the two operands written into the reg-
isters $s0 and $s1 and writes the result to register $s2.
Then a store word instruction writes the content of register $s2 to the memory at
address 136.
The following instructions are for subtract, add, or, slt, beq and jump. The result
of a computation is always stored to the memory by a store word instruction.
Note:
For description of the register numbers and names used for the test see Figure
3.13 of [PaHe98] p. 140.
The used assembler instructions are not completely declared in this report.
For information on the machine language see [PaHe98] Chapter 3, especially fig-
ure 3.14 on page 141.
48 M. Linder, M. Schmid, 07/07
59. 6.2 Simulation Result
Department of Electrical Engineering
6.2 Simulation Result
Figure 6.1: Simulation Results of MIPS and Memory
M. Linder, M. Schmid, 07/07 49
60. 7 Conclusion
Department of Electrical Engineering
7 Conclusion
7.1 Our own experiences
While working on our miniproject, we applied a lot of knowledge learned in the
lecture VHDL. Furthermore, we gained a lot of experience in using the simulation
and synthesis tools. It was very interesting and exciting to describe real hardware
and to see the expected results in simulation and the block diagrams after syn-
thesis.
Our miniproject implementing a processor in VHDL has been a real challenge.
The complexity was not located in the single components, but rather in the imple-
mentation of the synchronous operation of the whole control and datapath. Due
to an intensive preparation of the desired hardware according to the literature
“Computer Organization & Design” [PaHe98], we prevented unintended design
errors. Since our project transcends a pure implementation of VHDL code, we
were able to gain experience in hierarchical design with component instantiation
and package design.
Additionally, while implementing a microprocessor, we could refresh our knowl-
edge in processor operations, memory addressing and MIPS instruction coding.
7.2 Annotations to “Computer Organization & Design” [PaHe98]
Since the design of our MIPS processor is closely connected to the literature
[PaHe98], we read the chapter 5 in detail. Overall, we adjusted the design as
conform as possible to the description in [PaHe98]. There are some passages
which do not provide a full description, e.g. the output signals of the control FSM
are not listed completely for each state. Nevertheless, “Computer Organization &
Design” by Patterson and Hennessy provides a brilliant composition describing
the control and datapath of a processor implementation.
50 M. Linder, M. Schmid, 07/07
61. 7.3 Further work on the project
Department of Electrical Engineering
7.3 Further work on the project
Although we spent much more time than scheduled, we did not reach all our
aims. For further work on the project, we recommend our successors to continue
the following tasks:
– Verify the synthesis results (with VHDL code created by Quartus) with desired
behavior implemented in RTL and seen in testbench simulation in order to
obtain the desired unregistered memory output mentioned in chapter 4.2.
– Realise an hardware implementation of processor and memory in order to
verify the behavior of the desired hardware on the Cyclone II Development &
Education Board, e.g. debug the memory data.
– Introduce the pipelining of instructions described in chapter 6 [PaHe98] to im-
prove the performance of the MIPS processor.
M. Linder, M. Schmid, 07/07 51
62. 8 Appendix
Department of Electrical Engineering
8 Appendix
8.1 Design files
8.1.1 Project Entities
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
ENTITY ControlFSM IS
PORT (clk, rst_n : IN std_ulogic;
instr_31_26 : IN std_ulogic_vector(5 downto 0);
RegDst, RegWrite, ALUSrcA, MemRead, MemWrite, MemtoReg, IorD, IRWrite, PCWrite,
PCWriteCond : OUT std_ulogic;
ALUOp, ALUSrcB, PCSource : OUT std_ulogic_vector(1 downto 0)
);
END ControlFSM;
VHDLSource 8.1: e_control_ControlFSM.vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
ENTITY ALUControl IS
PORT (instr_15_0 : IN std_ulogic_vector(15 downto 0);
ALUOp : IN std_ulogic_vector(1 downto 0);
ALUopcode : OUT std_ulogic_vector(2 downto 0)
);
END ALUControl;
VHDLSource 8.2: e_control_ALUControl.vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
ENTITY control IS
PORT (clk, rst_n : IN std_ulogic;
instr_31_26 : IN std_ulogic_vector(5 downto 0);
instr_15_0 : IN std_ulogic_vector(15 downto 0);
zero : IN std_ulogic;
ALUopcode : OUT std_ulogic_vector(2 downto 0);
RegDst, RegWrite, ALUSrcA, MemRead, MemWrite, MemtoReg, IorD, IRWrite : OUT
std_ulogic;
ALUSrcB, PCSource : OUT std_ulogic_vector(1 downto 0);
PC_en : OUT std_ulogic
);
END control
VHDLSource 8.3: e_control.vhd
52 M. Linder, M. Schmid, 07/07
63. 8.1 Project Entities
Department of Electrical Engineering
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY tempreg IS
PORT (
clk : IN STD_ULOGIC;
rst_n : IN STD_ULOGIC;
reg_in : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
reg_out : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0) );
END tempreg
VHDLSource 8.4: e_tempreg.vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY pc IS
PORT (
clk : IN STD_ULOGIC;
rst_n : IN STD_ULOGIC;
pc_in : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
PC_en : IN STD_ULOGIC;
pc_out : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0) );
END pc;
VHDLSource 8.5: e_pc.vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY instreg IS
PORT (
clk : IN STD_ULOGIC;
rst_n : IN STD_ULOGIC;
memdata : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
IRWrite : IN STD_ULOGIC;
instr_31_26 : OUT STD_ULOGIC_VECTOR(5 DOWNTO 0);
instr_25_21 : OUT STD_ULOGIC_VECTOR(4 DOWNTO 0);
instr_20_16 : OUT STD_ULOGIC_VECTOR(4 DOWNTO 0);
instr_15_0 : OUT STD_ULOGIC_VECTOR(15 DOWNTO 0) );
END instreg;
VHDLSource 8.6: e_instreg.vhd
M. Linder, M. Schmid, 07/07 53
64. 8.1 Project Entities
Department of Electrical Engineering
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY regfile IS
PORT (clk,rst_n : IN std_ulogic;
wen : IN std_ulogic; -- write control
writeport : IN std_ulogic_vector(width-1 DOWNTO 0); -- register input
adrwport : IN std_ulogic_vector(regfile_adrsize-1 DOWNTO 0);-- address write
adrport0 : IN std_ulogic_vector(regfile_adrsize-1 DOWNTO 0);-- address port 0
adrport1 : IN std_ulogic_vector(regfile_adrsize-1 DOWNTO 0);-- address port 1
readport0 : OUT std_ulogic_vector(width-1 DOWNTO 0); -- output port 0
readport1 : OUT std_ulogic_vector(width-1 DOWNTO 0) -- output port 1
);
END regfile;
VHDLSource 8.7: e_regfile.vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY alu IS
PORT (
a, b : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
opcode : IN STD_ULOGIC_VECTOR(2 DOWNTO 0);
result : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
zero : OUT STD_ULOGIC);
END alu;
VHDLSource 8.8: e_alu_vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY data_fetch IS
PORT (
-- inputs
clk : IN STD_ULOGIC;
rst_n : IN STD_ULOGIC;
pc_in : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
alu_out : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
mem_data : IN std_ulogic_vector(width-1 DOWNTO 0);
-- control signals
PC_en : IN STD_ULOGIC;
IorD : IN STD_ULOGIC;
IRWrite : IN STD_ULOGIC;
-- outputs
reg_memdata : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
instr_31_26 : OUT STD_ULOGIC_VECTOR(5 DOWNTO 0);
instr_25_21 : OUT STD_ULOGIC_VECTOR(4 DOWNTO 0);
instr_20_16 : OUT STD_ULOGIC_VECTOR(4 DOWNTO 0);
instr_15_0 : OUT STD_ULOGIC_VECTOR(15 DOWNTO 0);
mem_address : OUT std_ulogic_vector(width-1 DOWNTO 0);
pc_out : OUT std_ulogic_vector(width-1 DOWNTO 0)
);
END data_fetch;
VHDLSource 8.9: e_data_fetch.vhd
54 M. Linder, M. Schmid, 07/07
65. 8.1 Project Entities
Department of Electrical Engineering
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY data_decode IS
PORT (
-- inputs
clk : IN STD_ULOGIC;
rst_n : IN STD_ULOGIC;
instr_25_21 : IN STD_ULOGIC_VECTOR(4 DOWNTO 0);
instr_20_16 : IN STD_ULOGIC_VECTOR(4 DOWNTO 0);
instr_15_0 : IN STD_ULOGIC_VECTOR(15 DOWNTO 0);
reg_memdata : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
alu_out : IN STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
-- control signals
RegDst : IN STD_ULOGIC;
RegWrite : IN STD_ULOGIC;
MemtoReg : IN STD_ULOGIC;
-- outputs
reg_A : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
reg_B : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
instr_15_0_se : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0);
instr_15_0_se_sl : OUT STD_ULOGIC_VECTOR(width-1 DOWNTO 0)
);
END data_decode;
VHDLSource 8.10: e_data_decode.vhd
LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;
USE IEEE.numeric_std.ALL;
-- use package
USE work.procmem_definitions.ALL;
ENTITY data_execution IS
PORT (instr_25_21 : IN std_ulogic_vector(4 downto 0);
instr_20_16 : IN std_ulogic_vector(4 downto 0);
instr_15_0 : IN std_ulogic_vector(15 downto 0);
ALUSrcA : IN std_ulogic;
ALUSrcB : IN std_ulogic_vector(1 downto 0);
ALUopcode : IN std_ulogic_vector(2 downto 0);
reg_A, reg_B : IN std_ulogic_vector(width-1 downto 0);
pc_out : IN std_ulogic_vector(width-1 downto 0);
instr_15_0_se : IN std_ulogic_vector(width-1 downto 0);
instr_15_0_se_sl : IN std_ulogic_vector(width-1 downto 0);
jump_addr : OUT std_ulogic_vector(width-1 downto 0);
alu_result : OUT std_ulogic_vector(width-1 downto 0);
zero : OUT std_ulogic
);
END data_execution;
VHDLSource 8.11: e_data_execution.vhd
M. Linder, M. Schmid, 07/07 55