On Tue, Jul 2, 2013 at 9:39 PM, Olof Kindgren <[email protected]> wrote: > > > On Tue, Jul 2, 2013 at 5:41 PM, Stefan Kristiansson > <[email protected]> wrote: >> >> The problem with using the internal classes directly is >> that you have to use the internally generated name, >> this in itself is perhaps not such a big issue, the issue >> is that the internal name changes when the underlaying verilog >> design changes. >> This works around this by using the classes through the >> top module, which is part of the external api. >> --- >> bench/sysc/include/OrpsocAccess.h | 7 ++----- >> bench/sysc/src/OrpsocAccess.cpp | 14 +++----------- >> 2 files changed, 5 insertions(+), 16 deletions(-) >> >> diff --git a/bench/sysc/include/OrpsocAccess.h >> b/bench/sysc/include/OrpsocAccess.h >> index 147028e..24cd3a6 100644 >> --- a/bench/sysc/include/OrpsocAccess.h >> +++ b/bench/sysc/include/OrpsocAccess.h >> @@ -30,6 +30,7 @@ >> #define ORPSOC_ACCESS__H >> >> #include <stdint.h> >> +#define wishbone_ram orpsoc_top->v->ram_wb0->ram_wb_b3_0 >> >> class Vorpsoc_top; >> class Vorpsoc_top_orpsoc_top; >> @@ -107,11 +108,7 @@ private: >> Vorpsoc_top_or1200_except *or1200_except; >> Vorpsoc_top_or1200_sprs *or1200_sprs; >> Vorpsoc_top_or1200_dpram *rf_a; >> - /*Vorpsoc_top_ram_wb_sc_sw >> *//*Vorpsoc_top_ram_wb_sc_sw__D20_A19_M800000 >> *//*Vorpsoc_top_wb_ram_b3__D20_A17_M800000 *ram_wb_sc_sw; */ >> - Vorpsoc_top_ram_wb_b3__pi3 *wishbone_ram; >> - // Arbiter >> - //Vorpsoc_top_wb_conbus_top__pi1 *wb_arbiter; >> - >> + Vorpsoc_top *orpsoc_top; >> }; // OrpsocAccess () >> >> #endif // ORPSOC_ACCESS__H >> diff --git a/bench/sysc/src/OrpsocAccess.cpp >> b/bench/sysc/src/OrpsocAccess.cpp >> index 92c6375..c8bdbcb 100644 >> --- a/bench/sysc/src/OrpsocAccess.cpp >> +++ b/bench/sysc/src/OrpsocAccess.cpp >> @@ -29,6 +29,8 @@ >> >> #include "OrpsocAccess.h" >> >> +#include "Vorpsoc_top__Syms.h" >> + >> #include "Vorpsoc_top.h" >> #include "Vorpsoc_top_orpsoc_top.h" >> #include "Vorpsoc_top_or1200_top.h" >> @@ -38,11 +40,6 @@ >> #include "Vorpsoc_top_or1200_sprs.h" >> #include "Vorpsoc_top_or1200_rf.h" >> #include "Vorpsoc_top_or1200_dpram.h" >> -// Need RAM instantiation has parameters after module name >> -// Include for ram_wb >> -#include "Vorpsoc_top_ram_wb__A20_D20_M800000_MB17.h" >> -// Include for ram_wb_b3 >> -#include "Vorpsoc_top_ram_wb_b3__pi3.h" >> >> //! Constructor for the ORPSoC access class >> >> @@ -58,13 +55,8 @@ OrpsocAccess::OrpsocAccess(Vorpsoc_top * orpsoc_top) >> or1200_except = >> orpsoc_top->v->or1200_top0->or1200_cpu->or1200_except; >> or1200_sprs = orpsoc_top->v->or1200_top0->or1200_cpu->or1200_sprs; >> rf_a = orpsoc_top->v->or1200_top0->or1200_cpu->or1200_rf->rf_a; >> - // Assign main memory accessor objects >> - // For old ram_wb: ram_wb_sc_sw = orpsoc_top->v->ram_wb0->ram0; >> - //ram_wb_sc_sw = orpsoc_top->v->wb_ram_b3_0; >> - wishbone_ram = orpsoc_top->v->ram_wb0->ram_wb_b3_0; >> >> - // Assign arbiter accessor object >> - //wb_arbiter = orpsoc_top->v->wb_conbus; >> + this->orpsoc_top = orpsoc_top; >> >> } // OrpsocAccess () >> >> -- >> 1.8.1.2 >> >> _______________________________________________ >> OpenRISC mailing list >> [email protected] >> http://lists.openrisc.net/listinfo/openrisc > > > Those parameter-dependant names are great to get rid of. Would it make sense > to put #define wishbone_ram inside a #ifndef wishbone_ram, so that it could > be overridden by the scripts? I'm thinking flexibility here
Are the defines from the orpsoc_defines.v file not passed into SystemC compile flow as #defines? I guess not - that would be easy to do though. Next question is do we even have an option for the Wishbone RAM slave? Man, this could do with a makeover, something like a next version of ORPSoC.... Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
