Recen progress

1. Recen progress R93088 李清新

2. Recent status – about hardware design • Finishing the EPXA10 JPEG2000 project. Due to the DPRAM problem can’t be solved by me, I decide to write a AHB slave. • I started by rewrite the accumulator project. I connect a memory compiler produced RAM on the AHB bus, and add some control logic to control the accumulator. It works. Under this architecture, it is easy to replace the accumulator with DWT. • If I have three AHB slave, there will be some problems. The AHB is a pipelined protocol, which separate the address phase and data phase. There may be a situation that master is waiting data from slave1 and sending address to slave2 at the same time. To decide which slave can grant the READY bus and when to pass the control to another slave needs some understanding about the bus protocol.

3. Recent status – about software(1) The simplified booting flow is described below 1. By default, FLASH memory is mapped at 0x0000_0000 2. Running the megawizard produced code in FLASH 3. After setup the SRAM, copy the booting codes to the SRAM and resume the rest of the booting process 4. Jump to _start label. By experiment, the _start label is located at 0x0000_0000. I think there should be a code copy or memory remap which is done by booting code. The first 8 address is ARM interrupt vector location. The codes below _start are used to setup software environment. After, the code will jump to our main function which is located at 0x0000_8000. The problem the scanf fuction will fail may be that memory is not enough. This can be solved by not using function from stdio. To implement scanf function, we must have _read function which is like a device driver. Scanf provide a more user friendly API for programmer. Without scanf function, we still can read something from UART.

4. Recent status – about software(2) • To use the SDRAM for our software program, the binding is a problem. • There are three kinds of binding, compile time ,link time, execution time. In windows system, we have page tables. Programs can always start at 0x0000_0000 and there won’t be any problem. In our development board, we don’t include a OS and we don’t have page table. So we have to bind our software program at link time, and put it to the propose location then jump to the address. • To run our software program in SDRAM, we have to solve two problems. First, how to bind the software to an address we assigned? Second, how to load the software from the host computer and put it to the proper memory address. • I think these functionality is providded by a bootloader, like redboot.

5. Recent status – about FPGA • I don’t have any idea about the FPGA problem. I will try to solve it by configure the FPGA ourselves, not using the megawizard.

6. Recent understanding about cycle accurate and timing accurate (1) A B • After discuss with Yider and the coware trainer, I get some picture about the cycle accurate and timing accurate. • Timing accurate : This is mentioned in my presentation 4/11. The difference between this with not timing accurate is show in the graph. • Not timing accurate : once B receive the data from A, and B finish it job, it won’t synchronize the execution time. • Timing accurate : everytime data exchange, it will synchronize timing. 100 50 Not Timing accurate A B 100 50 50 extra waiting Timing accurate

7. Recent understanding about cycle accurate and timing accurate (2) • Cycle accurate : the time needed to perform a task is correct. Compared with none cycle accurate approach, there may be a situation that an easy task can run 1 ns in hardware but run 100ns in hardware simulator. Software can do a lot of things in 100 ns but software can’t do many things in 1ns. And this is the problem. Yider and I consider that if we use proper synchronization protocol, there won’t be a functional problem, but the performance estimation may be a big problem. • According to Coware’s trainer, the problem that none cycle accurate will have is the performance estimation. If we use none cycle accurate co-simulation method to test our architecture. We can’t find the problem in our architecture because the simulation result is not correct.

8. Recent understanding about cycle accurate and timing accurate (3) • Comparing the three method ,cycle accurate, timing accurate, no timing • Timing accurate seems to have it’s own value, since it can reflect the architecture performance and it have the faster execution speed, but the quality is a problem. • Cycle accurate have the best quality but the slowest execution speed. If it is a big design, the simulation speed is still too high. But if we don’t use a bus with cycle, we can’t connect a RTL level ( systemC or HDL) component to it. • No timing is the fastest. We can use it to test functionality but we can’t use it to improve architecture. • A proper approach is that we start at no timing co-simulation. The refine it to cycle accurate or timing accurate. • Take SystemC for example. Initially, systemC is a cycle based simulator, and now it is an event based simulator. If timing accurate can have good estimation quality, then it is better to use timing accurate.

9. About Luke’s work • Yider and I have read Luke’s paper and the source code of expert template for many times, but we have some problems to run the flow. • First, we can’t run Luke’s TLM or RTL level design in our computer. We can run any other SystemC design in our computer. We follows the steps from systemC user guide in systemC website. It may be an one-line problem, but we have no idea about it now. • Second, we can’t build the ecos tool chain. Yider and I follow the steps from ecos website but we all fail when we try to open configtool. We can’t build any ecos program right now.