| commit | cabf26f33f6964caba640d9638873d681ba4a6a5 | [log] [tgz] |
|---|---|---|
| author | Philipp Wagner <phw@lowrisc.org> | Fri Oct 18 14:58:57 2019 +0100 |
| committer | Philipp Wagner <mail@philipp-wagner.com> | Wed Oct 23 18:28:01 2019 +0100 |
| tree | cd39978d170a55993ef1d9f17874052aa17f30e9 | |
| parent | e7aef113916a0391ef56392e5db2e727567051ba [diff] |
[prim] Restore ability to select default implementation
When we introduced the primitives library, we also had the possibility
to choose a per-design default implementation for primitives. To set a
default implementation, the synthesis script would set the
PRIM_DEFAULT_IMPL define to values like "xilinx" or "generic", which was
then used as default value for the Impl parameter, which is present in
all primitives modules:
```verilog
parameter Impl = `"`PRIM_DEFAULT_IMPL`"
```
Unfortunately, this syntax to "cast" a define to a string isn't
supported in Cadence LEC. As a stop-gap, we removed the functionality
altogether. This resulted in always using the "generic" implementation
for all targets, which produces suboptimal results e.g. on Xilinx FPGAs.
With this commit, the original functionality is restored in a
LEC-compatible way. Instead of using strings for PRIM_DEFAULT_IMPL, we
now use integers. The allowed values are listed in the
prim_pkg::impl_e enum.
Implementation notes on types:
* PRIM_DEFAULT_IMPL is a define passed through to tools as command line
options. Most/all tools only support "primitive" types in this way,
not enums; hence PRIM_DEFAULT_IMPL is an integer, and all assignments
to it must be integer as well. This includes the default assignment:
`ifndef PRIM_DEFAULT_IMPL
`define PRIM_DEFAULT_IMPL integer'(prim_pkg::ImplGeneric)
`endif
* Since we assign the PRIM_DEFAULT_IMPL define to the Impl parameter,
this parameter needs to be either an integer, or cast the RHS to an
enum.
* In this implementation we stayed with an integer type for the Impl to
avoid potential problems with tools don't supporting enums as
parameter type. (We don't know of any tool yet that doesn't support
it, but it seems sufficiently exotic to run into problems down the
road.)
Thanks to Tim for an initial version of this code.
Fixes #40
This repository contains hardware, software and utilities written as part of the OpenTitan project. It is structured as monolithic repository, or “monorepo”, where all components live in one repository.
The project contains comprehensive documentation of all IPs and tools. You can either access it online or build it locally by following the steps below.
$ sudo apt install python3 python3-pip $ pip3 install --user -r python-requirements.txt
$ ./util/build_docs.py --preview
This compiles the documentation into ./opentitan-docs and starts a local server, which allows you to access the documentation at http://127.0.0.1:5500.
Have a look at CONTRIBUTING.md for guidelines how to contribute code to this repository.
Unless otherwise noted, everything in this repository is covered by the Apache License, Version 2.0 (see LICENSE for full text).