Firmware -> Gateware. Plus fix typos

Let's suppose your new repository is called `new_repo` with URL `new_repo_url`, your project is named `myproject` and it is currently stored in some local folder `mypath`. If you do not have a new repository, you can go on GitLab and create one.

## Creating the git repository

First of all create a new folder where you will store your firmware, initialise it as a git repository and connect it to the remote repository:

First of all create a new folder where you will store your HDL design, initialise it as a git repository and connect it to the remote repository:

```bash

  mkdir new_repo

:::{admonition} Absolute or relative paths in `.ext` files?

:class: warning

By default `.ext` file use absolute paths. The only other option is to define the environmental variable `HOG_EXTERNAL_PATH`. If this is defined, Hog will interpret the entries in the `.ext` file as relative to `HOG_EXTERNAL_PATH`. To use the firmware Continuous Integration, external files must be accessible to the machine performing the git CI, e.g. can be on a protected `afs` folder.

By default `.ext` file use absolute paths. The only other option is to define the environmental variable `HOG_EXTERNAL_PATH`. If this is defined, Hog will interpret the entries in the `.ext` file as relative to `HOG_EXTERNAL_PATH`. To use them in the Hog-CI, external files must be accessible to the machine performing the git CI, e.g. can be on a protected `afs` folder.

:::

More information on the list file can be found in the dedicated [list files](01-Hog-local/02-List-files) section.

The supported properties are:

- `ALLOW_FAIL_ON_CONF`: will not set the version to 0 in firmware registers, even if the conf file is modified with respect to the project (The Critical Warning is still raised)

- `ALLOW_FAIL_ON_LIST`: will not set the version to 0 in firmware registers, even if any of the list files is modified with respect to the project (The Critical Warning is still raised)

- `ALLOW_FAIL_ON_GIT`: will not set the version to 0 in firmware registers, even if a file is found in the project which is not committed to the repository (The Critical Warning is still raised)

- `ALLOW_FAIL_ON_CONF`: will not set the version to 0 in HDL registers, even if the conf file is modified with respect to the project (The Critical Warning is still raised)

- `ALLOW_FAIL_ON_LIST`: will not set the version to 0 in HDL registers, even if any of the list files is modified with respect to the project (The Critical Warning is still raised)

- `ALLOW_FAIL_ON_GIT`: will not set the version to 0 in HDL registers, even if a file is found in the project which is not committed to the repository (The Critical Warning is still raised)

- `EXPORT_XSA`: will either force or prevent the export of an XSA file for Xilinx Zynq devices (documentation [below](#xsa-export-for-zynq-devices-xilinx-only))

### Generics section

At the moment, this functionality is supported only by Xilinx and Microchip IDEs. 

### XSA Export for Zynq Devices (Xilinx Only)

For Xilinx Zynq devices, integration of the firmware with the Linux system uses a Xilinx Support Archive (XSA) file.

For Xilinx Zynq devices, integration of the gateware with the Linux system uses a Xilinx Support Archive (XSA) file.

An XSA file is a zip archive containing files such as Vivado tool versions, part numbers, the compiled firmware bitstream, C headers, and the Hardware Handoff File (HHF) that contains information describing the Processor-to-FPGA-interface implemented in the Vivado Block Designer.

An XSA file is a zip archive containing files such as Vivado tool versions, part numbers, the compiled bitstream, C headers, and the Hardware Handoff File (HHF) that contains information describing the Processor-to-FPGA-interface implemented in the Vivado Block Designer.

Hog supports the automatic generation of XSA files for Zynq devices.

In the post-bitstream stage of compiling Zynq firmware, Hog will check the FPGA part number. If it is determined to be a Zynq device, Hog will automatically run the `write_hw_platform` command which is used to export an XSA file from a Vivado project.

In the post-bitstream stage of compiling Zynq gateware, Hog will check the FPGA part number. If it is determined to be a Zynq device, Hog will automatically run the `write_hw_platform` command which is used to export an XSA file from a Vivado project.

Detection of a Zynq part is using a simple regex for parts beginning with `xc7z` or `xczu`; this will need to be updated in the future as new parts are released by Xilinx.

If automatic detection of a supported device fails, generation of an XSA file can be forced with the `EXPORT_XSA` property in `hog.conf`.

:::{admonition} Absolute or relative paths in `.ext` files?

:class: warning

`.ext` list files must use absolute paths or relative to __HOG_EXTERNAL_PATH__ folder, if defined. To use the firmware Continuous Integration, this path must be accessible to the machine performing the git CI, e.g. can be on a protected `afs` folder.

`.ext` list files must use absolute paths or relative to the `HOG_EXTERNAL_PATH`, if defined. To use the it in the Hog-CI, this path must be accessible to the machine performing the git CI, e.g. can be on a protected `afs` folder.

:::

:::{note}

```

### Simulation Configuration File

The simulation properties are read from another file called `./Top/<my_project>/sim.conf`, with a similar syntax as the `hog.conf`. The need for a separate file lies on the fact that touching the simulation properties does not affect the actual firmware which will be synthesised. Thus we don't want Hog to change the version of the project, when the developers touch only the simulation. 

The simulation properties are read from another file called `./Top/<my_project>/sim.conf`, with a similar syntax as the `hog.conf`. The need for a separate file lies on the fact that touching the simulation properties does not affect the actual HDL design which will be synthesised. Thus we don't want Hog to change the version of the project, when the developers touch only the simulation. 

Simulation properties can be set individually for each simulation set, or globally for all of them. For example, to set `xsim.elaborate.rangecheck` property for the simulation set `sim_1`, you should write