Development instructions
Repo layout
The repository contains only generic and reusable White Rabbit cores, which are not be tied to any particular piece of hardware (for example, the Routing Table Unit belongs to the WR Switch HDL repository, because it would be of very little use anywhere else). If there are any platform dependencies, the platform-specific part should be clearly separated from the generic part.
The repo is organized as follows:
-
modules
- "big" modules, such as the WR Endpoint or the WR Core - each in a separate subdirectory, with dir name matching the name of of the top level entity. Only platform-independent RTL code is allowed. -
platform
- platform dependent code, for example wrappers for gigabit transceivers or Chipscope cores. -
sim
- simulation models and header files -
top
- top level entities for actual hardware implementations (i.e. FPGA-wide top levels). Each design should be placed in a separate subdirectory with the name matching the patternhw_platform
/@firmware_name. For example,
spec_1_1/wr_core_demo@ means a demo project for the WR core synthesized for the SPEC 1.1. card. FPGA pin assignment files should be also stored intop/
subdirectory. -
syn
- synthesis-specific files and resulting binaries - for example ISE/Quartus projects. Only the files which are necessary to run a synthesis (i.e.hdlmake
manifests,.xise
or.qpf
files may be uploaded here). Pushing synthesis outputs (reports, intermediate netlists, etc.) is forbidden, with an exception of tested FPGA bitstreams which may take long time to build from sources. -
testbench
- testbenches, grouped in subdirectories with names corresponding to the names of the modules being tested. Each testbench must contain a simulation run script and ahdlmake
manifest.
Coding style
In general, the OHR VHDL coding guidelines should be followed. However, due to large complexity of some of the modules, there are some exceptions:
* you must not prefix signals with s_
.
* if the module inteface comprises multiple repetitive signals, use
structures instead of flattened std_logic
ports. This makes the
interconnections between the modules much easier to understand and less
error prone. For compatibility with Verilog and gate-level simulations,
you should provide a module with flattened ports. Names of modules with
structs in ports are prefixed with x
, for example:
-- version with structs
entity xwr_module is
port (
wb_i : t_wishbone_slave_in;
wb_o : t_wishbone_slave_out
);
end xwr_module;
-- version without structs
entity wr_module is
port (
wb_adr_i : in std_logic_vector;
wb_dat_i : in std_logic_vector;
wb_ack_o : out std_logic;
);
end wr_module;
- do not type signals, names and keywords in UPPERCASE.
- for every Wishbone module, implement a generic
g_interface_mode
, allowing the user to choose between Classic and Pipelined (B4) bus operation. - use Emacs-style formatting VHDL formatting rules (2-space indentation) and file header.