Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by avot

  1. Hello, We received an IP-XACT 2009 file with an empty model name : <spirit:model> <spirit:views> <spirit:view> <spirit:name>View</spirit:name> <spirit:envIdentifier>EnvId:EnvId:EnvId</spirit:envIdentifier> <spirit:modelName></spirit:modelName> </spirit:view> </spirit:views> Both IP-XACT 2009 and 2014 section explain how to manage such situation for mandatory element, but do not for optional elements. For this particular situation (modelName), we consider this element as it is not present. But I didn't investigate if this is always the correct answer for all element in the schemas, particularly if the empty element has XML attributes. Do we need to raise this point to the Accellera consortium for next IP-XACT release ? Regards, Grégoire Avot.
  2. Hello, I am investigating how to handle SV interface in IP-XACT 2009 (and 2014). From the PSS written by Mark Noll "System Verilog Support", the idea is to describe the SVinterface instance with the SVmodule: - Represent each SVinterface as a transactional port : <interface.modport> - Represent port to be passed to the interface as <transactionalport.wire> - And similarly, even if not explicitly written, same for parameters to be passed to the interface. Ex: interface bus #(parameter width = 0,parameter offset = 0)( input clk); logic [7:0] Addr, Data; logic RWn; modport slave (input Addr, inout Data); modport master (output Addr, inout Data); endinterface module proc(bus.master procbus); endmodule module ram(bus.slave membus); endmodule module top(); reg thebus_clk; bus #(.width (4),.offset (2)) thebus (.clk( thebus_clk )); proc theproc (.procbus( thebus.master )); ram theram (.membus( thebus.slave ) ); endmodule Corresponding IPXACT description: proc.xml : transtactional port “procbus”, typeName = “bus.master” wire port “procbus.clk” parameters: “procbus.width” and “procbus.offset” ram.xml: transactional port “membus”, typeName = “bus.slave”.During netlisting, this is the tool responsibility to detect and build the corresponding SVinterface from the IPXACT module (instance name thebus is automatically generated). From my point of view, this approach has the following benefits: It is simple, efficient, it works. Even if the port is mapped inside an IPXACT bus interface, netlister is still able to build the SV interface. But also the following limitations: It is not clear which component (here this is proc, but it could also be ram) must handle the interface description. How to manage conflict? The problem is more complex if the interface has several modport. All legacy generator for IP-XACT component, particularly the one manipulating ports and parameters, must be updated to take care that some element are not related to the verilog module itself, but to the corresponding SVinterface instance. Since the SVinterface instance is implicit in the IP-XACT design, it is difficult to set additional properties for this object: instance name, vendor extensions, … The overall idea is this packaging is a kind of IP-XACT wrapper over a module and its Svinterfaces. From my humble opinion, point 2 is a real problem. So to tackle these 3 limitations, I am wondering if SV interfaces can be explicitly packaged and instantiated as an ordinary IPXACT module: IP-XACT component for SVInterface: All ports, parameters, fileset, default values, documentation, etc as usual. ModPort packaged as transactional IP-XACT component for verilog module for modport reference: ModPort packaged as transactional + typeName : <svinterface.modport>.And for design: All IPXACT components (for module and SVinterface) explicitly instantiated, parameterized and connected. Checkers ensures <svinterface.modport> is actually connected to a module with name “svinterface” and port “modport”. Optionally, IP-XACT component instances for SvInterface can be omitted in the design, a generator will automatically add necessary corresponding instances for all connection crossing from <svinterface.modportA> to <svinterface.modportB> before netlisting (port connexion and configuration must be done manually). This proposition seems to resolve limitations 1, 2 3, but we lose benefit 2 regarding IP-XACT bus connections. Anyone have an opinion on the matter? Best regards, Grégoire Avot.
  3. Hello Torsten, You are right, I can call function set_timestep() on a module instance, not on a port on a module instance. Best regards, Grégoire.
  4. Thank you Torsten and Martin. Martin, I fully agree your explanation, this is clearly explained in the User Guide. Torsten, I remember I did this test, I set timeStep globally for the module, not for a port, and got an error when function set_timeStep() is called outside the set_attributes(). But maybe I missed something, I will try again. Best regards, Grégoire.
  5. Hello, I am a beginner in SystemC-AMS. So I started using the User Guide (very good document) and tutorials about C++ found on the web. I am able to run simulation using a set of TDF modules connected together. Everything works perfectly. I have a question regarding the coding style: since I have the same module (sin_src from User Guide) implemented twice in the same cluster, I set the timeStep in only one of the two module instance using the following code: ---- sin_src.hpp ---- private: sca_core::sca_time *tm; // cluster time step ---- sin_src.cpp ---- void sin_src::setTimeStep(sca_core::sca_time *tm ) { // My method this->tm = tm; } void sin_src::set_attributes() { if( tm!=NULL ) { set_timestep(*tm); } } ---- end ---- Then I am able to set the time step only on the relevant sin_src instance, everything works well, no technical problem. Reason for this implementation is I don't want to mix behavioural parameters passed to the constructor (gain, amplitude) and simulation specific parameters (time step). This is purely arbitrary. My question is : Is there a kind of cookbook defining some "good practices" in order to build a reusable and sharable library of SystemC-AMS modules ? Best regards, Grégoire.
  • Create New...