Building Whole Systems: an Overview

Transcription

1 1 Building Whole Systems: an Overview In this lecture: System specification, design, and synthesis Hardware/software co-design Work tips Design challenges and trade-offs

2 2 Ideal flow (Informal) Specification Abracadabra Implementation

3 2 Ideal flow (Informal) Specification Abracadabra formalize choose platform decide architecture decide Hw/Sw synthesize optimize keep correctness Implementation

4 3 Realistic flow designer (implementation) Refine: Tools by Hand high-level imp Verify model 1 imp Verify model 2 customer (spec) imp Verify model 3 Redesign Optimize full imp model

5 4 Specs: Modeling vs. Synthesis Modeling: simple/focused specifications reason about the system have a reference behavior Synthesis: complete specifications produces the implementation complex/designer controlled refinement steps

6 5 Modeling Different computational models: Finite State Machines,SpecCharts Process Networks Petri-Nets (Control) Data-Flow Graphs, Executable: C, Java, Python,... VHDL, Verilog, SystemC, C#, MATLAB, BlueSpec

7 6 Synthesis Historically: Hw/Sw distinction Sw compilation vs. Hw synthesis specific computational models, languages, tools abstraction-level specific Vision: no distinction between Hw and Sw co-design, co-simulation, co-synthesis, unique language (SystemC, SystemVerilog? ) common tools (front-end) abstraction-level independent

8 7 Classic Design vs. Co-design Flow specification partition Classic Sw refine refine comm. extraction Hw refine refine compile synthesize implementation

9 7 Classic Design vs. Co-design Flow Sw refine refine compile specification partition comm. extraction implementation Classic Hw refine refine synthesize Sw compile specification refine refine partition comm. extraction implementation Co-design Hw synthesize

10 8 Hw/Sw co-design in a nutshell Late Hw/Sw partitioning: larger design space (fuzzy Hw/Sw border) allows for finer grain partitioning flexible (late architecture selection) more homogeneous system specification

11 8 Hw/Sw co-design in a nutshell Late Hw/Sw partitioning: larger design space (fuzzy Hw/Sw border) allows for finer grain partitioning flexible (late architecture selection) more homogeneous system specification the problems: requires a powerful enough language to express both Hw and Sw at different abstraction levels appropriate tool support

12 9 System Synthesis Issues neither Hw or Sw are fully functional Sw needs a Hw for implementation Target platform development: unit test Hw Partition implement DONE! Sw integrate and test Time

13 10 Improved System Development cross platform development: decide interfaces and write stubs develop Sw on an available machine + stubs develop Hw in parallel + tests in Sw Host Sw port, integrate,test Hw Target Sw Partition spec DONE! Time

14 11 An Example Spec: load a pair of integers on the serial and display a pixel on the screen

15 11 An Example Spec: load a pair of integers on the serial and display a pixel on the screen load integer and put pixel are Hw/Sw interfaces

16 11 An Example Spec: load a pair of integers on the serial and display a pixel on the screen load integer and put pixel are Hw/Sw interfaces Hardware Developed in parallel Stubs: int LoadInt() {scanf} void PutPixel() {printf} Software: PutPixel(LoadInt(),LoadInt())

17 11 An Example Spec: load a pair of integers on the serial and display a pixel on the screen load integer and put pixel are Hw/Sw interfaces Hardware Developed in parallel Stubs: int LoadInt() {scanf} void PutPixel() {printf} tested on the host platform Software: PutPixel(LoadInt(),LoadInt())

18 11 An Example Spec: load a pair of integers on the serial and display a pixel on the screen load integer and put pixel are Hw/Sw interfaces Hardware Developed in parallel (port) Stubs: int LoadInt() {scanf} void PutPixel() {printf} Re-write LoadInt and PutPixel using XIo_In,XIo_Out tested on the host platform Software: PutPixel(LoadInt(),LoadInt()) target implementation

19 12 Team Work

20 12 Team Work make an initial detailed specification reduces useless discussions later reduces free interpretation, blaming others

21 12 Team Work make an initial detailed specification reduces useless discussions later reduces free interpretation, blaming others distribute work wisely (Hw,Sw, Stubs, Integration, Testing, etc ) minimize interdependency allow for loads of parallel work

