Changes between Version 10 and Version 11 of DsxDocumentation
- Timestamp:
- Jan 28, 2008, 6:35:17 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DsxDocumentation
v10 v11 81 81 footprint is reduced, at the cost of loosing the POSIX compatibility. 82 82 83 == C) Defining the software application ==83 == C) Software application definition == 84 84 85 85 This section describes the DSX/L syntax used to define the Task & Communication Graph structure. … … 96 96 As a software application can instanciate several instances of the same task, we must distinguish the task, and the task model. A task model defines the code associated to the task, and the task interface (corresponding to the system resources used by the task : MWMR communications channels, synchronization barriers, locks, and memspaces). 97 97 {{{ 98 Task_Model = TaskModel( 'model_name',98 task_model = TaskModel( 'model_name', 99 99 infifos = [ 'inport_name', ... ] , 100 100 outfifos = [ 'outport_name', ... ] , … … 122 122 For performances reasons the channel ''width'' itself must be a multiple of 4 bytes. 123 123 {{{ 124 My_Channel = Mwmr( 'channel_name', width, depth )124 my_channel = Mwmr( 'channel_name', width, depth ) 125 125 }}} 126 126 In the mapping section of the DSX/L program, the 4 following software objects must be placed : … … 136 136 is defined when the the tasks are intanciated. Exclusive access to the barrier is protected by an implicit lock. 137 137 {{{ 138 My_Barrier = Barrier( 'barrier_name' )138 my_barrier = Barrier( 'barrier_name' ) 139 139 }}} 140 140 In the mapping section of the DSX/L program, the 3 following software objects must be placed : … … 149 149 the number of bytes to be reserved. 150 150 {{{ 151 My_Shared_Buffer = Memspave( ''memspace_name', size )151 my_buffer = Memspace( ''buiffer_name', size ) 152 152 }}} 153 153 In the mapping section of the DSX/L program, the 2 following software objects must be placed : … … 161 161 has been obtained. 162 162 {{{ 163 My_Lock = Lock( 'lock_name' )163 my_lock = Lock( 'lock_name' ) 164 164 }}} 165 165 In the mapping section of the DSX/L program, the lock can be explicitely placed in the memory space. … … 170 170 ''Task_Model'' (created by the TaskModel() function), and a list of resources (MWMR channels, synchronization barriers, locks or memspaces), that must be associated to the task ports. DSX performs type checking between the port name and the associated resource. 171 171 {{{ 172 My_Task = Task( 'task_name',173 Task_Model ,174 portmap = { 'port_name' : My_Channel, 'barrier_name' : My_Barrier, ... } )172 my_task = Task( 'task_name', 173 task_model , 174 portmap = { 'port_name' : my_channel, 'barrier_name' : my_barrier, ... } ) 175 175 }}} 176 176 In the mapping section of the DSX/L program, 4 software objects must be placed : … … 184 184 The Task and Communication Graph must be defined : 185 185 {{{ 186 My_Tcg = Tcg(186 my_tcg = Tcg( 187 187 Task( 'task_name1, 188 188 Task_Model1, … … 194 194 }}} 195 195 196 == D) Defining the hardware architecture==196 == D) Hardware architecture definition == 197 197 198 198 This section describes the DSX/L syntax used to define the MP-SoC hardware architecture, 199 199 using the hardware components defined in the SoCLib library. 200 200 201 === D1) SoCLib components definition===201 === D1) SoCLib components === 202 202 203 203 In the present version of DSX, each hardware component must be described by a PYTHON … … 207 207 {{{ 208 208 # creation of a MIPS R3000 processor core 209 My_Proc = Mips( 'proc' )209 my_proc = Mips( 'proc' ) 210 210 211 211 # creation of a cache controler 212 My_Cache = Xcache( 'cache',212 my_Cache = Xcache( 'cache', 213 213 dcache_lines = 32, 214 214 dcache_words = 8, … … 220 220 221 221 Hardware components have input/output ports, and are connected through signals, 222 but those signals are implicit in the DSX/L description. To connect the port a of component c1 to the port b of component c2, DSX/L define the // operator :222 but those signals are implicit in the DSX/L description. To connect the port '''a''' of component '''c1''' to the port '''b''' of component '''c2''', DSX/L define the // operator : 223 223 {{{ 224 224 c1.a // c2.b … … 230 230 {{{ 231 231 # components instanciacion 232 My_Proc0 = Mips( 'proc0' )233 My_Cache0 = Xcache( 'cache0' )234 My_Proc1 = Mips( 'proc1' )235 My_Cache1 = Xcache( 'cache1' )236 My_Ram = MultiRam( 'ram' )237 My_Crossbar = LocalCrossbar( 'crossbar' )232 my_Proc0 = Mips( 'proc0' ) 233 my_Cache0 = Xcache( 'cache0' ) 234 my_Proc1 = Mips( 'proc1' ) 235 my_Cache1 = Xcache( 'cache1' ) 236 my_Ram = MultiRam( 'ram' ) 237 my_Crossbar = LocalCrossbar( 'crossbar' ) 238 238 239 239 # components connexion 240 My_Proc0.cache // My_Cache0.cache 241 My_Proc1.cache // My_Cache1.cache 242 My_Crossbar.getTarget() // My_cache0.vci 243 My_Crossbar.getTarget() // My_cache1.vci 244 My_Crossbar.getInitiator() // My_cache0.vci 245 246 240 my_proc0.cache // my_cache0.cache 241 my_proc1.cache // my_cache1.cache 242 my_crossbar.getTarget() // my_cache0.vci 243 my_crossbar.getTarget() // my_cache1.vci 244 my_crossbar.getInitiator() // my_cache0.vci 247 245 }}} 248 246 }}} … … 250 248 === D3) Address space segmentation === 251 249 250 All hardware components defining the hardware architecture should be grouped in a single object. 251 As any MP-SoC architecture build with the SoCLib library uses a VCI interconnect hardware component, 252 this component must be declared as the ''root'' of the architecture : 253 {{{ 254 my_architecture = Hardware( vgmn ) 255 }}} 256 257 In any shared memory architecture, the address space is a shared resource. This resource is structured in several segments. A segment has a name, a base address, a size 258 (number of bytes), and a cacheability attribut (Boolean). A segment is a physical entity associated to a 259 given VCI target. Several segments can be associated to the same VCI target, but a given segment cannot be distributed over several VCI targets. 260 261 The DSX/L language allows the system designer to define the various segments used by a given application, 262 and to link those segments to the hardware components. 263 The base address and the segment size are optional parameters : 264 {{{ 265 # segments definition 266 seg_data1 = Segment( 'seg1', Cached ) 267 seg_data2 = Segment( 'seg2', Uncached ) 268 seg_reset = Segment( 'reset', Cached, addr = 0xBFC00000 ) 269 270 # Instanciating a VCI target hardware component 271 # and Linking the segments to this component 272 my_ram = MultiRam ( 'ram', seg_data1, seg_data2, seg_reset ) 273 }}} 274 275 As a segment is defined by the MSB bits of the VCI address, the hardware interconnect must decode those MSB bits to select the proper VCI target. The corresponding decoder is generally implemented as a ROM. Those hardware decoders are automatically constructed using the '''Mapping Table'''. The mapping table is 276 an associative table. Each entry corresponds to a physical segment. This object must be constructed, and initialised: 277 {{{ 278 # mapping table construction 279 my_mt = MappingTable() 280 # mapping table initialisation 281 my_hardware.setConfig( 'maptab', my_mt ) 282 }}} 283 284 252 285 === D4) Hardware architecture definition === 253 286 287 254 288 === D5) Mapping table === 255 289