If a fast model static library can't be found, we should treat that as
a warning instead of an error, and pass back the original library name
so that it can at least be added and potentially come from somewhere
else.
In practice, this is important because gem5 will be configured by SCons
indirectly in the future, using kconfig based tools that SCons runs on
the user's behalf. If SCons is misconfigured or not configured, this
error can trip, preventing those tools from starting. That creates a
catch 22, since you'd need SCons to fix the config, and SCons can't
run because of the config.
We can avoid that problem by making SCons more lenient, so that it can
still run even if it doesn't find static libraries where it might have
expected to.
Change-Id: Iadfd823b61fe96b937c2650250487d290492f265
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58352
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This held the location of the license file, assuming it actually was a
license file and not a license server URL. If this variable was unset
because the fast model configuration parameters hadn't been set, then
the "File" would resolve to the local directory, and SCons would get
upset that you'd called the same path a directory and a file.
We can avoid this problem by just getting rid of this variable, since
it isn't used anyway.
Change-Id: I2ccda90b85f2c83c73816967d145e6bf45733f89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58351
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The first big change is gcc-6.4 is no longer supported in FastModel
11.17. We switch to gcc-7.3. Next, TARGET_MAXVIEW is
replaced by TARGET_SYSTEMC_MAXVIEW. The default value of
TARGET_SYSTEMC_MAXVIEW is zero. So we can simply remove TARGET_MAXVIEW.
Finally, I fixed an undefined exception in the build script.
Change-Id: I5ec70112056513c253e6127ed5f8abacf191431f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57549
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We want to insist that the fast model libraries are the static versions
so they don't have to be found on non-system paths at run time, but we
don't need or want to do the same for system libraries which are from
standard paths on the host system.
Split the set of libraries fast model adds to the build into ones that
come from fast model itself, and ones it needs which should be
provided by the system. The ones from fast model itself should still
go through staticify, but the system libraries should be passed to the
compiler generically so it can pick which version it wants.
Change-Id: I222c94f8117143b86377150e686a4af669a994fe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51627
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
To limit the number of license slots used by SCons when building fast
model components, the fastmodel SConscript set up a group of nodes
which are attached to each simgen run using the SCons SideEffect
method using one of the library files it generates.
To create each unique node, the SCons Value() method was used, passing
it the counter for the loop. In at least version 4 of SCons, what this
ended up doing was setting that library file as a source for each of
the Value() nodes it corresponds to.
That doesn't *seem* like a problem, but then when creating config
include files, files which expose SCons configuration values to C++,
they also create Value() nodes using the value of the config variable.
In cases where that variable is boolean, the value might be 0 or 1.
The result was that the config header depended on Value(0) (for
instance), and then Value(0) depended on a collection of static library
files.
When scons tried to determine whether the config file was up to date,
it tried to check if if its sources had changed. It would check
Value(0), and then Value(0) would try to compute a checksum for its own
source. To do that, it seems to assume that the value can be
interpreted as a string and tries to decode it as utf8. Since the
library is a binary file, that would fail and break the build with a
cryptic message from within the guts of SCons.
To address this, this change replaces the loop index with a call to
object(). Each instance created in that way will be different from
every other, and there will be no way (purposefully or otherwise) to
create a collision with it when creating Value() nodes for some other
purpose.
Change-Id: I56bc842ae66b8cb36d3dcbc25796b708254d6982
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38617
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Ahbong Chang <cwahbong@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Each instance of simgen uses a license. If there are only so many to
go around, running many instances at once could exhaust the pool of
licenses and break the build.
The number of licenses may be less than the number of regular build
steps we want to do in parallel, but may be greater than zero. To
limit them to at most n in parallel where n might be less than j
and/or more than 1, we create a group of license slots, assign simgen
invocations to a slot, and then use scons's side effect mechanism to
ensure no two invocations in the same slot run at the same time.
This may be a suboptimal packing if the commands take significantly
different amounts of time to run since the slots are preallocated and
not demand allocated, but the difference shouldn't normally matter in
practice, and scons doesn't provide a better mechanism for partially
serializing certain build steps.
Change-Id: Ifae58b48ae1b989c1915444bf7564f352f042305
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32124
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
* dict methods dict.keys(), dict.items() and dict.values()
return "views" instead of lists
* The dict.iterkeys(), dict.iteritems() and dict.itervalues()
methods are no longer supported.
* map() and filter() return iterators.
* range() now behaves like xrange() used to behave, except it works with
values of arbitrary size. The latter no longer exists.
* zip() now returns an iterator.
Change-Id: Id480018239db88d7f5d60588c93719056de4a0c0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26248
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This lets us avoid having to have two levels of bridging and twice as
many ports on both the CPU and GIC side. The direct communication ports
can be instantiated and connected using array syntax, where the bridges
require instantiating each bridge individually and wiring them up one
at a time with a lot of boilerplate/duplicate code.
Change-Id: I815ee47bcd19994e46a5220e0c23e89c497d7aa5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21050
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Fast Models are models written by ARM which emulate different
components of a computer system. They can be combined into small
subsystems and then exported as systemc modules.
To enable this code, you'll need to set USE_ARM_FASTMODEL variable to
true. This CL does not include the fast models themselves, or a license
to use them or the associated tools. To build these fast models, you'll
need to set some scons variables. These variables should be set as
described in the fast model distribution.
* PVLIB_HOME
* MAXCORE_HOME
* ARMLMD_LICENSE_FILE
Some minor patches to source filesdistributed with the fast model code
may be necessary since their use of systemc is not necessarily 100%
standards compliant.
Change-Id: Id53814b95d8aa320da4d4f2159be0736fc12eb73
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20799
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