22 12 Team Work make an initial detailed specification reduces useless discussions later reduces free interpretation, blaming others distribute work wisely (Hw,Sw, Stubs, Integration, Testing, etc ) minimize interdependency allow for loads of parallel work report your progress to each other often

23 13 More Work Tips start from working Hw and build around full re-design takes much more time and effort

24 13 More Work Tips start from working Hw and build around full re-design takes much more time and effort do unit tests, simulate modules painful to detect bugs later

25 13 More Work Tips start from working Hw and build around full re-design takes much more time and effort do unit tests, simulate modules painful to detect bugs later use debuggers, printouts, leds, everything to make sure your system works

26 13 More Work Tips start from working Hw and build around full re-design takes much more time and effort do unit tests, simulate modules painful to detect bugs later use debuggers, printouts, leds, everything to make sure your system works write simple Sw tests for your Hw

27 13 More Work Tips start from working Hw and build around full re-design takes much more time and effort do unit tests, simulate modules painful to detect bugs later use debuggers, printouts, leds, everything to make sure your system works write simple Sw tests for your Hw if time is short, go around problems (patch bad Hw with Sw)

28 14 Real-life design trade-offs (choices, optimizations, and fine tuning)

29 15 Real-life restrictions Limited type and amount of resources Changing specifications Limited knowledge

30 16 Limited Resources

31 16 Limited Resources Time

32 16 Limited Resources Time Tools Build (compilers, synthesis, technology) Test, debug, maintenance

33 16 Limited Resources Time Tools Build (compilers, synthesis, technology) Test, debug, maintenance Target hardware support Type & amount of available IPs/chips Partially fixed architecture

34 16 Limited Resources Time Tools Build (compilers, synthesis, technology) Test, debug, maintenance Target hardware support Type & amount of available IPs/chips Partially fixed architecture Target software support operating system, libraries, drivers

35 17 Challenges

36 17 Challenges Design using available components Select the most suitable architecture (cores and communication channels) Adapt the custom hardware/software to the available system Allow some flexibility, configurability (shifting specs.)

37 17 Challenges Design using available components Select the most suitable architecture (cores and communication channels) Adapt the custom hardware/software to the available system Allow some flexibility, configurability (shifting specs.) Optimize Do not use more (area, memory, ) than you need Add Hw to speed up/simplify Sw (e.g. DMA ctrl)

38 17 Challenges Design using available components Select the most suitable architecture (cores and communication channels) Adapt the custom hardware/software to the available system Allow some flexibility, configurability (shifting specs.) Optimize Do not use more (area, memory, ) than you need Add Hw to speed up/simplify Sw (e.g. DMA ctrl) Test & Debug

39 18 Hw/architecture design techniques

40 18 Hw/architecture design techniques Start with a simple, working design

41 18 Hw/architecture design techniques Start with a simple, working design Expand gradually by adding tested IPs

42 18 Hw/architecture design techniques Start with a simple, working design Expand gradually by adding tested IPs Design custom IPs only when necessary

43 18 Hw/architecture design techniques Start with a simple, working design Expand gradually by adding tested IPs Design custom IPs only when necessary Communicating/shuffling data is usually the bottleneck, not computing: choose fast/many memories, buses

44 18 Hw/architecture design techniques Start with a simple, working design Expand gradually by adding tested IPs Design custom IPs only when necessary Communicating/shuffling data is usually the bottleneck, not computing: choose fast/many memories, buses Improve/Optimize a working prototype

45 19 Memory Band-width: VGA controller example 640x480 rrrbbbggg 60Hz

46 19 Memory Band-width: VGA controller example 640x480x9x60 = 165,888 kb/s 640x480 rrrbbbggg 60Hz

47 19 Memory Band-width: VGA controller example 640x480x9x60 = 165,888 kb/s 640x480 rrrbbbggg 60Hz = 5,184kw/s = 5.2Mw/s

48 19 Memory Band-width: VGA controller example 640x480x9x60 = 165,888 kb/s 640x480 rrrbbbggg 60Hz = 5,184kw/s = 5.2Mw/s 100 MHz bus clock Approx. 1 word each 19 cycles (read access!)

49 20 Memory Band-width: VGA controller example (II)

50 20 Memory Band-width: VGA controller example (II) LMB_BRAM: Single read access: 1clock cyle/word no problem. Avg. Utilization due to ctrl = 5%

