Ex3: 2010/11: ACS P35 SoC D/M Week 5 Exercises. In this task you establish the frameworks for three mini-projects. You will typically develop one of these mini-projects to give in as MiniProject 1 in week 7 and another to give in as MiniProject II at the start of the Easter Term, but a fresh start for either of these submissions is also acceptable. --------------------------------------- Task: Please either write a device driver (and basic test application) or a TLM model for three of the following examples. Overall, please either write two device drivers and one TLM model or one TLM model and two device drivers. They should be as simple as possible to prove the point. We can always add further complexity later. Do not write a complete device driver and TLM model pair: instead liase with someone else in the group and each do half of the pair. Before coding, please first agree your peers (ideally not the same for each of the three exercises) and submit a draft specification of each system to DJG for approval. Keep it very simple! Miss out all of the extensions to start with. Where appropriate, specifications should include the 'programmer model' (including memory map) for the device. --------------------------------------- Submission: Please install your work under CVS in the project shared folder: /usr/groups/acs-projectwork/year1011/p35/cvs I will put an example in there (perhaps UART). Please check out the example. $ cvs -d /usr/groups/acs-projectwork/year1011/p35/cvs co example-uart which will have the following form week5/example/doc/spec.html - The specification week5/example/tlm - The TLM model week5/example/device-driver - C code (perhaps some assembly too) for the OR1k Processor week5/example/testbench - Test system makefiles, stimulus data and so on week5/example/rtl - RTL implementation (normally leave empty ) Please make your own folder under week5 and check it in as follows. $ cd week5 (i.e. change to where you checked out week5) $ mkdir mycomponent $ cvs add mycomponent $ mkdir mycomponent/tlm $ ... etc You should follow the same sub-directory structure as my example and check in your subdirectories as well. Do not check in .o or other binary files. Please write a brief report that explains how your work meets the spec. Mention sources of modelling error where an RTL version would be different. Mention execution time, bus loading, register accuracy, conditional compilation in the firmware/device-dreiver, and so on. Please print out hardcopy of source files and submit this to student admin together with your report. --------------------------------------- Example components are: Hard-disk : (SATA/SCSI or IDE style) and controller. Device model: should support persistent data storage (on workstation disk) and model seek times Device driver: should enable a disk block to be read or written. Extensions: add interrupts. DMA controller Device model: should implement a block move Device driver: should supply a simple callable API similar to posix memcpy Extensions: access to a disk drive or sound card (i.e. src or dest address is a fixed I/O device), following a linked-list of buffers, ... etc. Ethernet or other network Device model: sending packets to/from a workstation file Device driver: should have a sendpkt and rcvpkt call Extensions using psock: to access the real LAN on the workstation, implement ICMP ping response. Multi-bank DRAM controller: Dram model: should include multiple concurrent open banks Dram controller model: should implement several bank closing policies and bank interleaving patterns Device driver: actually a memory test program that determines the performance of the different controllers Extensions: mirrored DRAM ? is this useful ever? Cache with hardware profiler. Device model: should be easily adjustable in size and structure and be turnoffable. Device driver: should give a simple console log of the recent statistics read from the hardware. Extensions: do not store the data in the cache, just model the misses. Or, do not model the tags either, just add estimated costs to the main metrics (delay, power, bus load). Memory manager (with/without TLB) Device model: should be easily adjustable in size and structure and be turnoffable. Device driver: should implement demand paging (install a fresh page on page fault) Extensions: (for Ex5 make it compatible with the OR1K MMU and boot linux!) Inter-core message-passing I/F (perhaps using shared memory and an inter-core interrupter or special channels). Device model: should enable a 'packet' to be sent to another core Device driver: support blocking read() and write() calls. Extensions: add fifo queues to decouple the two sides. VGA device: Device model: should read or write media to a workstation file (e.g. raw samples or .bmp format) DJG has some useful libraries... Device driver: should enable pixels to be turned on and off and read. Extensions: provide line and rectangle support. Support blit or scroll. Realtime output to X window. Sound output port: Device model: should read or write media to a workstation file (e.g. raw samples .wav format) DJG has some useful libraries Device driver: should allow blocks of audio to be queued for playing one after another. Extensions: play to real workstation soundcard. Support mixing of several channels. Device of your choosing? Memory management unit ? Hardware assist for MP3 ? Also: Breakpoint/debugger block (see the RSP prototype, but this may be better for MiniProject-II) Device model: should support basic RSP memory inspection primitives Device driver: There is none (except perhaps some gdb scripts... ) ------------------------------------------------------ Further notes: Q. How do I send a complete Ethernet packet from the processor model to the network device model ? A. The highest-level model of this operation is a single TLM call for the whole packet transfer where the generic payload of that call does not even contain the Ethernet packet, it just contains a pointer to a buffer on the modelling workstation where the packet is actually stored. This TLM call might, for instance, increment its sc_delay parameter by an amount proportional to the length of the Ethernet packet to model the delay that would be experienced sending the packet over a bus or NoC. HOWEVER: this level of modelling is only suitable if both ends of the TLM connection understand Ethernet packets. Connecting a general processor, like the OR1K, to an Ethernet device model at this level of abstraction would require the OR1K to have knowledge of Ethernet packets, whereas in reality it is the device driver s/w running on the OR1K that understands the Ethernet packets but the processor model itself (ISS and btlm-wrapper.cpp or RTL model) is not specialised in that way. Therefore, the expected answer to this exercise would not define new uses for the generic payload but would instead implement a memory-mapped Ethernet device that can be operated with standard read and write TLM transactions. Either approach is possible of course. Perhaps the easiest way to start is first to sketch our the minimal OR1K program that would cause the shortest Ethernet packet to be sent under programmed I/O. Q. Is there a standard technique used to read from ethernet devices? We are thinking about having a readable status register in the ethernet device which has flags indicating whether or not it is ready to send a packet or has received and buffered a packet. However, how does the device driver know how long the packet will be when it is reading from the device? Should the device act as a state machine which returns the length of the packet on the first read and data on each subsequent read? Or could we take a fixed packet size for simplicity? A. There is no official standard but the NE2000 register map is widely implemented Having several registers where one is the length field is a typical approach. The state machine approach is also sometimes used. Q. I'm just looking at the example in the CVS directory for P35 (example-uart) and there does not appear to be any content in it. Was this example just to show the desired directory structure or is there supposed to be an example of a TLM model and corresponding driver? A. You are correct: I have only set up the directory structure so far. I am copying in the relevant files from the btlm-ref-model at the moment. Q. Also, you've mentioned in the exercise specification that you have some useful libraries for some of the components. Could you send a link to these libraries? (Specifically the ones for the VGA device and the sound output port). A. For the LCD (and perhaps for audio) there are some useful bits and bobs in /usr/groups/han/vhls/tlm-power-help/tp2 but I have not looked through them in any detail. For audio there is also /usr/groups/han/clteach/orpsoc/musicbox For video there is also /usr/groups/han/clteach/misc/vogtile/vogtile.cpp These may need x11-devel to be installed on the acs workstations - I'll ask for that.