https://community.cadence.com/search?q=*%3A*&category=blog&users=50026&sort=date%20desc&Redirected=trueen-USTelligent Community 12en-usnoSearch results for '*:*' by user ID 50026https://community.cadence.com/cadence_blogs_8/b/fv/posts/creating-systemc-tlm-2-0-peripheral-modelsThu, 14 Jul 2011 16:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1286033TeamESL/cadence_blogs_8/b/fv/posts/creating-systemc-tlm-2-0-peripheral-models2Over two years ago, I made some experiments and raised some requirements for an effective Virtual Platform IP authoring tool. Even with the passage of time, some people seem to find it useful as I regularly get questions about it. It is more than time to give you an update, and the good news is that such a tool is now available as part of the new Cadence Virtual System Platform (VSP) product. One of the capabilities provided by the Virtual System Platform is a tool to enable easy authoring of Virtual Platform IP models. Virtual Platform IP Authoring Requirements One of the major challenges with peripheral IP authoring is to model and manage registers. Some IP may include tens of thousands of registers and hundreds of thousands of register fields, which can represent 80% to 90% of the model code. In addition, the IP developer may have to create multiple implementations of the model, each at different abstraction levels such as a TLM-2.0 model (LT and AT), a TLM synthesizable model or an RTL model. All of these representations are likely to share the same set of registers, hence the need to have a unique, golden reference of the model registers from which the implementation models can be derived. For tool and IP interoperability reasons, this golden reference should be compliant to an existing standard. Hence the idea to use the IP-XACT ( IEEE 1685 ) as the golden model to represent registers. For more details on IP-XACT for TLM refer to a recent Industry Insights article by Richard Goering. IP-XACT supports all the major requirements for modelling IP register and memory banks. Its XML structure eases the processing of the metadata and the automation of the implementation code at various abstraction levels. SystemC Virtual Platform IP models are just one specific use case of IP-XACT, but it's interesting to look into the details of the specific requirements for SystemC IP model creation. TLM-2.0 defines the main infrastructure for IP interoperability, but one thing it lacks is a standard representation of registers. Until a standard register representation becomes available the Virtual System Platform provides a class called sc_register. Overview of tlmgen The Virtual System Platform includes a TLM Generator, called tlmgen , that saves time and coding effort by automating the generation of SystemC TLM code, mainly for defining and accessing the registers, both from the bus and from the internal behavior of the model. In addition tlmgen provides the following: Automatic generation of a SystemC testbench (implementing all the appropriate read and write sanity checks for each register) and a simple system connecting the testbench to the SystemC model Automatic generation of a C testbench (implementing all the appropriate read and write sanity checks for each register) to be executed on a processor running as part of a virtual platform Automatic generation of a build script to generate a shared library for this IP (to be linked by the platform integrator instantiating this IP) The tlmgen solution is fully open. Not only you can get all of the above from an IP-XACT standard description, but the SystemC code that's generated relies on a SystemC register class delivered as source code to all Virtual System Platform users. It can therefore simulate on the OSCI simulator, but if you use Virtual System Platform to simulate and debug your code, you will be able to visualize the register descriptions and content at runtime. Hands On Let's put our hands on the keyboard, and check how much code can be automatically generated and check how useful and how easy to update and maintain the code is. For this article, I propose to create a SystemC TLM-2.0 un-timed model for the PL011 UART , starting from the same ARM specification I used in my previous experiment. Modelling the Registers The first step is to capture the registers. Virtual System Platform offers two options: A simple Cadence proprietary format named Register Description Format (RDF) An IP-XACT component XML description The Cadence RDF format is a simple ASCII file, with a very simple grammar to describe each register and its fields and to describe a bank of registers with the base address for each. Below is an example of a register bank for for the UART. Each register in the register bank also has a description. Below shows the description of the UART data register. One of the inputs for tlmgen is the specification of callback hooks in the register input format. These hooks are called PREAMBLE and POSTAMBLE. They indicate to the code generator that the user may want to add a specific functionality before and/or after a register access. For example, when writing to the DR register, the model should also write to TX field of the RIS register. In IP-XACT format the PREAMBLE and POSTAMBLE hooks are defined as register vendor extensions.You can see the example of postamble = RW in the picture above for the UART Data Register. Below is an IP-XACT representation showing the vspExtensions and the equivalent POSTAMBLE for the UART Data Register. Another nice feature of tlmgen is the ability to generate IP-XACT output from an RDF input file, thus letting the user start with a simple text register description format and automate the translation to the verbose IP-XACT XML format. This IP-XACT output can then be used later for platform assembly. Generating the SystemC TLM model This step can be mostly automated by the execution of tlmgen to take an IP-XACT (or RDF) input and generate the SystemC TLM output. The SystemC code generated includes a SystemC module skeleton that you can modify to add the specific functionality. This skeleton already includes the definition and implementation of registers, target socket, tlm transport methods and registers access functions. Creating the HW IP is a two-step process: 1) Run the command: % tlmgen -name uartPL011 -rdf uart_registers.rdl -simple Or for IP-XACT input: % tlmgen -name uartPL011 -ipxact uart_registers.xml -simple This generates about 80% of the code for the UART. It includes the SystemC TLM-2.0 module skeleton for the model of the UART which derives from an automatically generated base class with all the registers defined, the target socket to access them and the implementation of the transport methods to access these registers. 2) Update the generated HW template code to match the UART behavior. Once the base model is generated it's up to the model creator to add processes, add extra ports, and add the functionality inside the pre- and post-register access virtual methods. This completes the model functionality. The advantage of using tlmgen is not only that you save writing code (and writing errors), but also that all the registers can be visualized at runtime. Below is the register viewer which provides the values at runtime by automatically recognizing the sc_register class. This is very helpful for software engineers who spend much of their time reading, writing, shifting, ANDing, and ORing register bits to make the hardware do what it is supposed to do. ECO Support One of the issues with code generation from a golden source is the ability to manage (not lose) user modifications when the golden source needs to be modified. Let's assume one of the bit fields of the register of our UART IP needs to be modified. How should we propagate this change to the generated code? tlmgen solves this problem by generating a hierarchy of classes and virtual methods where the user functional code is localized in the top-most inherited class. Whenever a change occurs in the golden register representation (RDF or IP-XACT), all of the base classes can be re-generated without loosing the user code. Moreover, most if the time, the user code does not need to change or needs very little and localized modification to include the new register change. Such an inheritance hierarchy of classes and virtual methods allow the user functional code to be localized, hence allowing reuse if the user code when the base classes have to be re-generated. The flexibility of tlmgen also allows the user to choose the type of target interface generated depending on its usage. It could be a TLM-2.0 simple socket or multi passthrough socket or it could be a TLM-1.0 sc_export. In the tlmgen usage example above, the -simple option specifies a TLM-2.0 simple target socket. Packaging the Virtual Platform IP Model Like any other IP, a virtual platform IP needs to be packaged to be delivered to other internal or external groups. Such a package should be self-contained, versioned, and easy to plug into a system and easy to verify. The IP should therefore be delivered as a kit including hardware verification, software verification, APIs, documentation, and scripts. Next Steps You have now an effective, standard, and reusable solution to ease the modeling and validation of TLM-2.0 peripheral IP using tlmgen from VSP. Many models created using tlmgen have been integrated in various Virtual Platforms. It has proven to not only save a lot if development time but it also significantly helps the platform creator and the embedded software developer to debug and fine tune their hardware and software models. It overcomes the blank page syndrome when it's time to create a new model and provides much of the needed structure and checking to help users learn TLM-2.0 very quickly. The good news is that it doesn't try to hide the details of TLM-2.0 from the user, but instead generates clean code that users can learn from. So what else is needed to help the Virtual Platform Model creator's life? More complex register specification should be supported. Some are already supported by IP-XACT, others need extensions to the standard, such as preamble and postamble, conditional registers, dependant registers. These are all being considered as IP-XACT enhancements within Accellera Working Groups. As with any automation there is always more code that can be automatically generated such as multiple target sockets (and multiple memory maps), initiator sockets, and reset or interrupt behaviour by further using the information recorded in IP-XACT. Jean-Michel This Team ESL article is provided by Jean-Michel Fernandez, Archtect for System Solutions. Jean-Michel has actively contributed to the definition of the TLM and IP-XACT standards.https://community.cadence.com/cadence_blogs_8/b/fv/posts/more-details-on-post-silicon-embedded-software-verification-with-isxTue, 18 Aug 2009 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:20190TeamESL/cadence_blogs_8/b/fv/posts/more-details-on-post-silicon-embedded-software-verification-with-isx1Please welcome back Joerg Simon and Markus Winterholer, both from the ISX team in Germany, to the TeamESL blog for the next installment on post-silicon embedded software verification with ISX. This post is a discussion featuring Markus and Joerg talking to Malte Henzelmann and Ernst Zwingenberger of El Camino GmbH . It builds on the introduction that was provided in June titled OVM Metric Driven Verification with an FPGA-based Design . You guys built a cool demo connecting ISX to a FPGA board for post-silicon software verification. Congratulations on getting this set up and working. Why did you want to build a system like this? In various projects where we were using ISX for HW/SW co-verification it turned out that the coverage driven verification approach is very powerful for SW verification as well. Due to our expertise in both worlds, FPGA and Coverage Driven Verification, we already liked the idea of bringing both worlds together. Finally, a customer request was the impetus to do it. This project sounds like a lot of fun. Tell us something about yourselves and your background. Malte was working as scientific assistant from 2001 to 2006 doing research in the area of formal verification, particularly abstraction techniques. Since 2007 he has been a verification engineer at El Camino doing verification of a display controller and a PCIe to AXI bridge with Specman and Incisive Formal Verifier. He also worked on the test utilization of ISX in combination with a FPGA board. Ernst is currently head of verification at El Camino. From 2004 to 2006 Ernst was System-On-Chip Verification Engineer responsible for Coverage Driven Verification Methodology and Verification Concepts at Micronas GmbH in Munich. Prior to that, he was a Verification Consulting Engineer at El Camino focused on Coverage Driven Verification and design of reusable Verification Components. You have been working for El Camino as Cadence Verification Alliance Partner for many years. What are the main areas you are working on? The main areas of focus for El Camino are engineering and verification services around FPGA, ASIC, and Embedded Systems/Software as well as board layout. Tell us more details about the Altera board (CPU types, max. design size) One of the really cool characteristics of this interface is the fact that it uses the standard JTAG port together with the standard Altera download hardware. This means that virtually every Altera based FPGA board can be used. Also in terms of CPU types there’s no real limitation. All that needs to be done is to instantiate a special on-chip dual-port memory function from El Camino. One port is automatically connected to the JTAG interface of the FPGA while the other port has to be connected to the CPU. This can be setup on off-the-shelf FPGA boards but also on application specific platforms. The biggest FPGA that’s currently available from Altera is the EP4SGX530, which has 530,000 Logic Elements, plenty of room for complex, embedded systems. What tools did you use in your verification flow? Altera Nios ® II Embedded Design Suite (EDS) Altera Quartus ® II Design Software Cadence Incisive Enterprise Specman Elite Testbench with the Enterprise System-Level (ESL) Option What about visibility of the hardware and debug options? Internal hardware nodes are visible through Altera’s SignalTap embedded Logic Analyzer. Furthermore there’s SignalProbe which allows us to route individual nodes to test pins or the Logic Analyzer Interface, which allows the multiplexing of internal groups of signals to a set of test pins. The software debugging options depend on the CPU used. For example, there’s the μVision Debugger for the ARM Cortex-M1 or the GNU based NIOS II IDE debugger or for the NIOS II CPU. Such debuggers can simultaneously use the very same JTAG Interface and download hardware as ISX in order to control the CPU. What group of users are you targeting for ISX on the Altera FPGA Board? We’re targeting engineers verifying a System-on-Chip design or some IP modules integrated as a HW/SW package. Also, embedded software developers could use ISX on an FPGA board to apply coverage driven verification to their software. What is the ideal use model for your post silicon verification solution? Nowadays SoCs or IP modules always require a significant amount of software drivers or protocol stacks. We believe that high quality SoC and IP module (HW+SW) packages are perfect candidates. Are you able to reuse the pre-silicon testbench? Yes, the software e Verification Component (eVC) can be used throughout the whole verification flow. Starting with Virtual Platforms, RTL simulation/acceleration and finally on the FPGA board. With ISX you can run your software encapsulated in an eVC on all of these representations of the hardware. Thank you for your time and thank you to all the readers out there on cadence.com. Jason Andrewshttps://community.cadence.com/cadence_blogs_8/b/fv/posts/a-classification-of-esl-_2d00_-high-level-synthesis-toolsThu, 06 Aug 2009 15:47:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:19898TeamESL/cadence_blogs_8/b/fv/posts/a-classification-of-esl-_2d00_-high-level-synthesis-tools0These days, there is a lot of talk of what the next design methodology for Digital Systems will be and how this methodology will be the replacement of RTL Synthesis. The term ESL (Electronic System Level) is used as a general term for the new wave of modeling and synthesis for digital systems. We have noticed that the term ESL is a very different concept for different people. It might mean a modeling approach, a design approach or a combination of both. In this blog we are not attempting to define what ESL is, but we are trying to provide a brief classification of the different types of ESL / High Level Synthesis tools. Before, we attempt to classify the different types of ESL / High Level Synthesis tools, let us, for the purpose of this blog, define an ESL / High Level Synthesis tool as follows: “An ESL / High Level Synthesis Tool is a software tool that takes a high level description of a digital system and transforms this description into an RTL (Register Transfer Language) description in a language such as VHDL or Verilog.” Additionally “The RTL description synthesized by the ESL / High Level Synthesis tool must be synthesizable into a gate level netlist by an RTL Synthesis tool such as Cadence’s RC”. Currently, there are three kinds of ESL Synthesis tools being marketed as follows: The first kind are tools which take a graphical / data-flow description of the system and usually translate this description into “structural RTL” (a netlist of synthesizable block instances) which have been originally written in a parameterizable way. The second kind are tools which take a single threaded computer programming language (usually C or C++ without support for threads) and translate this description into either a single synthesizable RTL block or into a structural pipeline of RTL blocks. The thrid kind are tools which take a multi-threaded computer programming language (usually SystemC ) and translate this description into a “structural RTL” description which can be an arbitrary netlist of synchronous state machines. Cadence’s C-to-Silicon Compiler is an example of the third kind of ESL / High Level Synthesis tools. As said before, the basic characteristic of this kind of tools is support of multiple threads in a similar fashion that support for multiple processes (threads) is an inherent characteristic of RTL based synthesis tools and Hardware Description Languages. Supporting multiple threads brings the following advantages: Support of multiple clock environment in a similar way that RTL synthesis tools support multiple clocks. Support of multiple concurrently executing blocks in a similar way that RTL synthesis tools support multiple processes (always blocks in Verilog or Process block in VHDL). Support of multiple instances in a similar way that RTL synthesis tools support “structural” code. Support of reactive blocks. This is usually not possible single threaded approaches. Support of feedback loops. This is usually not possible, or difficult to implement in single threaded approaches. Support of control structures. This is not usually possible in single threaded approaches or in graphics based approaches. Support of non-sample based interfaces. Burst transfers and other type of interfaces usually require the implementation of reactive blocks such as DMAs. This is not possible in single threaded environments. Support of Mealy style state machines. Mealy type state machines usually require two threads (one for the combinational logic and one for the registers), therefore they cannot be implemented in a single threaded environment. Support of non-blocking constructs. All statements in a single threaded environment are blocking. These advantages are what makes the third kind of ESL / High Level Synthesis tools the only viable alternative to RTL synthesis. Single threaded environments or graphics based data flow entry tools cannot, and probably never will, be able to describe a complete digital system as it is currently done with RTL based tools This Team ESL posting is provided by Dr. Sergio Ramirez, Core Comp Architect for the C-to-Silicon Compiler high level synthesis product.https://community.cadence.com/cadence_blogs_8/b/fv/posts/full-system-vs-sub-system-virtual-prototypingThu, 06 Aug 2009 15:45:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:19897TeamESL/cadence_blogs_8/b/fv/posts/full-system-vs-sub-system-virtual-prototyping0There is a strong movement in the industry to move to create Virtual Prototypes of systems, prior to RTL coding. These Virtual Prototypes are being used for early software development and architectural analysis. Since there are typically many blocks in a design, the development of a Virtual Prototype can be unwieldy. While you might have a goal of creating one, you may be dazed at the number of components that need to be created or acquired (multiple CPU's, DSP's, MPEG engines, multiple memory sub-systems, DMA's, etc.). Companies are realizing that they can successfully achieve productivity gains y working with sub-systems instead of full systems. After all, this is how many high-level design and verification tasks are done today (ie sub-system simulation on emulators, sub-system c models created for reference models, etc.). But what is the difference between a sub-system and a full system? A sub-system generally is a well defined entity in your design. There are CPU sub-systems, memory sub-systems, disk sub-systems, etc. This systems are very complex in their own right and usually contain some form of processing unit (CPU, DSP, micro-controller, etc.). Below is a table that suggests some characteristics of a a sub-system vs a full-system: The first advantage to creating a sub-system is that there are a smaller number of blocks to create or acquire. Looking at the table, you can see there are other advantages. Typically minimum performance requirements are lower then a full system. That is because lower level software is being executed, meaning less instructions, allowing reasonable simulation speeds will lower performance. Secondly, you will probably model sub-systems that you are most concerned about, which are the ones that you are creating. Therefore most of the models will be created rather then acquired. If you are using a TLM Driven flow (in which TLM models are the golden source for synthesis), then the TLM models for the platform need to be created anyway. If you aren't, then you should look at the productivity that such a flow provides. Full system Virtual Platforms provide the ability to exercise complete functionality of a system. Creating one can take time in acquiring models, porting operating systems, developing applications, and making sure simulations speeds are fast enough to be productive. Sub-systems Virtual Platforms require less effort to create (less blocks, reuse TLM Design models), address a smaller problem (sub-system programming or analysis), and are less demanding on performance. Leonard Druckerhttps://community.cadence.com/cadence_blogs_8/b/fv/posts/intel-vs-arm-did-the-embedded-systems-conference-india-shed-light-on-the-battleWed, 05 Aug 2009 14:34:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:19837TeamESL/cadence_blogs_8/b/fv/posts/intel-vs-arm-did-the-embedded-systems-conference-india-shed-light-on-the-battle2Being a Brit, Cricket is never very far from my thoughts especially when travelling to India, the biggest cricket mad nation in the world. There is a saying in cricket that you should always think of doing what the opposition would least like, a statement that applies in business too. I was on my way to present a session on Verifying Embedded SW Power Management” at the Embedded System Conference in Bangalore . With the recent activity by Intel firstly joining forces with TSMC to deliver licensed Atom IP and also acquiring WindRiver , I was interested to see if there was further evidence of Intels mooted ambition to go head to head with ARM on deeply embedded systems at the conference. The Atom was well represented on the Microsoft Stand with local firm iWave displaying for the first time in public a fully integrated battery powered in-car Windows system running on Atom at 1.1/1.6GHz. Whilst this is an exciting step forward in terms of the physical profile of Atom systems the power consumption still pitches it someway above the top-end ARM Cortex A9. I then headed into the Intel presentation itself and while mention was made of Atom there was a definite emphasis on the higher-end processors and especially the Virtualization technologies being incorporated to the server line. So is the predicted war between Intel and ARM a journalists wish to whip up a media storm or are the battlelines being drawn behind closed doors as Intel prepares an orchestrated attack? As an outsider it would appear there are at least two barriers for Intel, the first is power consumption, no doubt technology shrinks will progressively improve this, however the Atom is unlikely to challenge for very low power designs. Secondly, there is a lack of a lower-end family to bootstrap embedded customers. Whilst ARM is winning customers on it’s Application Processor offerings, most SoCs have multiple processors of varying degrees of complexity; this is ARMs stronghold. Most deeply embedded products are evolutions of previous designs and integrations of sub-systems. For most customers their previous product offerings used a lower end ARM7 or ARM9 processor they can easily migrate or even incorporate an entire system as a sub-system inside a much bigger SoC. I was pondering Intel’s lack of low power, lower-end licenseable processor IP last week when I returned from India only to hear the news that ARC is in discussions with a takeover candidate. Could this be Intel bowling ARM a googly (curve-ball for all those who’d rather a baseball metaphor) ? This TeamESL blog was provided by Nick Heaton, a Senior Solution Architect within the Cadence Front-End R&D organization, with specific responsibility for the Incisive Verification Kit. Nick is an industry veteran based in the UK with more than 25 years of SoC design and verification experience.https://community.cadence.com/cadence_blogs_8/b/fv/posts/customer-questions-about-tlm-driven-design-and-verificationMon, 27 Jul 2009 12:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:19576TeamESL/cadence_blogs_8/b/fv/posts/customer-questions-about-tlm-driven-design-and-verification0In the latest blog published by Ron Wilson there were two questions about our TLM-driven design and verification solution introduction. We would like to respond to these comments here: 1. " one line of SystemC generates three lines of RTL " During our interview with Ron, we showed an example of one of our customers who wrote in parallel SystemC and RTL code. In this case the number of RTL code lines was 3X of the number of SystemC code lines and was based on control-centric design. Many customers report a much higher ratio. The SystemC source will mostly be untimed and not detail many of the low-level RTL requirements such as resource sharing and specific state machine. As such, it could be as small as 1/10th the size of the equivalent hand-written RTL (in the extreme cases, even smaller) for datapath-centric designs and 1/4th the size for control-centric designs. Abstracting away signals to use a TLM interface will also increase these ratios. 2. " Is the RTL OVM SystemVerilog or Verilog. Do we get to choose? " It's not 100% clear whether you are asking "What language is the DUT that's output by C-to-Silicon?"; or based on your mention of OVM , whether you are asking about how testbenches relate to the code output by C-to-Silicon . Thus, allow us to provide answers from both a DUT and testbench angle -- let us know if we address your original question. First, from a DUT angle, The primary output of C-to-Silicon is IEEE-compliant synthesizable RTL Verilog. [Note the question is asking if this RTL is Verilog-95 or SystemVerilog --the answer is that it is v2k Verilog since it has to work on all downstream tools]. C-to-Silicon also can automatically wrap that RTL so it can be easily plugged-and-played into the higher-level design and/or testbench. W.r.t. to the testbench aspect of C-to-Silicon output: the architecture of OVM verification components is replicated across e, SV, and SystemC. Additionally, Cadence's IES-XL simulator supports e, SV, and SystemC -- and hence OVM -- so the choice of testbench for your C-to-Silicon created DUT is really up to you. Team ESLhttps://community.cadence.com/cadence_blogs_8/b/fv/posts/metric-driven-verification-with-an-fpga-based-designWed, 17 Jun 2009 17:30:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:18532TeamESL/cadence_blogs_8/b/fv/posts/metric-driven-verification-with-an-fpga-based-design1During the last 2 years I have enjoyed the opportunity to work with the Incisive Software Extensions (ISX) with many customers. I learned a lot about software/hardware co-verification and we reached the point were we started to see beyond one’s own nose. One of the substantial concepts of ISX is the generic software adapter. The accentuation here is the attribute 'generic'. The generic approach guaranties the freedom to connect almost everything that somehow drives embedded software. From this point of view it's very easy to build up a library of supported devices and reuse proven and customized adapters out of the box for convenience. Is the generic concept a really proven one, mature enough to document a step by step approach? What are potential areas of using the ISX technology with the metric driven verification methodology apart from the simulation based mainstream? The ISX installation explains, with the help of examples, the connection to the OpenRisc processor ork1 ( http://www.opencores.org/openrisc ) driven in a simulation environment, and the integration of Palladium and Xtreme boxes. There is an open question remaining: what is the effort and benefit to connect it to an arbitrary FPGA prototype board? This question comes up during our engagements with customers, and we looked for a chance to find a practical answer to it instead of the theoretical explanations we used so far. In 2008 we embarked upon an ISX activity together with ElCamino ( http://www.elcamino.de ), a consulting company and partner of Cadence for many years. During our discussions we selected a ElCaminos FPGA training board and integrated it into a metric driven verification environment using ISX. The hardware was a low-cost, low-power Cyclone III FPGA from Altera combined with a LCD color touch panel for visualization driven by Specman testbench. The result was a small eyecatcher we introduced first time on CDNlive! in Munich this year. Figure 1 - Altera FPGA Board The demo vehicle proves that the generic adapter concept provides significant flexibility, and is a solid base to extend ISX into embedded software verification strategy.The integration effort for the selected board was not higher than the standard ISX simulation based project and no additional functionality needed to be added to the ISX tool itself to make this happen. The benefit of such an integration is the post silicon verification with existing fundamental verification methodology and the expected high reuse factor of any existing metric driven verification environment (MDV). And finally the generic FPGA board support of ISX enables the introduction of MDV to the software verification world, which is revolutionary thinking from the software testing perspective. More background information about this engagement will be provided in an upcoming blog interview with the ElCamino engineers, Ernst Zwingenberge and Malte Henzelmann, who supervised both the project at ElCamino. This TeamESL posting was provided by Joerg Simon who is a CoreComp Verification Engineer at Cadence Design Systems where he is responsible for ESL product deployment, including hardware/software co-verifciation products and TLM methodology.https://community.cadence.com/cadence_blogs_8/b/fv/posts/way-worse-than-the-real-thingTue, 19 May 2009 02:05:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:17475TeamESL/cadence_blogs_8/b/fv/posts/way-worse-than-the-real-thing0This week Cadence and Virtutech announced a collaborative effort to bring together the Virtutech Simics virtual platform with the Cadence ISX software testing system. This is a very interesting combination of technologies, clearly demonstrating how virtual platforms make it possible to test software in ways that are plain impossible on physical hardware. With a virtual platform, it is possible to systematically subject a system software stack to extreme (and normal) working conditions, trying to provoke errors and find conditions where the software breaks. We are not just doing regular automated software testing as you would do any host, but also changing parameters for the hardware on which the software runs. In this particular example we are showing at CDNLive! EMEA , we have a time-to-result latency parameter that determines the time it takes for the hardware to issue an interrupt to the software. The software behaviors demonstrated with latencies at 1 ns and 1 s are quite different... in the fast case, the driver software needs to ensure it can handle an interrupt immediately after starting an operation. In the slow case, the driver has to put the calling process to sleep and wake it up later so that the rest of the system can go on working while we wait for the hardware unit to complete. Try doing that on hardware... Some other obvious examples of how hardware can be controlled to stress software is to vary the number of processors, the speed of the processors, or the size of memory in a system. Isn't it interesting to find out what REALLY happens if you have 2^64 bytes of physical RAM? Will the OS suffer an integer overflow and report -2^63 bytes? Or if all processors run at different clock frequencies? It tends to reveal all kinds of bad assumptions in code. If you add in the ability to inject known bad results from hardware, or turning off units to simulate local hardware failures, you have a very powerful tool to exercise software correctness and robustness. Putting a space-bound computer board in a radiation chamber to check robustness for transient errors is not quite as easy as injecting a sprinkle of memory errors in a simulation. Thinking about it... this is how hardware testing has always been done: create controlled experiments, often looking for corner cases. For software, that has not really been possible since the execution hardware was always fundamentally uncontrollable. But with a virtual platform, suddently the hardware becomes controllable. And the possibilities become boundless. The Cadence ISX integration with Virtutech Simics is just a first step, and we have only scratched the surface of a very exiting topic. The software that was used to have a nice and cushy environment to run needs to wake up and realize that it will be subject to something worse, way worse, than the real thing. This Team ESL posting is provided by Dr. Jakob Engblom , Technical Marketing Manager for Virtutech. He holds an MSc in Computer Science and a PhD in Computer Systems from Uppsala University. He has been with Virtutech since 2002, and has worked with embedded software, real-time programming, and computer systems simulation for the past decade.https://community.cadence.com/cadence_blogs_8/b/fv/posts/systemc-debug-a-summary-of-summary-probesFri, 15 May 2009 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:17653TeamESL/cadence_blogs_8/b/fv/posts/systemc-debug-a-summary-of-summary-probes0SystemC goes well beyond generic C and C++ to provide a number of semantic constructs that are essential for system-level modeling, design and verification. Among the most powerful of these are threading and concurrency. Using threading is required in order to represent concurrent systems, whether for modeling a system-on-chip, or creating a verification environment with concurrent sequences streaming across multiple interfaces. But with this power comes responsibility. Threading, when used incorrectly or beyond a modest level of complexity, can quickly become a challenge to debug when things do not behave as expected. Thread debugging tools are needed in these situations. Thread debugging can also be an important analysis tool when working with and attempting to understand code that has been written by other engineers, who may be from other organizations or otherwise unavailable. Standard command line debuggers such as GDB provide only basic support for thread debugging. The sequential text interface is not a natural representation of the concurrent distributed nature of a threaded system. Such debuggers also do not recognize or natively support SystemC and SystemC threads. What is needed is a debug environment that understands SystemC threads natively, and can display the concurrent activity in detail to clearly let you see exactly what is going on in your design. Incisive simulation and debugging has multiple ways in which it simplifies thread analysis and debug. In a typical system model or testbench you have a set of SystemC modules which are producing, processing or consuming data. This is true whether it is a model of a multi-channel network switch, or a testbench driving and monitoring multiple interfaces to a system-level design. Each module may have one or more SystemC threads that respond to data and events from other modules in the design. In analyzing such a design, questions that typically arise include: Why did one thread respond before another? Did a particular thread respond when expected? or not at all? To what extent does the design behavior depend on the specific order in which threads respond? To try to begin to answer some of these questions, you could try source line debugging, by setting breakpoints and stepping through them, or stepping line by line, watching for where threads drive data or trigger events and then stepping through until you catch where other threads respond. But unless you know exactly which locations to set breakpoints on and can jump between them, this can quickly become tedious, and even disorienting as you bounce around levels of function calls and multiple source files. It also would require you to know more about your design up front than may be reasonable, especially if someone else wrote a significant part of the code. Another option is to use Incisive debugging to set process probes on individual SystemC threads. This will allow you to see thread process activity in the Waveform Viewer, alongside signal and transaction probe activity. This is useful, but in the case where you don't yet know which thread is activating just prior to a critical value change or event triggering, you need to set many individual process probes on a set of threads in order to detect which one was active at the time of interest. In this case, it is more useful to have one action you can take to capture a set of thread activations, and still be able to zero in on the point of interest. The summary probe allows you to do this. The summary probe lets you select not just a thread, but an entire design hierarchy scope level, and it will probe the activations of all threads in that scope. If the scope has multiple levels of hierarchy, you can choose to what depth you want it to descend to capture thread activity, or select "all" to get complete probing of threads under that scope. To set the summary probe, first select the scope at which you wish to apply it. Then, in the SimVision debugging console window, at the ncsim simulator prompt, use this command: probe -activations -depth all -waveform The "-depth all" option is what selects threads in all levels of hierarchy under that scope. When you apply the summary probe in Incisive and simulate your design, you will be able to see data activity alongside thread process activity in the SimVision Waveform Viewer, on the same timescale. An example using this is where you have a design with multiple threads writing to the same channel or sc_export. You see a value change occurring which may be incorrect or at an unexpected time, but how do you quickly zero in on which thread wrote the value? Set a summary probe on the scope above the threads of interest and run through the simulation time of interest, then use SimVision to isolate the cause. In SimVision, open the Waveform Viewer. Next, expand sequence time in order to see details of activity at the delta-cycle level, within a single simulation time step. Sequence time allows you to see events and data recorded to the waveform database, step-by-step, which gives you insight into causality and the ordering of event activity in your design. In Figure 1, you can see that sequence time has been expanded at 30 ns. The waveform trace of the summary probe (labeled "_2_sc_summary"), shows that at time 30(1) ns (which is time 30 ns, step 1), the thread that is active at the Time A cursor is "scMain.Top.Producer.send_data". This is the send_data thread in the design scope scMain.Top.Producer. This thread is active beginning at time step 1 and ending at time step 2. Immediately after that, at time step 3, the waveform at the top for connect1 transitions its value from 101 to 102. From this information, and knowing that in this design data is written immediately on the next step, you know that the send_data thread is responsible for sending the new data value 102. Figure 1 - Incisvie Enterprise Simulator debug window Conclusion A language such as SystemC with powerful constructs requires powerful debug tools and techniques in order to efficiently get to resolution on whether a given design is behaving as expected. In addition to the summary probe, there are many other SystemC and multi-language debugging features in Incisive that can speed this time to resolution. For more information, please look at the IES SystemC Advanced Debugging Tutorial in your IES installation documentation. You can also find this tutorial by going to http://sourcelink.cadence.com/ . This Team ESL posting is provided by Michael WIlliamson, Product Engineer for the Cadence SystemC Simulation capabilities in the Incisive Enterprise Simulator.https://community.cadence.com/cadence_blogs_8/b/fv/posts/modeling-interfaces-with-c-to-silicon-compiler4Thu, 07 May 2009 11:15:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:17455TeamESL/cadence_blogs_8/b/fv/posts/modeling-interfaces-with-c-to-silicon-compiler40Users of ESL tools are curious about the procedure for handling the interface to a bus or other communicaton protocol in a High Level Synthesis environment. This is usually formulated in the following question: “How do we take into account the interface to the bus/processor for a piece of IP going into C-to-Silicon Compiler ?” There are two ways of addressing this issue using CtoS. The first option is to model the interface at the signal level using sc_signals. For example, a simple request-acknowledge interface would be written as follows: request.write(1); while (acknoldege.read()==0) wait(); // wait until acknowledge. in = input.read(); request.write(0); A more complicated interface, for example a DMA transfer, would be similarly written: request.write(1); while (acknoldege.read()==0) wait(); // wait until acknowledge. address = 0; read_enable.write(1); for(i=0;i<N;i++) { // Loop as many samples as the DMA read requests address_bus.write(address++); data[i] = data_bus.read(); } ... process the N samples of read data For a higher level of abstraction and for faster simulations the interface can be described using Transaction-Level Modeling (TLM). When Transaction Level Modeling is used, the signals are abstracted away and I/O operations are performed by passing pointers or using function calls (Transactions). By doing this, there is a decoupling of the algorithm with the method it uses to communicate to the external world. Not having an interface “hard wired” in the design makes the design more flexible and re-usable. CtoS supports synthesis of Transaction Level Modeling (TLM). Also, synthesizable TLM models of common bus protocols are available. The details embedded in these models provide CtoS the information necessary to synthesize the signal-level interface for the generated RTL from the High Level System C code. It is important to emphasize that, in CtoS, both the algorithm as well as the TLM or signal based interface are described in a High Level Language (System C). Less Effective Interface Synthesis Rather than synthesizing an interface from a High Level Language such as SystemC, other technologies, such as pure C/C++ High Level Synthesis tools, decouple the algorithm from the interface by writing the algorithm in a High Level Language such as C++ and instantiating the interface from a pre-written menu of interfaces written in Verilog or VHDL. This approach has the following disadvantages: Only the algorithm and not the interface are written at a high level. The algorithm and the interface are designed in different programming languages. There is a substantial amount of overhead in incorporating the low level (Verilog or VHDL) interface into the High Level Synthesis environment. A simulation which includes the interface can only be performed using low level RTL which is inherently slower. Since the approach followed by CtoS does not have these disadvantages, I believe that CtoS’s approach is superior to a mixed C/C++-RTL interface synthesis approach. This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product. Product Engineer for the C-to-Silicon Compiler high level synthesis product.https://community.cadence.com/cadence_blogs_8/b/fv/posts/ctos-support-of-multiple-clocksMon, 20 Apr 2009 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:16788TeamESL/cadence_blogs_8/b/fv/posts/ctos-support-of-multiple-clocks0In a previous blog entry we discussed C-to-Silicon’s (CtoS’s) ability to support multiple threads in a similar way that traditional Hardware Description Languages (HDLs) support multiple processes. There are many applications, such as multi-rate DSP applications, in which it is not only necessary to describe the circuit as multiple concurrent threads but also that these threads operate on different clock domains. Multiple clocks are fully supported by traditional RTL based synthesis tools and therefore must also be supported by any viable ESL High Level Synthesis alternative. SystemC and CtoS support multiple clock domains. Each thread declared inside an SC_MODULE can be clocked by a separate clock signal. By supporting multiple threads and multiple clocks SystemC and CtoS provide a viable alternative to the traditional RTL Synthesis approach. This support is usually not provided by a pure C / C++ High Level Synthesis approach. This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product. Product Engineer for the C-to-Silicon Compiler high level synthesis product.https://community.cadence.com/cadence_blogs_8/b/fv/posts/c_2d00_to_2d00_silicon-support-of-concurrent-processesWed, 15 Apr 2009 13:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:16787TeamESL/cadence_blogs_8/b/fv/posts/c_2d00_to_2d00_silicon-support-of-concurrent-processes0Another key differentiator of C-to-Silicon Compiler (CtoS) when compared to C / C++ based ESL tools is its ability to describe multiple concurrent threads. CtoS supports multiple concurrent threads because, rather than using pure C or C++ as input language, CtoS uses SystemC. SystemC and CtoS support the capability of declaring multiple concurrent threads in a single SC_MODULE. SystemC and CtoS also support the description of an SC_MODULE as a structural netlist of other SC_MODULES. Supporting multiple threads and module instances are requirements for any ESL language and High Level Synthesis tool to be a viable alternative to traditional RTL synthesis. Pure C / C++ ESL based tools cannot support multiple threads and therefore their scope is limited to what can be described by a single process in VHDL or a single “always” block in Verilog. This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product. Product Engineer for the C-to-Silicon Compiler high level synthesis product.https://community.cadence.com/cadence_blogs_8/b/fv/posts/verification-of-autosar-software-using-a-systemc-virtual-platformTue, 07 Apr 2009 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:16533TeamESL/cadence_blogs_8/b/fv/posts/verification-of-autosar-software-using-a-systemc-virtual-platform0[Please welcome ISX R&D team member Markus Winterholer back to the Team ESL blog. This is the second post from Markus, last week he posted " Software Verification or Validation with ISX? "] My bedtime reading of the last couple of days was a new book Hardware-dependent Software: Principles and Practice . It motivated me to work even harder on the upcoming releases of ISX. According to the authors, software verification is gaining more and more importance since the complexity of software in embedded systems is increasing exponentially. Until a decade ago, only about 10% of the development costs of electronic systems were spent on software, whereas 90% of expenses went into the hardware. Today, this ratio has shifted significantly toward software. It was one chapter (the last one in fact) that most caught my attention. Chapter 10 "Verification of AUTOSAR Software by SystemC-based Virtual Prototyping" by M. Krause, O.Bringmann and W. Rosenstiel outlines how car makers and tier 1 suppliers in the automotive industry can benefit from SystemC Virtual Platforms. The automotive standard AUTOSAR (AUTomotive Open System ARchitecture) decouples hardware dependent software or Basic SoftWare (BSW) and application software using a standardized middleware layer called RTE (RunTime Environment). The goal is to make the application software completely independent from the underlying hardware architecture to allow an arbitrary distribution onto different ECUs. Applications can exist and communicate independently of a particular infrastructure and mapping onto ECUs in an environment called Virtual Functional Bus (VFB). Besides the separation of application and infrastructure, the use of abstraction levels is also part of the concept. Three levels of abstraction are defined: specification level with no timing behavior, a timed modeling level where time has been considered by sequenced behavior, and cycle accurate timing by implementation of prototype platforms. The authors show how AUTOSAR software components can generally be represented by SystemC modules. The presented mapping of the AUTOSAR VFB view to SystemC Communication Processes (CP) level offers a potential use model for ISX. In the automotive industry (similar to other industries) parts of the functionality are developed by suppliers. If functional behavior of an application does not exist yet, or is provided by another supplier or by the OEM later during the development process, communication traffic can be generated by cyclic or constrained random data transmission of the corresponding data type. ISX seems to be the perfect fit here. Since the group of Prof. Rosenstiel is already experienced using ISX it should be feasible to build a testbench for the case study described in the book. Another idea that came to mind is to build a general AUTOSAR software verification component. We can use ISX either at the RTE interface to verify that the hardware dependent software has no bugs when running on the specific hardware or prototype by driving the embedded software through the RTE interface and checking that the responses are as expected. We can also validate the architecture of the system by driving testcases and building checks to validate the timing of the unit. Since we are able to use ISX for different levels of abstraction we can validate the system at all three levels of abstraction. In the case of application software (above the RTE interface), we can use ISX to drive regression tests. Markus Winterholerhttps://community.cadence.com/cadence_blogs_8/b/fv/posts/c-to-silicon-compiler-is-a-high-level-and-a-low-level-synthesis-toolsFri, 03 Apr 2009 12:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:16376TeamESL/cadence_blogs_8/b/fv/posts/c-to-silicon-compiler-is-a-high-level-and-a-low-level-synthesis-tools0Some customers have inquired if C-to-Silicon Compiler (CtoS) is a “Low Level” Synthesis tool. The question is usually based on the fact that SystemC is the input language for CtoS. It is partially correct. In reality, CtoS is both a High and a Low level synthesis tool. On the High Level side CtoS can accept very high level constructs such as C++ “classes” and “templates”. A parameterized “High Level” description of a hardware block (a templetized class) can be instantiated inside the SystemC module and synthesized by CtoS. On the other hand, SystemC, in general, and CtoS, in particular, can also accept very Low Level constructs when necessary. For example, a very complex I/O protocol with very specific timing requirements can be specified in SystemC and synthesized into hardware. Not every I/O protocol can be defined at a High Level. Trying to specify complex protocols at a High Level was the failure of the early High Level Synthesis tools. Additionally, SystemC and CtoS provide other “Low Level” features such as the ability to describe multiple processes and various instances of the same hardware block running concurrently. The “Low Level” communication protocol between these multiple processes can also be specified. This is not possible in a single process C/C++ based design. In conclusion, what makes CtoS a viable synthesis tool for the design of complete Digital Systems is its ability to synthesize both “High Level” and “Low Level” features described in the same SystemC code. Complete systems cannot be described and synthesized if one stays in the “High Level Only” design paradigm. This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product. Product Engineer for the C-to-Silicon Compiler high level synthesis product.https://community.cadence.com/cadence_blogs_8/b/fv/posts/software-verification-or-validation-with-isxMon, 30 Mar 2009 12:26:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:16281TeamESL/cadence_blogs_8/b/fv/posts/software-verification-or-validation-with-isx0[Please welcome Markus Winterholer to the Team ESL blog. Markus is one of the founding members of the ISX R&D team and is from Tubingen, Germany.] At the Embedded World Conference in Nuremberg, Germany I delivered a presentation with the title " Metric Driven Functional Verification of Embedded Software " which caused a lively discussion started by Assistant Professor Dr. Winfried Dulz from the University of Erlangen asking if we are doing verification or validation. Since I have been doing hardware verification for 10 years I was pretty sure that I knew what verification meant. For three years I have been working on ISX, a product that extends our verification capabilities for embedded software developers. Until now we have focused on using software for the purpose of hardware verification, but our tools and methodologies are also suitable for pure software testing. What is still missing is a common language to address software engineers who never heard of Cadence before (only ten percent of the audience knew anything about Cadence). We are looking at verification from another perspective, we are not yet speaking the same language, but to be successful in verifying todays complex distributed systems we have to bring in our hardware verification experience and our view of the world and get the software developers with their experience on the same page to discuss and share experiences. Both worlds are working on complex highly parallel systems where timing in communication is crucial. Both are starting the verification and test process by defining requirements and are extracting test cases, checks, and coverage from the specification. Software engineers often use the V-Model to describe the development and test process. Jason Andrews (Andrews, J.R. 2005. Co-verification of Hardware and Software for ARM SoC Design . Elsevier.) defines the terms Verification and Validation as follows: Embedded system verification refers to the tools and techniques used to verify a system does not have hardware or software bugs. Software verification aims to execute the software and observe its behavior, while hardware verification involves making sure the hardware performs correctly in response to the outside stimulus and the executing software. (Does it work?). Validation of embedded systems refers to the tools and techniques used to validate that the system meets or exceeds the requirements. Validation aims to confirm the requirements in areas such as functionality, performance, and power are satisfied. It answers the question, “Did we build the right thing?” Validation confirms that the architecture is correct and the system is performing optimally. Given this definition, ISX is capable of doing both. Driving constrained random testcases stimulating the software API and monitoring the software behavior (variables and software states) as well as connecting to the hardware testbench to check hardware states at the same time, makes sure that the functionality of system or subsystem was verified. By adding timing checks and power simulations we can validate that the architecture was implemented correctly. For sure we have to do both verification and validation. The flexibility and scalability of ISX should enable both. ISX can be used on various platforms from simulated RTL processor models, over Instruction Set Simulators to Virtual Prototypes, emulators and prototype boards. Depending on the abstraction level of the used software API it can be used for unit testing as well as for system integration tests. In conclusion, the correct title of my talk probably should have been "Metric Driven Verification and Validation of Embedded Software". Markus Winterholerhttps://community.cadence.com/cadence_blogs_8/b/fv/posts/bridge-blog-postThu, 19 Mar 2009 15:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:15608TeamESL/cadence_blogs_8/b/fv/posts/bridge-blog-post51. Introduction With TLM2 enabling more sophisticated SystemC IP interoperability, most of the new TLM IP models will come with TLM2 interfaces. Along the way there will continue to be some IP that use TLM1. For example, the recently contributed SystemC portion of OVM-ML uses TLM1 to be compatible with IP that is available today. This experiment (and I hope useful guide) to help you bridge the gap when mixing TLM1 and TLM2 models. For the sake of simplicity, this experiment is based on a simple SystemC TLM2 un-timed description of a dummy IP having only one TLM2 target socket connected to a simple OVM testbench. The same methodology can be applied to any real IP models having TLM2 sockets. 2. The experiment The goal of this experiment is to verify a TLM2 IP using an OVM environment. The problem here is that the OVM library (Multi-Language OVM library implemented by Cadence) only supports TLM1 interfaces with a payload deriving from ovm_object. I have therefore implemented an adapter, called “OVM bridge” to convert from an OVM port to a TLM2 socket. I will first describe the OVM environment (a simple env with an OVM agent and a sequencer sending random addresses on its initiator port and monitoring read values), then detail the OVM bridge and last show how to assemble together the OVM test, the bridge and the TLM2 IP. Creating the TLM2 IP I assume you have already created your TLM2 IP (i.e. a SystemC IP with TLM2 sockets). Here I use a simplistic TLM2 model of a slave IP: a sc_module class with a simple_target_socket implementing a blocking read. It models a fake register bank (10 registers of 32bits) accessible from address 0 to 9. If a read is attempted at an address larger than 9, an error is returned. The read returns the address value plus 10. A sample of the TLM2 slave is given here after: class tlm2_slave : public sc_module { public: simple_target_socket target; // socket tlm2_slave(sc_module_name module_name) : sc_module(module_name), target("TLM2_TARGET_PORT") { target.register_b_transport(this, &tlm2_slave::b_read); } // simple blocking read: set data value to address + 10 virtual void b_read( tlm_generic_payload &payload, sc_core::sc_time &tdelay) { if (payload.get_address() class ovm_bridge : public sc_module { public: sc_export > target; // the last template arg (2) is to limit the binding to // the sub module initiator socket and to an external slave // target soket multi_passthrough_initiator_socket initor; ovm_bridge(sc_module_name name) : sc_module(name), totlm1 ("ovm_to_tlm1"), totlm2 ("tlm1_to_tlm2"), target("OVM_TARGET_PORT"), initor("TLM2_INITOR_PORT") { //bind target.bind(totlm1.target); totlm1.initor(totlm2.target); totlm2.initor(initor); } private: bridge_ovmtlm1 totlm1; bridge_tlm1tlm2 totlm2; The tricky part is the hierarchical connection of the socket. To isolate the testbench and the slave TLM2 IP from the bridge content, I have created a TLM1 export and a TLM2 socket on the bridge. This TLM2 socket will therefore connect internally to the socket of the TLM1 to TLM2 converter, and it will connect externally to the slave TLM2 IP. This can not be achieved with a simple_initiator_socket but instead with a multi_passthrough_initiator_socket. The ovm to tlm1 bridge just converts an ovm payload into its equivalent tlm payload and calls transport from ints initiator port. The tlm1 to tlm2 bridge converts a tlm1 payload into a tlm_generic_payload and calls the b_transport from its initiator socket. Both payload conversions his is done by copying the data from one to the other. Note that to keep the bridges implementations independent from the payload content; I have defined the bridge as a template of both the payload and the ovm payload. Moreover, the tlm1 payload used is a derived class of a pure virtual class defining two methods to copy from an ovm payload and to a tlm generic payload. Assembling all pieces together To ease the connection to the OVM testbench I have created a simple sub-system only containing the tlm2 slave and the bridge. This sub-system has no port/socket; it only serves the multi-language OVM-SystemC communication. Therefore the OVM test connection has to directly bind to the bridge target port (sc_export). Note that the payloads (ovm_payload, simple_payload) are only instantiated in this sub_system class all sub modules use templates. Note also that the ovm_bridge multi passthrough initiator socket connects directly to the tlm2_slave simple target socket. A sample of this sub_system class is given here after: using namespace ml_ovm; class sub_system : public sc_module { public: ovm_bridge bridge; // constructor sub_system(sc_module_name name) : sc_module(name), bridge ("OVM_bridge"), slave ("tlm2_slave") { bridge.initor(slave.target); // register the external ports for mixed-language OVM // communication ml_ovm_register(&bridge.target); } // phase callback that is used for connection void end_of_construction() { // ml ovm binding // Note that the 2nd argument defines the path with class // names and not class objects (i.e. instance names) ! ml_ovm_connect(bridge.target.name(), "tlm_test.tlm_env.tlm_agent.tlm_driver.tlm_drv_port"); } private: // can't acces slave ports directly tlm2_slave slave; }; This sub-system also has the advantage of localizing the multi-language (ml_ovm) code in one place: – register the external ports for mixed-language OVM communication in the constructor – do the ml ovm binding at the end of construction You’re now ready to run the simulation in Incisive. First edit the irun command file (run.f) to include: the OVM top module and the SC top module (i.e. -ovmtop SV:tlm_test –sctop sub_system). Then run the command: % irun -f ovm_run.f A sample of the generated output is given here after: 3. Conclusion & future posts You have now the basic bricks for defining a simple OVM testbench and connecting to a TLM2 IP with simple target sockets. More experiments – stay tuned! – shall include usage of extended tlm generic payload and creation of a systemC OVM testbench.https://community.cadence.com/cadence_blogs_8/b/fv/posts/c-to-silicon-compiler-is-the-only-esl-tool-with-eco-capabilitiesThu, 19 Mar 2009 14:28:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:15965TeamESL/cadence_blogs_8/b/fv/posts/c-to-silicon-compiler-is-the-only-esl-tool-with-eco-capabilities0Another key differentiator of C-to-Silicon Compiler (CtoS) when compared to other ESL tools is its ability to make incremental changes to the generated RTL based on very small changes to the System C source code. This capability, allows designers to make very small changes to the generated RTL and gate level netlists from a very small change to the input source code. Some of the changes that are supported by this approach are the following: Change of the sign of an input. Change inverting the logic level of a signal. Adding an extra condition to an “if then else” statement. Other minor changes to the input source code which reflect in minor changes in the generated RTL. Without this capability, even a minor change to input source code, such as inverting a signal, might result in large differences between the original RTL and the RTL generated after the modification is done. The user must notice that changes which imply major changes in the functionality of the generated RTL should not be treated with an ECO approach. Some changes in the System C code, such as changing the value of a template parameter, like the number of processors in an array processor, may result in a large difference in the generated RTL. This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product. Product Engineer for the C-to-Silicon Compiler high level synthesis product.https://community.cadence.com/cadence_blogs_8/b/fv/posts/esl-design-systemc-tlm2-ip-authoring-a-practical-experimentThu, 26 Feb 2009 19:30:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:15109TeamESL/cadence_blogs_8/b/fv/posts/esl-design-systemc-tlm2-ip-authoring-a-practical-experiment0Introduction ESL Virtual Platforms (systems or sub-systems) require heterogeneous libraries of TLM IP models that can interconnect. Indeed, the OSCI TLM2 interfaces appear to be the only viable solution to solve this interoperability issue. Moreover the IP you need is not always available (because it is a new IP or a custom IP or because it is not yet available from your 3 rd party provider). For whatever reason, you have to hand-write it and this is sometimes really painful and error prone, mainly when your IP includes hundreds of registers. The experiment This experiment shows how you can save time and coding effort by automating the generation of your TLM2 IP SystemC code, mainly for accessing the registers, and for automating the generation of a C API for eSW programmers or Verification engineers. The following is based on a simple SystemC TLM2 un-timed description of the ARM UART pcell PL011. Creating the TLM2 IP The first step of this experiment is to create the TLM2 SystemC model for your IP. I propose to automate this step by using an existing feature of Incisive Enterprise Simulator -XL (IES -XL) (see SystemC reference doc, chapter 11) called nccodegen. This allows you – among other things – to automatically generate a template SystemC TLM code for your HW model. Today this tool generates a TLM1 model, but with little changes you can easily make it a “ TLM2-ready ” IP. To generate the HW IP, follow these steps: 1) Describe the PL011 registers (as defined in the section 3.2 summary of registers of the TRM version r1p5) in a simple Register Description Language (RDL) format. This is a very simple grammar but it’s enough to describe the UART registers. A sample of the RDL file for the PL011 is given here after: // describe registers … REGISTER rsr_ecr { ACCESS = rw; DESC = receive status register / error clear register; SIZE = 4; RESET_VAL = 0x0; PREAMBLE = rw; POSTAMBLE = rw; } REGISTER fr { ACCESS = ro; DESC = flag register; SIZE = 9; RESET_VAL = 0x090; PREAMBLE = ro; POSTAMBLE = ro; } … // describe memory map REGISTER_BANK reg_bank { SIZE = 0xFFF; MAP: … rsr_ecr 0x004 RESERVED 0x008 - 0x014 fr 0x018 … } 2) Run the command: % nccodegen -name uartPL011 -rmf uart_registers.rdl -samplebus -hwonly It generates a SystemC TLM template for the HW model of the UART. It derives from an automatically generated base class with all the registers defined and the access methods to these registers. 3) Update the generated HW template code to match the uart behavior (i.e. add processes, ports ...) and cleanup the code to make it TLM2-ready. The main change is to replace the target sc_export by a simple target socket, and to modify the register base class to remove dependency to the bus_slave_adaptor.h and bus_info.h. You obtain a Uart model with a simple TLM target socket (Ts) and two serial ports (Rx and Tx). The Tx and Rx ports are modeled as simple signals. Note : the advantage of using nccodegen is not only that you save writing time and coding errors, but also that all the registers can be visualized in S imVision when running the simulation because all the registers are declared as ncsc_register. A sample of the automatically generated base class is given here after: template class uartPL011_base : public sc_module { // REGISTER DECLARATION ncsc_register rsr_ecr_reg; ncsc_register fr_reg; … protected: // REGISTER READ ACCESS INTERFACE char read_rsr_ecr() {return rsr_ecr_reg.read() & 0xF;} short read_fr() {return fr_reg.read() & 0x1FF;} … // REGISTER WRITE ACCESS INTERFACE void write_rsr_ecr(DATA_TYPE data) {rsr_ecr_reg = data;} // the rsr_ecr register is read-only, therefore it has // no write method defined … // BLOCKING TRANSPORT CONVENIENCE METHODS // these methods are called by the method registered // on the target socket bool read_register(ADDR_TYPE offset, DATA_TYPE *data); bool write_register(ADDR_TYPE offset, DATA_TYPE *data); }; Converting a TLM1 IP into a TLM2 IP An alternative to (re)creating a TLM2 IP from scratch is to wrap it. This is to be used when you just want to reuse an existing – legacy – TLM1 IP that you can not edit. For example, it could be a 3 rd party IP for which you don’t have the source implementation. This process consists in wrapping all the TLM1 blocking interfaces/ports of your IP with TLM2 interfaces/sockets. This is done by creating a hierarchical module with sockets, instantiating the TLM1 module and a module converting from each TLM1 blocking interface port/export into socket. This is illustrated in the following picture. Note that as consequence to the hierarchical binding is the use of a TLM2 multi passthrough socket (instead of a simple socket) in both the bridge and the TLM2 wrapping module. Note also that to keep the TLM bridge code independent of the user-defined payload; I have defined the bridge as a template of the payload. Moreover, the payload used is a derived class of a pure virtual class defining two methods to copy from and to a tlm generic payload. An example of the TLM1 to TLM2 Initiator Bridge is given here after: template class bridge_initiator_tlm1tlm2 : public sc_module, public tlm_transport_if { public: // port and socket declarations sc_export > target; multi_passthrough_initiator_socket initor; // Constructor // binds the target sc_export to this bridge_initiator_tlm1tlm2(sc_module_name module_name); // implements the TLM1 target transport // converts the TLM1 PAYLOAD into a TLM2 generic payload // and calls b_transport on the initor port virtual PAYLOAD transport( const PAYLOAD &tlm_req ); }; A trivial example of user-defined payload is defined here after. // a simple payload class simple_payload { public: // data int addr; int data; std::string msg; }; // a pure virtual class for payloads conversion // Every tlm1 payload should derive from this // to be used in a tlm1-tlm2 bridge class payload_adapter { public: // these methods allow writing payload adapters generic code virtual void copy_from_gp (const tlm_generic_payload& tgp) = 0; virtual void update_gp (tlm_generic_payload& tgp) const = 0; }; // the convertible payload class simple_convertible_payload : public simple_payload, public virtual payload_adapter { public: // get data from the generic payload void copy_from_gp (const tlm_generic_payload& tgp); // set data to the generic payload void update_gp (tlm_generic_payload& tgp) const; }; Generating the C API for embedded SW SW developers (mainly the device driver SW) need a C API to access and write to registers. This API can be automatically generated from the same source input (the RDL file) used for generating the HW IP. Moreover the API can be re-generated when the input changes. To generate the C API, follow these steps: 1) Run the command: % nccodegen -name uartPL011 -rmf uart_registers.rdl -samplebus -swonly It generates a .c and a .h file files for reading and writing the form/to the HW registers. 2) Modify the generated header file by defining the type of the ADDR_TYPE and DATA_TYPE macros and removing the inclusion of the bus_info.h file. A sample of the generated API is given here after: #define ADDR_TYPE unsigned #define DATA_TYPE unsigned /* Read API for the Registers */ … BUS_DATA_TYPE get_uartPL011_rsr_ecr(ADDR_TYPE baseAddr); BUS_DATA_TYPE get_uartPL011_fr(ADDR_TYPE baseAddr); /* Write API for the Registers */ … void set_uartPL011_rsr_ecr(ADDR_TYPE baseAddr, DATA_TYPE value); Generating HTML documentation The nccodegen utility includes a documentation generator which generates a basic HTML document. Documentation is crucial in design IP packaging (every IP comes with source or compiled code plus documentation) and a key area for automation. But each company has its own documentation format and conventions. A customized HTML documentation could be obtained by (1) converting the generated HTML doc into XML format and (2) apply an XSLT to transform it into a new HTML format. The conversion from HTML to XML can be automated using free tools such as HTML Tidi (see http://www.ibm.com/developerworks/library/x-tiptidy.html ). A sample of transformed HTML doc is given here after: I Conclusion & future posts You have now the basic bricks to ease the modeling of your TLM2 IP (mainly for those with large number of registers) using the IES -XL nccodegen utility, and for generating code and documentation for embedded SW developers . Soon you’ll see these features directly implemented in upcoming Cadence Incisive releases; we’re working on it J So what’s next? More experiments – stay tuned! – will include additional guidelines for TLM2 IP modeling and use of OVM testbench for verifying the TLM2 IP. Note also that alternative solutions for describing registers could be used as input to nccodegen. Currently nccodegen takes as input a Cadence proprietary format for describing registers. However other standard formats exist or are emerging that could be used as input to nccodegen to generate SW and documentation. For example, IP-XACT 1.5alpha and SystemRDL 1.0alpha (hosted by The SPIRIT Consortium http://www.spiritconsortium.org ), both include detailed registers description. This Team ESL posting is provided by Jean-Michel Fernandez, Core Comp Archtect for system level design and verificationhttps://community.cadence.com/cadence_blogs_8/b/fv/posts/c-to-silicon-does-not-require-a-library-characterizationFri, 13 Feb 2009 21:10:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:14706TeamESL/cadence_blogs_8/b/fv/posts/c-to-silicon-does-not-require-a-library-characterization0One of the key strengths of C-to-Silicon Compiler (CtoS) over other ESL Synthesis tools is its ability to directly read industry standards .lib files. By providing this ability an expensive library characterization which is required by other ESL Synthesis tools is avoided. This approach not only avoids an expensive library characterization, which only provides estimates of the component delays, but also has the advantage of using the synthesized components in the context of the actual design. This is done using CtoS's built-in RTL Compiler synthesis engine and the provided .lib file to synthesize and analyze the timing of the generated RTL from which CtoS gets accurate feedback to refine the scheduling of components. The end result is higher quality RTL with more aggressive resource sharing that once synthesized, meets the timing requirements in the targeted technology. This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product.