Thursday 21 May 2009

Debugging packing and unpacking in Specman

Hello readers, I am back after a loooooong break. It has been quite a some time since I posted something here as I was too busy with my personal life and responsibilities. I try to be regular now. So with this note, let me start something from today itself.

While using packing/unpacking in your environment, you might have gone through some debugging troubles due to silly mistakes. So here are few tips to avoid errors for packing and unpacking.
So starting with Unpacking, there can be 2 kind of problems you may face while unpacking a list into struct
  • You run out of data while unpacking (i.e. list is shorter than total length of physical fields of a struct)
  • Unpacking is finished but you have bits/bytes left over (i.e. list is bigger than total length of physical fields of struct)
If you have situation 1, it will be flagged as run-time error by Specman. But, if you have situation 2, you might not even aware of it as Specman does not issue even a warning for this. For situation 1, if you want to suppress run-time error, you can use 'try' action.

tcm() @clk is {
try {
unpack(packing.low, my_list, my_struct);
} else {
message (LOW, "Unpacking failed");
};
};

To debug packing/unpacking issues, you can use Specman command 'trace packing'. It shows how packing/unpacking is performed. Following example shows the result of 'trace packing' command performed for unpacking.


Following example shows the result of 'trace packing' command performed for packing



If unpacking is unsuccessful (ran out of data in the list), you normally get following message on Specman STDOUT.

*** Error: Ran out of data while trying to unpack (use 'trace packing' for further details)
at line 19 in @packing_unpacking_debug
unpack(packing.low, lob_u, x);


But if you use 'trace packing' Specman command, you see where unpacking stopped.

> ----- Starting an unpack() at line 19 in @packing_unpacking_debug ----

> ----------- Unpacking 'x': x_s
> Unpacking 'x.a': uint (bits: 4)
8 .0
> 'x.a': uint (bits: 4) = 8
> Unpacking 'x.b': uint (bits: 8)
0 5 .0
> 'x.b': uint (bits: 8) = 5
> Unpacking 'x.c': list of byte
*** Error: Ran out of data while trying to unpack into 'x.c'
at line 19 in @packing_unpacking_debug
unpack(packing.low, lob_u, x);


One of the very common cause of the unpacking failure is the unsized list. If the target struct has unsized list as a physical field, all the bits/bytes of the source list will be absorbed by this unsized list and there will be no data left for the next physical field and Specaman will issue an error. So it is always advisable not to have unsized list in the target struct.

Another reason for unpacking failure could be subtype physical fields. If you have few physical fields defined under 'when' subtype of a struct, your need to make sure which subtype to pick while unpacking.

One more reason for the unpacking to give errorneous result is the order of the physical fields in a struct. If physical fields of a struct is defined in the multiple files, then import order of that file becomes crucial because based on the order, physical fields will be treated differently during unpacking. Take a look at the following example.

No comments: