| commit | 62b3e7680de54d9edd9916bc04768bcfca7d633e | [log] [tgz] |
|---|---|---|
| author | Rupert Swarbrick <rswarbrick@lowrisc.org> | Fri Jan 29 15:21:49 2021 +0000 |
| committer | Rupert Swarbrick <rswarbrick@gmail.com> | Fri Jan 29 16:26:00 2021 +0000 |
| tree | 3dcc6104ada8c2273bf1e6c03a2931e2c6c27f40 | |
| parent | 604fe250038530280f5976499957c96cc73c4543 [diff] |
[dvsim] Generate FUSESOC_IGNORE at top of scratch root This is a bit of a work-around for a race condition that was causing all sorts of confusing CI failures. This crops up the second time you run a "primary config" (list of configurations), if you do that second run with a high parallelism. Suppose you've done a dvsim lint run already and you have two IP blocks, A and B. At this point, you'll have generated .core files somewhere inside A's build directory, protected by a FUSESOC_IGNORE file. Now you start a new run. Two fusesoc processes (for A and B, respectively) start to race. The one for A cleans its build directory, essentially running "rm -rf" on the generated tree. This works top-down, deleting files and directories. Within a directory, it works in the order that files come back from readdir. What happens if FUSESOC_IGNORE appears in the list before the directories containing the core files? The "rm -rf" process deletes the FUSESOC_IGNORE file. Now suppose that the kernel suspends that process and switches over to the fusesoc process for block B. That process can now merrily read its way down the build directory. There's no FUSESOC_IGNORE file, so it looks in core A's generated core files and finds some. Oops. Now the process for block B gets suspended and we're back to A, which finishes up deleting stuff. When we get back to B again, it tries to load that juicy core file that it found... which isn't there any more. Total confusion! Debugging this was made much worse by the fact that the time stamps have all since been trashed by core A's fusesoc run, which has since helpfully re-created all the files! One "proper" fix would be to delete the old build directory more carefully, ensuring that the generated core files get deleted before FUSESOC_IGNORE. That seems rather difficult, though. Ideally, we'd want to move that logic back to fusesoc, rather than calling "rm -rf" ourselves. Another possible fix would be to move this "touch" operation into the various flow configurations that need it. I'm not so keen on that, though, because now we duplicate the logic all over the place. I'm hoping this commit will be reverted and replaced by a better solution soon :-) 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 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).