C6670 VCP2 Status Register(VCPSTAT0)

Hi g.f,
We are working on your post. We will get back to you. Thank you for your patience.

Hi g.f.

This bit should be set while the VCP2 is running i.e. actively decoding a block. Writing the START Command in VCPEXE register generates a transmit event (VCPXEVT) to transfer the VCP2 input configuration parameters through EDMA3. This transfer is linked to the EDMA channel for Branch Metrics transfer. I'm not sure at what point does the VCP2 set the running bit during this process i.e. whether it's set at the begining of the IC and BM EDMA transfers or when enough BMs are transferred to enable the VCP to start decoding. My guess would be when enough BMs are transferred and the VCP starts decoding the block i.e. VCP is actively decoding a block.

Can you provide some context to this question e.g. what kind of delay are you seeing/expecting in your application? Thanks.

-Nitin

 

Hi Nitin,

Thank you for the reply.
Actually this question was from my customer.

In the VCP2 sample program which they have, after writing the START Command in VCPEXE register
asm(" IDLE") was called. But my customer want to wait for the VCP2 response by polling the status register.
So, they are thinking to poll the VCPSTAT0.

But they don't know the timing of VCPSTAT0 transition so that they want to know the timing of transition.
Can you get certain information about the VCPSTAT0 Run bit transition timing?
And what kind of factor does this bit transit by?

best regards,
g.f.

Hello,

I could not provide you complete and reliable info, but let me give you a hint. Some time ago I was provided with an example for VCP2 in another thread https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/48093/248296#248296 . Please see an attachment in the referenced message. Inside there you may find TCI6488TCP2VCP2BER_1_0_0\source\include\csl_vcp2Aux.h file, and then take a look starting at line 1110:

/** 
 * ============================================================================
 *  @n@b VCP2_statRun
 *
 *  @b Description
 *  @n This function returns the RUN bit status indicating whether the VCP is 
 *     running or not. 
 *
 *  @b Arguments
    @verbatim
            None.
 
    @endverbatim
 *
 *  <b>Return Value </b> bitStatus
 *  @li     bitStatus   RUN bit field value of VCP status register 0.
 *
 *  <b>Pre Condition </b>
 *  @n None.        
 *
 *  <b>Post Condition </b>
 *  @n The returned value indicates 
 *  @li    0   -   VCP is not running.
 *  @li    1   -   VCP is running.
 *
 *  @b Modifies
 *  @n None.  
 *
 *  @b Example
 *  @verbatim
            // start the VCP 
            VCP2_start ();
            // check that the VCP is running 
            while (! VCP2_statRun ());
            
    @endverbatim
 * ============================================================================
 */
CSL_IDEF_INLINE
Uint32 VCP2_statRun (
    void
)
{
    return CSL_FEXT (hVcp2->VCPSTAT0, VCP2_VCPSTAT0_RUN);
}

My point is suggested usage in the example section. I know the processor is different now, but as they share similar peripheral, I think its OK to try before TI support may get back.

If you decide to try, don't you mind to share your experience? Thanks.

Hello,

My colleague just experimented with VCP2 of C6670 with some short frame. We used a code like

VCP2_start(vcpSt->vcp2handle);
s1=TSCL;
while (!VCP2_statRun (vcpSt->vcp2handle)); // wait for Run to be asserted
f1=TSCL;
while (VCP2_statRun (vcpSt->vcp2handle)); // wait for Run to be deasserted
f2=TSCL;

In our run f1-s1 is 400+ ticks @1.2GHz. In other words, it takes a while before Run bit gets asserted in VCP Status register. I can assume, that is a time while EDMA is loading metrics to VCP. Because of that one may conclude that deassertion of Run bit in Status register indicates that coprocessor engine has finished, but that tells us nothing, whether EDMA transfer of decisions has been completed. Thus, its seems dangerous to rely on Run bit to check for decoding completion. It seems that interrupt on EDMA last transfer completion is the only reliable way.

I would be happy if TI people comment on the topic.

Hello,

I am not sure why you want to rely on the VCP2 status bit to check decoding completion as this is inefficient (polling wastes CPU resources). A better way to get decoding completion notifications is to use EDMA completion interrupts. I have attached an example which shows how to setup and use EDMA interrupts for this purpose. Please look at the functions Setup_Interrupt and EDMA_ISR in vcp2_interrupt.c. Please look at included ReadMe.txt for build instructions and general overview of the example.

Regards

-Nitin

vcp2example.zip

 

Hello Nitin,

Thank you for the sample, I have forwarded that to my colleague to study.

As to polling Run bit, of course we all understand inefficiency of that method. There are 3 reasons to do that.

First, the application we are modifying was written in a way that is blocks anyway until software decoder was processing, so replacing it with coprocessor and blocking until it completes is just a gradual step in further modifications. We just want to check all other preparations, like BMs calculations, parameter setup were correct before modifying the scheduling.

Second, there was a question of topic starter. I'm sure he would appreciate clear and definite answer.

And thirdly, I'd like to have complete knowledge of device features. With that I can judge the difference between a) recommended efficient way, b) possible though inefficient way, c) not an option at all. There was no doubt using EDMA is option a). What we want to know is whether polling Run bit is b) or c). Most likely, its latter, but it would be nice if data manual was clear about that.

People eat hamburgers and drink cola, and there is nothing bad if one have complete knowledge about risks. Then one take a decision according to situation.  I'd like to see some clarification like "Run bit indicates activity of coprocessor machinery, however, user should not make any assumptions about processing status based on this bit. Synchronize to EDMA events instead."