[gem5-dev] error from new test_convert.py?
Hi gem5 devs, specifically Andreas. I was just running the regressions on a change I'm working on, and I noticed this message: Exception thrown while loading "/home/gblack/gem5/work/tests/pyunit/util/test_convert.py" Ignoring all tests in this file. FYI, it looks like these tests are not runnng... ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Change in gem5/gem5[develop]: systemc: Extend TlmBridges to 512 bits
Yu-hsin Wang has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/44528 )
Change subject: systemc: Extend TlmBridges to 512 bits
..
systemc: Extend TlmBridges to 512 bits
Change-Id: I41763743974665e78ff05203d6ad2b8ac14ad625
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44528
Reviewed-by: Gabe Black
Maintainer: Gabe Black
Tested-by: kokoro
---
M src/systemc/tlm_bridge/TlmBridge.py
M src/systemc/tlm_bridge/gem5_to_tlm.cc
M src/systemc/tlm_bridge/tlm_to_gem5.cc
3 files changed, 96 insertions(+), 0 deletions(-)
Approvals:
Gabe Black: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/systemc/tlm_bridge/TlmBridge.py
b/src/systemc/tlm_bridge/TlmBridge.py
index 0a2aaa7..9238535 100644
--- a/src/systemc/tlm_bridge/TlmBridge.py
+++ b/src/systemc/tlm_bridge/TlmBridge.py
@@ -68,6 +68,30 @@
tlm = TlmInitiatorSocket(64, 'TLM initiator socket')
+class Gem5ToTlmBridge128(Gem5ToTlmBridgeBase):
+type = 'Gem5ToTlmBridge128'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::Gem5ToTlmBridge<128>'
+cxx_header = 'systemc/tlm_bridge/gem5_to_tlm.hh'
+
+tlm = TlmInitiatorSocket(128, 'TLM initiator socket')
+
+class Gem5ToTlmBridge256(Gem5ToTlmBridgeBase):
+type = 'Gem5ToTlmBridge256'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::Gem5ToTlmBridge<256>'
+cxx_header = 'systemc/tlm_bridge/gem5_to_tlm.hh'
+
+tlm = TlmInitiatorSocket(256, 'TLM initiator socket')
+
+class Gem5ToTlmBridge512(Gem5ToTlmBridgeBase):
+type = 'Gem5ToTlmBridge512'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::Gem5ToTlmBridge<512>'
+cxx_header = 'systemc/tlm_bridge/gem5_to_tlm.hh'
+
+tlm = TlmInitiatorSocket(512, 'TLM initiator socket')
+
class TlmToGem5Bridge32(TlmToGem5BridgeBase):
type = 'TlmToGem5Bridge32'
@@ -84,3 +108,27 @@
cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
tlm = TlmTargetSocket(64, 'TLM target socket')
+
+class TlmToGem5Bridge128(TlmToGem5BridgeBase):
+type = 'TlmToGem5Bridge128'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::TlmToGem5Bridge<128>'
+cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
+
+tlm = TlmTargetSocket(128, 'TLM target socket')
+
+class TlmToGem5Bridge256(TlmToGem5BridgeBase):
+type = 'TlmToGem5Bridge256'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::TlmToGem5Bridge<256>'
+cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
+
+tlm = TlmTargetSocket(256, 'TLM target socket')
+
+class TlmToGem5Bridge512(TlmToGem5BridgeBase):
+type = 'TlmToGem5Bridge512'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::TlmToGem5Bridge<512>'
+cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
+
+tlm = TlmTargetSocket(512, 'TLM target socket')
diff --git a/src/systemc/tlm_bridge/gem5_to_tlm.cc
b/src/systemc/tlm_bridge/gem5_to_tlm.cc
index e1cc087..c7d1b16 100644
--- a/src/systemc/tlm_bridge/gem5_to_tlm.cc
+++ b/src/systemc/tlm_bridge/gem5_to_tlm.cc
@@ -62,6 +62,9 @@
#include "params/Gem5ToTlmBridge32.hh"
#include "params/Gem5ToTlmBridge64.hh"
+#include "params/Gem5ToTlmBridge128.hh"
+#include "params/Gem5ToTlmBridge256.hh"
+#include "params/Gem5ToTlmBridge512.hh"
#include "sim/eventq.hh"
#include "sim/system.hh"
#include "systemc/tlm_bridge/sc_ext.hh"
@@ -538,3 +541,24 @@
return new sc_gem5::Gem5ToTlmBridge<64>(
*this, sc_core::sc_module_name(name.c_str()));
}
+
+sc_gem5::Gem5ToTlmBridge<128> *
+Gem5ToTlmBridge128Params::create() const
+{
+return new sc_gem5::Gem5ToTlmBridge<128>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
+
+sc_gem5::Gem5ToTlmBridge<256> *
+Gem5ToTlmBridge256Params::create() const
+{
+return new sc_gem5::Gem5ToTlmBridge<256>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
+
+sc_gem5::Gem5ToTlmBridge<512> *
+Gem5ToTlmBridge512Params::create() const
+{
+return new sc_gem5::Gem5ToTlmBridge<512>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
diff --git a/src/systemc/tlm_bridge/tlm_to_gem5.cc
b/src/systemc/tlm_bridge/tlm_to_gem5.cc
index 143eeac..36809d3 100644
--- a/src/systemc/tlm_bridge/tlm_to_gem5.cc
+++ b/src/systemc/tlm_bridge/tlm_to_gem5.cc
@@ -61,6 +61,9 @@
#include "params/TlmToGem5Bridge32.hh"
#include "params/TlmToGem5Bridge64.hh"
+#include "params/TlmToGem5Bridge128.hh"
+#include "params/TlmToGem5Bridge256.hh"
+#include "params/TlmToGem5Bridge512.hh"
#include "sim/system.hh"
#include "systemc/ext/core/sc_module_name.hh"
#include "systemc/ext/core/sc_time.hh"
@@ -558,3 +561,24 @@
return new sc_gem5::TlmToGem5Bridge<64>(
*this, sc_core::sc_module_name(name.c_str()));
}
+
+sc_gem5::TlmToGem5Bridge<128> *
+TlmToGem5Bridge128Params:
[gem5-dev] Re: gem5 namespace
Overall, there are way more uses of "gem5" than "Gem5" in the codebase, and
most of the instances that break the identity rule could be easily fixed;
however, there are cases that generate inconvenience: classes starting with
lowercase, and situations where gem5 is in the middle of the var name (like
"haveGem5Extension") make the code harder to read/understand. In this sense,
the uppercase version generates better code.
I still favor namespace gem5 - it'd be the "external external" API, i.e. we
probably wouldn't be using it within src/ that much, and it would be used by
other simulators and within our SystemC bridge (more on that later) - however,
since we already have some exceptions, it wouldn't be the end of the world
having it start with a capital letter.
In the end, I personally do not care about which approach is taken, but the
decision taken must be taken as a community. Therefore, it would be nice if we
could have participation from other contributors to make the final decision
less susceptible to changes/complaints in the future.
Regarding when to use it:IMHO (and not thoroughly thought out), all .cc and .hh
and objects within src/ should be subject to the namespace. Objects declared
there are declared and maintained by gem5. Because of that there would probably
be very few instances of namespace resolution within src/, so we should keep
avoiding "using namespace" and being verbose about it. Finally, we also
probably want to encourage users to define their objects inside the gem5
namespace to make it less unlikely that they will give up on uploading their
contributions due to the different styles, and the laziness to adapt code. This
means that disturbance in user code would be minimal: they would simply add
"namespace (G|g)em5 {" in the beginning and "} // namespace (G|g)em5" at the
end, instead of multiple "(G)|gem5::" instances.
Regards,
Daniel
For the record, if the namespaces you found using snake_case start with sc_,
those are for systemc and are mandated by that standard. The one exception,
sc_gem5, is one I made up which is closely associated with the other systemc
namespaces and is named similarly to them for consistency.
Gabe
On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini
wrote:
My vote goes to 1 and A as well
My sole argument is consistency; in general I'd rather start a namespace with a
lowercase. So that when we have something
like a scope resolution we know we are dealing with a namespace and not a
class. But that's off-topic.
Namespace names are anyway not covered by our coding style, so it's probably
worth adding an entry.
https://www.gem5.org/documentation/general_docs/development/coding_style/
>From a quick grep I can see most of our namespaces follow the PascalCase type,
>though there are some namespaces using snake_case convention.
Giacomo
> -Original Message-
> From: Gabe Black via gem5-dev
> Sent: 15 April 2021 09:03
> To: gem5 Developer List
> Cc: Gabe Black
> Subject: [gem5-dev] Re: gem5 namespace
>
> My vote is for 1 and A.
>
> We have style rules for a reason, and that is because not following them
> causes technical problems like name collisions, and makes it less obvious
> when reading code what things are and what they're doing. It's a bit
> hypocritical to say that we should follow style rules and completely ignore
> the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic
> rule should win when dealing with the namespace.
>
> This is further inconsistent with the Gem5Internal namespace, the Gem5
> class in SCons, the Gem5Op instruction format used for ARM, and the
> Gem5Imm constant used for ARM semihosting. It would also cause a collision
> with any variable called gem5, a completely legal and reasonable name to use,
> *especially* in code outside of gem5 which might be using it to refer to
> something related to gem5 which it is interacting with.
>
> There are no other instances where we let superficial aesthetic conventions
> like this overrule technical considerations. We don't add _tm to the end of
> trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
> since that's not a valid class name, and a hundred other examples of where
> prose takes a back seat because this is not prose, this is a conceptual
> machine
> people happen to be able to read.
>
> Our website is the place for branding and identity and marketing, our code is
> not.
>
> Gabe
>
> On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev d...@gem5.org > wrote:
>
>
> Thanks for putting this all together, Daniel!
>
> My opinion is the same as yours: option 2 and macro A.
>
> One other thing we need to do is to standardize and document when
> and where you need to use the gem5 namespace. For instance, do we need
> to update *all* headers to be in the gem5 namespace? If not, when is an
> object in the gem5 namespace and when it is not? What about `using
> namespace gem5`?
