| commit | def83fdc48a06a49e6f7eecd8dbb6e0cc50f8816 | [log] [tgz] |
|---|---|---|
| author | Rupert Swarbrick <rswarbrick@lowrisc.org> | Thu May 20 12:15:35 2021 +0100 |
| committer | Rupert Swarbrick <rswarbrick@gmail.com> | Tue May 25 09:41:45 2021 +0100 |
| tree | d052e3f54cacd7ff05632c303ff2e38c9b091a5d | |
| parent | 38a4bc56f61d2d86862895e0e928f8febc0327d2 [diff] |
[prim] Break always_comb block to avoid apparent loop
When Verilator schedules its simulation, it tracks dependencies in a
big graph containing processes (including always_comb blocks) and
variables. Here, that graph has a loop between e.g. idx_tree and
sel_tree. The result is an UNOPTFLAT warning and poor
scheduling (which will impact simulator performance).
Often these loops can be broken by judicious use of Verilator's
split_var directive. This tells Verilator to split up an array or
struct into multiple nodes in the graph. Here, that's not enough. The
problem is that the graph looks something like this:
idx_tree[47:44] --- (is_written_in) -->
always_comb block on line 143 --- (sensitive_to) --->
sel_tree[11] --- (is_written_in) -->
always_comb block on line 143 --- (sensitive_to) --->
idx_tree[47:44]
To fix things, we need to split the always_comb block. The Verilator
documentation describes an isolate_assignments directive that looks
like it should handle this, but I've not had any luck with it.
It turns out that splitting out just the definition of sel into its
own always_comb block is enough to silence the warning. Presumably,
this means that Verilator is doing other clever breaking up of blocks,
otherwise it wouldn't fix the chain above, so this seems a bit
fragile.
It would be nice to sort this out by turning things into continuous
assignments, but a Vivado synthesis bug means we can't do that at the
moment. Add a TODO that explains what's going on.
Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
OpenTitan is an open source silicon Root of Trust (RoT) project. OpenTitan will make the silicon RoT design and implementation more transparent, trustworthy, and secure for enterprises, platform providers, and chip manufacturers. OpenTitan is administered by lowRISC CIC as a collaborative project to produce high quality, open IP for instantiation as a full-featured product. See the OpenTitan site and OpenTitan docs for more information about the project.
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. It exists to enable collaboration across partners participating in the OpenTitan project.
The project contains comprehensive documentation of all IPs and tools. You can access it online at docs.opentitan.org.
Have a look at CONTRIBUTING and our documentation on project organization and processes for guidelines on 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).