The repository contains only generic and reusable White Rabbit cores,
which should not be tied to any particular piece of hardware. 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 of 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 pattern
hw_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 in top/ 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
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 a hdlmake
In general, the OHR VHDL coding guidelines should be followed. However,
due to large complexity of some of the modules, there are some
* 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 structsentity xwr_module is port ( wb_i : t_wishbone_slave_in; wb_o : t_wishbone_slave_out );end xwr_module;-- version without structsentity 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
use Emacs-style formatting VHDL formatting rules (2-space
indentation) and file header.
A very temporary todo list:
Flexible Auxillary clock synchronization unit – hardware support.
Add more auxilary clock inputs to wr_softpll, so a single WR core can support more than 1 FMC slot. Add a possibility of working with clocks of frequencies different than 125 MHz (impelent programmable dividers)
Aux clock DAC control
Define a way of telling the WR Core what type of DAC (or a programmable oscillator, such as Si57x) it has to drive without need for changes inside the WRPC software. That means, what hardware interface (I2C, SPI), part type, PI controller gains and thresholds, etc.