Skip Nav
Home » Forums » SystemC Forum

Icon - KMLM List KMLM List

View email archives for the history of this mailing list.

List Home All Archives Dates Threads Authors Subjects
systemc-forum - Re: [Systemc-forum] sc_signal_resolved now working for serial interfacin Message Thread: Previous | Next
  • To: systemc-forum@xxxxxxxxxxx
  • From: Mudiaga Obada <obada@xxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 17 Feb 2004 14:16:49 +0100
  • Cc: Mudiaga Obada <obada@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Send Email to systemc-forum@osci.kavi.com:
Send new message
Reply to this message
Hi Jayram,

thanks a lot for your reply. It helped me solve my problem.

More below:


jayram.nageswaran@xxxxxxxxxxx wrote:

Your code contains many minor errors. I have corrected them and enclosed in
this mail. The changes can  be found by searching the source code
for the tag MNJ.


/*
 * Problem: an assignment here causes spi_out to go 'X' instead of '1'
 *  (output can be undefined until clock but still...)
 */             
//spi_out = sc_logic_0;         
>
>  //MNJ: This process is also always driving the signal, spi_out
// to zero, when spi_cs=1, concurrently with sig_proc_spi_clk. Hence // by resolved signal, final value of spu_out is always 'X'.
// So i commented this assignment.


I had figured that removing that line helped (a little) but your your word "always" sent lots of light into my head.

I now realize that I have to think of an SC_METHOD as a circuit on it's own and not just at the SC_MODULE level. I thought that as long as I don't send stimuli that triggers both the sc (select) and the clk SC_METHODS during the same simulation time, I was fine. Now I know better. Each SC_METHOD keeps the signals it modifies pulled to it's own value "always".

Now that was a major error. Have to go see what the SystemC documentation says...

Come to think of it, it really is too much expected from a simulator/synthesis tool to resolve an SC_MODULE made up of different SC_METHODS to one mega-circuit.



void top::spi_out_test_0()
{
        
        spi_out_test(0, 0x20);
        wait(9, SC_MS);                 
>
//MNJ: I guess this should be in milli-second(SC_MS) instead of SC_SEC,
// because the simulation itself runs for only
// 500 MS. Even in case of SC_MS, test_0 and test_1
// would clash in between. So the start of test_1 // should be delayed appropriately.
>

Actually, MS_SEC was alright... it comes from the original context. I did reduced the simulation time for the test and it went to show that even though the other units where not being run, I was getting undefined values. But as I now know, that was not the problem.

Thanks again,

Mudi

P.S.

For the Archiv:

Now I got rid of the cs handler and the working code now looks like this:

SC_CTOR(spi_echo)
{

        initialized = false;

        SC_METHOD(sig_proc_spi_clk);
        sensitive_pos << spi_clk;
        sensitive << spi_cs;

}


/* * In this SC_METHOD, spi_out is modifed exactly once per call * Especially, spi_out is set to 'Z' exactly when spi_cs goes HIGH * spi_out is never asigned if spi_cs is low */

spi_echo::sig_proc_spi_clk()
{

        if ( ! initialized || spi_cs.negedge() ) {

                if ( ! initialized) {
                        initialized = true;;
                }
                
                spi_out = sc_logic_Z;

                return;

        } else if (spi_cs.posedge()) {
                

                // spi_out := <undefined>

                return;

        } else if (! spi_cs.read()) {

                return;
        
        }
        

        bit = <output>


spi_out = sc_logic(bit); }




By Date: Previous | Next Current Thread By Thread: Previous | Next


  Mail converted by the most-excellent MHonArc 2.6.10