Beehive configuration is driven by an XML file associated with each particular design instantiation. Typically these XML files are in the directory for the design we are building, since it defines a particular topology, but theoretically they could be anywhere. This configuration is used mainly to generate certain portions of code, but is also used for message deadlock analysis since much of the information needed can be derived from this XML configuration file.
Beehive generates certain files that have to do with the tile topology and logical routing using a Python preprocessor that allows Python prints embedded in the file to output Verilog. In particular, the files Beehive currently generates are the file that instantiates and wires up all the tiles and the CAMs that control message routing in the RX path.
We choose to do actual code generation instead of using (System)Verilog generates and for loops, because of the usefulness of being able to actually look at the generated wires for debugging both the instantiation of the design itself and during waveform analysis.
The generator code and preprocessor code lives in tile_generator.
The goal of the code generation is to automate some of the very structured, but tedious code that exists when building the design, such as connecting wires between tiles. This is especially true as we move to supporting more than one physical NoC. Notably, the goal of the code generation is NOT to replace Verilog or to define some higher level language.
This is a revamp of the original system where we did try and generate the whole tile, but there are a couple cases where tiles have unique interfaces that start to introduce complexities into the code generation that start to bring it dangerously close to us developing a small language.
In particular, while all tiles will have the same set of NoC ports, not all tiles will have the same set of ports in general. For example, the Ethernet tiles have additional ports to connect to the MAC and memory tiles have additional ports for connecting to a memory interface. There are also certain endpoints that are wrapped in one module at the level of instantiating tiles. For example, the TCP has one endpoint for send and one for receive. However, the TCP engine receive and transmit side need to share a fair bit of state, so it is easier if they are wrapped in one module
The XML is parsed to turn it into a Python configuration object that can be used when generating code. An example XML is in cocotb_testing/udp_echo/tile_config.xml
The top level XML tag is design. Within design there are two main subtags: nocs which controls the NoC setup for the design and tiles which makes up the bulk of the file and specifies the tiles and their topology.
This tag controls the number of NoCs generated. Each NoC is specified with the tag noc. The subelements for a noc are:
noc_name: a string that is used when generatingnoc_width_def: a string that provides the name of the define macro that sets the data width for the NoC. This should match the define in the Verilog as it’s used when generating the data wires for the NoC.Since we are using a 2D mesh, there should be two subelements to specify the mesh dimensions:
num_x_tiles : number of tiles in the x-dimensionnum_y_tiles : number of tiles in the y-dimension