![1) Read and convert the JSON
into a dictionary
Template Engine
© Accellera Systems Initiative 10
def generate_template(data,templ_tb,gen_tb):
f=open(gen_tb,'w')
template=env.get_template(templ_tb)
sv=template.render(data)
f.write(sv)
f.close()
def main():
def converthex2dec(n,fmt=None):
return int(n,16)
env.filters['converthex2dec']=converthex2dec
parser = argparse.ArgumentParser(description='Template generator')
parser.add_argument('--cfg',"-f", action="store", dest="cfg",
help="specify the configuration file in JSON",default="platform.json")
parser.add_argument('--otb',"-o", action="store", dest="otb",
help="define the file name of the generated file")
parser.add_argument('--itb',"-i", action="store", dest="itb",
help="define the file name of the template file")
parser.add_argument('--extval',"-e", action="store", dest="extval",
help="pass value to the template file", default="0")
args = parser.parse_args()
cfg_h = open(os.path.join(PATH,".",args.cfg),"r")
data = json.load(cfg_h)
generate_template(data,args.itb,args.otb)
2) Read the input template and
create a template object
3) Render the template based
on the content of the dictionary
Example of user defined filter](https://image.slidesharecdn.com/webtemplatemechanismsinsocverification-dvcon-220729161829-2a686111/85/Web-Template-Mechanisms-in-SOC-Verification-DVCon-pdf-10-320.jpg)
Ad
More Related Content
Similar to Web Template Mechanisms in SOC Verification - DVCon.pdf (20)
More from SamHoney6 (14)
Ad
Recently uploaded (20)
![Halstead’s_Software_Science_&_Putnam’s_Model[1].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/halsteadssoftwarescienceputnamsmodel1-250502175814-4c85707e-thumbnail.jpg?width=560&fit=bounds)
Ad
Web Template Mechanisms in SOC Verification - DVCon.pdf
- 1. Web Template Mechanisms in SOC Verification Rinaldo Franco, Alberto Allara © Accellera Systems Initiative 1 STMicroelectronics, Digital & Mixed Processes Asic Division
- 2. • IPs & SoC verification environments are based on UVM- methodology – Advanced verification capabilities – Robust class libraries – Open, Interoperable – CAD Multi-vendor compatibility • Software Driven Verification for IPs & SoC – Development of SW tests running at bare metal without any OS – Low-level drivers to abstract hardware • Reusability during Top-Level verification • Reusability during silicon validation – Verification environment exposed on SW (VAL) • Use of Virtual Platform for the verification – An LVP (Lightweight Virtual Platform) instantiated with Dut (IP or SUBS) used to develop test that will be ported at SoC level 2 Key SOC Methodologies
- 3. The path to SOC verification © Accellera Systems Initiative 3 IP VIP Virtual Platform (LVP) SOC level Verification in simulation IP/SS level sw-driven verification MEM IP VIP IP VIP IP VIP SOC LVP enables the development of integration tests in a simplified environment (abstraction of SoC) IP Firmware, C tests and verification components are developed at LVP level and ported at SOC
- 4. Hide the differences • Main assumption of the path from LVP to SOC: – The scenario developed at LVP must be reusable at SOC • This implies that: • The differences in the SW layers and/or in the verification infrastructures are hidden to the test developer © Accellera Systems Initiative 4
- 5. Our Proposal • Keep the information and relevant data to distinguish platforms (the “model”) separated from a layer representing SW and HVL implementation of functionalities (the “view”) • In the Web application domain the technique is an architectural pattern known as MTV (Model- Template-View) – The data (“Model”) are separated from the way they are presented to the user (the “View” through “Template”) • The Template language used is a Python package called “Jinja2” © Accellera Systems Initiative 5
- 6. What is a Template Language? • The Template languages are tools used to simplify the dynamic generation of Web pages • Jinja2 is a modern and designer-friendly template language for Python – a Jinja2 template is a text file and can generate any text-based files as output – http://jinja.pocoo.org/docs/dev/ • A Jinja2 template contains variable and/or expressions, which get replaced with values coming from a context dictionary in Python during rendering © Accellera Systems Initiative 6
- 7. Example of Template mechanism <!DOCTYPE html> <html lang="en"> <head> <title>My Webpage</title> </head> <body> <ul id="navigation"> {% for item in navigation %} <li><a href="{{ item.href }}">{{ item.caption }}</a></li> {% endfor %} </ul> <h1>My Webpage</h1> {{ a_variable }} {# a comment #} </body> </html> © Accellera Systems Initiative 7 Unrolls the content based on the information of “navigation” variable Each item from navigation list include an href and a caption The content of variable is represented with {{ }} Supported tags are {% if %}, {%macro%}, {%filter%}, {% set %}, {%include%}, {% import %},..
- 8. Templates in the SOC context • Our proposal is to apply the Jinja2 template mechanism in the context of a SoC verification • The templates are used to generate a SW view and a HVL view in a consistent manner based on high level descriptions of a platform expressed in a JSON format © Accellera Systems Initiative 8
- 9. Why JSON? • JSON is a language independent open format using human-readable text. • The choice of using JSON w.r.t. other formats more common in the SOC context (e.g. XML) is due to a list of benefits: – Python comes with a standard library to easily convert a JSON file into a dictionary • Jinja2 uses the dictionary to directly render a Template – JSON is extremely more compact than XML, aspect that simplifies the insertion and the manipulation of data – Typically IPXACT data targets register map and pin-level connectivity not addressed by the platform description © Accellera Systems Initiative 9
- 10. 1) Read and convert the JSON into a dictionary Template Engine © Accellera Systems Initiative 10 def generate_template(data,templ_tb,gen_tb): f=open(gen_tb,'w') template=env.get_template(templ_tb) sv=template.render(data) f.write(sv) f.close() def main(): def converthex2dec(n,fmt=None): return int(n,16) env.filters['converthex2dec']=converthex2dec parser = argparse.ArgumentParser(description='Template generator') parser.add_argument('--cfg',"-f", action="store", dest="cfg", help="specify the configuration file in JSON",default="platform.json") parser.add_argument('--otb',"-o", action="store", dest="otb", help="define the file name of the generated file") parser.add_argument('--itb',"-i", action="store", dest="itb", help="define the file name of the template file") parser.add_argument('--extval',"-e", action="store", dest="extval", help="pass value to the template file", default="0") args = parser.parse_args() cfg_h = open(os.path.join(PATH,".",args.cfg),"r") data = json.load(cfg_h) generate_template(data,args.itb,args.otb) 2) Read the input template and create a template object 3) Render the template based on the content of the dictionary Example of user defined filter
- 11. Example of Template file 11 #ifndef _MEMORY_MAP_H_ #define _MEMORY_MAP_H_ /* ATTENTION this file is automatic generated! DO NOT MODIFY BY HAND! */ /* ESRAM MEMORY MAP */ {% for esram in platform.memory_map.esram %} #define {{ esram.name }}_BASE_ADDR 0x{{ esram.base_addr }} #define {{ esram.name }}_SOC_COMMON_BASE_ADDR 0x{{ esram.base_addr }} #define {{ esram.name }}_CUT_SIZE 0x{{ esram.cut_size }} {% for cut in range(esram.n_cut) %} {% if loop.first %} #define {{ esram.name }}_CUT{{ cut }}_BASE_ADDR {{ esram.name }}_BASE_ADDR {% else %} #define {{ esram.name }}_CUT{{ cut }}_BASE_ADDR ({{ esram.name }}_CUT{{ cut-1 }}_BASE_ADDR + {{ esram.name }}_CUT_SIZE) {% endif %} {% endfor %} {% endfor %} ... /* IPs MEMORY MAP */ {% for ip in platform.ip %} {% if (ip.n_instance > 1) %} {% for n_inst in range(ip.n_instance) %} {% if loop.first %} #define {{ ip.name.upper() }}_{{ n_inst }}_BASE_ADDR 0x{{ ip.base_addr }} {% else %} #define {{ ip.name.upper() }}_{{ n_inst }}_BASE_ADDR ({{ ip.name.upper() }}_{{ n_inst-1 }}_BASE_ADDR + 0x{{ ip.instance_offset }}) {% endif%} {% endfor %} {% else %} #define {{ ip.name.upper() }}_BASE_ADDR 0x{{ ip.base_addr }} {% endif%} {% endfor %} #endif // _MEMORY_MAP_H_
- 12. Template flow applied to a SOC © Accellera Systems Initiative 12 verif fw Ip vip project <IP> include scatter tb test Soc common hvl project <IP> db sv sim vips aux templates Template Engine .h,.c,.scatter systemverilog Makefiles Platform.json
- 13. Template flow applied to a SOC (2) © Accellera Systems Initiative 13 verif fw Ip vip project <IP> include scatter tb test soc common hvl project <IP> db sv sim vips aux templates Template Engine Each <IP> identify a platform, includes information regarding the register map description of the component, the low- level drivers in C and the platform- independent integration tests in C Common c-code used by all the platform C environment
- 14. Template flow applied to a SOC (3) © Accellera Systems Initiative 14 verif fw Ip vip project <IP> include scatter tb test soc common hvl project <IP> db sv sim vips aux templates Template Engine Contains for each VAL backend the “virtual” description of the register map and their APIs Contains a set of “platform” elements. Each platform is matched with the SW view Contains the UVM code of the VAL backend. Each component matches the SW view Contains for each Ip, the description of the register map, the low-level driver and platform independent test
- 15. Platform Description File Format • The platform description file is characterized by the following structure of information: – Details on IPs (e.g. base address, INT lines, DMA lines,..) – Static RAM and Memory regions – Testbench details with information regarding: • Clocks • Resets • Timers • VAL front-ends each them connecting a set of UVM env © Accellera Systems Initiative 15
- 16. Platform at LVP level 16 IP info VAL backend VAL backend UVM Env Clocks/Resets/Timers At LVP only one VAL FE is available. The VAL FE include a single UVM env containing one or more VAL back end components Define clocks, resets and timers that are generated at LVP level through dedicated VAL components VAL FE ESRAMs Regions Define the esram for the LVP Define other memory regions Define an IP at LVP (usually only 1) TB
- 17. Platform at SOC level 17 Clocks/Resets/Timers VAL FE ESRAMs Regions TB VAL FE UVM Env IP info IP info IP info At SOC level the platform is a set of IPs Define the esram for the LVP Define other memory regions Clocks, resets and Timers are features of the SOC and not of the TB. Their information are used to pre-generate the related FW UVM Env UVM Env The platform contains a set of UVM env, one for each IP/SS. Each UVM env is directly connected to a VAL FE and internally it takes care of managing the VIPs needed for the verification of the associated IP. More than one VAL FE is possible
- 18. Conclusions • The Web Template Mechanism allow to separate the data (Platform configuration file) from the way they are used in the layers representing SW implementation of functionalities (c-code) and HDL verification infrastructures (System Verilog – UVM). • The Platform configuration file contains high level descriptions of the scenario developed at LVP that can be reusable at SOC level, hiding differences to the test developer and reducing porting overhead. © Accellera Systems Initiative 24