ACS SOC D/M P35: Ex 5 2012/13: Mini-Project and Structured Research Essay. The deadline for all P35 work is the first day of Easter Term. Preliminary: Please ensure you have completed Exercises 3 and 4 by completing all of the required parts. Also, you will most likely build on these exercises for the Mini-Project. Owing to overlapping baselines, it is perfectly acceptable for an overview diagram, table of results, graph or introductory paragraph of text to be used in more than one of Ex 3, 4 or 5. Collaborating is not allowed for the Research Essay and is only allowed for any parts of the mini-project that are borrowed from the term-time work or with express permission that will only be granted if the nature of the collaboration will enable individual contributions to be clearly discriminated. --------------------------------------------------------------------------- Notes arising this year: Note: Your audience is the External Examiner, Second Assessor and readers of Design and Reuse or Electronics Times. It is therefore worthwhile explaining material that would be well known to others involved in this module. Note: Some combinations of numbers of cores and quantum keeper settings can cause the or1k simulator to spend a lot of time doing failed load-links and the fix to this (if you are using condition variables or barriers) may be be to edit djgthread.c cond_wait at line 212 by inserting a call to yield for as follows: while (_djg_Threads[tid].waiting == cond) { _core_pause(tid); ... } I have made this edit on the copy installed in clteach/btlm-baseline. --------------------------------------------------------------------------- Exercise 5: Mini-Project Specification. Please submit up to one page of short notes on your plans and any progress so far for your mini-project. This can include what you might expect to be the first one or two and the final one or two sentences of your final report. The report should ultimately tell an interesting story and this generally involves phrasing a question to be investigated. These should have been discussed with D Greaves in advance. Eg in person on Weds 13th March or over email. --------------------------------------------------------------------------- Exercise 5: In both parts of Exercise 5, ten percent of marks will be awarded for overall presentation including quality of written English. Ex5 Part A: (Mini-Project): Construct an interesting argument based on experiments you have conducted on a multi-core system-on-chip TLM model. This will most likely be the SystemC TLM model used in Exercises 3 and 4. Write a report in a style suitable for publication in Electronics Times or Design and Reuse (or similar). These articles tend to be between 1000 and 3000 words. Your argument must illustrate a trend, either in terms of SoC design or in terms of SoC modelling. You should compare various approaches and be able to run the same experiments with different settings of parameters. (Example parameters are: number of cores, localised scratchpads versus caches, different bus and cache structures, different TLM quantum, different settings of gcc optimisation flags, different styles of communication, different ways of modelling contention, counting net transitions in verilated models, ...) You argument does not have to be original: basing your report on an existing D&R or ET article is acceptable, but you must include your own experimental results. Ex5 Part A accounts for 35 credit points. --------------------------------------------------------------------------- Ex5 Part B: (Assessed Essay) Write an essay entitled 'System On Chip Design and Modelling' that consists of five sections whose headings are taken from the list below. Each section should consist of 300 to 600 words of text and an appropriate number of diagrams. Ex5 Part B accounts for 25 credit points. ** Please refer to part A as a source of examples for part B where possible. ** Section headings (choose five and place in the best order): 1. Relative roles of ISS and cycle-callable models of processor cores and cache systems. Discuss various abstraction levels for modelling of processor cores, including cross compilation of firmware for the modelling workstation through to cycle-accurate models of every target instruction. Mention styles for modelling caches (e.g. is the hit ratio estimated or measured ?). (You might compare performance or modelling style of the OR1200.cpp (verilated core) with the orsim_sc.cpp ISS.) 2. Use of assertions and temporal logic in SoC modelling. Using several example assertions that are potentially relevant at several levels of abstraction, explain how they are re-applied at each level or mention whether this is not always the case. 3. Ease of design re-partition and architectural exploration. Show how a target application can be 'run' (i.e. explored) on SoC models that vary in their level of abstraction and show how having a lower-level model makes architectural changes, such as changing the number of processors, memories or bus/network-on-chip structures more difficult. 4. Statistics collection and modelling contention and queueing. Show how performance can be estimated or measured using SoC models at various levels of abstraction according to how many of the contended resources, such as memory ports or bus bridges are modelled and the style of modelling used for them (e.g. actual queues versus estimated queuing delays). 5. Using direct calls between device drivers compared with abstract and concrete bus/NoC models. Explain how firmware and high-level models of devices should be modified to run an application without any hardware model (i.e. with direct calls between h/w and s/w components) compared with its final form. Include an interrupt service routine. 6. Clock frequency and power consumption modelling. Discuss how well a high-level SoC model can be used to estimate system clock frequency (i.e. critical path) and power consumption (including dynamic frequency and voltage scaling) compared with pre-synthesis, post-synthesis and post-layout RTL models. 7. The role of high-level synthesis and synthesis from formal specifications in SoC design flow. Show how part of your example design could have looked if synthesised from a higher-level form. (You may have included this anyway.) 8. Evaluation and automatic generation of glue logic and/or SoC bus/NoC Explain how the components of your example design are connected to each other at the various levels of abstraction and perhaps discuss the potential for automatic generation of address maps and automatic synthesis of the joining code or logic. (Perhaps refer to http://www.cl.cam.ac.uk/~djg11/pubs/joining-fdl10 or google for 'network on chip traffic generator') 9. Relative role of FPGA and ASIC in contemporary products. Tape out mask costs are ever increasing. FPGA has now eaten all of the low volume ASIC market and the Structured ASIC has died. Which sectors still do SoC design ? 10. A similar topic of your own choosing. By 'various levels of abstraction' we refer to ESL models spanning: 1. Application software and device drivers with no hardware model at all, 2. High-level TLM modelling, loosely timed, with no models of bus or network structures, 3. Lower-level TLM modelling that accurately models contention points, 4. Cycle-accurate modelling. END ----------------------------------------------------------------------------- Questions Arising (clarification points from email exchanges from previous years.) Q. In question one you use the term cycle-callable. Is this the same as cycle-accurate? A. cycle-callable is a cycle accurate model of a subsystem implemented in a non-blocking style where one clock cycle is executed for each call. Q. Looking at the Part II course notes, does cross compiling the firmware for the modelling workstation represent the "Functional Modelling" level of abstraction? A. In broad terms yes. My notes define this term to mean the output of the simulation is correct. It implies that the same algorithm is used to arrive at that output as well. Cross compiling firmware should lead to correct output but also models further aspects of the implementation beyond those needed to just get the output correct. For instance, the UML diagram of the class instances used by the cross-compiled code would be the same as the actual implementation whereas we can consider different implementations that still use the same algorithm (e.g. minor variations in record field structure, a different calling pattern between methods or executing on a different number of CPU cores). Q. Would I be correct in saying that if you cross compile the firmware for the workstation then there is actually no model of the processor core at all? A. Yes, but one can still profile the code using gprof, valgrind, oprofile or whatever to find out how many instructions it used and method calls it made to get some idea of what the target processor would have consumed. Using oprofile you can get cache hits and misses and other details. This might be useful at the very early stages of system development (e.g. for a new data coding scheme like low-density parity checks or candidates for 4G mobile telephony or a replacement for DES) to understand what class of core or number of cores are going to be needed and to estimate the basic cost of a product based on this technology. Q. In question 5 you've asked for a description of an interrupt service routine. Have you any instructions on how to write an ISR for the or1k? A. There is an example of an interrupt service routine in my notes and this is the same as the SystemC UART with interrupts (/home/djg11/example-uart/example-uart-with-interrupts/) I have not made this work on the OR1K personally (I did not get as far as finding the OR1K instruction to enable interrupts, which needs adding to the crt.S). The linux kernel compiled for OR1K uses them of course, so perhaps look in a kernel source folder such as linux-2.6.24/arch/or32/kernel for real OR1K interrupt handlers. Q. "Show how part of your example design could have looked if synthesised from a higher-level form. (You may have included this anyway." By this do you mean, say, how would the ethernet TLM model ook if it had actually been implemented in, say, Csharp with Kiwi attributes? A. This question potentially covers a great deal of ground. For instance, you might generate a protocol or packet checker by compiling a formal spec to include in the system RTL. You could also cite work regarding synthesis of memory maps, bus structures and other glue logic needed to connect parts together. Perhaps the most obvious thing to do is to talk about compiling a behavioural model of the subsystem into synthesisable RTL for the target implementation, commenting on what is likely to work (or even trying out one or two experiments on Kiwic or one of the online C-to-gate servers). Considering TLM, which you mention, manually-coded TLM models of devices are very much like high-level behavioural models written specifically for synthesis by C-to-gates flows. So if comparing these two forms you would mostly comment on what parts of the TLM model can and cannot be expected to be synthesisable to RTL implementations. There are a number of research papers on this but no accepted standards. Generating a TLM model from Kiwic is not something I have considered: although Kiwic can generate SystemC output, this is RTL-style code, not TLM code. I guess when you say the 'ethernet TLM' you really me the ethernet synthesisable RTL implementation that I spoke of above under 'most obvious thing to do' ? END.