tvanas / r-vex

A reconfigurable and extensible VLIW processor implemented in VHDL

ρ-VEX: A Reconfigurable and Extensible VLIW Processor

ρ-VEX is an open source VLIW processor with an accompanied development framework. The project started as the MSc project of Thijs van As while he was at the Computer Engineering Laboratory at Delft University of Technology.

Today, multiple research groups are still actively working on extending and improving the ρ-VEX framework.

This project was originally hosted on Google Code (at r-vex.googlecode.com).

About ρ-VEX

ρ-VEX is an open source reconfigurable and extensible Very-Long Instruction Word (VLIW) processor, accompanied by a development framework consisting of a VEX assembler, ρ-ASM. The processor architecture is based on the VEX ISA, as introduced by J.A. Fisher et al.. The VEX ISA offers a scalable technology platform for embedded VLIW processors, that allows variation in many aspects, including instruction issue-width, organization of functional units, and instruction set. The ρ-VEX source code is described in VHDL. ρ-ASM is written in C.

A software development compiler toolchain for VEX is made publicly available by Hewlett-Packard. The reasons VEX was chosen as the ISA are merely its extensibility and the quality of the available compiler. The design provides mechanisms that allow parametric extensibility of ρ-VEX. Both reconfigurable operations, as well as the versatility of VEX machine models are supported by ρ-VEX. The processor and framework are targeted at VLIW prototyping research and embedded processor design.

The name ρ-VEX stands for 'reconfigurable VEX' processor. Because the letter Rho (P or ρ) is the Greek analogous for the Roman R or r, ρ-VEX is pronounced as r-VEX. This is also the correct spelling when no Greek letters can be used.

Getting Started

To start experimenting with ρ-VEX, read the Quickstart Guide and download a release snapshot, or clone master. When you have a Xilinx University Program Virtex-II Pro Board by Digilent, you should have ρ-VEX running within moments.

Documentation

