Skip to content

Commit

Permalink
Fix typos
Browse files Browse the repository at this point in the history
  • Loading branch information
nazar-codethink authored and olofk committed Apr 6, 2024
1 parent bebc875 commit a26c296
Show file tree
Hide file tree
Showing 11 changed files with 32 additions and 32 deletions.
2 changes: 1 addition & 1 deletion NEWS
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
1.2.0 2022-07-25 Olof Kindgren
======================================================

* New Servant ports: EBAZ4205, Chameleion96, Nexys2, Alinx AX309
* New Servant ports: EBAZ4205, Chameleon96, Nexys2, Alinx AX309
* Support for M ISA extension
* Support for C ISA extension
* Fix occasionally wrong sign on immediates
Expand Down
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ SERV can be easily integrated into any design, but if you are looking at just qu

[CoreScore](https://corescore.store/) is an award-giving benchmark for FPGAs and their synthesis/P&R tools. It tests how many SERV cores that can be put into a particular FPGA.

[Observer](https://github.com/olofk/observer) is a configurable and software-programmable sensor aggregation platform for heterogenous sensors.
[Observer](https://github.com/olofk/observer) is a configurable and software-programmable sensor aggregation platform for heterogeneous sensors.

[Subservient](https://github.com/olofk/subservient/) is a small technology-independent SERV-based SoC intended for ASIC implementations together with a single-port SRAM.

Expand Down Expand Up @@ -65,7 +65,7 @@ All the following commands will be run from this directory unless otherwise stat
$ fusesoc library add serv https://github.com/olofk/serv
>:warning: The SERV repo will now be available in `$WORKSPACE/fusesoc_libraries/serv`. We will refer to that directory as `$SERV`.
- Install latest version of [Verilator](https://www.veripool.org/wiki/verilator)
- (Optional) To support RISC-V M-extension extension, Multiplication and Division unit (MDU) can be added included into the SERV as a seprate library.
- (Optional) To support RISC-V M-extension extension, Multiplication and Division unit (MDU) can be added included into the SERV as a separate library.

$ fusesoc library add mdu https://github.com/zeeshanrafique23/mdu
MDU will be available in `$WORKSPACE/fusesoc_libraries/mdu`
Expand Down Expand Up @@ -128,7 +128,7 @@ For a more advanced example, we can also run the Dining philosophers demo



If the [toolchain](https://github.com/riscv-collab/riscv-gnu-toolchain) is installed, other applications can be tested by compiling the assembly prgram and converting to bin and then hex with makehex.py found in [`$SERV/sw`](/sw/).
If the [toolchain](https://github.com/riscv-collab/riscv-gnu-toolchain) is installed, other applications can be tested by compiling the assembly program and converting to bin and then hex with makehex.py found in [`$SERV/sw`](/sw/).

:bulb:RISC-V Compressed Extension can be enabled by passing `--compressed=1` parameter.

Expand Down
2 changes: 1 addition & 1 deletion doc/interface.rst
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ Users of SERV can choose to use either serv_top or serv_rf_top depending on what

.. image:: serv_top.png

serv_rf_top is a convenience wrapper that combines serv_top with a memory-based RF (serf_rf_ram) and an adapter between them (serv_rf_ram_if). This allows users to choose between a drop-in implemenentation when the memory-based RF is good enough or supply an alternative RF implementation, such as a shift-register based one or a combined SRAM for instruction/data memory and RF.
serv_rf_top is a convenience wrapper that combines serv_top with a memory-based RF (serf_rf_ram) and an adapter between them (serv_rf_ram_if). This allows users to choose between a drop-in implementation when the memory-based RF is good enough or supply an alternative RF implementation, such as a shift-register based one or a combined SRAM for instruction/data memory and RF.

.. image:: serv_rf_top.png

Expand Down
12 changes: 6 additions & 6 deletions doc/modules.rst
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
Modules
-------

SERV is a bit-serial CPU which means that the internal datapath is one bit wide. :ref:`dataflow` show the internal dataflow. For each instruction, data is read from the register file or the immediate fields of the instruction word and the result of the operation is stored back into the register file. Reading and writing memory is handled through the memory interface module.
SERV is a bit-serial CPU which means that the internal datapath is one bit wide. :ref:`dataflow` shows the internal dataflow. For each instruction, data is read from the register file or the immediate fields of the instruction word and the result of the operation is stored back into the register file. Reading and writing memory is handled through the memory interface module.

.. _dataflow:

Expand All @@ -28,7 +28,7 @@ serv_alu

serv_alu handles alu operations. The first input operand (A) comes from i_rs1 and the second operand (B) comes from i_rs2 or i_imm depending on the type of operation. The data passes through the add/sub or bool logic unit and finally ends up in o_rd to be written to the destination register. The output o_cmp is used for conditional branches to decide whether or not to take the branch.

The add/sub unit can do additions A+B or subtractions A-B by converting it to A+B̅+1. Subtraction mode (i_sub = 1) is also used for the comparisions in the slt* and conditional branch instructions. The +1 used in subtraction mode is done by preloading the carry input with 1. Less-than comparisons are handled by converting the expression A<B to A-B<0 and checking the MSB, which will be set when the result is less than 0. This however requires sign-extending the operands to 33-bit inputs. For signed operands (when i_cmp_sig is set), the extra bit is the same as the MSB. For unsigned, the extra bit is always 0. Because the ALU is only active for 32 cycles, the 33rd bit must be calculated in parallel to the ordinary addition. The result from this operations is available in result_lt. For equality checks, result_eq checks that all bits are 0 from the subtraction.
The add/sub unit can do additions A+B or subtractions A-B by converting it to A+B̅+1. Subtraction mode (i_sub = 1) is also used for the comparisons in the slt* and conditional branch instructions. The +1 used in subtraction mode is done by preloading the carry input with 1. Less-than comparisons are handled by converting the expression A<B to A-B<0 and checking the MSB, which will be set when the result is less than 0. This however requires sign-extending the operands to 33-bit inputs. For signed operands (when i_cmp_sig is set), the extra bit is the same as the MSB. For unsigned, the extra bit is always 0. Because the ALU is only active for 32 cycles, the 33rd bit must be calculated in parallel to the ordinary addition. The result from this operations is available in result_lt. For equality checks, result_eq checks that all bits are 0 from the subtraction.

.. image:: serv_alu_int.png

Expand All @@ -37,7 +37,7 @@ serv_bufreg

.. image:: serv_bufreg.png

For two-stage operations, serv_bufreg holds data between stages. This data can be the effective address for branches or load/stores or data to be shifted for shift ops. It has a serial output for streaming out results during stage two and a parallel output that forms the dbus address. serv_bufreg also keeps track of the two lsb when calculating adresses. This is used to check for alignment errors. In order to support these different modes, the input to the shift register can come from rs1, the immediate (imm), rs1+imm or looped back from the shift register output. The latter is used for shift operations. For some operations, the LSB of the immediate is cleared before written to the shift register. The two LSB of the shift register are special. When the shift register is loaded, these two get written first before the rest of the register is filled up. This allows the memory interface to check data/address alignment early.
For two-stage operations, serv_bufreg holds data between stages. This data can be the effective address for branches or load/stores or data to be shifted for shift ops. It has a serial output for streaming out results during stage two and a parallel output that forms the dbus address. serv_bufreg also keeps track of the two lsb when calculating addresses. This is used to check for alignment errors. In order to support these different modes, the input to the shift register can come from rs1, the immediate (imm), rs1+imm or looped back from the shift register output. The latter is used for shift operations. For some operations, the LSB of the immediate is cleared before written to the shift register. The two LSB of the shift register are special. When the shift register is loaded, these two get written first before the rest of the register is filled up. This allows the memory interface to check data/address alignment early.

.. image:: serv_bufreg_int.png

Expand All @@ -46,7 +46,7 @@ serv_bufreg2

.. image:: serv_bufreg2.png

serv_bugreg2 is a 32-bit buffer register with some special features. It is used for shift operations to store the shift amount. It's used in load and store operations to store the data to be written or be read from the data bus, and it holds rs2 for the SERV extension interface. For shift and store operations, the register is shifted in from MSB when dat_en is asserted, while for loads and uses of the extension interface, the whole data word is written to when the i_load signal is asserted. Once the data is in the buffer, it is used differently depending on the operation. For stores and the extension interface the whole buffer is directly connected to the data bus as a 32-bit register. For load operations, the data is fed out serially once it has been fetched from the data bus. To better support load operations of varying sizes the buffer contains logic for reading out data serially from any of the byte LSBs of the 32-bit word. Finally, in shift mode, the 6 LSB of the register is used as a downcounter that is initialized during the init stage and then counts the remaining number of steps to shift the data and signals using sh_done and sh_done_r when finished.
serv_bufreg2 is a 32-bit buffer register with some special features. It is used for shift operations to store the shift amount. It's used in load and store operations to store the data to be written or be read from the data bus, and it holds rs2 for the SERV extension interface. For shift and store operations, the register is shifted in from MSB when dat_en is asserted, while for loads and uses of the extension interface, the whole data word is written to when the i_load signal is asserted. Once the data is in the buffer, it is used differently depending on the operation. For stores and the extension interface the whole buffer is directly connected to the data bus as a 32-bit register. For load operations, the data is fed out serially once it has been fetched from the data bus. To better support load operations of varying sizes the buffer contains logic for reading out data serially from any of the byte LSBs of the 32-bit word. Finally, in shift mode, the 6 LSB of the register is used as a downcounter that is initialized during the init stage and then counts the remaining number of steps to shift the data and signals using sh_done and sh_done_r when finished.

.. image:: serv_bufreg2_int.png

Expand All @@ -64,7 +64,7 @@ serv_ctrl

.. image:: serv_ctrl.png

serv_ctrl keeps track of the current PC and contains the logic needed to calculate the next PC. The PC is stored in shift register with a parellel output connected to the instruction bus.
serv_ctrl keeps track of the current PC and contains the logic needed to calculate the next PC. The PC is stored in shift register with a parallel output connected to the instruction bus.

The new PC can come from three sources. For normal instructions, it is incremented by four, which is the next 32-bit address. Jumps can be absolute or relative to the current PC. Absolute jumps are precalculated in serv_bufreg and written directly to the PC. PC relative jumps have the offset part precalculated in serv_bufreg which gets added to the current PC before storing as the new PC. The third source for the new PC comes from the CSR registers when entering or returning traps.

Expand Down Expand Up @@ -281,7 +281,7 @@ External timer interrupts and ecall/ebreak are also one-stage operations with so
Two-stage operations
::::::::::::::::::::

Some operations need to be executed in two stages. In the first stage the operands are read out from the instruction immediate fields and the rs1/rs2 registers. In the second stage rd and the PC are updated with the results from the operation. The operation-specific things happen between the aformentioned stages. SERV has four types of four two-stage operations; memory, shift, slt and branch operations. In all cases the first stage is distinguished by having the init signal raised and only performing reads from the RF.
Some operations need to be executed in two stages. In the first stage the operands are read out from the instruction immediate fields and the rs1/rs2 registers. In the second stage rd and the PC are updated with the results from the operation. The operation-specific things happen between the aforementioned stages. SERV has four types of four two-stage operations; memory, shift, slt and branch operations. In all cases the first stage is distinguished by having the init signal raised and only performing reads from the RF.

.. wavedrom::

Expand Down
4 changes: 2 additions & 2 deletions doc/reservoir.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@
Building systems with SERV
**************************

A CPU is only as good as its eosystem. In order to make use of SERV, it needs to be combined with other components such as memories, accelerators and peripheral controllers.
A CPU is only as good as its ecosystem. In order to make use of SERV, it needs to be combined with other components such as memories, accelerators and peripheral controllers.

Welcome to the reservoir, a pool of ready-made designs and subsystems for different purpsoses that you can use to quickly get started with SERV or integrate it into larger designs.
Welcome to the reservoir, a pool of ready-made designs and subsystems for different purposes that you can use to quickly get started with SERV or integrate it into larger designs.

.. include:: servile.rst
.. include:: serving.rst
Expand Down
4 changes: 2 additions & 2 deletions doc/servant.rst
Original file line number Diff line number Diff line change
Expand Up @@ -155,7 +155,7 @@ Pin 56 is used as the GPIO output which is connected to the board's LED1. Due to
Nexys 2
^^^^^^^

Pmod pin JA1 is conntected to UART tx with 57600 baud rate. A USB to TTL connector is used to display to hello world message on the serial monitor.
Pmod pin JA1 is connected to UART tx with 57600 baud rate. A USB to TTL connector is used to display to hello world message on the serial monitor.
(To use blinky.hex change L15 to J14 (led[0]) in data/nexys_2.ucf).

fusesoc run --target=nexys_2_500 servant --uart_baudrate=57600 --firmware=$SERV/sw/zephyr_hello.hex
Expand Down Expand Up @@ -208,7 +208,7 @@ Pin A6 is used for UART output with 115200 baud rate.
Porting Servant to a new target
-------------------------------

Mostly any FPGA board can be used to run the Servant SoC. In its simplest form it just needs and FPGA with a clock input and an output that can be used to connect an UART or a LED.
Mostly any FPGA board can be used to run the Servant SoC. In its simplest form it just needs an FPGA with a clock input and an output that can be used to connect an UART or a LED.

The porting process consists of FIXME steps.
We will use `<name>` as a placeholder for the name of the FPGA board.
Expand Down
2 changes: 1 addition & 1 deletion rtl/serv_csr.v
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ module serv_csr
During a mstatus CSR access instruction it's assigned when
bit 3 gets updated
These conditions are all mutually exclusibe
These conditions are all mutually exclusive
*/
if ((i_trap & i_cnt_done) | i_mstatus_en & i_cnt3 & i_en | i_mret)
mstatus_mie <= !i_trap & (i_mret ? mstatus_mpie : csr_in[B]);
Expand Down
6 changes: 3 additions & 3 deletions rtl/serv_state.v
Original file line number Diff line number Diff line change
Expand Up @@ -105,10 +105,10 @@ module serv_state
assign o_rf_rd_en = i_rd_op & !o_init;

/*
bufreg is used during mem. branch and shift operations
bufreg is used during mem, branch, and shift operations
mem : bufreg is used for dbus address. Shift in data during phase 1.
Shift out during phase 2 if there was an misalignment exception.
Shift out during phase 2 if there was a misalignment exception.
branch : Shift in during phase 1. Shift out during phase 2
Expand All @@ -127,7 +127,7 @@ module serv_state
//ibus_cyc changes on three conditions.
//1. i_rst is asserted. Together with the async gating above, o_ibus_cyc
// will be asserted as soon as the reset is released. This is how the
// first instruction is fetced
// first instruction is fetched
//2. o_cnt_done and o_ctrl_pc_en are asserted. This means that SERV just
// finished updating the PC, is done with the current instruction and
// o_ibus_cyc gets asserted to fetch a new instruction
Expand Down
2 changes: 1 addition & 1 deletion servant/servant_orangecrab.v
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ module servant_orangecrab
.CLKOS2(), // secondary output
.CLKOS3(), // secondary output
.LOCK(pll_locked), // lock indicator
.INTLOCK(), // internal lock indictor
.INTLOCK(), // internal lock indicator
.REFCLK(), // output of ref select mux
.CLKINTFB() // internal fb
);
Expand Down
Loading

0 comments on commit a26c296

Please sign in to comment.