51 20 Memory Band-width: VGA controller example (II) LMB_BRAM: Single read access: 1clock cyle/word no problem. Avg. Utilization due to ctrl = 5% PLB_BRAM: (plb_bram_if_ctrl.pdf) Single read: 6cc/w OK?. Avg. Utilization due to VGA ctrl =30% Burst reads: ~10cc/4x2ws = 1.25cc/w no problem. Avg. U = 7%

52 21 Memory Band-width: VGA controller example (III)

53 21 Memory Band-width: VGA controller example (III) PLB_DDR (plb_ddr.pdf) Single read: 14cc/2w OK?, avg. U = 35% Burst read: 16cc/2x2w ~ 4cc/w OK, avg. Utilization = 20%

54 21 Memory Band-width: VGA controller example (III) PLB_DDR (plb_ddr.pdf) Single read: 14cc/2w OK?, avg. U = 35% Burst read: 16cc/2x2w ~ 4cc/w OK, avg. Utilization = 20% PLB_EMC (SRAM,Flash): 8-bit access Single read: 10cc/B (40/w) problem. Bus cannot cope: avg. U = 200% Burst read, etc.

55 22 Variable Band-width: VGA controller example (IV) 640x480x9b 60Hz hsynch Pixel clock (pc) = 25MHz Bus clock (bc) = 100MHz Total pixels 800x525

56 22 Variable Band-width: VGA controller example (IV) 640x480x9b 60Hz Total pixels 800x525 hsynch Pixel clock (pc) = 25MHz Bus clock (bc) = 100MHz Instant Demand: 0w/bc

57 22 Variable Band-width: VGA controller example (IV) 640x480x9b 60Hz Total pixels 800x525 hsynch Pixel clock (pc) = 25MHz Bus clock (bc) = 100MHz Instant Demand: 0w/bc Instant Demand: 9b/pc = 0.07 w/bc 1w/14bc

58 22 Variable Band-width: VGA controller example (IV) 640x480x9b 60Hz Total pixels 800x525 hsynch Pixel clock (pc) = 25MHz Bus clock (bc) = 100MHz Instant Demand: 0w/bc Band-width demand changes at run-time: High band-width may be too high for the chosen bus Smoother bus utilization may be required Instant Demand: 9b/pc = 0.07 w/bc 1w/14bc

59 22 Variable Band-width: VGA controller example (IV) 640x480x9b 60Hz Total pixels 800x525 Band-width demand changes at run-time: High band-width may be too high for the chosen bus Smoother bus utilization may be required Solution: BUFFERING! hsynch Pixel clock (pc) = 25MHz Bus clock (bc) = 100MHz Instant Demand: 0w/bc Instant Demand: 9b/pc = 0.07 w/bc 1w/14bc

60 23 Variable Band-width: VGA controller example (V)

61 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data

62 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data Buffer size?

63 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data Buffer size? Easy way out: full frame - not always possible

64 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data Buffer size? Easy way out: full frame - not always possible Trial and error: start with a small buffer and increase it if the controller starves.

65 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data Buffer size? Easy way out: full frame - not always possible Trial and error: start with a small buffer and increase it if the controller starves. Analysis:

66 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data Buffer size? Easy way out: full frame - not always possible Trial and error: start with a small buffer and increase it if the controller starves. Analysis: Compute the avg. rate (19bc/w ~ 0.052w/bc)

67 23 Variable Band-width: VGA controller example (V) Keep the buffer filled with data Buffer size? Easy way out: full frame - not always possible Trial and error: start with a small buffer and increase it if the controller starves. Analysis: Compute the avg. rate (19bc/w ~ 0.052w/bc) Size = Longest_time_without_using_data x Rate (last pixel to first pixel delay) vhdl: ( )x800x0.052 = 1914 words (~2kw)

68 24 Fine Tuning: VGA controller example (VI) Initial assumption: all bits in a word carry information! complex decoder and unpacking method Bus transfer Memory organisation

69 24 Fine Tuning: VGA controller example (VI) Initial assumption: all bits in a word carry information! complex decoder and unpacking method Solutions: 1. Reduce bpp: 8 (4p/w) 2. Align & discard bits Required band-width and buffer size change! Bus transfer Memory organisation Translate 8 to 9 bits: 1. conversion table 2. default bit No conversion required Decoder not so simple

70 25 IP Configuration Trade-off area/power for performance: Processor Cache type/size Floating point support Pipeline depth (?) Memory sizes Interconnect type/width (buses) Timing/wait states

