Hello everyone!
I’m trying to complete a UVM agent for Ethernet 1G PCS.
The protocol includes:
- TX process:
-PCS TX ordered-set SM;
-PCS TX code-group SM; - RX process:
- PCS RX synchronization SM
- PCS RX receive SM.
- Auto-neg process.
Currently, each item(RX/TX datapath and auto-neg process) is encoded as a separate SV task in the pcs_driver class. All these items are mandatory in the driver to support Ethernet specifications:
- RX process receives the link partner config register then sends it to auto-neg process.
- Auto-neg uses the TX process to deliver its own capabilities via the TX config register.
In parallel, I’ve started to work on the monitor and realized that I need the same code for the RX datapath in the pcs_monitor to assemble incoming packets and send it to an analysis port. Because of the code maintenance, I guess it’s not a nice idea just to copy-paste the huge bunch of the code that is related to the RX datapath from the driver to the monitor. Since the projecton the early stage I don’t want to fix bugs in two places for RX process.
As I see it right now there are three potential ways to solve this:
- Incapsulate all processes into separate uvm_components and build it inside pcs_driver. Add uvm_component that is responsible for RX process into uvm_monitor. In this case, the code maintenance problem is solved.
- Create a custom uvm_component that could include driver and monitor functionality (add uvm_ports and analysis ports). But not sure that it’s a good idea because this way would brake uvm_agent philosophy that should strictly include driver/monitor components.
- Just copy-paste RX process code into the pcs_monitor. But as I already said this solution looks very clumsy.
Could anyone please, advise what architecture would be the best choice here and why?!