[aadl]: Modelling best practices

dominique.blouin dominique.blouin at univ-ubs.fr
Wed Nov 2 09:22:38 EDT 2011 

Hi Julien,

Here is some concrete example using AADL V1 :-( .

The first layer (highest genericity) captures the fact that a FPGA 
always contain a configurable component (conf_space) and that there is a 
data port of type "Bitstream" to transfer the FPGA configuration data. 
We also provide specific types for components that are synthesizable in 
the FPGA configurable component (not shown here).

/system Generic_FPGA/
/    features/
/      icap_port: in data port FPGA_Bitstream.impl;/
/  end Generic_FPGA;/
//
/ system FPGA_Conf_Space/
/    features/
/      icap_port: in data port FPGA_Bitstream.impl;/
/      bus_access: provides bus access FPGA_Bus.impl;/
/  end FPGA_Conf_Space;/
//
/system implementation Generic_FPGA.impl/
/    subcomponents/
/      conf_space: system;/
/  end Generic_FPGA.impl;/

At the next refinement level, the generic FPGA component is extended to 
provide a description for a specific FPGA model (/XC5VFX100T /in this 
case, but there could also be in-between layers to define a product 
family). This provides a description of the components that are also 
included in the FPGA such as PowerPC processors besides the configurable 
component.

/  system implementation XC5VFX100T_FPGA.impl
     extends generic_fpga::Generic_FPGA.impl
     subcomponents
       powerPC_0: processor PowerPC440.impl;
       powerPC_1: processor PowerPC440.impl;
       ethernet_ctrl: device Ethernet_Ctrl.impl;
       sysACE_ctrl: device SysACE_Ctrl.impl;
       -- Still needs to refine it otherwise error when refining the 
extended
       conf_space: refined to system;
     properties
       Power_Properties::Power_Avg_Max_Supported => 5.5 W;
   end XC5VFX100T_FPGA.impl;

/The generic configurable component is also redefined at this level to 
specify its features and the amount of available resources for 
configuration such as the number of memory and logical element basic blocks.
/
system XC5VFX100T_Conf_Space
     extends generic_fpga::FPGA_Conf_Space
     features
       icap_port: refined to in data port XC5VFX100T_Bitstream.impl;
       bus_access: refined to provides bus access XC5VFX100T_Bus.PLB;
       bus_access1: provides bus access XC5VFX100T_Bus.PLB;
       busAccPPC0_inst: provides bus access XC5VFX100T_Bus.PLB;
       busAccPPC0_data: provides bus access XC5VFX100T_Bus.PLB;
...
     properties
       FPGA_Properties::FPGA_Surface => 102400 cle;
   end XC5VFX100T_Conf_Space;
/
The next layer actually provides the configuration of the configurable 
component, using modes to model dynamic reconfiguration.

/  system implementation XC5VFX100T_Conf_Space_Conf.impl
     extends xc5vfx100t::XC5VFX100T_Conf_Space.impl
     subcomponents
       bram_memory: memory xc5vfx100t::BRAM.impl;
       plb_bus: bus xc5vfx100t::XC5VFX100T_Bus.PLB;
       opb_bus: bus xc5vfx100t::XC5VFX100T_Bus.OPB;
       ip_block_1: processor IP_Block.impl_1 in modes (all_ip_blocks_on, 
ip_block_1_on, ip_block_1_3_on, ip_block_1_2_on);
       ip_block_2: processor IP_Block.impl_2 in modes (all_ip_blocks_on, 
ip_block_2_on, ip_block_2_3_on, ip_block_1_2_on);
       ip_block_3: processor IP_Block.impl_3 in modes (all_ip_blocks_on, 
ip_block_3_on, ip_block_2_3_on, ip_block_1_3_on);
     connections
       bus access plb_bus -> bram_memory.Bus_Access;
       bus access plb_bus -> ip_block_1.bus_access in modes 
(all_ip_blocks_on, ip_block_1_on, ip_block_1_3_on, ip_block_1_2_on);
       bus access plb_bus -> ip_block_2.bus_access in modes 
(all_ip_blocks_on, ip_block_2_on, ip_block_2_3_on, ip_block_1_2_on);
       bus access plb_bus -> ip_block_3.bus_access in modes 
(all_ip_blocks_on, ip_block_3_on, ip_block_2_3_on, ip_block_1_3_on);
...
     modes
       no_ip_blocks_on: initial mode ;
       ip_block_3_on: mode ;
...
   end XC5VFX100T_Conf_Space_Conf.impl;
/
The FPGA is again extended and the configurable component is refined to 
the specific classifier presented above.

/  system implementation XC5VFX100T_FPGA_Configured.impl
     extends xc5vfx100t::XC5VFX100T_FPGA.impl
     subcomponents
       conf_space: refined to system XC5VFX100T_Conf_Space_Conf.impl;
     connections
       data port icap_port -> conf_space.icap_port;
       event port ip_block_on_to_ip_block_off -> 
conf_space.ip_block_on_to_ip_block_off;
       event port ip_block_off_to_ip_block_on -> 
conf_space.ip_block_off_to_ip_block_on;
   end XC5VFX100T_FPGA_Configured.impl;
/
The advantage of this approach is a clear separation of what is known at 
each layer so that analyses can be performed on the component of the 
proper layer containing the information needed for the analysis. Also, 
once a model library has been created for a given FPGA platform, it can 
be made read only and reuse with distinct configurable component 
configurations over which design space exploration can be performed.

If you need more details, the sources of this example are provided with 
the requirements tool that was used to define a number of non-functional 
requirements on configurable component resources, power consumption, etc.

Cheers,

D.

Le 01/11/2011 09:45, julien.delange at esa.int a écrit :
> Dear Dominique,
>
> Thanks for your answer. Unfortunately, it is difficult to retrieve in such
> a big paper the example that would really highlight the modelling pattern.
> Would it be possible to give a simple example of your modelling pattern ?
> Just with one or two components that show exactly what workaround you used
> ?
>
> Thanks again for your feedback,
>
>
>
>
>
> From:
> "dominique.blouin"<dominique.blouin at univ-ubs.fr>
> To:
> julien.delange at esa.int
> Cc:
> sae-aadl-users at lists.sei.cmu.edu
> Date:
> 31/10/2011 19:55
> Subject:
> Re: [aadl]: Modelling best practices
>
>
>
> Hi Julien,
>
> We have worked on a similar approach for modeling FPGA components with
> AADL. We use three layers of extension according to different genericity
> levels, using the AADL extend and refined to mechanisms. Basically, the
> first level is very generic and captures the fact that every FPGA may
> contain static (or built-in) components and a configurable component.
> The second level, defines the actual static components for a specific
> platform (e.g.: Xilinx Virtex ...). The third level captures the actual
> synthesized design of the configurable component.
>
> More info is available here:
> http://www.hindawi.com/journals/ijrc/2011/425401/. Hope this helps,
>
> D.
>
> Le 31/10/2011 14:57, julien.delange at esa.int a écrit :
>> Dear all,
>>
>> I am currently using AADL to capture a system architecture. It is
> composed
>> of many heterogeneous components.Then, I am wondering about the best
>> modelling patterns and I think this could interest different persons on
>> this list. The thing is that for some components, there is only few
>> variability but they share a lot of common properties/requirements.
>> For example, imagine a monitoring system with camera and an audio
>> recorder. These devices have some properties and constraints and are
>> connected to a network using a 100M ethernet link. The vendor also has
> the
>> SAME devices but with a wireless link.
>>
>> So, one approach would be to first model generic components like
>>
>> device generic_camera
>> properties
>>       ....
>> end generic_camera;
>>
>> device generic_recorder
>> properties
>>       ....
>> end generic_recorder;
>>
>> And then, create new device components that extend the generic one.
>>
>> device camera_eth extends generic_camera
>> features
>>      link : requires bus access ethernet_bus;
>> end camera_eth;
>>
>> device camera_wifi extends generic_camera
>> features
>>      link : requires bus access wifi_bus;
>> end camera_wifi;
>>
>> device recorder_eth extends generic_recorder
>> features
>>      link : requires bus access ethernet_bus;
>> end recorder_eth;
>>
>> device recorder_wifi extends generic_camera
>> features
>>      link : requires bus access wifi_bus;
>> end recorder_wifi;
>>
>>
>> But on the other hand, it forces to redeclare the features access while
> it
>> could be declared only in one generic component and then, be inherited.
>>
>> So, we could add
>> device generic_eth
>> features
>>      link : requires bus access ethernet_bus
>> end generic_eth;
>>
>> And then, if we have multiple inheritance, one would be able to write
>> device camera_ethernet extends generic_camera, generic_eth
>> end camera_ethernet;
>>
>> This would ensure that devices using the same network have the same
>> properties each other. Otherwise, network-related properties and
>> requirements must be duplicated, which could be error-prone. On the
> other
>> hand, adding multiple inheritance would raise new issues.
>>
>> So, I'm wondering what are the best practices to model such components
>> with few variability. I'm quite sure that some AADL users already face
>> such issues and so, having a feedback about existing experience would be
>> nice ! On the other hand, I hope this could be useful for other people
> and
>> then, show some useful modelling patterns !
>>
>> Thanks for any comment/suggestion,

-- 
Dominique BLOUIN

Ingénieur de Recherche / Research Engineer

Université de Bretagne Sud
Lab-STICC / CNRS UMR 3192

Centre de Recherches
BP92116 / 56321 LORIENT Cedex
Tel:0297874616 / Fax:0297874527

http://www.labsticc.fr/

-------------- next part --------------
HTML attachment scrubbed and removed

More information about the Sae-aadl-users mailing list