Our annual design contest took place on campus between November 23 and 25, and the design challenge was again based on the mapping of embedded software tasks onto a multiprocessor system based on Networks-on-Chip (NoC). This challenge was introduced last year, and was successfully solved by most groups despite of the difficulties of working online. One of the groups even managed to find a solution that was superior to the model solution I had found for the challenge! More details in last year's blog post.
For this year's challenge, I decided to make the problem a bit harder. Firstly, because the element of surprise would no longer be there (over the years I have witness how much students learn from their seniors). And secondly, because last year's groups did so much better than I expected, so I wanted to make sure this year's students felt sufficiently challenged.
The increased difficulty came from two small changes to challenge. The first was simple and obvious: I increased slightly the number of tasks (from 44 to 54) and inter-task communications (from 68 to 70). The complexity of a mapping problem always increases with the number of "things" to be mapped, so this was an easy way to make the problem more challenging. But it is likely that the solutions used by last year's groups would cope with this year's problem as well. So I also changed the design alternatives that the students were allowed to consider. Last year, they were allowed to lower the clock frequency of the processing cores and the NoC interconnect, as long as the application tasks would not overutilise any core or interconnect link, aiming to reduce energy dissipation. But they would not be able to overclock the cores or the interconnect: in case a particular processor configuration was not fast enough to run all application tasks without overutilising the platform, their alternative was to go for a larger platform (i.e. with more cores and a larger interconnect). This year, students were allowed to overclock processing cores and/or the interconnect by up to 20%, which provided them more design alternatives to explore (e.g. overclock a smaller platform vs. underclock a larger platform). To take into account both dimensions of the design space, the quality of the solutions found by each group was ranked by the number of processing cores they needed (lower is better), and by the frequency scaling factor for cores and interconnect (lower is better).
The class was randomly divided in four groups, but due to absences each group had between 1 and 3 active members (the design contest is not a mandatory part of the embedded systems module, and does not contribute to the final mark). They were given two days to work on the design challenge, and all groups submitted a solution by the deadline. Just like in 2020, three of the solutions submitted were valid task mappings that did not overutilise the multiprocessor platform when scaling the clock frequency by the submitted factors (one of the groups submitted only a partial mapping that did not include all tasks, so it could not be evaluated). The valid solutions submitted by groups 2, 3 and 4 required platforms with 20, 36 and 18 cores, respectively. With a smaller number of cores, group 4 was named the winner even when taking into account the frequency scaling factors used by each group. Below, a photo with the members of group 4 David Kacs and Ben Marsh (and their prize).
The post on the design contest is always closed with links to the now famous EMBS Design Contest Hall of Fame, with pictures of the top teams from all previous contests: 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2012, 2011, 2010 (in 2013, no group managed to finish the challenge on time).