• ρ-VEX Quickstart Guide
• ρ-VEX Machine Operations and Semantics
• Thijs' MSc Thesis with extensive documentation about ρ-VEX' design and implementation
• ρ-VEX: A Reconfigurable and Extensible VLIW Softcore Processor (published at ICFPT'08)
• instruction_layout.txt
• syllable_layout.txt

r-vex's Issues

Add support for long immediate operands

Implement support for long immediate operands. There is an immediate switch
available for this type of operands.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:31

r-ASM: Add support for hexadecimal immediate notation

Currently, r-ASM only supports decimal immediate notation. However, the VEX
compiler sometimes presents immediate operands as hexadecimal numbers (in
0x<hex> C-like notation).

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:18

Add separate link register $l0.0 instead of using $r0.63

Currently, $r0.63 is hardcoded as the link register address. In some VEX
documents, $r0.63 is referred for this job, but it seems better to add a
dedicated link register to the design. This also avoids issues when less
than 64 GR registers are assigned in r-VEX (currently, there is no fix for
this case).

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:10

r-ASM: Add support for r-OPS configuration file

Add support for r-OPS within a configuration file. A configuration file
format has to be determined first.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:29

r-ASM: Add support for VEX machine model (.fmm) files

Add support for VEX machine model (.fmm) files to gain 'knowledge' about
the target processor.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:27

Makefile for r-VEX does not work under Ubuntu 9.04

The makefile for synthesis does not work with the Make version that ships
with Ubuntu 9.04. The problem is the "-e" flag for the @echo commands.
Removing them fixes this problem. This version of Make does not need this
flag, the '\' escapes are automatically parsed. 

Original issue reported on code.google.com by [email protected] on 12 Nov 2009 at 9:59

Add branch_taken signal, make waiting_branch state dependent on this

The transition to the waiting_branch state in the writeback stage should be
 on a branch_taken signal. At least in the unpipelined implementation. When
a branch isn't taken, this saves a cycle.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:49

Pipeline the implementation

From my MSc thesis:

---

r-VEX is designed to be easily pipelined, as can be seen from the various
stage diagrams with the signal flows. However, the current prototype is not
yet pipelined. To have a pipelined implementation, these things have to be
done:

 * Pass destination GR and BR addresses through the execute stage
   to the writeback stage with pipeline registers, instead of
   directly driving these addresses from the decode stage to the
   corresponding register files.
 * Pass the 'target_' signal bundle through the execute stage to the
   writeback stage with pipeline registers, instead of bypassing it.
 * Let consecutive stages only be dependent on control signals drive
   by their direct neighbour stages, instead of skipping stages.
 * The 'stop' bit for the fetch stage should be driven by the
   writeback stage, in order not to lose operations inside the pipeline. 
 * The Program Counter should be updated by the fetch stage upon
   non-CTRL operations (possible branches).
 * The current Program Counter value (for the syllables in a certain
   stage) should be registered between each stage.
 * When a CTRL syllable is decoded, a signal 'flush_pipeline' should
   be set, in order to flush the pipeline before branching.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 8:03

r-ASM: Add support for long immediate operands

Add support for long immediate operands in r-ASM. Issue 6 (r-VEX support
for long immediate operands) should be resolved first.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:34

Logical/select ALU operations fix when BR is destination in combination with immediate operand

On the logical (compare) ALU operations with BR or GR destination register
options, no immediate operation is supported when a BR is the destination.
This is caused by the fact that part of the immediate field is used by the
BR destination address field, as can be see below:


 31              23              15              7             0
 ^               ^               ^               ^             ^
|             |   |           |           |           |     | | |
|o o o o o o o|0 0|d d d d d d|a a a a a a|b b b b b b|k k k|L|F|
|             |S S|           |           |           |     | | |

o   : Opcode
d   : Destination register address
a   : Source register 1 address
b   : Source register 2 address
k   : Destination branch register address
L   : '1' if the syllable is the last in the instruction
F   : '1' if the syllable is the first in the instruction

S S : Immediate switch
      0 0 = NO_IMM      no immediate value
      0 1 = SHORT_IMM   short immediate
      1 0 = BRANCH_IMM  branch offset immediate
      1 1 = LONG_IMM    long immediate

Possible fix:
Use SHORT_IMM immediate switch when GR is destination and BRANCH_IMM when
BR is target. BR could then be packed in GR destination address field. The
BRANCH_IMM switch is normally illegal in ALU operations, so this does not
provoke any conflicts.

Original issue reported on code.google.com by [email protected] on 19 Aug 2008 at 7:06

Garbled output on UART

What steps will reproduce the problem?
1. Synthesize r-VEX using ISE10.1
2. Create SystemACE file using impact and copy to CF card
3. Boot XUPv2 board from CF card, connect USB-UART adapter or real (DEC VT510) 
terminal using 115200 8N1 settings

What is expected? What do you get instead?

Expected: UART demo output as in demo/reference_outputs/fibonacci.txt
Received: Garbled output, some characters readable, see attached screen shot

Which synthesizer and what version are you using? On what operating system?

ISE 10.1 on Debian 7 x86
Current svn checkout of r-VEX as well as MSc thesis version (these seem to be 
identical anyways?)

Please provide any additional information below.

Screenshot of terminal emulator is attached. Some of the characters are 
actually readable, however, the exact
characters differ from run to run. In this run, "Cy[cle]s" and "conten[t]s" can 
be deciphered.

I tried the following to fix the problem:
- use different USB-UART adapter (I only had some with Prolific 2303 chipsets, 
however)
- use different OS (Ubuntu 13.04/x64 instead of OS X) with Prolific adapter
- use real hardware terminal (DEC VT510) and serial null modem cable
- change baud rate multiplier (in r-VEX/src/uart/clk_18432.vhd) to result in 
9600 and 230400 baud, resp.
   (and set terminal (emulation) accordingly), synthesize, ACE, restart -> similar effects
- use a second XUPv2 board
- use (in desparation ;-)) different settings for parity and stop bits and test 
all other standard baud rates

However, all these changes had no significant effects. I know this error looks 
rather like a misconfiguration of the UART on the displaying side, but I tried 
my best to rule this out.

Could it be that the transmit register gets overrun before the transmission is 
actually completed? I can't imagine any other probable error at the moment. In 
addition, I couldn't find (I only did a quick search, however) where exactly 
the memory dump text is actually generated. The binary code in i_mem.vhd only 
seems to implement the fib calculation itself.

Original issue reported on code.google.com by [email protected] on 5 Sep 2013 at 7:25

Attachments:

• [Screen Shot 2013-09-05 at 21.14.28.png](https://storage.googleapis.com/google-code-attachments/r-vex/issue-11/comment-0/Screen Shot 2013-09-05 at 21.14.28.png)