http://iis-projects.ee.ethz.ch/api.php?action=feedcontributions&user=Nwistoff&feedformat=atomiis-projects - User contributions [en]2024-03-29T09:21:58ZUser contributionsMediaWiki 1.28.0http://iis-projects.ee.ethz.ch/index.php?title=Implementation_of_a_Coherent_Application-Class_Multicore_System_(1-2S)&diff=8397Implementation of a Coherent Application-Class Multicore System (1-2S)2022-11-15T14:41:16Z<p>Nwistoff: Created page with "Category:Digital Category:High Performance SoCs Category:Computer Architecture Category:2023 Category:Semester Thesis Category:Nwistoff Category:Avai..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2023]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Status: Available ==<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. Ariane features a write-back level 1 data cache, which temporally stores a copy of recently accessed memory contents to accelerate future accesses to this data.<br />
<br />
To increase a system's performance on parallel workloads, a common technique is to combine multiple instances of a core to a ''multi-core'' system. This technique introduces a new challenge: Each core keeps its own copy of the (partial) main memory in its respective L1 data cache. Working of different copies of the same data can quickly result in inconsistencies between the cores' memory views.<br />
<br />
This challenge can be tackled by introducing ''cache-coherence'', a set of mechanisms that keep the local caches synchronized and up-to-date. Cache coherence for Ariane is currently under development and a prototype is expected to become available soon.<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement a chip featuring multiple coherent Ariane cores. Throughout this project, the feasibility and performance of the system shall be evaluated.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II<br />
<br />
Composition: 20% RTL Implementation, 50% Chip Backend, 30% Verification<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Coherence-Capable_Write-Back_L1_Data_Cache_for_Ariane_(M)&diff=8396Coherence-Capable Write-Back L1 Data Cache for Ariane (M)2022-11-15T14:32:25Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Zarubaf]]<br />
[[Category:In progress]]<br />
<br />
<br />
== Status: In Progress ==<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. Ariane features a write-back level 1 data cache, which temporally stores a copy of recently accessed memory contents to accelerate future accesses to this data.<br />
<br />
To increase a system's performance on parallel workloads, a common technique is to combine multiple instances of a core to a ''multi-core'' system. This technique introduces a new challenge: Each core keeps its own copy of the (partial) main memory in its respective L1 data cache. Working of different copies of the same data can quickly result in inconsistencies between the cores' memory views.<br />
<br />
This challenge can be tackled by introducing ''cache-coherence'', a set of mechanisms that keep the local caches synchronized and up-to-date.<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement general coherence support in Ariane’s write-back L1 data cache, so that it can be integrated into various coherent memory systems. For instance,<br />
* the cache needs to track and handle additional state of the cache lines, e.g. whether they are unique or shared, and<br />
* a coherent memory system must be able to invalidate or update specific cache lines, and to request specific cache lines for forwarding or write-back.<br />
<br />
Depending on the work’s progress, this functionality can be demonstrated by implementing adapters to existing coherent interconnects, such as OpenPiton’s NoCs [2,3], BlackParrot’s BedRock [4], or SiFive’s TileLink [5] and thus building a sample multi-core system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II<br />
<br />
Composition: 30% Architecture specification, 40% Verification, 30% RTL Implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] http://parallel.princeton.edu/papers/openpiton-asplos16.pdf<br />
* [3] http://www.parallel.princeton.edu/papers/aspl20-balkind.pdf<br />
* [4] https://github.com/black-parrot/black-parrot/blob/master/docs/bedrock_guide.md<br />
* [5] https://sifive.cdn.prismic.io/sifive%2Fcab05224-2df1-4af8-adee-8d9cba3378cd_tilelink-spec-1.8.0.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=A_Flexible_FPGA-Based_Peripheral_Platform_Extending_Linux-Capable_Systems_on_Chip_(1-3S/B)&diff=7974A Flexible FPGA-Based Peripheral Platform Extending Linux-Capable Systems on Chip (1-3S/B)2022-08-15T17:58:55Z<p>Nwistoff: Created page with "Category:Digital Category:High Performance SoCs Category:Computer Architecture Category:FPGA Category:2022 Category:Semester Thesis Category:Bachelor..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:FPGA]]<br />
[[Category:2022]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Tbenz]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Status: Available ==<br />
<br />
* Professor: Prof. Dr. L. Benini<br />
* Supervisors:<br />
** [[:User:Tbenz | Thomas Benz]]: [mailto:tbenz@iis.ee.ethz.ch tbenz@iis.ee.ethz.ch]<br />
** [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== Introduction ==<br />
<br />
Recent PULP chips, such as [http://asic.ethz.ch/2022/Occamy.html Occamy] or [http://asic.ethz.ch/2022/Neo.html Neo], feature a Linux-capable '''CVA6''' core [1] and a '''Serial Link''' off-chip interface. While the chips contain a few basic peripherals that allow running Linux (such as UART, GPIO), further peripherals to extend their functionality (e.g. Ethernet, USB Host, DVI/HDMI) are desirable.<br />
<br />
The idea of this project is to bring up an FPGA-based peripheral platform that can be connected to existing chips via Serial Link to extend their functionality.<br />
<br />
== Project ==<br />
<br />
This project involves both creating the FPGA platform and extending the software stack (e.g. Linux) running on the ASIC to use it.<br />
<br />
===== Tasks =====<br />
<br />
====== Hardware Design ====== <br />
<br />
* '''Serial-Link-capable base platform:''' Design an FPGA platform that can be accessed via Serial Link.<br />
<br />
* '''Integration of an Ethernet Peripheral:''' Integrate an Ethernet controller that communicates with the on-board Ethernet PHY.<br />
<br />
* '''Integration of PAPER:''' Integrate PAPER, a DVI/HDMI peripheral developed in previous student projects.<br />
<br />
====== Software Design ======<br />
<br />
* '''Bare-Metal Applications:''' Prototype bare-metal applications that access the integrated peripherals.<br />
<br />
* '''U-Boot and Linux Device Drivers:''' Integrate the necessary drivers in U-Boot and Linux to use the integrated peripherals<br />
<br />
<br />
====== Stretch Goals ======<br />
<br />
Depending on your progress and interests, several further steps can be considered, such as:<br />
<br />
* '''Integration of further peripherals:''' Further peripherals can be integrated in hardware and software, such as SPI devices and a USB Host.<br />
<br />
We can also discuss targeting a subset of the tasks above depending on your time frame and interests.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest system design and hardware/software interaction<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Basic knowledge of operating systems<br />
<br />
Composition: 40% RTL Implementation, 20% Verification, 40% Software Design<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Tbenz | Thomas Benz]]: [mailto:tbenz@iis.ee.ethz.ch tbenz@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Serverless_Benchmarks_on_RISC-V_(M)&diff=7356Serverless Benchmarks on RISC-V (M)2021-12-06T19:41:39Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2021]]<br />
[[Category:Master Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The introduction of function-as-a-service (FaaS) or serverless cloud services has re-opened a number of interesting research questions about software architecture, operating systems, security, and hardware [6]. For example, the steady move from monolithic applications to collections of microservices is based upon a number of advantages such as increased modularity and functional independence [4]. The modification, upgrade, or deployment of functionality becomes significantly simpler, and scaling out of individual services can be made much more dynamic. Microservices also allow for greater heterogeneity in both software (e.g. using different languages) and hardware (e.g. accelerators). Heterogeneous hardware such as TPUs, VPUs, and FPGAs are finding increasing use in datacenters for accelerating applications. This can be even more significant when using serverless or function-as-a-service (FaaS) architectures.<br />
<br />
However, this modularity comes with potential drawbacks including increased inter- function latency, unforeseen interactions due to the complexity of the functional graph, and challenges in deployment, allocation, and management. The behavior of these microservices/functions has been shown to have very different performance characteristics from traditional monolithic applications. For example, a short-running function makes significantly less use of sophisticated branch predictors or large caches found in modern server processors [7]. This preliminary research suggests that the complexity of modern processors is not especially suited to serverless functions and we would like to undertake a more thorough exploration of the design space of microarchitectural features.<br />
<br />
One way to examine different microarchitectural features is to use an open-source CPU design which allows for relatively easy modications of various units (e.g. branch predictor, cache, ALUs) as well as additions to the ISA. The first step is to get a set of serverless benchmarks runnning on an open-source CPU, in this case, the open-source RISC-V CPU CVA6 (formerly Ariane) [8]. CVA6 is a thoroughly documented and tested application class 6-stage RISC-V CPU capable of booting Linux [1]. The ultimate goal is to compare the performance of a broad set of functions running on various processor architectures (e.g. Intel/AMD x86, ARMv8, RISC-V) in order to gain insight into what types of architectural features and resources are best suited for different types of lambdas.<br />
<br />
== Project ==<br />
<br />
In order to test benchmarks on the CVA6 core, it must be built and loaded onto the Xilinx Ultrascale+ FPGA found on Enzian. As the CVA6 core is already running in the Xilinx toolchain, and there are reports of it working on the VCU118 [2] which contains the same model FPGA as Enzian, this should not be a significant roadblock, but it may involve modifying block diagrams, projects, etc.<br />
<br />
In parallel, a benchmarking suite (or subset of benchmarks) should be decided upon and tested. There are a number of possible benchmarks that could be used [5, 3]. Most importantly, it should (be made to) run on a RISC-V Linux distribution. This does not initially have to be the CVA6 core on the FPGA, but could be on a hard RISC-V core for testing and debugging. Ideally, we would also run the same set of benchmarks on an Intel/AMD x86 processor (possibly via Cloudlab), and an ARMv8 such as the ThunderX1 found in Enzian.<br />
<br />
===== Experimental Evaluation =====<br />
<br />
Extensive measurements should be collected for analyzing power and performance of the benchmarks across architectures. Aside from obvious metrics such as latency and execution time, we place special emphasis on behavior of specific microarchitectural elements (e.g. branch predictors, caches) as well as energy measurements (e.g. instructions per joule). It is important to keep in mind that this is exploratory work and thus certain desired measurements may not be available on the CVA6 core, and these limitations will not impact the outcome of this thesis.<br />
<br />
===== Work Plan =====<br />
<br />
The work consists of the following units:<br />
# A critical survey of the relevant related work and important ideas<br />
# Running the CVA6 core on the Enzian FPGA.<br />
# Porting one or more serverless function benchmarks to the RISC-V architecture.<br />
# An evaluation of the work based on Section 3 above, or subsequent revisions.<br />
<br />
===== Requirements ===== <br />
<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Programming Languages: C, Python<br />
* Tools: git, Vivado, Vitis<br />
<br />
Composition: 30% Architecture specification, 30% RTL implementation, 40% Software implementation<br />
<br />
===== Project Supervisors =====<br />
<br />
This project is a collaboration with the Systems Group of D-INFK and will be jointly supervised.<br />
<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* Tom Kucher: [mailto:tom.kuchler@inf.ethz.ch tom.kuchler@inf.ethz.ch]<br />
* Michael Giardino: [mailto:michael.giardino@inf.ethz.ch michael.giardino@inf.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] CVA6 (fka Ariane) Github Repository.[[https://github.com/openhwgroup/cva6 Link]]<br />
* [2] CVA6 Github Issue Tracker: Support more FPGA boards 154. [[https://github.com/openhwgroup/cva6/issues/154 Link]]<br />
* [3] Copik et al., "Sebs: A serverless benchmark suite for function-as-a-service computing", Middleware 2021. [[https://arxiv.org/abs/2012.14132 Link]]<br />
* [4] Gan et al., "An open-source benchmark suite for microservices and their hardware-software implications for cloud and edge systems", ASPLOS 2019. [[https://dl.acm.org/doi/abs/10.1145/3297858.3304013 Link]]<br />
* [5] Maissen et al., "FaaSdom: A benchmark suite for serverless computing", DEBS 2020. [[https://dl.acm.org/doi/abs/10.1145/3401025.3401738 Link]] <br />
* [6] Raza et al., "SoK: Function-as-a- Service: From An Application Developer’s Perspective", JSys 2021. [[https://escholarship.org/uc/item/1wg7h0qf Link]]<br />
* [7] Shahrad et al., "Architectural implications of function-as-a-service computing", MICRO 2019. [[https://dl.acm.org/doi/abs/10.1145/3352460.3358296 Link]]<br />
* [8] Zaruba and Benini, "Energy and performance analysis of a Linux-ready 1.7-GHz 64-bit RISC-V core in 22-nm FDSOI technology", VLSI 2019. [[https://arxiv.org/abs/1904.05442 Link]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Serverless_Benchmarks_on_RISC-V_(M)&diff=7355Serverless Benchmarks on RISC-V (M)2021-12-06T17:48:57Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2021]]<br />
[[Category:Master Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The introduction of function-as-a-service (FaaS) or serverless cloud services has re-opened a number of interesting research questions about software architecture, operating systems, security, and hardware [6]. For example, the steady move from monolithic applications to collections of microservices is based upon a number of advantages such as increased modularity and functional independence [4]. The modification, upgrade, or deployment of functionality becomes significantly simpler, and scaling out of individual services can be made much more dynamic. Microservices also allow for greater heterogeneity in both software (e.g. using different languages) and hardware (e.g. accelerators). Heterogeneous hardware such as TPUs, VPUs, and FPGAs are finding increasing use in datacenters for accelerating applications. This can be even more significant when using serverless or function-as-a-service (FaaS) architectures.<br />
<br />
However, this modularity comes with potential drawbacks including increased inter- function latency, unforeseen interactions due to the complexity of the functional graph, and challenges in deployment, allocation, and management. The behavior of these microservices/functions has been shown to have very different performance characteristics from traditional monolithic applications. For example, a short-running function makes significantly less use of sophisticated branch predictors or large caches found in modern server processors [7]. This preliminary research suggests that the complexity of modern processors is not especially suited to serverless functions and we would like to undertake a more thorough exploration of the design space of microarchitectural features.<br />
<br />
One way to examine different microarchitectural features is to use an open-source CPU design which allows for relatively easy modications of various units (e.g. branch predictor, cache, ALUs) as well as additions to the ISA. The first step is to get a set of serverless benchmarks runnning on an open-source CPU, in this case, the open-source RISC-V CPU CVA6 (formerly Ariane) [8]. CVA6 is a thoroughly documented and tested application class 6-stage RISC-V CPU capable of booting Linux [1]. The ultimate goal is to compare the performance of a broad set of functions running on various processor architectures (e.g. Intel/AMD x86, ARMv8, RISC-V) in order to gain insight into what types of architectural features and resources are best suited for different types of lambdas.<br />
<br />
== Project ==<br />
<br />
In order to test benchmarks on the CVA6 core, it must be built and loaded onto the Xilinx Ultrascale+ FPGA found on Enzian. As the CVA6 core is already running in the Xilinx toolchain, and there are reports of it working on the VCU118 [2] which contains the same model FPGA as Enzian, this should not be a significant roadblock, but it may involve modifying block diagrams, projects, etc.<br />
<br />
In parallel, a benchmarking suite (or subset of benchmarks) should be decided upon and tested. There are a number of possible benchmarks that could be used [5, 3]. Most importantly, it should (be made to) run on a RISC-V Linux distribution. This does not initially have to be the CVA6 core on the FPGA, but could be on a hard RISC-V core for testing and debugging. Ideally, we would also run the same set of benchmarks on an Intel/AMD x86 processor (possibly via Cloudlab), and an ARMv8 such as the ThunderX1 found in Enzian.<br />
<br />
===== Experimental Evaluation =====<br />
<br />
Extensive measurements should be collected for analyzing power and performance of the benchmarks across architectures. Aside from obvious metrics such as latency and execution time, we place special emphasis on behavior of specific microarchitectural elements (e.g. branch predictors, caches) as well as energy measurements (e.g. instructions per joule). It is important to keep in mind that this is exploratory work and thus certain desired measurements may not be available on the CVA6 core, and these limitations will not impact the outcome of this thesis.<br />
<br />
===== Work Plan =====<br />
<br />
The work consists of the following units:<br />
# A critical survey of the relevant related work and important ideas<br />
# Running the CVA6 core on the Enzian FPGA.<br />
# Porting one or more serverless function benchmarks to the RISC-V architecture.<br />
# An evaluation of the work based on Section 3 above, or subsequent revisions.<br />
<br />
===== Requirements ===== <br />
<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Programming Languages: C, Python<br />
* Tools: git, Vivado, Vitis<br />
<br />
Composition: 30% Architecture specification, 30% RTL implementation, 40% Software implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] CVA6 (fka Ariane) Github Repository. https://github.com/openhwgroup/cva6<br />
* [2] CVA6 Github Issue Tracker: Support more FPGA boards 154. https://github.com/openhwgroup/cva6/issues/154<br />
* [3] Copik et al., "Sebs: A serverless benchmark suite for function-as-a-service computing", Middleware 2021. (Link)[https://arxiv.org/abs/2012.14132]<br />
* [4] Gan et al., "An open-source benchmark suite for microservices and their hardware-software implications for cloud and edge systems", ASPLOS 2019.<br />
* [5] Maissen et al., "FaaSdom: A benchmark suite for serverless computing", DEBS 2020.<br />
* [6] Raza et al., "SoK: Function-as-a- Service: From An Application Developer’s Perspective", JSys 2021.<br />
* [7] Shahrad et al., "Architectural implications of function-as-a-service computing", MICRO 2019.<br />
* [8] Zaruba and Benini, "Energy and per- formance analysis of a Linux-ready 1.7-GHz 64-bit RISC-V core in 22-nm FDSOI technology", VLSI 2019.</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Serverless_Benchmarks_on_RISC-V_(M)&diff=7354Serverless Benchmarks on RISC-V (M)2021-12-06T17:48:40Z<p>Nwistoff: Created page with "Category:Digital Category:High Performance SoCs Category:Computer Architecture Category:2021 Category:Master Thesis Category:Nwistoff Category:Availa..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2021]]<br />
[[Category:Master Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The introduction of function-as-a-service (FaaS) or serverless cloud services has re-opened a number of interesting research questions about software architecture, operating systems, security, and hardware [6]. For example, the steady move from monolithic applications to collections of microservices is based upon a number of advantages such as increased modularity and functional independence [4]. The modification, upgrade, or deployment of functionality becomes significantly simpler, and scaling out of individual services can be made much more dynamic. Microservices also allow for greater heterogeneity in both software (e.g. using different languages) and hardware (e.g. accelerators). Heterogeneous hardware such as TPUs, VPUs, and FPGAs are finding increasing use in datacenters for accelerating applications. This can be even more significant when using serverless or function-as-a-service (FaaS) architectures.<br />
<br />
However, this modularity comes with potential drawbacks including increased inter- function latency, unforeseen interactions due to the complexity of the functional graph, and challenges in deployment, allocation, and management. The behavior of these microservices/functions has been shown to have very different performance characteristics from traditional monolithic applications. For example, a short-running function makes significantly less use of sophisticated branch predictors or large caches found in modern server processors [7]. This preliminary research suggests that the complexity of modern processors is not especially suited to serverless functions and we would like to undertake a more thorough exploration of the design space of microarchitectural features.<br />
<br />
One way to examine different microarchitectural features is to use an open-source CPU design which allows for relatively easy modications of various units (e.g. branch predictor, cache, ALUs) as well as additions to the ISA. The first step is to get a set of serverless benchmarks runnning on an open-source CPU, in this case, the open-source RISC-V CPU CVA6 (formerly Ariane) [8]. CVA6 is a thoroughly documented and tested application class 6-stage RISC-V CPU capable of booting Linux [1]. The ultimate goal is to compare the performance of a broad set of functions running on various processor architectures (e.g. Intel/AMD x86, ARMv8, RISC-V) in order to gain insight into what types of architectural features and resources are best suited for different types of lambdas.<br />
<br />
== Project ==<br />
<br />
In order to test benchmarks on the CVA6 core, it must be built and loaded onto the Xilinx Ultrascale+ FPGA found on Enzian. As the CVA6 core is already running in the Xilinx toolchain, and there are reports of it working on the VCU118 [2] which contains the same model FPGA as Enzian, this should not be a significant roadblock, but it may involve modifying block diagrams, projects, etc.<br />
<br />
In parallel, a benchmarking suite (or subset of benchmarks) should be decided upon and tested. There are a number of possible benchmarks that could be used [5, 3]. Most importantly, it should (be made to) run on a RISC-V Linux distribution. This does not initially have to be the CVA6 core on the FPGA, but could be on a hard RISC-V core for testing and debugging. Ideally, we would also run the same set of benchmarks on an Intel/AMD x86 processor (possibly via Cloudlab), and an ARMv8 such as the ThunderX1 found in Enzian.<br />
<br />
===== Experimental Evaluation =====<br />
<br />
Extensive measurements should be collected for analyzing power and performance of the benchmarks across architectures. Aside from obvious metrics such as latency and execution time, we place special emphasis on behavior of specific microarchitectural elements (e.g. branch predictors, caches) as well as energy measurements (e.g. instructions per joule). It is important to keep in mind that this is exploratory work and thus certain desired measurements may not be available on the CVA6 core, and these limitations will not impact the outcome of this thesis.<br />
<br />
===== Work Plan =====<br />
<br />
The work consists of the following units:<br />
# A critical survey of the relevant related work and important ideas<br />
# Running the CVA6 core on the Enzian FPGA.<br />
# Porting one or more serverless function benchmarks to the RISC-V architecture.<br />
# An evaluation of the work based on Section 3 above, or subsequent revisions.<br />
<br />
===== Requirements ===== <br />
<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Programming Languages: C, Python<br />
* Tools: git, Vivado, Vitis<br />
<br />
Composition: 30% Architecture specification, 30% RTL implementation, 40% Software implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] CVA6 (fka Ariane) Github Repository. https://github.com/openhwgroup/cva6<br />
* [2] CVA6 Github Issue Tracker: Support more FPGA boards 154. https://github.com/openhwgroup/cva6/issues/154<br />
* [3] Copik et al., "Sebs: A serverless benchmark suite for function-as-a-service computing", Middleware 2021. (Link)[https://arxiv.org/abs/2012.14132]<br />
* [4] Gan et al., "An open-source benchmark suite for microservices and their hardware-software implications for cloud and edge systems", ASPLOS 2019.<br />
* [5] Maissen et al., "FaaSdom: A benchmark suite for serverless computing", DEBS 2020.<br />
* [6] Raza et al., "SoK: Function-as-a- Service: From An Application Developer’s Perspective", JSys 2021.<br />
* [7] Shahrad et al., "Architectural implications of function-as-a-service computing", MICRO 2019.<br />
* [8] Zaruba and Benini, "Energy and per- formance analysis of a Linux-ready 1.7-GHz 64-bit RISC-V core in 22-nm FDSOI technology", VLSI 2019.</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Implementation_of_an_AES_Hardware_Processing_Engine_(B/S)&diff=7353Implementation of an AES Hardware Processing Engine (B/S)2021-12-06T17:14:22Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:Cryptography]]<br />
[[Category:2021]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Completed]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The Advanced Encryption Standard (AES) [1] is an encryption algorithm used in many of today's applications. It operates in multiple rounds on fixed-size data blocks, converting a clear-text data stream into an encrypted one (or vice-versa). This process is computationally expensive, and can become a bottleneck when applied on large amounts of data. A solution to this problem is a dedicated hardware accelerator that directly operates on the data that should be en-/decrypted. <br />
<br />
== Project ==<br />
<br />
This project proposes to implement an AES accelerator for the PULP platform [2], interfacing as a Hardware Processing Engine (HWPE) [3] and operating directly on the Tightly-Coupled Data Memory (TCDM), to serve as a baseline for future follow-up work, and to provide an open-source reference implementation that is compatible with PULP. The main components of this thesis are:<br />
* RTL-implementation of the AES HWPE,<br />
* Validation the design using existing reference implementations,<br />
* Performing a basic design-space exploration of the accelerator.<br />
<br />
Depending on the progress, the component can furthermore be integrated into PULPissimo [4], and prepared for a tape-out.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in hardware design<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is beneficial<br />
<br />
Composition: 25% Design specification, 25% RTL Implementation, 25% Verification, 25% Synthesis and design-space exploration<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
<br />
* [1] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf<br />
* [2] https://github.com/pulp-platform/pulp<br />
* [3] https://hwpe-doc.readthedocs.io/en/latest/<br />
* [4] https://github.com/pulp-platform/pulpissimo</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Hypervisor_Extension_for_Ariane_(M)&diff=7121Hypervisor Extension for Ariane (M)2021-11-16T15:51:22Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:SW/HW Predictability and Security]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Zarubaf]]<br />
[[Category:In progress]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. To support common operating systems, Ariane features three privilege levels (Machine-, Supervisor-, and User-Mode) and address translation as described in the RISC-V privileged ISA [2].<br />
<br />
The RISC-V Hypervisor Extension ([2], pages 79-112) adds Hypervisor mode to the three existing privilege levels. This mode supports the virtualization and isolation of guest operating systems (OSes) – a common technique used in secure systems and cloud computing to allow running untrusted OSes or multiple OSes in parallel.<br />
<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement the Hypervisor extension as an optional feature in Ariane. The reqiured modifications include<br />
* adding a second stage of address translation,<br />
* extending the CSR (control and status register) register file by hypervisor-mode versions of existing CSRs and newly defined CSRs required for the second stage address translation, and<br />
* adding newly defined instructions for loads and stores from hypervisor mode to virtual memory, and for flushing the TLBs (<code>hfence</code>).<br />
<br />
The implemented features shall be verified and their hardware costs evaluated. The experiences gained during this work can be fed back to the RISC-V community and contribute to the development of the Hypervisor specification.<br />
<br />
Depending on the work’s progress, the Hypervisor extension's functionality can be demonstrated by porting a hypervisor to Ariane and running multiple OSes on top.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is of benefit.<br />
<br />
Composition: 20% Architecture specification, 50% Verification, 30% RTL Implementation<br />
<br />
== Status: In Progress ==<br />
<br />
* Student: Andreas Kuster<br />
* Type: Master Thesis<br />
* Professor: Prof. Dr. L. Benini<br />
* Supervisors:<br />
** [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
** [[:User:Michaero | Michael Rogenmoser]]: [mailto:michaero@iis.ee.ethz.ch michaero@iis.ee.ethz.ch]<br />
** [[:User:Balasr | Robert Balas]]: [mailto:balasr@iis.ee.ethz.ch balasr@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20201018-48191f8/riscv-privileged.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=IBM_Research&diff=7040IBM Research2021-10-04T11:35:57Z<p>Nwistoff: Add advertisement on crypto meets in-memory computing</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Master Thesis]] <br />
[[Category:Available]] <br />
[[Category:2021]]<br />
[[Category:Hot]]<br />
[[File:IBM_ZRLab.png|center]]<br />
<br />
==Short Description==<br />
Today, we are entering the era of cognitive computing, which holds great promise in deriving intelligence and knowledge from huge volumes of data. In today’s computers based on von Neumann architecture, huge amounts of data need to be shuttled back and forth at high speeds, a task at which this architecture is inefficient.<br />
<br />
It is becoming increasingly clear that to build efficient cognitive computers, we need to transition to non-von Neumann architectures in which memory and processing coexist in some form. At IBM Research–Zurich in the [https://www.zurich.ibm.com/sto/memory/ Neuromorphic and In-memory Computing Group], we explore various such computing paradigms from in-memory computing to brain-inspired neuromorphic computing. Our research spans from devices and architectures to algorithms and applications. <!--Here is a list of available projects:<br />
<br />
* [http://iis-projects.ee.ethz.ch/images/0/01/IBM_MANN_Y2020.pdf '''Artificial general intelligence (AGI):''' lifelong learning challenge] <br />
* [http://iis-projects.ee.ethz.ch/images/3/33/IBM_OT_Y2020.pdf '''Machine learning based on optimal transport using in-memory computing''']<br />
* [http://iis-projects.ee.ethz.ch/images/4/4b/IBM_RPM.pdf Developing Efficient Models of '''Strong AI for Intelligence Quotient (IQ) Test''']<br />
--><br />
<br />
===About the IBM Research–Zurich===<br />
The location in Zurich is one of IBM’s 12 global research labs. IBM has maintained a research laboratory in Switzerland since 1956. As the first European branch of IBM Research, the mission of the Zurich Lab, in addition to pursuing cutting-edge research for tomorrow’s information technology, is to cultivate close relationships with academic and industrial partners, be one of the premier places to work for world-class researchers, to promote women in IT and science, and to help drive Europe’s innovation agenda. [https://www.zurich.ibm.com/pdf/ZRL_Fact_Sheet.pdf Download factsheet]<br />
<br />
==Hybrid AI Systems (HAS)==<br />
<br />
[[File:NatureElectronics20.jpg|thumb|right|200px]]<br />
Neither symbolic AI nor neural networks alone has produced the kind of intelligence expressed in human and animal behavior. Why? Each has a long and rich history, but has addressed a relatively narrow aspect of the problem. Symbolic AI focuses on solving cognitive problems, drawing upon the rich framework of symbolic computation to manipulate internal representations in order to perform reasoning and inference. But it suffers from being non-adaptive, lacking the ability to learn from example or by direct observation of the world. Neural networks on the other hand have the ability to learn from data, and derive much of their power from nonlinear function approximation combined with stochastic gradient descent. But intelligence requires more than modeling input-output relationships. Without the richness of symbolic computation, neural nets lack the simple but powerful operations such as variable binding that allow for analogy making and reasoning, which underlie the ability to generalize from few examples.<br />
<br />
We approach the problem from a very different perspective, inspired by the brain’s high-dimensional circuits and the unique mathematical properties of high-dimensional spaces. ''It leads us to a novel information processing architecture that combines the strengths of symbolic AI and neural networks, and yet has novel emergent properties of its own.'' By combining a small set of basic operations on high-dimensional vectors, we obtain hybrid AI system (HAS) that makes it possible to represent and manipulate data in ways familiar to us from symbolic AI, and to learn from the statistics of data in ways familiar to us from artificial neural networks and deep learning. Further, principles of such HAS allow few-shot learning capabilities, and extremely robust operations against failures, defects, variations, and noise, all of which are complementary to ultra-low energy computation on nanoscale fabrics such as phase-change memory devices. Exciting further research (listed in below table) awaiting in this direction spans high-level algorithmic exploration all the way to efficient hardware design for emerging computational fabrics.<br />
<br />
===Useful Reading===<br />
*[https://www.nature.com/articles/s41467-021-22364-0 Robust high-dimensional memory-augmented neural networks], Nature Communications, 2021.<br />
*[https://www.nature.com/articles/s41928-020-0410-3 In-memory hyperdimensional computing], Nature Electronics, 2020.<br />
*[https://www.nature.com/articles/s41928-020-00510-8 A wearable biosensing system with in-sensor adaptive machine learning for hand gesture recognition], Nature Electronics, 2020. <br />
*[https://link.springer.com/article/10.1007/s12559-009-9009-8 Hyperdimensional computing: an introduction to computing in distributed representation with high-dimensional random vectors], Cognitive Computation, 2009.<br />
<br />
===Prerequisites===<br />
*Python<br />
*Background in machine learning (''recommended'')<br />
*Experience with any deep learning framework such as TensorFlow or PyTorch (''recommended'')<br />
*VLSI I (''recommended'')<br />
<br />
<!-- ==In-Memory Computing (IMC)==<br />
<br />
[[File:NNcover_imc.jpg|thumb|right|200px]]<br />
For decades, conventional computers based on the von Neumann architecture have performed computation by repeatedly transferring data between their processing and their memory units, which are physically separated. As computation becomes increasingly data-centric and as the scalability limits in terms of performance and power are being reached, alternative computing paradigms are searched for in which computation and storage are collocated. A fascinating new approach is that of computational memory where the physics of nanoscale memory devices are used to perform certain computational tasks within the memory unit in a non-von Neumann manner. '''Computational Memory''' (CM) is finding application in a variety of areas such as machine learning and signal processing. In addition to novel non-volatile memory technologies like '''PCM''' and '''ReRAM''', also conventional '''SRAM''' has been proposed as underlying storage technology in Computational Memories.<br />
<br />
===Useful Reading===<br />
*[https://ieeexplore.ieee.org/document/9288639 An SRAM-Based Multibit In-Memory Matrix-Vector Multiplier With a Precision That Scales Linearly in Area, Time, and Power]<br />
*[https://www.nature.com/articles/s41565-020-0655-z Memory devices and applications for in-memory computing]<br />
*[https://ieeexplore.ieee.org/abstract/document/8865099 Deep learning acceleration based on in-memory computing]<br />
<br />
===Prerequisites===<br />
*General interest in Deep Learning and memory/system design<br />
*VLSI I and VLSI II (''recommended'')<br />
Specific requirements for the different projects vary and are generally negotiable.<br />
---><br />
<br />
==Available Projects==<br />
We are inviting applications from students to conduct their thesis (bachelor, semester, and master) or an internship project at the IBM Research lab in Zurich on this exciting new topic. <br />
<!--<br />
The work performed could span low-level hardware experiments on phase-change memory chips comprising more than 1 million devices to high-level algorithmic development in a deep learning framework such as TensorFlow or PyTorch. It also involves interactions with several researchers across IBM research focusing on various aspects of the project. The ideal candidate should have a multi-disciplinary background, strong mathematical aptitude and programming skills. Prior knowledge on emerging memory technologies such as phase-change memory is a bonus but not necessary.<br />
--><br />
<br />
{| class="wikitable" style="text-align: center;"<br />
|-<br />
! style="width: 5%;"|Type !! style="width: 20%"|Project !! style="width: 60%"|Description !! style="width: 5%"|Workload Type <br />
|-<br />
<br />
| MA/SA/BA || Developing Efficient Models of Strong AI for Intelligence Quotient (IQ) Test || [http://iis-projects.ee.ethz.ch/images/4/4b/IBM_RPM.pdf Link to description] || algorithmic design<br />
|-<br />
<br />
| MA/SA/BA || Zero-shot learning || TBD || algorithmic design<br />
|-<br />
<br />
| MA || Accelerating Mixers with Computational Memory || [http://iis-projects.ee.ethz.ch/images/e/e8/IBM_Mixer.pdf Link to description] || Hardware design and experiments<br />
|-<br />
<br />
| MA || Accelerating Transformers with Computational Memory || [http://iis-projects.ee.ethz.ch/images/b/be/IBM_TransfAcc.pdf Link to description] || Hardware/algorithmic design<br />
|-<br />
<br />
| MA/SA/BA || Face Recognition at Scale || [http://iis-projects.ee.ethz.ch/images/3/3d/IBM_FaceRec_at_Scale.pdf Link to description] || algorithmic design<br />
|-<br />
<br />
<br />
| MA|| Lifelong learning challenge || [http://iis-projects.ee.ethz.ch/images/0/01/IBM_MANN_Y2020.pdf Link to description] || algorithmic/hardware design<br />
|-<br />
<br />
| MA|| Crytography meets in-memory computing || [https://iis-projects.ee.ethz.ch/images/6/62/Y2021_10_Advertisement_VME.pdf Link to description] || algorithmic design and hardware experiments<br />
|-<br />
<br />
<br />
|}<br />
<br />
==Contact==<br />
: Thesis will be at IBM Zurich in Rüschlikon<br />
; Hybrid AI Systems (HAS) projects<br />
: Contact (at ETH Zurich): [[:User:kgf | Dr. Frank K. Gurkaynak]], [[:User:Herschmi | Michael Hersche]]<br />
: Contact (at IBM): [mailto:kar@zurich.ibm.com Geethan Karunaratne]<br />
: Contact (at IBM): [mailto:ase@zurich.ibm.com Dr. Abu Sebastian] <br />
: Contact (at IBM): [mailto:abr@zurich.ibm.com Dr. Abbas Rahimi]<br />
: Professor: [https://iis.ee.ethz.ch/people/person-detail.html?persid=194234 Luca Benini]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=File:Y2021_10_Advertisement_VME.pdf&diff=7039File:Y2021 10 Advertisement VME.pdf2021-10-04T11:25:41Z<p>Nwistoff: Project description by IBM Research</p>
<hr />
<div>Project description by IBM Research</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Hypervisor_Extension_for_Ariane_(M)&diff=6787Hypervisor Extension for Ariane (M)2021-07-29T13:00:13Z<p>Nwistoff: In Progress</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:SW/HW Predictability and Security]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Zarubaf]]<br />
[[Category:In progress]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. To support common operating systems, Ariane features three privilege levels (Machine-, Supervisor-, and User-Mode) and address translation as described in the RISC-V privileged ISA [2].<br />
<br />
The RISC-V Hypervisor Extension ([2], pages 79-112) adds Hypervisor mode to the three existing privilege levels. This mode supports the virtualization and isolation of guest operating systems (OSes) – a common technique used in secure systems and cloud computing to allow running untrusted OSes or multiple OSes in parallel.<br />
<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement the Hypervisor extension as an optional feature in Ariane. The reqiured modifications include<br />
* adding a second stage of address translation,<br />
* extending the CSR (control and status register) register file by hypervisor-mode versions of existing CSRs and newly defined CSRs required for the second stage address translation, and<br />
* adding newly defined instructions for loads and stores from hypervisor mode to virtual memory, and for flushing the TLBs (<code>hfence</code>).<br />
<br />
The implemented features shall be verified and their hardware costs evaluated. The experiences gained during this work can be fed back to the RISC-V community and contribute to the development of the Hypervisor specification.<br />
<br />
Depending on the work’s progress, the Hypervisor extension's functionality can be demonstrated by porting a hypervisor to Ariane and running multiple OSes on top.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is of benefit.<br />
<br />
Composition: 20% Architecture specification, 50% Verification, 30% RTL Implementation<br />
<br />
== Status: In Progress ==<br />
<br />
* Student: Andreas Kuster<br />
* Type: Master Thesis<br />
* Professor: Prof. Dr. L. Benini<br />
* Supervisors:<br />
** [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
** [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20201018-48191f8/riscv-privileged.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Towards_the_Ariane_Desktop:_Display_Output_for_Ariane_on_FPGA_under_Linux_(S/B/G)&diff=6583Towards the Ariane Desktop: Display Output for Ariane on FPGA under Linux (S/B/G)2021-06-02T12:49:49Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:FPGA]]<br />
[[Category:2021]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Group Work]]<br />
[[Category:Georg]]<br />
[[Category:Nwistoff]]<br />
[[Category:In progress]]<br />
[[Category:Hot]]<br />
<br />
[[File:ariane-desktop.png|thumb|700px]]<br />
<br />
<br />
== Status: In progress ==<br />
<br />
* Type: Bachelor's Thesis<br />
* Semester: Spring Semester 2021<br />
* Student: Roman Marquart<br />
* Start: March 15, 2021<br />
* Hand-In: June 28, 2021<br />
* Professor: Prof. Dr. L. Benini<br />
* Supervisors:<br />
** [[:User:Georg | Georg Rutishauser]]: [mailto:georgr@iis.ee.ethz.ch georgr@iis.ee.ethz.ch]<br />
** [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
** [[:User:Balasr | Robert Balas]]: [mailto:balasr@iis.ee.ethz.ch balasr@iis.ee.ethz.ch]<br />
<br />
== Introduction ==<br />
<br />
'''Ariane''' (recently renamed to CVA6, [1]) is an open-source, general-purpose RISC-V CPU architecture which implements the RV64GC instruction set and is capable of running Linux. Intended as a research and demonstration platform, it has been taped out in several incarnations and can be mapped to an FPGA device for low-cost evaluation and testing. The supported target for FPGA emulation is the '''Genesys II''' board, and the mapping flow and auxiliary hardware environment provided by the Ariane maintainers offers a rich feature set, making it possible to run RISC-V programs on custom hardware in real time. <br />
<br />
On Ariane, user interaction with the programs running on the CPU was until recently limited to an UART link, which only allows for text input and output and requires a computer to be connected. In a previous project, a display peripheral (called PAPER) was integrated into the FPGA platform and tested.<br />
<br />
'''PAPER''' is an AXI-compliant peripheral module which supports the streaming of image (framebuffer) data from memory, as well as possessing the capability of streaming a text buffer in VGA text format – such as the Linux Virtual Terminal’s internal text representation – from memory and graphically rendering the text it contains. While PAPER has been successfully integrated into the FPGA platform and tested using simple bare-metal examples, driver support under Linux has not yet been implemented, and the current hardware implementation still has a prototype character. <br />
<br />
The overall goal of this project is to take a step towards a fully-featured autonomous Linux system based on Ariane with extensive user interaction support. To this end, you will work to provide usable display output, directly from the FPGA’s HDMI port, on the FPGA port of Ariane. This will involve both hardware design tasks to improve maturity and extend the current feature set, as well as software development in the form of Linux driver development. <br />
<br />
== Project ==<br />
<br />
In this project, you will learn to work with and extend an advanced processing system all the way from the RTL/hardware level to the Linux kernel and userspace levels. This will provide you with unique insights into the workings of such a platform, and these insights will apply readily to the Linux systems you will encounter in your academic, professional and private lives. You will learn how hardware peripherals are designed and integrated into processing systems, as well as how to establish software support for them both in bare-metal applications and under Linux.<br />
<br />
===== Tasks =====<br />
<br />
====== Hardware Design ====== <br />
<br />
* '''Support for higher resolutions:''' Due to the current structure of the AXI infrastructure, output resolutions are limited to a maximum of SVGA (800x600) at a 60 hertz refresh rate. By refactoring the AXI infrastructure, you will eliminate this restriction and allow resolutions of Full HD and beyond. <br />
<br />
* '''Resource reclamation:''' Currently, FIFOs are implemented in HDL, which results in relatively high flip-flop utilization. By replacing them with Xilinx primitives, the FF utilization of the peripheral can be reduced by ~66%.<br />
<br />
* '''Support for Runtime-Configurable Resolution:''' Currently, the frequency of the output pixel clock is fixed at compile time. In order to make the resolution runtime-configurable, you will replace the fixed-frequency clock generator with a configurable one. This will make it possible to change the output resolution while the system is running and without requiring time-intensive re-implementation. <br />
<br />
* '''Verification:''' The assembled platform must be thoroughly tested to ensure complete and correct functionality. Furthermore, it must be ensured that the modifications don’t impact the system’s critical path.<br />
<br />
====== Software Design ======<br />
<br />
* '''Bare-Metal Driver Adaptation:''' The existing bare-metal software framework is kept as platform-agnostic as possible, but certain specifics must be adapted to correspond to the specific platform. The goal is to achieve an easy-to-use library which provides user-friendly support for both image and text display in bare-metal applications.<br />
<br />
* '''Linux Device Driver:''' In order to interact with the PAPER peripheral under Linux, it must be abstracted by a simple device driver kernel module. This driver will allow higher-level drivers (e.g. a console driver) to interact with the peripheral through a unified interface.<br />
<br />
* '''Linux Console Driver:''' A prototype console driver for Linux exists, which allows the output of the linux console to be displayed from the first line on PAPER’s original target platform, the ZEDBoard. The objective is to develop this driver to provide a more streamlined integration into the Linux kernel and to port the resulting software to source tree for the Linux distribution targeting Ariane.<br />
<br />
====== Stretch Goals ======<br />
<br />
Depending on your progress and interests, several further steps can be considered, such as:<br />
<br />
* '''Feature Extensions (HW):''' As an example for an optional goal, the PAPER module’s functionality could be extended to allow for runtime-customizable fonts in text mode.<br />
<br />
* '''Linux display driver (SW):''' In order to provide graphical output under Linux, a framebuffer driver or a KMS/DRM display driver can be implemented.<br />
<br />
* '''Input Peripheral Support (HW):''' In order to completely remove dependence on serial UART input, support for keyboard input over PS/2 or USB could be implemented. This may be realized with a dedicated hardware peripheral (re-using an existing open-source core is the most time-effective option), or by using GPIO pins to “bit-bang” the PS/2 protocol. The Genesys II board has both a dedicated USB HID host which converts USB to PS/2 and a general-purpose USB 2.0 controller which is attached to the FPGA with an ULPI interface.<br />
<br />
* '''Input Peripheral Support (SW):''' If support for PS/2 keyboard input is implemented, this will require software support under Linux. <br />
<br />
<br />
We can also discuss targeting a subset of the tasks above depending on your time frame and interests. Possible follow-up work could involve a tape-out of the system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest system design and hardware/software interaction<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Basic knowledge of operating systems<br />
<br />
Composition: 40% RTL Implementation, 20% Verification, 40% Software Design<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Georg | Georg Rutishauser]]: [mailto:georgr@iis.ee.ethz.ch georgr@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
===Practical Details===<br />
* '''[http://n.ethz.ch/~georgr/project-descriptions/FS21/task_descr_paper_linux.pdf Detailed Project Description]'''<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Implementation_of_an_AES_Hardware_Processing_Engine_(B/S)&diff=6582Implementation of an AES Hardware Processing Engine (B/S)2021-06-02T12:47:47Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:Cryptography]]<br />
[[Category:2021]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:In progress]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The Advanced Encryption Standard (AES) [1] is an encryption algorithm used in many of today's applications. It operates in multiple rounds on fixed-size data blocks, converting a clear-text data stream into an encrypted one (or vice-versa). This process is computationally expensive, and can become a bottleneck when applied on large amounts of data. A solution to this problem is a dedicated hardware accelerator that directly operates on the data that should be en-/decrypted. <br />
<br />
== Project ==<br />
<br />
This project proposes to implement an AES accelerator for the PULP platform [2], interfacing as a Hardware Processing Engine (HWPE) [3] and operating directly on the Tightly-Coupled Data Memory (TCDM), to serve as a baseline for future follow-up work, and to provide an open-source reference implementation that is compatible with PULP. The main components of this thesis are:<br />
* RTL-implementation of the AES HWPE,<br />
* Validation the design using existing reference implementations,<br />
* Performing a basic design-space exploration of the accelerator.<br />
<br />
Depending on the progress, the component can furthermore be integrated into PULPissimo [4], and prepared for a tape-out.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in hardware design<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is beneficial<br />
<br />
Composition: 25% Design specification, 25% RTL Implementation, 25% Verification, 25% Synthesis and design-space exploration<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
<br />
* [1] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf<br />
* [2] https://github.com/pulp-platform/pulp<br />
* [3] https://hwpe-doc.readthedocs.io/en/latest/<br />
* [4] https://github.com/pulp-platform/pulpissimo</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=PULP_in_space_-_Fault_Tolerant_PULP_System_for_Critical_Space_Applications&diff=6581PULP in space - Fault Tolerant PULP System for Critical Space Applications2021-06-02T12:46:55Z<p>Nwistoff: </p>
<hr />
<div>[[File:AlcantaraLaunchCenter.jpg|thumb|400px]]<br />
== Introduction ==<br />
<br />
The miniaturization of increasingly complex integrated circuits (ICs) is coupled with a reduction of their noise margin, which makes such circuits more and more exposed to faults and failures. While in the past a certain reliability level could be achieved by disposing the failing circuits after their fabrication, such technique would incur into low yield and high costs if applied to modern processes.<br />
<br />
The problem is even more accentuated in critical applications, such as the transport and aerospace industries, which require strict levels of reliability. Even at the altitude of commercial flights, due to a thinner atmospheric protection, the electrical components are exposed to energetic cosmic rays, which increase the probability of the ICs encountering a transient fault (soft errors). Faster clocks increase the probability of signal spikes due to cosmic rays being captured by sequential elements, taking the system into a faulty state.<br />
<br />
Design for Reliability (DfR) is a must for such critical domains. Traditional fault-tolerant systems use massive redundancy schemes, such as Triple Modular Redundancy (TMR), to ensure a reliability level. For example, a processor core is replicated an odd number of times, and a voting mechanism is used to detect and correct any discrepancies between the cores' outputs. While such schemes are relatively simple, they incur a high cost in terms of circuit area and power. <br />
<br />
== Project description ==<br />
[[File:Ibex.png|thumb|600px]]<br />
<br />
The goal of this project in collaboration with the [https://ufrn.br/en ''Federal University of Rio Grande do Norte'' (UFRN - Brazil)] and the [http://www.inpe.br/ ''Brazilian National Institute for Space Research'' (INPE)] is to investigate architectural enhancements for building fault-tolerant low-power [https://www.pulp-platform.org/ OpenPULP multicore clusters].<br />
<br />
There are quite a few approaches at different architectural levels that can be explored. For example, a set of cores could be dynamically configured to run in lockstep, with an error being detected/corrected once they diverge (i.e., their program counter/register content differ). Alternatively, a core could run a checking task that verifies the execution of another core. The checking routines can also be run sporadically, at the end of each "critical function" for example. Moreover, flexible redundancy can be added to the cores themselves. For example, redundancy at the register-file level be dynamically added at the cost of performance by reducing the number of available registers. Finally, redundancy techniques can also be applied to the memory side, either using Error Correcting Codes (ECC) or by using redundant memory banks.<br />
<br />
For this project the OpenPULP cluster will be used in combination with the [https://www.github.com/lowRISC/ibex Ibex] processor core. Similar to RI5CY, Ibex implements the RV32IMC instruction set architecture and is open source. It has originally been designed at ETH Zürich and University of Bologna under the name Zero-riscy [3] and is now maintained and developed by the [https://www.lowrisc.org not-for-profit company lowRISC C.I.C.]. In contrast to RI5CY, Ibex has a much simpler 2-stage pipeline and no custom hardware extensions. It is fully compliant with the RISC-V specification, comes with extensive documentation and industry-grade verification infrastructure. All this facilitates the addition of new features e.g. targeting core-level fault tolerance.<br />
<br />
The project can either be done by a team of two students as a semester thesis, or by one student as a Master thesis. The project consists of three parts:<br />
<br />
1. Familiarizing with the architecture of the OpenPULP cluster and the Ibex processor core, exploration of fault-tolerant techniques (~2 person months).<br />
<br />
2. Specification and RTL design on top of an OpenPULP cluster with Ibex processor cores (~2 person months).<br />
<br />
3. FPGA evaluation of the implementation (~1-2 person months).<br />
<br />
If time permits and if you are interested, an ASIC implementation of the design is also feasible.<br />
<br />
== Required skills ==<br />
<br />
To work on this project, you will need:<br />
<br />
* to have worked in the past with at least one RTL language (SystemVerilog or Verilog or VHDL). Having followed the VLSI 1 / VLSI 2 courses is recommended.<br />
* to have prior knowledge of hardware design and computer architecture<br />
* to be motivated to work hard on a super cool open-source project<br />
<br />
=== Status: Completed ===<br />
<br />
* Student: Michael Rogenmoser<br />
* Supervision: [[:User:nwistoff|Nils Wistoff]], [[:User:Matheusd|Matheus Cavalcante]], [[:User:Vogelpi|Pirmin Vogel]]<br />
<br />
=== Professor ===<br />
: [http://www.iis.ee.ethz.ch/portrait/staff/lbenini.en.html Luca Benini]<br />
[[#top|↑ top]]<br />
<br />
== Meetings & Presentations ==<br />
<br />
The students and advisor(s) agree on weekly meetings to discuss all relevant decisions and decide on how to proceed. Of course, additional meetings can be organized to address urgent issues.<br />
<br />
Around the middle of the project there is a design review, where senior members of the lab review your work (bring all the relevant information, such as prelim. specifications, block diagrams, synthesis reports, testing strategy, ...) to make sure everything is on track and decide whether further support is necessary. They also make the definite decision on whether the chip is actually manufactured (no reason to worry, if the project is on track) and whether more chip area, a different package, ... is provided. For more details refer to [http://eda.ee.ethz.ch/index.php/Design_review (1)].<br />
<br />
At the end of the project, you have to present/defend your work during a 15 min. presentation and 5 min. of discussion as part of the IIS colloquium.<br />
<br />
== References ==<br />
<br />
# Lorena Anghel. Les limites technologiques du silicium et tolérance aux fautes. PhD Thesis, Institut Polytechnique de Grenoble, 2001.<br />
# Matheus Cavalcante. Conception d'une plateforme RISC-V avec le système d'exploitation temps réel Trampoline. Semester Thesis, Institut Polytechnique de Grenoble, 2017.<br />
# P.D. Schiavone, et al. "Slow and steady wins the race? A comparison of ultra-low-power RISC-V cores for Internet-of-Things applications", ''Proceedings of the 27th International Symposium on Power and Timing Modeling, Optimization and Simulation (PATMOS)'', Thessaloniki, Greece, 2017. [https://ieeexplore.ieee.org/document/8106976 link]<br />
<br />
[[#top|↑ top]]<br />
[[Category:Digital]]<br />
[[Category:Completed]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:PULP]]<br />
[[Category:Vogelpi]]<br />
[[Category:Nwistoff]]<br />
[[Category:Matheusd]]<br />
[[Category:Computer Architecture]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=PULP_in_space_-_Fault_Tolerant_PULP_System_for_Critical_Space_Applications&diff=6580PULP in space - Fault Tolerant PULP System for Critical Space Applications2021-06-02T12:45:37Z<p>Nwistoff: </p>
<hr />
<div>[[File:AlcantaraLaunchCenter.jpg|thumb|400px]]<br />
== Introduction ==<br />
<br />
The miniaturization of increasingly complex integrated circuits (ICs) is coupled with a reduction of their noise margin, which makes such circuits more and more exposed to faults and failures. While in the past a certain reliability level could be achieved by disposing the failing circuits after their fabrication, such technique would incur into low yield and high costs if applied to modern processes.<br />
<br />
The problem is even more accentuated in critical applications, such as the transport and aerospace industries, which require strict levels of reliability. Even at the altitude of commercial flights, due to a thinner atmospheric protection, the electrical components are exposed to energetic cosmic rays, which increase the probability of the ICs encountering a transient fault (soft errors). Faster clocks increase the probability of signal spikes due to cosmic rays being captured by sequential elements, taking the system into a faulty state.<br />
<br />
Design for Reliability (DfR) is a must for such critical domains. Traditional fault-tolerant systems use massive redundancy schemes, such as Triple Modular Redundancy (TMR), to ensure a reliability level. For example, a processor core is replicated an odd number of times, and a voting mechanism is used to detect and correct any discrepancies between the cores' outputs. While such schemes are relatively simple, they incur a high cost in terms of circuit area and power. <br />
<br />
== Project description ==<br />
[[File:Ibex.png|thumb|600px]]<br />
<br />
The goal of this project in collaboration with the [https://ufrn.br/en ''Federal University of Rio Grande do Norte'' (UFRN - Brazil)] and the [http://www.inpe.br/ ''Brazilian National Institute for Space Research'' (INPE)] is to investigate architectural enhancements for building fault-tolerant low-power [https://www.pulp-platform.org/ OpenPULP multicore clusters].<br />
<br />
There are quite a few approaches at different architectural levels that can be explored. For example, a set of cores could be dynamically configured to run in lockstep, with an error being detected/corrected once they diverge (i.e., their program counter/register content differ). Alternatively, a core could run a checking task that verifies the execution of another core. The checking routines can also be run sporadically, at the end of each "critical function" for example. Moreover, flexible redundancy can be added to the cores themselves. For example, redundancy at the register-file level be dynamically added at the cost of performance by reducing the number of available registers. Finally, redundancy techniques can also be applied to the memory side, either using Error Correcting Codes (ECC) or by using redundant memory banks.<br />
<br />
For this project the OpenPULP cluster will be used in combination with the [https://www.github.com/lowRISC/ibex Ibex] processor core. Similar to RI5CY, Ibex implements the RV32IMC instruction set architecture and is open source. It has originally been designed at ETH Zürich and University of Bologna under the name Zero-riscy [3] and is now maintained and developed by the [https://www.lowrisc.org not-for-profit company lowRISC C.I.C.]. In contrast to RI5CY, Ibex has a much simpler 2-stage pipeline and no custom hardware extensions. It is fully compliant with the RISC-V specification, comes with extensive documentation and industry-grade verification infrastructure. All this facilitates the addition of new features e.g. targeting core-level fault tolerance.<br />
<br />
The project can either be done by a team of two students as a semester thesis, or by one student as a Master thesis. The project consists of three parts:<br />
<br />
1. Familiarizing with the architecture of the OpenPULP cluster and the Ibex processor core, exploration of fault-tolerant techniques (~2 person months).<br />
<br />
2. Specification and RTL design on top of an OpenPULP cluster with Ibex processor cores (~2 person months).<br />
<br />
3. FPGA evaluation of the implementation (~1-2 person months).<br />
<br />
If time permits and if you are interested, an ASIC implementation of the design is also feasible.<br />
<br />
== Required skills ==<br />
<br />
To work on this project, you will need:<br />
<br />
* to have worked in the past with at least one RTL language (SystemVerilog or Verilog or VHDL). Having followed the VLSI 1 / VLSI 2 courses is recommended.<br />
* to have prior knowledge of hardware design and computer architecture<br />
* to be motivated to work hard on a super cool open-source project<br />
<br />
=== Status: In Progress ===<br />
<br />
* Student: Michael Rogenmoser<br />
* Supervision: [[:User:nwistoff|Nils Wistoff]], [[:User:Matheusd|Matheus Cavalcante]], [[:User:Vogelpi|Pirmin Vogel]]<br />
<br />
=== Professor ===<br />
: [http://www.iis.ee.ethz.ch/portrait/staff/lbenini.en.html Luca Benini]<br />
[[#top|↑ top]]<br />
<br />
== Meetings & Presentations ==<br />
<br />
The students and advisor(s) agree on weekly meetings to discuss all relevant decisions and decide on how to proceed. Of course, additional meetings can be organized to address urgent issues.<br />
<br />
Around the middle of the project there is a design review, where senior members of the lab review your work (bring all the relevant information, such as prelim. specifications, block diagrams, synthesis reports, testing strategy, ...) to make sure everything is on track and decide whether further support is necessary. They also make the definite decision on whether the chip is actually manufactured (no reason to worry, if the project is on track) and whether more chip area, a different package, ... is provided. For more details refer to [http://eda.ee.ethz.ch/index.php/Design_review (1)].<br />
<br />
At the end of the project, you have to present/defend your work during a 15 min. presentation and 5 min. of discussion as part of the IIS colloquium.<br />
<br />
== References ==<br />
<br />
# Lorena Anghel. Les limites technologiques du silicium et tolérance aux fautes. PhD Thesis, Institut Polytechnique de Grenoble, 2001.<br />
# Matheus Cavalcante. Conception d'une plateforme RISC-V avec le système d'exploitation temps réel Trampoline. Semester Thesis, Institut Polytechnique de Grenoble, 2017.<br />
# P.D. Schiavone, et al. "Slow and steady wins the race? A comparison of ultra-low-power RISC-V cores for Internet-of-Things applications", ''Proceedings of the 27th International Symposium on Power and Timing Modeling, Optimization and Simulation (PATMOS)'', Thessaloniki, Greece, 2017. [https://ieeexplore.ieee.org/document/8106976 link]<br />
<br />
[[#top|↑ top]]<br />
[[Category:Digital]]<br />
[[Category:Completed]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:PULP]]<br />
[[Category:Vogelpi]]<br />
[[Category:Nwistoff]]<br />
[[Category:Matheusd]]<br />
[[Category:Computer Architecture]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Implementation_of_an_AES_Hardware_Processing_Engine_(B/S)&diff=6498Implementation of an AES Hardware Processing Engine (B/S)2021-03-19T08:33:26Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:Cryptography]]<br />
[[Category:2021]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The Advanced Encryption Standard (AES) [1] is an encryption algorithm used in many of today's applications. It operates in multiple rounds on fixed-size data blocks, converting a clear-text data stream into an encrypted one (or vice-versa). This process is computationally expensive, and can become a bottleneck when applied on large amounts of data. A solution to this problem is a dedicated hardware accelerator that directly operates on the data that should be en-/decrypted. <br />
<br />
== Project ==<br />
<br />
This project proposes to implement an AES accelerator for the PULP platform [2], interfacing as a Hardware Processing Engine (HWPE) [3] and operating directly on the Tightly-Coupled Data Memory (TCDM), to serve as a baseline for future follow-up work, and to provide an open-source reference implementation that is compatible with PULP. The main components of this thesis are:<br />
* RTL-implementation of the AES HWPE,<br />
* Validation the design using existing reference implementations,<br />
* Performing a basic design-space exploration of the accelerator.<br />
<br />
Depending on the progress, the component can furthermore be integrated into PULPissimo [4], and prepared for a tape-out.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in hardware design<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is beneficial<br />
<br />
Composition: 25% Design specification, 25% RTL Implementation, 25% Verification, 25% Synthesis and design-space exploration<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
<br />
* [1] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf<br />
* [2] https://github.com/pulp-platform/pulp<br />
* [3] https://hwpe-doc.readthedocs.io/en/latest/<br />
* [4] https://github.com/pulp-platform/pulpissimo</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Implementation_of_an_AES_Hardware_Processing_Engine_(B/S)&diff=6497Implementation of an AES Hardware Processing Engine (B/S)2021-03-18T13:35:36Z<p>Nwistoff: Created page with "Category:Digital Category:Cryptography Category:2021 Category:Bachelor Thesis Category:Semester Thesis Category:Nwistoff Category:Available == In..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:Cryptography]]<br />
[[Category:2021]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
The Advanced Encryption Standard (AES) [1] is an encryption algorithm used in many of today's applications. It operates in multiple rounds on fixed-size data blocks, converting a clear-text data stream into an encrypted one (or vice-versa). This process is computationally expensive, and can become a bottleneck when applied on large amounts of data. A solution to this problem is a dedicated hardware accelerator, which directly operates on the data that should be en-/decrypted. <br />
<br />
== Project ==<br />
<br />
This project proposes to implement an AES accelerator for the PULP platform [2], interfacing as a Hardware Processing Engine (HWPE) [3] and operating directly on the Tightly-Coupled Data Memory (TCDM), to serve as a baseline for future follow-up work, and to provide an open-source reference implementation that is compatible with PULP. The main components of this thesis are:<br />
* RTL-implementation of the AES HWPE,<br />
* Validation the design using existing reference implementations,<br />
* Performing a basic design-space exploration of the accelerator.<br />
<br />
Depending on the progress, the component can furthermore be integrated into PULPissimo [4], and prepared for a tape-out.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in hardware design<br />
* Experience with HDLs (preferably SystemVerilog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is beneficial<br />
<br />
Composition: 25% Design specification, 25% RTL Implementation, 25% Verification, 25% Synthesis and design-space exploration<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
<br />
* [1] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf<br />
* [2] https://github.com/pulp-platform/pulp<br />
* [3] https://hwpe-doc.readthedocs.io/en/latest/<br />
* [4] https://github.com/pulp-platform/pulpissimo</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Towards_the_Ariane_Desktop:_Display_Output_for_Ariane_on_FPGA_under_Linux_(S/B/G)&diff=6368Towards the Ariane Desktop: Display Output for Ariane on FPGA under Linux (S/B/G)2021-02-05T20:54:08Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:FPGA]]<br />
[[Category:2021]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Group Work]]<br />
[[Category:Georg]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
[[File:ariane-desktop.png|thumb|700px]]<br />
<br />
== Introduction ==<br />
<br />
'''Ariane''' (recently renamed to CVA6, [1]) is an open-source, general-purpose RISC-V CPU architecture which implements the RV64GC instruction set and is capable of running Linux. Intended as a research and demonstration platform, it has been taped out in several incarnations and can be mapped to an FPGA device for low-cost evaluation and testing. The supported target for FPGA emulation is the '''Genesys II''' board, and the mapping flow and auxiliary hardware environment provided by the Ariane maintainers offers a rich feature set, making it possible to run RISC-V programs on custom hardware in real time. <br />
<br />
On Ariane, user interaction with the programs running on the CPU was until recently limited to an UART link, which only allows for text input and output and requires a computer to be connected. In a previous project, a display peripheral (called PAPER) was integrated into the FPGA platform and tested.<br />
<br />
'''PAPER''' is an AXI-compliant peripheral module which supports the streaming of image (framebuffer) data from memory, as well as possessing the capability of streaming a text buffer in VGA text format – such as the Linux Virtual Terminal’s internal text representation – from memory and graphically rendering the text it contains. While PAPER has been successfully integrated into the FPGA platform and tested using simple bare-metal examples, driver support under Linux has not yet been implemented, and the current hardware implementation still has a prototype character. <br />
<br />
The overall goal of this project is to take a step towards a fully-featured autonomous Linux system based on Ariane with extensive user interaction support. To this end, you will work to provide usable display output, directly from the FPGA’s HDMI port, on the FPGA port of Ariane. This will involve both hardware design tasks to improve maturity and extend the current feature set, as well as software development in the form of Linux driver development. <br />
<br />
== Project ==<br />
<br />
In this project, you will learn to work with and extend an advanced processing system all the way from the RTL/hardware level to the Linux kernel and userspace levels. This will provide you with unique insights into the workings of such a platform, and these insights will apply readily to the Linux systems you will encounter in your academic, professional and private lives. You will learn how to hardware peripherals are designed and integrated into processing systems, as well as how to establish software support for them both in bare-metal applications and under Linux.<br />
<br />
===== Tasks =====<br />
<br />
====== Hardware Design ====== <br />
<br />
* '''Support for higher resolutions:''' Due to the current structure of the AXI infrastructure, output resolutions are limited to a maximum of SVGA (800x600) at a 60 hertz refresh rate. By refactoring the AXI infrastructure, you will eliminate this restriction and allow resolutions of Full HD and beyond. <br />
<br />
* '''Resource reclamation:''' Currently, FIFOs are implemented in HDL, which results in relatively high flip-flop utilization. By replacing them with Xilinx primitives, the FF utilization of the peripheral can be reduced by ~66%.<br />
<br />
* '''Support for Runtime-Configurable Resolution:''' Currently, the frequency of the output pixel clock is fixed at compile time. In order to make the resolution runtime-configurable, you will replace the fixed-frequency clock generator with a configurable one. This will make it possible to change the output resolution while the system is running and without requiring time-intensive re-implementation. <br />
<br />
* '''Verification:''' The assembled platform must be thoroughly tested to ensure complete and correct functionality. Furthermore, it must be ensured that the modifications don’t impact the system’s critical path.<br />
<br />
====== Software Design ======<br />
<br />
* '''Bare-Metal Driver Adaptation:''' The existing bare-metal software framework is kept as platform-agnostic as possible, but certain specifics must be adapted to correspond to the specific platform. The goal is to achieve an easy-to-use library which provides user-friendly support for both image and text display in bare-metal applications.<br />
<br />
* '''Linux Device Driver:''' In order to interact with the PAPER peripheral under Linux, it must be abstracted by a simple device driver kernel module. This driver will allow higher-level drivers (e.g. a console driver) to interact with the peripheral through a unified interface.<br />
<br />
* '''Linux Console Driver:''' A prototype console driver for Linux exists, which allows the output of the linux console to be displayed from the first line on PAPER’s original target platform, the ZEDBoard. The objective is to develop this driver to provide a more streamlined integration into the Linux kernel and to port the resulting software to source tree for the Linux distribution targeting Ariane.<br />
<br />
====== Stretch Goals ======<br />
<br />
Depending on your progress and interests, several further steps can be considered, such as:<br />
<br />
* '''Feature Extensions (HW):''' As an example for an optional goal, the PAPER module’s functionality could be extended to allow for runtime-customizable fonts in text mode.<br />
<br />
* '''Linux display driver (SW):''' In order to provide graphical output under Linux, a framebuffer driver or a KMS/DRM display driver can be implemented.<br />
<br />
* '''Input Peripheral Support (HW):''' In order to completely remove dependence on serial UART input, support for keyboard input over PS/2 or USB could be implemented. This may be realized with a dedicated hardware peripheral (re-using an existing open-source core is the most time-effective option), or by using GPIO pins to “bit-bang” the PS/2 protocol. The Genesys II board has both a dedicated USB HID host which converts USB to PS/2 and a general-purpose USB 2.0 controller which is attached to the FPGA with an ULPI interface.<br />
<br />
* '''Input Peripheral Support (SW):''' If support for PS/2 keyboard input is implemented, this will require software support under Linux. <br />
<br />
<br />
We can also discuss targeting a subset of the tasks above depending on your time frame and interests. Possible follow-up work could involve a tape-out of the system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest system design and hardware/software interaction<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Basic knowledge of operating systems<br />
<br />
Composition: 40% RTL Implementation, 20% Verification, 40% Software Design<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Georg | Georg Rutishauser]]: [mailto:georgr@iis.ee.ethz.ch georgr@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Category:SW/HW_Predictability_and_Security&diff=6367Category:SW/HW Predictability and Security2021-02-05T20:53:19Z<p>Nwistoff: Redirected page to SW/HW Predictability and Security</p>
<hr />
<div>#Redirect [[SW/HW Predictability and Security]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Towards_the_Ariane_Desktop:_Display_Output_for_Ariane_on_FPGA_under_Linux_(S/B/G)&diff=6366Towards the Ariane Desktop: Display Output for Ariane on FPGA under Linux (S/B/G)2021-02-05T20:46:35Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2021]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Group Work]]<br />
[[Category:Georg]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
[[File:ariane-desktop.png|thumb|700px]]<br />
<br />
== Introduction ==<br />
<br />
'''Ariane''' (recently renamed to CVA6, [1]) is an open-source, general-purpose RISC-V CPU architecture which implements the RV64GC instruction set and is capable of running Linux. Intended as a research and demonstration platform, it has been taped out in several incarnations and can be mapped to an FPGA device for low-cost evaluation and testing. The supported target for FPGA emulation is the '''Genesys II''' board, and the mapping flow and auxiliary hardware environment provided by the Ariane maintainers offers a rich feature set, making it possible to run RISC-V programs on custom hardware in real time. <br />
<br />
On Ariane, user interaction with the programs running on the CPU was until recently limited to an UART link, which only allows for text input and output and requires a computer to be connected. In a previous project, a display peripheral (called PAPER) was integrated into the FPGA platform and tested.<br />
<br />
'''PAPER''' is an AXI-compliant peripheral module which supports the streaming of image (framebuffer) data from memory, as well as possessing the capability of streaming a text buffer in VGA text format – such as the Linux Virtual Terminal’s internal text representation – from memory and graphically rendering the text it contains. While PAPER has been successfully integrated into the FPGA platform and tested using simple bare-metal examples, driver support under Linux has not yet been implemented, and the current hardware implementation still has a prototype character. <br />
<br />
The overall goal of this project is to take a step towards a fully-featured autonomous Linux system based on Ariane with extensive user interaction support. To this end, you will work to provide usable display output, directly from the FPGA’s HDMI port, on the FPGA port of Ariane. This will involve both hardware design tasks to improve maturity and extend the current feature set, as well as software development in the form of Linux driver development. <br />
<br />
== Project ==<br />
<br />
In this project, you will learn to work with and extend an advanced processing system all the way from the RTL/hardware level to the Linux kernel and userspace levels. This will provide you with unique insights into the workings of such a platform, and these insights will apply readily to the Linux systems you will encounter in your academic, professional and private lives. You will learn how to hardware peripherals are designed and integrated into processing systems, as well as how to establish software support for them both in bare-metal applications and under Linux.<br />
<br />
===== Tasks =====<br />
<br />
====== Hardware Design ====== <br />
<br />
* '''Support for higher resolutions:''' Due to the current structure of the AXI infrastructure, output resolutions are limited to a maximum of SVGA (800x600) at a 60 hertz refresh rate. By refactoring the AXI infrastructure, you will eliminate this restriction and allow resolutions of Full HD and beyond. <br />
<br />
* '''Resource reclamation:''' Currently, FIFOs are implemented in HDL, which results in relatively high flip-flop utilization. By replacing them with Xilinx primitives, the FF utilization of the peripheral can be reduced by ~66%.<br />
<br />
* '''Support for Runtime-Configurable Resolution:''' Currently, the frequency of the output pixel clock is fixed at compile time. In order to make the resolution runtime-configurable, you will replace the fixed-frequency clock generator with a configurable one. This will make it possible to change the output resolution while the system is running and without requiring time-intensive re-implementation. <br />
<br />
* '''Verification:''' The assembled platform must be thoroughly tested to ensure complete and correct functionality. Furthermore, it must be ensured that the modifications don’t impact the system’s critical path.<br />
<br />
====== Software Design ======<br />
<br />
* '''Bare-Metal Driver Adaptation:''' The existing bare-metal software framework is kept as platform-agnostic as possible, but certain specifics must be adapted to correspond to the specific platform. The goal is to achieve an easy-to-use library which provides user-friendly support for both image and text display in bare-metal applications.<br />
<br />
* '''Linux Device Driver:''' In order to interact with the PAPER peripheral under Linux, it must be abstracted by a simple device driver kernel module. This driver will allow higher-level drivers (e.g. a console driver) to interact with the peripheral through a unified interface.<br />
<br />
* '''Linux Console Driver:''' A prototype console driver for Linux exists, which allows the output of the linux console to be displayed from the first line on PAPER’s original target platform, the ZEDBoard. The objective is to develop this driver to provide a more streamlined integration into the Linux kernel and to port the resulting software to source tree for the Linux distribution targeting Ariane.<br />
<br />
====== Stretch Goals ======<br />
<br />
Depending on your progress and interests, several further steps can be considered, such as:<br />
<br />
* '''Feature Extensions (HW):''' As an example for an optional goal, the PAPER module’s functionality could be extended to allow for runtime-customizable fonts in text mode.<br />
<br />
* '''Linux display driver (SW):''' In order to provide graphical output under Linux, a framebuffer driver or a KMS/DRM display driver can be implemented.<br />
<br />
* '''Input Peripheral Support (HW):''' In order to completely remove dependence on serial UART input, support for keyboard input over PS/2 or USB could be implemented. This may be realized with a dedicated hardware peripheral (re-using an existing open-source core is the most time-effective option), or by using GPIO pins to “bit-bang” the PS/2 protocol. The Genesys II board has both a dedicated USB HID host which converts USB to PS/2 and a general-purpose USB 2.0 controller which is attached to the FPGA with an ULPI interface.<br />
<br />
* '''Input Peripheral Support (SW):''' If support for PS/2 keyboard input is implemented, this will require software support under Linux. <br />
<br />
<br />
We can also discuss targeting a subset of the tasks above depending on your time frame and interests. Possible follow-up work could involve a tape-out of the system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest system design and hardware/software interaction<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Basic knowledge of operating systems<br />
<br />
Composition: 40% RTL Implementation, 20% Verification, 40% Software Design<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Georg | Georg Rutishauser]]: [mailto:georgr@iis.ee.ethz.ch georgr@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Towards_the_Ariane_Desktop:_Display_Output_for_Ariane_on_FPGA_under_Linux_(S/B/G)&diff=6365Towards the Ariane Desktop: Display Output for Ariane on FPGA under Linux (S/B/G)2021-02-05T20:38:25Z<p>Nwistoff: Created page with "Category:Digital Category:High Performance SoCs Category:Computer Architecture Category:2021 Category:Semester Thesis Category:Bachelor Thesis Catego..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2021]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Bachelor Thesis]]<br />
[[Category:Group Thesis]]<br />
[[Category:Georg]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
[[File:ariane-desktop.png|thumb|700px]]<br />
<br />
== Introduction ==<br />
<br />
'''Ariane''' (recently renamed to CVA6, [1]) is an open-source, general-purpose RISC-V CPU architecture which implements the RV64GC instruction set and is capable of running Linux. Intended as a research and demonstration platform, it has been taped out in several incarnations and can be mapped to an FPGA device for low-cost evaluation and testing. The supported target for FPGA emulation is the '''Genesys II''' board, and the mapping flow and auxiliary hardware environment provided by the Ariane maintainers offers a rich feature set, making it possible to run RISC-V programs on custom hardware in real time. <br />
<br />
On Ariane, user interaction with the programs running on the CPU was until recently limited to an UART link, which only allows for text input and output and requires a computer to be connected. In a previous project, a display peripheral (called PAPER) was integrated into the FPGA platform and tested.<br />
<br />
'''PAPER''' is an AXI-compliant peripheral module which supports the streaming of image (framebuffer) data from memory, as well as possessing the capability of streaming a text buffer in VGA text format – such as the Linux Virtual Terminal’s internal text representation – from memory and graphically rendering the text it contains. While PAPER has been successfully integrated into the FPGA platform and tested using simple bare-metal examples, driver support under Linux has not yet been implemented, and the current hardware implementation still has a prototype character. <br />
<br />
The overall goal of this project is to take a step towards a fully-featured autonomous Linux system based on Ariane with extensive user interaction support. To this end, you will work to provide usable display output, directly from the FPGA’s HDMI port, on the FPGA port of Ariane. This will involve both hardware design tasks to improve maturity and extend the current feature set, as well as software development in the form of Linux driver development. <br />
<br />
== Project ==<br />
<br />
In this project, you will learn to work with and extend an advanced processing system all the way from the RTL/hardware level to the Linux kernel and userspace levels. This will provide you with unique insights into the workings of such a platform, and these insights will apply readily to the Linux systems you will encounter in your academic, professional and private lives. You will learn how to hardware peripherals are designed and integrated into processing systems, as well as how to establish software support for them both in bare-metal applications and under Linux.<br />
<br />
===== Tasks =====<br />
<br />
====== Hardware Design ====== <br />
<br />
* '''Support for higher resolutions:''' Due to the current structure of the AXI infrastructure, output resolutions are limited to a maximum of SVGA (800x600) at a 60 hertz refresh rate. By refactoring the AXI infrastructure, you will eliminate this restriction and allow resolutions of Full HD and beyond. <br />
<br />
* '''Resource reclamation:''' Currently, FIFOs are implemented in HDL, which results in relatively high flip-flop utilization. By replacing them with Xilinx primitives, the FF utilization of the peripheral can be reduced by ~66%.<br />
<br />
* '''Support for Runtime-Configurable Resolution:''' Currently, the frequency of the output pixel clock is fixed at compile time. In order to make the resolution runtime-configurable, you will replace the fixed-frequency clock generator with a configurable one. This will make it possible to change the output resolution while the system is running and without requiring time-intensive re-implementation. <br />
<br />
* '''Verification:''' The assembled platform must be thoroughly tested to ensure complete and correct functionality. Furthermore, it must be ensured that the modifications don’t impact the system’s critical path.<br />
<br />
====== Software Design ======<br />
<br />
* '''Bare-Metal Driver Adaptation:''' The existing bare-metal software framework is kept as platform-agnostic as possible, but certain specifics must be adapted to correspond to the specific platform. The goal is to achieve an easy-to-use library which provides user-friendly support for both image and text display in bare-metal applications.<br />
<br />
* '''Linux Device Driver:''' In order to interact with the PAPER peripheral under Linux, it must be abstracted by a simple device driver kernel module. This driver will allow higher-level drivers (e.g. a console driver) to interact with the peripheral through a unified interface.<br />
<br />
* '''Linux Console Driver:''' A prototype console driver for Linux exists, which allows the output of the linux console to be displayed from the first line on PAPER’s original target platform, the ZEDBoard. The objective is to develop this driver to provide a more streamlined integration into the Linux kernel and to port the resulting software to source tree for the Linux distribution targeting Ariane.<br />
<br />
====== Stretch Goals ======<br />
<br />
Depending on your progress and interests, several further steps can be considered, such as:<br />
<br />
* '''Feature Extensions (HW):''' As an example for an optional goal, the PAPER module’s functionality could be extended to allow for runtime-customizable fonts in text mode.<br />
<br />
* '''Linux display driver (SW):''' In order to provide graphical output under Linux, a framebuffer driver or a KMS/DRM display driver can be implemented.<br />
<br />
* '''Input Peripheral Support (HW):''' In order to completely remove dependence on serial UART input, support for keyboard input over PS/2 or USB could be implemented. This may be realized with a dedicated hardware peripheral (re-using an existing open-source core is the most time-effective option), or by using GPIO pins to “bit-bang” the PS/2 protocol. The Genesys II board has both a dedicated USB HID host which converts USB to PS/2 and a general-purpose USB 2.0 controller which is attached to the FPGA with an ULPI interface.<br />
<br />
* '''Input Peripheral Support (SW):''' If support for PS/2 keyboard input is implemented, this will require software support under Linux. <br />
<br />
<br />
We can also discuss targeting a subset of the tasks above depending on your time frame and interests. Possible follow-up work could involve a tape-out of the system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest system design and hardware/software interaction<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Basic knowledge of operating systems<br />
<br />
Composition: 40% RTL Implementation, 20% Verification, 40% Software Design<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Georg | Georg Rutishauser]]: [mailto:georgr@iis.ee.ethz.ch georgr@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=File:Ariane-desktop.png&diff=6364File:Ariane-desktop.png2021-02-05T20:36:40Z<p>Nwistoff: Nwistoff uploaded a new version of File:Ariane-desktop.png</p>
<hr />
<div></div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=File:Ariane-desktop.png&diff=6363File:Ariane-desktop.png2021-02-05T20:28:08Z<p>Nwistoff: </p>
<hr />
<div></div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Hypervisor_Extension_for_Ariane_(M)&diff=6148Hypervisor Extension for Ariane (M)2020-11-16T22:33:37Z<p>Nwistoff: Created page with "Category:Digital Category:SW/HW Predictability and Security Category:High Performance SoCs Category:Computer Architecture Category:2020 Category:Master T..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:SW/HW Predictability and Security]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Zarubaf]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. To support common operating systems, Ariane features three privilege levels (Machine-, Supervisor-, and User-Mode) and address translation as described in the RISC-V privileged ISA [2].<br />
<br />
The RISC-V Hypervisor Extension ([2], pages 79-112) adds Hypervisor mode to the three existing privilege levels. This mode supports the virtualization and isolation of guest operating systems (OSes) – a common technique used in secure systems and cloud computing to allow running untrusted OSes or multiple OSes in parallel.<br />
<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement the Hypervisor extension as an optional feature in Ariane. The reqiured modifications include<br />
* adding a second stage of address translation,<br />
* extending the CSR (control and status register) register file by hypervisor-mode versions of existing CSRs and newly defined CSRs required for the second stage address translation, and<br />
* adding newly defined instructions for loads and stores from hypervisor mode to virtual memory, and for flushing the TLBs (<code>hfence</code>).<br />
<br />
The implemented features shall be verified and their hardware costs evaluated. The experiences gained during this work can be fed back to the RISC-V community and contribute to the development of the Hypervisor specification.<br />
<br />
Depending on the work’s progress, the Hypervisor extension's functionality can be demonstrated by porting a hypervisor to Ariane and running multiple OSes on top.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II is of benefit.<br />
<br />
Composition: 20% Architecture specification, 50% Verification, 30% RTL Implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20201018-48191f8/riscv-privileged.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=SW/HW_Predictability_and_Security&diff=6087SW/HW Predictability and Security2020-11-16T16:33:30Z<p>Nwistoff: </p>
<hr />
<div>We are in the processes of creating a top-level information page, in the meantime please continue directly to the specific subsections below.<br />
<br />
<br />
== Predictable Execution ==<br />
<br />
Please continue to [[Predictable_Execution]] if you are interested in timing predictable/safety critical embedded systems. <br />
<br />
== Cryptography ==<br />
<br />
Please continue to [[Cryptography]] if you are interested in cryptographic hardware.<br />
<br />
<br />
==Projects==<br />
<br />
===Available Projects===<br />
<DynamicPageList><br />
category = Available<br />
category = Digital<br />
category = SW/HW Predictability and Security<br />
suppresserrors=true<br />
ordermethod=sortkey<br />
order=ascending<br />
</DynamicPageList><br />
<br />
===Projects In Progress===<br />
<DynamicPageList><br />
category = In progress<br />
category = Digital<br />
category = SW/HW Predictability and Security<br />
suppresserrors=true<br />
ordermethod=sortkey<br />
order=ascending<br />
</DynamicPageList><br />
<br />
===Completed Projects===<br />
<DynamicPageList><br />
category = Completed<br />
category = Digital<br />
category = SW/HW Predictability and Security<br />
suppresserrors=true<br />
</DynamicPageList></div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=SW/HW_Predictability_and_Security&diff=6086SW/HW Predictability and Security2020-11-16T16:33:09Z<p>Nwistoff: add project section</p>
<hr />
<div>We are in the processes of creating a top-level information page, in the meantime please continue directly to the specific subsections below.<br />
<br />
<br />
== Predictable Execution ==<br />
<br />
Please continue to [[Predictable_Execution]] if you are interested in timing predictable/safety critical embedded systems. <br />
<br />
== Cryptography ==<br />
<br />
Please continue to [[Cryptography]] if you are interested in cryptographic hardware.<br />
<br />
<br />
==Projects==<br />
<br />
===Available Projects===<br />
<DynamicPageList><br />
category = Available<br />
category = Digital<br />
category = SW/HW Predictability and Security<br />
suppresserrors=true<br />
ordermethod=sortkey<br />
order=ascending<br />
</DynamicPageList><br />
<br />
===Projects In Progress===<br />
<DynamicPageList><br />
category = In progress<br />
category = Digital<br />
category = SW/HW Predictability and Security<br />
suppresserrors=false<br />
ordermethod=sortkey<br />
order=ascending<br />
</DynamicPageList><br />
<br />
===Completed Projects===<br />
<DynamicPageList><br />
category = Completed<br />
category = Digital<br />
category = SW/HW Predictability and Security<br />
suppresserrors=true<br />
</DynamicPageList></div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Category:Nwistoff&diff=5639Category:Nwistoff2020-11-02T12:30:49Z<p>Nwistoff: Redirected page to Nils Wistoff</p>
<hr />
<div>#REDIRECT [[Nils Wistoff]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=PULP_in_space_-_Fault_Tolerant_PULP_System_for_Critical_Space_Applications&diff=5611PULP in space - Fault Tolerant PULP System for Critical Space Applications2020-11-02T10:19:47Z<p>Nwistoff: Fix links</p>
<hr />
<div>[[File:AlcantaraLaunchCenter.jpg|thumb|400px]]<br />
== Introduction ==<br />
<br />
The miniaturization of increasingly complex integrated circuits (ICs) is coupled with a reduction of their noise margin, which makes such circuits more and more exposed to faults and failures. While in the past a certain reliability level could be achieved by disposing the failing circuits after their fabrication, such technique would incur into low yield and high costs if applied to modern processes.<br />
<br />
The problem is even more accentuated in critical applications, such as the transport and aerospace industries, which require strict levels of reliability. Even at the altitude of commercial flights, due to a thinner atmospheric protection, the electrical components are exposed to energetic cosmic rays, which increase the probability of the ICs encountering a transient fault (soft errors). Faster clocks increase the probability of signal spikes due to cosmic rays being captured by sequential elements, taking the system into a faulty state.<br />
<br />
Design for Reliability (DfR) is a must for such critical domains. Traditional fault-tolerant systems use massive redundancy schemes, such as Triple Modular Redundancy (TMR), to ensure a reliability level. For example, a processor core is replicated an odd number of times, and a voting mechanism is used to detect and correct any discrepancies between the cores' outputs. While such schemes are relatively simple, they incur a high cost in terms of circuit area and power. <br />
<br />
== Project description ==<br />
[[File:Ibex.png|thumb|600px]]<br />
<br />
The goal of this project in collaboration with the [https://ufrn.br/en ''Federal University of Rio Grande do Norte'' (UFRN - Brazil)] and the [http://www.inpe.br/ ''Brazilian National Institute for Space Research'' (INPE)] is to investigate architectural enhancements for building fault-tolerant low-power [https://www.pulp-platform.org/ OpenPULP multicore clusters].<br />
<br />
There are quite a few approaches at different architectural levels that can be explored. For example, a set of cores could be dynamically configured to run in lockstep, with an error being detected/corrected once they diverge (i.e., their program counter/register content differ). Alternatively, a core could run a checking task that verifies the execution of another core. The checking routines can also be run sporadically, at the end of each "critical function" for example. Moreover, flexible redundancy can be added to the cores themselves. For example, redundancy at the register-file level be dynamically added at the cost of performance by reducing the number of available registers. Finally, redundancy techniques can also be applied to the memory side, either using Error Correcting Codes (ECC) or by using redundant memory banks.<br />
<br />
For this project the OpenPULP cluster will be used in combination with the [https://www.github.com/lowRISC/ibex Ibex] processor core. Similar to RI5CY, Ibex implements the RV32IMC instruction set architecture and is open source. It has originally been designed at ETH Zürich and University of Bologna under the name Zero-riscy [3] and is now maintained and developed by the [https://www.lowrisc.org not-for-profit company lowRISC C.I.C.]. In contrast to RI5CY, Ibex has a much simpler 2-stage pipeline and no custom hardware extensions. It is fully compliant with the RISC-V specification, comes with extensive documentation and industry-grade verification infrastructure. All this facilitates the addition of new features e.g. targeting core-level fault tolerance.<br />
<br />
The project can either be done by a team of two students as a semester thesis, or by one student as a Master thesis. The project consists of three parts:<br />
<br />
1. Familiarizing with the architecture of the OpenPULP cluster and the Ibex processor core, exploration of fault-tolerant techniques (~2 person months).<br />
<br />
2. Specification and RTL design on top of an OpenPULP cluster with Ibex processor cores (~2 person months).<br />
<br />
3. FPGA evaluation of the implementation (~1-2 person months).<br />
<br />
If time permits and if you are interested, an ASIC implementation of the design is also feasible.<br />
<br />
== Required skills ==<br />
<br />
To work on this project, you will need:<br />
<br />
* to have worked in the past with at least one RTL language (SystemVerilog or Verilog or VHDL). Having followed the VLSI 1 / VLSI 2 courses is recommended.<br />
* to have prior knowledge of hardware design and computer architecture<br />
* to be motivated to work hard on a super cool open-source project<br />
<br />
=== Status: In Progress ===<br />
<br />
* Student: Michael Rogenmoser<br />
* Supervision: [[:User:nwistoff|Nils Wistoff]], [[:User:Matheusd|Matheus Cavalcante]], [[:User:Vogelpi|Pirmin Vogel]]<br />
<br />
=== Professor ===<br />
: [http://www.iis.ee.ethz.ch/portrait/staff/lbenini.en.html Luca Benini]<br />
[[#top|↑ top]]<br />
<br />
== Meetings & Presentations ==<br />
<br />
The students and advisor(s) agree on weekly meetings to discuss all relevant decisions and decide on how to proceed. Of course, additional meetings can be organized to address urgent issues.<br />
<br />
Around the middle of the project there is a design review, where senior members of the lab review your work (bring all the relevant information, such as prelim. specifications, block diagrams, synthesis reports, testing strategy, ...) to make sure everything is on track and decide whether further support is necessary. They also make the definite decision on whether the chip is actually manufactured (no reason to worry, if the project is on track) and whether more chip area, a different package, ... is provided. For more details refer to [http://eda.ee.ethz.ch/index.php/Design_review (1)].<br />
<br />
At the end of the project, you have to present/defend your work during a 15 min. presentation and 5 min. of discussion as part of the IIS colloquium.<br />
<br />
== References ==<br />
<br />
# Lorena Anghel. Les limites technologiques du silicium et tolérance aux fautes. PhD Thesis, Institut Polytechnique de Grenoble, 2001.<br />
# Matheus Cavalcante. Conception d'une plateforme RISC-V avec le système d'exploitation temps réel Trampoline. Semester Thesis, Institut Polytechnique de Grenoble, 2017.<br />
# P.D. Schiavone, et al. "Slow and steady wins the race? A comparison of ultra-low-power RISC-V cores for Internet-of-Things applications", ''Proceedings of the 27th International Symposium on Power and Timing Modeling, Optimization and Simulation (PATMOS)'', Thessaloniki, Greece, 2017. [https://ieeexplore.ieee.org/document/8106976 link]<br />
<br />
[[#top|↑ top]]<br />
[[Category:Digital]]<br />
[[Category:In progress]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:PULP]]<br />
[[Category:Vogelpi]]<br />
[[Category:Nwistoff]]<br />
[[Category:Matheusd]]<br />
[[Category:Computer Architecture]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Multi_issue_OoO_Ariane_Backend&diff=5564Multi issue OoO Ariane Backend2020-10-30T18:06:17Z<p>Nwistoff: /* Requirements */</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Zarubaf]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Ariane/CVA6 (it transitioned to Openhardware in June and was renamed to CVA6, however, we like the name and keep it as an internal code name) is a popular, 6-stage, in-order, RISC-V CPU designed as part of the PULP project and capable of booting Linux. The current Ariane backend [1] is built around a scoreboard (essentially a small ROB) which took over more and more functionality. <br />
<br />
A widely employed technique to increase sequential performance (IPC) is to issue multiple instructions per cycle, we call such architectures superscalar. A second performance improvement can come from the fact that not all instructions depend on each other. Clever architecture can issue independent instructions out of program order, exploiting instruction-level parallelism (ILP). <br />
<br />
But increasing the issue width would mean adding further ports into the scoreboard, increasing complexity, power, and reducing operating frequency. <br />
<br />
== Project ==<br />
<br />
This project proposes to re-architect the backend of Ariane (keeping the frontend and caches as well as suitable sub-blocks such as TLBs, FPU, etc.) in a similar manner as other OoO architectures such as the MIPS R10000 [2], Alpha 21264 [3], OpenPower A20 [4], Boom [5]. Ideally, we would make the core parametric over the issue width (ranging from single issue up to four or six-way superscalar). The final goal is to have a reasonably advanced superscalar core running at around 1.5GHz operating frequency in a modern 12nm process with IPCs expected from that class of processor [6].<br />
<br />
Depending on the timeframe further features can be added:<br />
* RoCC Interface<br />
* Bitmanipulation ALU<br />
* Multi-level TLBs<br />
* Page walk cache<br />
* Speculative load/store disambiguation predictor [7]<br />
<br />
This is an ambitious (but super rewarding) project so we are preferably looking for very dedicated master thesis students. In case you should be interested as part of a semester thesis we can try to find a suitable subset (for example just the re-naming logic) on which you can work.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II<br />
<br />
Composition: 30% Architecture specification, 40% Verification, 30% RTL Implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
<br />
<br />
== References ==<br />
<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] http://www.ece.mtu.edu/faculty/rmkieckh/cla/4173/REFERENCES/MIPS-R10K-uman1.pdf<br />
* [3] http://www.archive.ece.cmu.edu/~ece447/s13/lib/exe/fetch.php?media=21264hrm.pdf<br />
* [4] https://github.com/openpower-cores/a2o<br />
* [5] https://docs.boom-core.org/en/latest/<br />
* [6] https://carrv.github.io/2020/papers/CARRV2020_paper_15_Zhao.pdf<br />
* [7] https://people.csail.mit.edu/emer/papers/1998.06.isca.storesets.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=IBM_A2O_Core&diff=5563IBM A2O Core2020-10-30T18:05:20Z<p>Nwistoff: /* Requirements */</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Tbenz]]<br />
[[Category:Paulsc]]<br />
[[Category:Nwistoff]]<br />
[[Category:Available]]<br />
<br />
<br />
=Investigation of the high-performance multi-threaded OoO IBM A2O Core=<br />
<br />
IBM recently contributed their A2O processor core to the open-source community. The A2O is a 2-way multithreaded out-of-order core optimized for single thread performance. It is completely written in Verilog 2001. <br />
<br />
Even though the A2O is primarily targeted for embedded applications, it features high computational throughput by running up to 3GHz in a 45nm technology node. It was created as an application-grade linux-capable processor to be integrated in large SoCs primarily targeting applications like Artificial Intelligence and Autonomous driving. <br />
<br />
For us at IIS the core poses a great opportunity to advance from rather simple pipelined in-order cores (RI5CY, Zero-riscy, Ariane) to a full-fledged commercial superscalar, multi-threaded, out-of-order processor. There are many knobs available in RTL to tune and tweak the A2O core. As of now, only a single configuration has been tested and successfully implemented on an FPGA. There are therefore plenty of opportunities to experiment with the parameters and investigate their impact on performance, area, and speed.<br />
<br />
== Thesis Content ==<br />
The thesis will be divided into the following sub tasks:<br />
<br />
* '''Initial exploration:''' get familiar and understand the structure of the A2O core<br />
* '''RTL synthesis:''' process the Verilog source of the A2O core to be compatible with our synthesis toolchain and synthesize the default configuration<br />
* '''RTL simulation:''' understand the interface of the core and create a testbench that can execute binaries on the processor<br />
* '''Parameter exploration:''' understand what parameters can be tweaked and how they influence performance, area, and speed in a 22nm node.<br />
<br />
== Requirements ==<br />
<br />
* Profound knowledge of computer architecture<br />
* Experience with HDLs such as taught in ''VLSI I''<br />
* Preferably previous experience with FPGAs and / or an ASIC toolflow (simulation & synthesis)<br />
<br />
Composition: 40% initial exploration and base-line synthesis, 30% RTL simulation, 40% parameter exploration<br />
<br />
== Further Reading ==<br />
* [https://github.com/openpower-cores/a2o A2O on GitHub]<br />
<br />
== Project Supervisors ==<br />
* [[:User:Tbenz | Thomas Benz]]: [mailto:tbenz@iis.ee.ethz.ch tbenz@iis.ee.ethz.ch]<br />
* [[:User:Paulsc | Paul Scheffler]]: [mailto:paulsc@iis.ee.ethz.ch paulsc@iis.ee.ethz.ch]<br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Coherence-Capable_Write-Back_L1_Data_Cache_for_Ariane&diff=5562Coherence-Capable Write-Back L1 Data Cache for Ariane2020-10-30T18:01:52Z<p>Nwistoff: </p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Zarubaf]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. Ariane features a write-back level 1 data cache, which temporally stores a copy of recently accessed memory contents to accelerate future accesses to this data.<br />
<br />
To increase a system's performance on parallel workloads, a common technique is to combine multiple instances of a core to a ''multi-core'' system. This technique introduces a new challenge: Each core keeps its own copy of the (partial) main memory in its respective L1 data cache. Working of different copies of the same data can quickly result in inconsistencies between the cores' memory views.<br />
<br />
This challenge can be tackled by introducing ''cache-coherence'', a set of mechanisms that keep the local caches synchronized and up-to-date.<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement general coherence support in Ariane’s write-back L1 data cache, so that it can be integrated into various coherent memory systems. For instance,<br />
* the cache needs to track and handle additional state of the cache lines, e.g. whether they are unique or shared, and<br />
* a coherent memory system must be able to invalidate or update specific cache lines, and to request specific cache lines for forwarding or write-back.<br />
<br />
Depending on the work’s progress, this functionality can be demonstrated by implementing adapters to existing coherent interconnects, such as OpenPiton’s NoCs [2,3], BlackParrot’s BedRock [4], or SiFive’s TileLink [5] and thus building a sample multi-core system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II<br />
<br />
Composition: 30% Architecture specification, 40% Verification, 30% RTL Implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] http://parallel.princeton.edu/papers/openpiton-asplos16.pdf<br />
* [3] http://www.parallel.princeton.edu/papers/aspl20-balkind.pdf<br />
* [4] https://github.com/black-parrot/black-parrot/blob/master/docs/bedrock_guide.md<br />
* [5] https://sifive.cdn.prismic.io/sifive%2Fcab05224-2df1-4af8-adee-8d9cba3378cd_tilelink-spec-1.8.0.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Coherence-Capable_Write-Back_L1_Data_Cache_for_Ariane&diff=5561Coherence-Capable Write-Back L1 Data Cache for Ariane2020-10-30T18:00:31Z<p>Nwistoff: Created page with "Category:Digital Category:High Performance SoCs Category:Computer Architecture Category:2020 Category:Master Thesis Category:Semester Thesis Category..."</p>
<hr />
<div>[[Category:Digital]]<br />
[[Category:High Performance SoCs]]<br />
[[Category:Computer Architecture]]<br />
[[Category:2020]]<br />
[[Category:Master Thesis]]<br />
[[Category:Semester Thesis]]<br />
[[Category:Nwistoff]]<br />
[[Category:Zarubaf]]<br />
[[Category:Available]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Ariane is an open-source, 6-stage, 64-bit, in-order RISC-V core developed at IIS [1]. It is capable of booting Linux and it is widely used both in academia and industry. Ariane features a write-back level 1 data cache, which temporally stores a copy of recently accessed memory contents to accelerate future accesses to this data.<br />
<br />
To increase a system's performance on parallel workloads, a common technique is to combine multiple instances of a core in a ''multi-core'' system. This technique introduces a new challenge: Each core keeps its own copy of the (partial) main memory in its respective L1 data cache. Working of different copies of the same data can quickly result in inconsistencies between the cores' memory views.<br />
<br />
This challenge can be tackled by introducing ''cache-coherence'', a set of mechanisms that keep the local caches synchronized and up-to-date.<br />
<br />
== Project ==<br />
<br />
The goal of this project is to implement general coherence support in Ariane’s write-back L1 data cache, so that it can be integrated into various coherent memory systems. For instance,<br />
* the cache needs to track and handle additional state of the cache lines, e.g. whether they are unique or shared, and<br />
* a coherent memory system must be able to invalidate or update specific cache lines, and to request specific cache lines for forwarding or write-back.<br />
<br />
Depending on the work’s progress, this functionality can be demonstrated by implementing adapters to existing coherent interconnects, such as OpenPiton’s NoCs [2,3], BlackParrot’s BedRock [4], or SiFive’s TileLink [5] and thus building a sample multi-core system.<br />
<br />
===== Requirements ===== <br />
<br />
* Strong interest in computer architecture<br />
* Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I<br />
* Knowledge of ASIC tool flow (Synthesis) or parallel enrollment with VLSI II<br />
<br />
Composition: 30% Architecture specification, 40% Verification, 30% RTL Implementation<br />
<br />
===== Project Supervisors ===== <br />
* [[:User:Nwistoff | Nils Wistoff]]: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* [[:User:Zarubaf | Florian Zaruba]]: [mailto:zarubaf@iis.ee.ethz.ch zarubaf@iis.ee.ethz.ch]<br />
<br />
== References ==<br />
<br />
* [1] https://github.com/openhwgroup/cva6<br />
* [2] http://parallel.princeton.edu/papers/openpiton-asplos16.pdf<br />
* [3] http://www.parallel.princeton.edu/papers/aspl20-balkind.pdf<br />
* [4] https://github.com/black-parrot/black-parrot/blob/master/docs/bedrock_guide.md<br />
* [5] https://sifive.cdn.prismic.io/sifive%2Fcab05224-2df1-4af8-adee-8d9cba3378cd_tilelink-spec-1.8.0.pdf</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=User:Nwistoff&diff=5560User:Nwistoff2020-10-30T16:59:42Z<p>Nwistoff: Redirected page to Nils Wistoff</p>
<hr />
<div>#REDIRECT [[Nils Wistoff]]</div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=Nils_Wistoff&diff=5559Nils Wistoff2020-10-30T16:59:06Z<p>Nwistoff: Created page with "==Contact== * Office: ETZ J85 * E-Mail: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch] * Phone: +41 44 632 06 75 ==Interests== * Processor Design * Secure Computer..."</p>
<hr />
<div>==Contact==<br />
* Office: ETZ J85<br />
* E-Mail: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* Phone: +41 44 632 06 75<br />
<br />
==Interests==<br />
* Processor Design<br />
* Secure Computer Architectures<br />
* Operating Systems<br />
<br />
==Projects==<br />
<br />
===Available Projects===<br />
<DynamicPageList><br />
category = Available<br />
category = Nwistoff<br />
suppresserrors=true<br />
</DynamicPageList><br />
<br />
===Projects In Progress===<br />
<DynamicPageList><br />
category = In progress<br />
category = Nwistoff<br />
</DynamicPageList><br />
<br />
===Completed Projects===<br />
<DynamicPageList><br />
category = Completed<br />
category = Nwistoff<br />
suppresserrors=true<br />
</DynamicPageList></div>Nwistoffhttp://iis-projects.ee.ethz.ch/index.php?title=User:Nwistoff&diff=5558User:Nwistoff2020-10-30T16:56:01Z<p>Nwistoff: </p>
<hr />
<div>==Nils Wistoff==<br />
* Office: ETZ J85<br />
* E-Mail: [mailto:nwistoff@iis.ee.ethz.ch nwistoff@iis.ee.ethz.ch]<br />
* Phone: +41 44 632 06 75<br />
<br />
==Interests==<br />
* Processor Design<br />
* Secure Computer Architectures<br />
* Operating Systems<br />
<br />
==Projects==<br />
<br />
===Available Projects===<br />
<DynamicPageList><br />
category = Available<br />
category = Nwistoff<br />
suppresserrors=true<br />
</DynamicPageList><br />
<br />
===Projects In Progress===<br />
<DynamicPageList><br />
category = In progress<br />
category = Nwistoff<br />
</DynamicPageList><br />
<br />
===Completed Projects===<br />
<DynamicPageList><br />
category = Completed<br />
category = Nwistoff<br />
suppresserrors=true<br />
</DynamicPageList></div>Nwistoff