71 26 Memory Size Issues: SRAM executable example

72 26 Memory Size Issues: SRAM executable example problem: the program does not fit in the available on-chip BRAM

73 26 Memory Size Issues: SRAM executable example problem: the program does not fit in the available on-chip BRAM SOLUTIONS: compile with -Os, remove debug info. put the stack and heap in off-chip memories need to use available SDRAM, SRAM/Flash execute from the off-chip memory need to use proper controllers boot from BRAM, jump to an executable off-chip use caches to speed up

74 27 Memory Size Issues: SRAM executable example

75 27 Memory Size Issues: SRAM executable example Steps:

76 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR

77 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin

78 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin 3. Write/compile/link a bootloader from 0x0000

79 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin 3. Write/compile/link a bootloader from 0x0000 typedef int (*maintype)(int,char**); maintype maincode = (maintype)sram_baseaddr; int main(int argn, char **argv) { return maincode(argn, argv); }

80 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin 3. Write/compile/link a bootloader from 0x0000 typedef int (*maintype)(int,char**); maintype maincode = (maintype)sram_baseaddr; int main(int argn, char **argv) { return maincode(argn, argv); } 3. Add MDM debug periph., set mblaze DEBUG_ENABLE flag

81 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin 3. Write/compile/link a bootloader from 0x0000 typedef int (*maintype)(int,char**); maintype maincode = (maintype)sram_baseaddr; int main(int argn, char **argv) { return maincode(argn, argv); } 3. Add MDM debug periph., set mblaze DEBUG_ENABLE flag 4. Download configuration, connect in xmd: mbconnect mdm

82 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin 3. Write/compile/link a bootloader from 0x0000 typedef int (*maintype)(int,char**); maintype maincode = (maintype)sram_baseaddr; int main(int argn, char **argv) { return maincode(argn, argv); } 3. Add MDM debug periph., set mblaze DEBUG_ENABLE flag 4. Download configuration, connect in xmd: mbconnect mdm 5. xmd> dow -data main_app.bin SRAM_BASEADDR

83 27 Memory Size Issues: SRAM executable example Steps: 1. Link the main application from SRAM_BASEADDR 2. mb-objcopy -O binary main_app.elf main_app.bin 3. Write/compile/link a bootloader from 0x0000 typedef int (*maintype)(int,char**); maintype maincode = (maintype)sram_baseaddr; int main(int argn, char **argv) { return maincode(argn, argv); } 3. Add MDM debug periph., set mblaze DEBUG_ENABLE flag 4. Download configuration, connect in xmd: mbconnect mdm 5. xmd> dow -data main_app.bin SRAM_BASEADDR 6. Run or Download configuration again

84 28 Software fine tuning To adjust code speed and size: Algorithm selection (e.g. bubble vs. quick sort) Compiler optimization options Linker scripts segment splitting: distribute code,stack,heap, Driver choices low level, small, little functionality vs. high level, large, loads of functionality

85 29 Drivers - Hw/Sw interface: VGA controller example (VII)

86 29 Drivers - Hw/Sw interface: VGA controller example (VII) 8bpp (4p/w) Easy to modify single pixels (Xio_Out8) by writing single bytes

87 29 Drivers - Hw/Sw interface: VGA controller example (VII) 8bpp (4p/w) Easy to modify single pixels (Xio_Out8) by writing single bytes 9bpp (3p/w) Single pixels: read, modify & write Exact address/offset computation more complex

88 29 Drivers - Hw/Sw interface: VGA controller example (VII) 8bpp (4p/w) Easy to modify single pixels (Xio_Out8) by writing single bytes 9bpp (3p/w) Single pixels: read, modify & write Exact address/offset computation more complex Packed 9bpp Even harder to compute the offset/address, build masks, access split pixels, etc.

89 30 Conclusions

90 30 Conclusions Trade-offs are very common (e.g. band-width vs. simplicity, Hw vs. Sw)

91 30 Conclusions Trade-offs are very common (e.g. band-width vs. simplicity, Hw vs. Sw) Hardware, software, and interfaces must be designed together

92 30 Conclusions Trade-offs are very common (e.g. band-width vs. simplicity, Hw vs. Sw) Hardware, software, and interfaces must be designed together Knowledge about the available components is essential