Displaying 1 to 20 from 85 results

NyuziProcessor - GPGPU microprocessor architecture

  •    C++

Nyuzi is an experimental GPGPU processor hardware design focused on compute intensive tasks. It is optimized for use cases like blockchain mining, deep learning, and autonomous driving. This project includes a synthesizable hardware design written in System Verilog, an instruction set emulator, an LLVM based C/C++ compiler, software libraries, and tests. It can be used to experiment with microarchitectural and instruction set design tradeoffs.

paddle-mobile - This research aims at simply deploying deeplearning on mobile and embedded devices, with low complexity and high speed

  •    C++

This research aims at simply deploying deeplearning on mobile and embedded devices, with low complexity and high speed. old name mobile deep learning.




icestudio - :snowflake: Visual editor for open FPGA boards

  •    Javascript

Visual editor for open FPGA boards. Built on top of the Icestorm project using Apio. Check the Documentation for more information.

hdl - HDL libraries and projects

  •    Verilog

Analog Devices Inc. HDL libraries and projects. This repository supports reference designs for different Analog Devices boards based on Intel and Xilinx FPGA development boards or standalone.

VexRiscv - A FPGA friendly 32 bit RISC-V CPU implementation

  •    Assembly

For commercial support, please contact spinalhdl@gmail.com. The following numbers were obtained by synthesizing the CPU as toplevel without any specific synthesis options to save area or to get better maximal frequency (neutral). The clock constraint is set to an unattainable value, which tends to increase the design area. The dhrystone benchmark was compiled with the -O3 -fno-inline option. All the cached configurations have some cache trashing during the dhrystone benchmark except the VexRiscv full max perf one. This of course reduces the performance. It is possible to produce dhrystone binaries which fit inside a 4KB I$ and 4KB D$ (I already had this case once) but currently it isn't the case. The CPU configurations used below can be found in the src/scala/vexriscv/demo directory.

vunit - VUnit is a unit testing framework for VHDL/SystemVerilog

  •    VHDL

VUnit is an open source unit testing framework for VHDL/SystemVerilog released under the terms of Mozilla Public License, v. 2.0. It features the functionality needed to realize continuous and automated testing of your HDL code. VUnit doesn't replace but rather complements traditional testing methodologies by supporting a "test early and often" approach through automation. Contributing in the form of code, feedback, ideas or bug reports are welcome. Read our contribution guide to get started.


ariane - Ariane is a 6-stage RISC-V CPU

  •    SystemVerilog

Ariane is a 6-stage, single issue, in-order CPU which implements the 64-bit RISC-V instruction set. It fully implements I, M and C extensions as specified in Volume I: User-Level ISA V 2.1 as well as the draft privilege extension 1.10. It implements three privilege levels M, S, U to fully support a Unix-like operating system. Furthermore it is compliant to the draft external debug spec 0.13. It has configurable size, separate TLBs, a hardware PTW and branch-prediction (branch target buffer and branch history table). The primary design goal was on reducing critical path length.

fusesoc - FuseSoC is a package manager and a set of build tools for FPGA/ASIC development

  •    Python

FuseSoC is an award-winning package manager and a set of build tools for HDL (Hardware Description Language) code. Its main purpose is to increase reuse of IP (Intellectual Property) cores and be an aid for creating, building and simulating SoC solutions.

cfm - A 16-bit CPU and system, written in Haskell and running Forth on FPGA.

  •    Haskell

This is a Forth-inspired processor targeting the Lattice ICE40 FPGA series, primarily targeting the Icoboard. The distribution includes BsForth, a non-ANS Forth implementation that can provide a bare-bones interactive development environment with optimizing compiler in less than 5 kiB. It's interesting in the way that it bootstraps (using the cycle-accurate emulator) and for its machine instruction fusion algorithm.

LispMicrocontroller - A microcontroller that natively executes a simple LISP dialect

  •    Python

This is a simple microcontroller that runs a compiled LISP dialect. Details of operation are in the wiki. The test runner searches files for patterns that begin with 'CHECK:'. The output of the program will be compared to whatever comes after this declaration. If they do not match, an error will be flagged.

PASC - Parallel Array of Simple Cores. Multicore processor.

  •    Verilog

This is a multi-core embedded processor. There are a 16 RISC cores, each with a small chunk of local memory and a shared global memory area. Documentation is in the wiki (https://github.com/jbush001/PASC/wiki). Replace 'sourcefile' in the command line with the desired file.

clash-playground - A Clash playground/starter kit, using Nix

  •    Haskell

This repository contains a basic skeleton for doing FPGA development and testing, using Clash, Yosys, IceStorm, and more tools. These are all wrapped up and provided using the Nix package manager, meaning this setup should work on any Linux distribution. It gives you a fairly painless and one-shot way of setting up an environment for Clash development, along with a lot of other helpful tools.

usbcorev - A full-speed device-side USB peripheral core written in Verilog.

  •    Verilog

This core allows you to embed a full-speed (12Mbps) USB 2.0 device core into your FPGA design. The core requires a reasonably precise 48MHz clock. You'd better derive it from a crystal oscillator.

sega-system-for-fpga - FPGA Sega in Verilog, for Xilinx Virtex, circa 2002

  •    Assembly

I found this zip file from many years ago on my old laptop that I was giving away; might as well throw it up on github in case anyone has a use for Sega in Verilog that's synthesizable. According to the timestamps, I was a teenager when I worked on this, so the quality of the code isn't that great. Also, as I recall, the display was something very specific to the weirdo board we had, where half of the SRAM address and data lines were multiplexed to drive a display. The only bug I can recall was that in Double Dragon, the heads and torsos on some characters would be swapped, but that probably indicates that other games don't work perfectly, even if the bugs aren't as visually obvious.