After starting my thesis roughly 2 months ago, I've now reached a point which I could consider to be an internal milestone; a working behavioral simulation of the tile-based heterogeneous multicore architecture I've been working with.
Tomorrow (5th April) I'll be giving a status presentation to the research group I work with here at NTNU, I prepared a Prezi presentation for the occasion. It gives some brief background information on what the SHMAC is and why it's needed, why a simulator for the SHMAC is needed, and proceeds with some details about why SystemC was chosen for the simulation infrastructure and ArchC for the core generation. Contrary to the academic presentation trend there's (unfortunately) a general lack of text on the presentation itself, but it should be enough to get some ideas across :)
Showing posts with label shmac. Show all posts
Showing posts with label shmac. Show all posts
Thursday, April 4, 2013
Monday, March 11, 2013
Playing around with ArchC: TLM and multicores
As the final goal of my MSc thesis is to create a simulation framework for the SHMAC (Single ISA Heterogeneous Multicore Architecture Computer) I've been spending some time on creating ArchC/SystemC simulations for multicores and interconnects, and it feels like I'm finally getting to a point where I have a clearer picture of the concepts involved. Or so I hope :)
A bit of a background on SHMAC: it's a tile-based heterogeneous architecture which was first realized on an FPGA last year in the form of this MSc thesis by Leif Tore Rusten and Gunnar Inge Sortland at NTNU. The simulator I'm developing will (hopefully) eventually be used to evaluate interconnect and cache matters for the architecture.
It's mostly the "Processor Design with ArchC" chapter of the "Processor Description Languages" book that motivated me to write this - it gives a little warm-up on the features of ArchC including the TLM memory and interrupt controller port, and then goes on to how these concepts could be used to construct a two-core system.
// ...includes, includes...
int sc_main(int ac, char *av[])
{
mips1 proc1("p1");
mips1 proc2("p2");
someBus bus("b");
someMemory mem("m");
proc1.memoryPort(bus);
proc2.memoryPort(bus);
bus.memoryPort(mem);
// ...even more connections, omitted since they're related to the interrupt controller
proc1.initAndLoad(someBinary);
proc2.initAndLoad(someBinary);
sc_start();
// ..print start and exit
}
Despite how promising it looks, there unfortunately is no source code that follows with the book (at least that I'm aware of) - even though it is rather well described how the top-level components are connected in the code example in the book, how the memory, bus and interrupt controller are actually implemented is not mentioned. And I was unable to find any further code examples using ArchC for multi-core simulation. So I decided to take the plunge into ArchC's documentation and source code to understand how I could make it work, and well, I guess I can say the results are better than expected :)
More implementation details and juicy TLM stuff (not really, it's actually quite simple) coming up in the next post!
A bit of a background on SHMAC: it's a tile-based heterogeneous architecture which was first realized on an FPGA last year in the form of this MSc thesis by Leif Tore Rusten and Gunnar Inge Sortland at NTNU. The simulator I'm developing will (hopefully) eventually be used to evaluate interconnect and cache matters for the architecture.
It's mostly the "Processor Design with ArchC" chapter of the "Processor Description Languages" book that motivated me to write this - it gives a little warm-up on the features of ArchC including the TLM memory and interrupt controller port, and then goes on to how these concepts could be used to construct a two-core system.
// ...includes, includes...
int sc_main(int ac, char *av[])
{
mips1 proc1("p1");
mips1 proc2("p2");
someBus bus("b");
someMemory mem("m");
proc1.memoryPort(bus);
proc2.memoryPort(bus);
bus.memoryPort(mem);
// ...even more connections, omitted since they're related to the interrupt controller
proc1.initAndLoad(someBinary);
proc2.initAndLoad(someBinary);
sc_start();
// ..print start and exit
}
Despite how promising it looks, there unfortunately is no source code that follows with the book (at least that I'm aware of) - even though it is rather well described how the top-level components are connected in the code example in the book, how the memory, bus and interrupt controller are actually implemented is not mentioned. And I was unable to find any further code examples using ArchC for multi-core simulation. So I decided to take the plunge into ArchC's documentation and source code to understand how I could make it work, and well, I guess I can say the results are better than expected :)
More implementation details and juicy TLM stuff (not really, it's actually quite simple) coming up in the next post!
Tuesday, February 26, 2013
Architecture simulators, SystemC and ArchC
I've been looking into existing literature and simulators for the heterogeneous simulator I'll be developing, and after discussing some of the options with my supervisor Magnus the final conclusion was to use SystemC together with ArchC for the simulation infrastructure. To give a brief overview of what they are:
- SystemC is a set of C++ libraries and a simulation kernel, with plenty of useful functionality for creating models of complex hardware systems at different levels. Combining the object oriented paradigm with extra modelling capabilities for concurrency, timing and communication results in a flexible and powerful tool, and you get to decide the level of detail you would like for your models - anything from RTL (a hardware-synthesizable subset exists!) to expressing a whole processor instruction execution cycle with a switch statement.
- ArchC is an open-source architecture description language that was built to allow researchers or companies quickly prototype new computer architecture ideas. It can create SystemC simulations of the proposed architecture or create compiled versions for more speed, and it can even generate a GNU bintools suite targeting the architecture you specified!
So what's the first thing you'd like to see when someone starts talking about some new/esoteric language? You'd probably want to see examples. Here's a SystemC example from Wikipedia:
#include "systemc.h" SC_MODULE(adder) // module (class) declaration { sc_in<int> a, b; // ports sc_out<int> sum; void do_add() // process { sum.write(a.read() + b.read()); //or just sum = a + b } SC_CTOR(adder) // constructor { SC_METHOD(do_add); // register do_add to kernel sensitive << a << b; // sensitivity list of do_add } };
ArchC syntax looks pretty similar (it's inspired by SystemC in any case) with specific language constructs to specify the instruction set architecture (ISA) and the microarchitecture. They have ArchC models for a number of different cores at the ArchC website, check it out!
So the microarchitecture description (well, it's not a complete microarchitecture description, but you can always customize the connections and the components if you want to) looks like this in ArchC:
AC_ARCH(mips1){
ac_mem DM:5M; // 5 megs of direct access memory
ac_regbank RB:32; // register bank
ac_reg npc;
ac_reg hi, lo;
ac_wordsize 32; // 32-bit words
ARCH_CTOR(mips1) {
ac_isa("mips1_isa.ac"); // set ISA
set_endian("big"); // big endian
};
};
And here is an excerpt from the ISA description and a instruction behaviour description:
AC_ISA(mips1){
// declare the format of a group of instructions for decoding
// this can be thought of as parameter type/count declaration
ac_format Type_R = "%op:6 %rs:5 %rt:5 %rd:5 %shamt:5 %func:6";
// ... insert more instruction formats here
// which instructions belong to which format?
ac_instr add, addu, sub, subu, slt, sltu;
// ... insert more instruction-format matchings here
// assembly equivalent of instructions, for bintools generation
addi.set_asm("addi %reg, %reg, %exp", rt, rs, imm);
addi.set_asm("add %reg, %reg, %exp", rt, rs, imm);
addi.set_decoder(op=0x08);
// ...
};
...
// Instruction addi behavior method.
void ac_behavior( addi )
{
dbg_printf("addi r%d, r%d, %d\n", rt, rs, imm & 0xFFFF);
RB[rt] = RB[rs] + imm;
dbg_printf("Result = %#x\n", RB[rt]);
//Test overflow
if ( ((RB[rs] & 0x80000000) == (imm & 0x80000000)) &&
((imm & 0x80000000) != (RB[rt] & 0x80000000)) ) {
fprintf(stderr, "EXCEPTION(addi): integer overflow.\n"); exit(EXIT_FAILURE);
}
};
Tuesday, February 19, 2013
I'm back - with heterogeneous multicore computing!
Following the (bad) blogger tradition of long periods of silence followed by a "I'm back!" post, here we go :)
In the past 2.5 years I did a lot of things that I really felt like I should blogged about here, mostly as part of the fantastic Erasmus Mundus in Embedded Computing Systems (EMECS) master programme, but ah well. I intend to share the rest of my embedded systems and computer architecture adventures here, and if I manage to get back into the writing mode I might even become retrospective and write about some cool stuff I've seen during the Long Period of Silence :P
To summarize the current situation, I'm in the last semester of the EMECS programme writing my Master's thesis, and recently got a PhD position offer from the Norwegian University of Science and Technology (NTNU) Computer Architecture and Design Group. My thesis and the doctoral research for the following 4 years will be in the fascinating world of heterogeneous multicore architectures, and at the heart of the reason for doing all this still lies the same craving which fueled my Google Summer of Code 2010 project at BeagleBoard with dsp-rpc-posix: to make these amazing hardware be used to their full or near-full potential more easily by more developres.
On a more specific level of detail, my MSc thesis is going to be about developing a simulator for a tile-based heterogeneous architecture. I've done a bit of literature research and review of existing simulator work (and most naturally, a brain muddled due to trying to absorb all that information in 1.5 weeks) and for the moment it feels like I'll be basing my work on ArchC / SystemC for a variety of reasons which I'll hopefully go more into soon.
Expect to see blog posts about practical SystemC/ArchC issues, random ramblings about heterogeneous multicore architectures and maybe some cool embedded systems projects soon!
In the past 2.5 years I did a lot of things that I really felt like I should blogged about here, mostly as part of the fantastic Erasmus Mundus in Embedded Computing Systems (EMECS) master programme, but ah well. I intend to share the rest of my embedded systems and computer architecture adventures here, and if I manage to get back into the writing mode I might even become retrospective and write about some cool stuff I've seen during the Long Period of Silence :P
To summarize the current situation, I'm in the last semester of the EMECS programme writing my Master's thesis, and recently got a PhD position offer from the Norwegian University of Science and Technology (NTNU) Computer Architecture and Design Group. My thesis and the doctoral research for the following 4 years will be in the fascinating world of heterogeneous multicore architectures, and at the heart of the reason for doing all this still lies the same craving which fueled my Google Summer of Code 2010 project at BeagleBoard with dsp-rpc-posix: to make these amazing hardware be used to their full or near-full potential more easily by more developres.
On a more specific level of detail, my MSc thesis is going to be about developing a simulator for a tile-based heterogeneous architecture. I've done a bit of literature research and review of existing simulator work (and most naturally, a brain muddled due to trying to absorb all that information in 1.5 weeks) and for the moment it feels like I'll be basing my work on ArchC / SystemC for a variety of reasons which I'll hopefully go more into soon.
Expect to see blog posts about practical SystemC/ArchC issues, random ramblings about heterogeneous multicore architectures and maybe some cool embedded systems projects soon!
Subscribe to:
Posts (Atom)