[ADC modelling in AMS SystemcTLM]

This is a nice assigment; combining the powerful features of plain SystemC, TLM and AMS, for an ARM+ADC subsystem application. This is clearly not a task for a beginner in SystemC - it requires good understanding of all the individual disciplines to model such system. I almost think this is part of an exam or university exercise. But in this forum we will not solve students problems or exams

 

Having said that, here some basic guidance to get started. TLM is primarily used for the bus communication; it does no offer the hooks to model a register interface (RI) or memory map. You should check if your exercise/books/example propose the use of a certain modeling library for these elements. Most EDA vendors offer this type of functionality as non-standard extension for SystemC and TLM. Such register interface defines, as the name suggests, an interface between the bus and the model internals. Register reads/writes via the TLM bus protocol need to trigger certain callbacks in the module, and via these callbacks you can set internal model states or even start signal-level communication to the (TDF) leaf cell(s) in this block.

This should be sufficient info to get started - otherwise ask your teacher  

[DVCon 2014 SystemC AMS tutorial now available as webcast!]

Hello all,

For those who were not able to attend the SystemC AMS tutorial at DVCon 2014, the full tutorial is now made available as webcast, including the presentations with voice-over, examples ("labs") and solutions.

 

Visit the following link (free registration required)

http://www.accellera.org/resources/videos/amsnextwave

We appreciate your feedback and your experience after following this SystemC AMS tutorial.

Regards,

Martin

 

[sigma delta adc]

Without sharing code we cannot help much, other than pointing you to some nice papers or publications on the subject. My recommendation is to read the SystemC AMS User's Guide which is part of the SystemC AMS standard.

 

From the error you have, it looks like you are not using the TDF input port and LTF function inside the processing() callback of the TDF module. I assume you are calling it somewhere else, in the constructor or so? This will of course not work.

You should use the LTF function as shown in section 2.3.2. (Continuous-time modeling) of the user's guide.

[compiling systemc-uvm cosim test bench with irun]

AFAIK, you are making use of an old, vendor-specific piece of code for multi-language UVM.

 

Instead, you should have a look here or here or here. Note that although these technologies use various individual standards (UVM, TLM, SystemC, etc.), the overall multi-language offering is not standards based, so these vendors offer different approaches to solve the same problem, and are thus incompatible.

 

Therefore Accellera Systems Initiative is currently driving the development of a standard supporting multi-language verification. More information on this initiative can be found here.

[strange behavior in reg_driver in shipped UVM examples]

Hi all,

 

I experiencing some strange things in the reg_driver which is shipped as part of the UVM 1.1d release.

 

Below the code snippet taken from the examples/simple/registers/common/reg_agent.sv:

class reg_driver #(type DO=int) extends uvm_component;
   ...
   task run_phase(uvm_phase phase);
      reg_monitor mon;
      $cast(mon, m_parent.get_child("mon"));

      forever begin
         reg_rw rw;
         seqr_port.peek(rw); // aka 'get_next_rw'
         DO::rw(rw);
         mon.ap.write(rw);
         seqr_port.get(rw); // aka 'item_done'
      end
   endtask
   
endclass 

In here, the driver communicates via the sequencer using the peek/get method (in this example there is no explicit response give, so no put method) The call in between the peek and get is DO::rw, where DO is a parameter which points to the dut in these examples. In this dut, the value of transaction/sequence_item rw will be changed.

 

And now the interesting thing: When we peek a value first and after this we get the value, I would expect we get the *same* result. I basically assume the sequence item is stored in a tlm_fifo and we first peek the value without clearing it, and with the get it and will be flushed from the fifo (aka item_done). However, in these examples, the 'get' results in a different value as the initial peek!

It gets even more funny as this (unwanted?) updated value is also returned back to the sequencer, which will call the bus2reg method to process the (unwanted?) updated value.

 

Instead I would expect the usage of a put or put_response method to report back any updated value. But when updating the reg_driver to provide a response (and adding the provides_responses = 1 to the adapter component) some examples, like the register aliasing example, seems to break.

 

I would appreciate any input to clarify if this changed transaction item between the peek and get is really intendend, and if not, whether the exampels can be updated accordingly.

 

Thanks,
Martin

 

[missing proxy to automatically cast an sc_bv element to a bool?]

Hello Alan,

 

I tried your 3 suggestions, but none of them work. And that is good, because the modeling style was getting even more ugly than using the to_bool() method

 

My initial compiler error shows that it recognizes the input as an object derived from sc_dt::sc_bv_base. In a similar way, a sc_lv will be identified as derived from sc_dt::sc_lv_base. Therefore I think this automatic casting to bool is simply a missing functionality in the sc_proxy.

 

But as the sc_proxy as such is not a documented feature in the LRM, I cannot officially complain that something is missing

[missing proxy to automatically cast an sc_bv element to a bool?]

Hi all,

 

I'm using a bit-select of a sc_bv in an expression, something like this:

 

sc_bv<8> mybits;
...
if (mybits[0].to_bool())
  // do something

 

Sure this works, but I'm not so happy with this coding style. Therefore I expected some intelligence in the sc_proxy class to resolve the bit to bool conversion, simply because the sc_bv can be seen as an array of bools.

 

I expected that this would work as well:

sc_bv<8> mybits;
...
if (mybits[0]) // compiler error here
  // do something

 

Pity... we get the following compiler error:

 

... error: could not convert ‘sc_dt::sc_proxy<X>::operator[](int) [with X = sc_dt::sc_bv_base](0)’ to ‘bool’

It seems this type of functionality is not (or cannot be) implemented in the sc_proxy?

 

[coredump using kill() in SystemC 2.3 with clang]

When using clang++ (version 3.1 under cygwin/Windows) and SystemC 2.3, I get a coredump when killing a dynamically spawned process. The message is:

 

terminate called after throwing an instance of 'sc_core::sc_unwind_exception'

  what():  KILL

Aborted (core dumped)

 

Using gcc/g++ works correctly. Any idea what is causing this? Attached a simple example to reproduce the coredump.

SC_MODULE(x)
{
  void f1()
  {
    sc_process_handle h2 = sc_spawn(sc_bind(&x::f2, this) );
    wait(5, SC_MS);
    if (h2.valid())
      h2.kill();
  }

  void f2()
  {
    cout << "@" << sc_time_stamp() << ": A" << endl;
    wait(10, SC_MS);
    cout << "@" << sc_time_stamp() << ": B" << endl;
  }

  SC_CTOR(x)
  {
    sc_process_handle h1 = sc_spawn(sc_bind(&x::f1, this) );
  };
};

int sc_main(int, char*[])
{
  x mod_x("x");
  sc_start();
  return 0;
}

[SystemC AMS 2.0 standard released]

Hello all,

 

Accellera Systems Initiative annouced the release of the SystemC AMS 2.0 standard. The AMS 2.0 standard is available as Language Reference Manual and can be downloaded here:

 

http://www.accellera.org/downloads/standards/systemc

 

Note that this standards update does not contain the user's guide. The AMS working group is working hard to release this document in the future.

 

Now that AMS 2.0 is available, we anticipate that EDA companies and/or research institutes are getting inspired to make a proof-of-concept compatible with this standard. This means that today there is no simulation platform available, but we expect in the future it will become available.

Also ask your preferred EDA vendor or partner when SystemC AMS 2.0 gets integrated in the tool and flow.

 

Feel free to post your questions or remarks on the new SystemC AMS 2.0 standard in this forum.

 

Regards,

 

Martin Barnasconi

AMS working group chair