In reply to lalithjithan:
I’ll take one example to explain this .Lets have a TB which generates commands and data to DUT via common interface . We need to have separate logic for command and data generation .Say interface agent ( driver/sequencer pair) doesn’t distinguish between data and command , for this agent (interface_agent) packet will be generated from above components/sequences .
Sequence layering :
In sequence layering you have multiple sequences calling sub_sequences at each layer .
Say 1 virtual sequence is running on top , which calls 2 sub_sequences , each of them calls base sequences running on actual agents . In above scenario , there will be 1 top sequence ( say top_seq) running on virtual sequencer which will call command sequence ( say cmd_seq) and data sequence (say data_seq) , now comannd_seq/data_seq will call base sequences independently whenever required which will run on interface_agent . This type of layering in sequence layering . In my projects I have scene layering goes upto 7 levels .
Driver layering :
To improve readability and robustness of our TB , we can achieve same layering with driver layering , its just we will have components layered up rather then sequences . In above example , we will have one command agent (cmd_agent) and data agent ( data_agent) .Top sequence will run sequence on both agents , cmd_agent_driver and data_agent_driver will process the seq_items pushed by top_seq and push it to port connected to interface agent instead of driving to interface . You can call these agents as TLM level agents or virtual agents as there is no interface involved as such ,only ports are involved.
I personally feel ,driver layering gives cleaner boundaries in your TB .