Dear All,
I have a big problem: I want to develop a verification environment for a codec of a packet-base communication protocol and I would like to use UVMF.
Aforementioned packets are of unknown size, so queues should be the best way to model them, but I suppose that queues are not an allowed variable data type to be passed from transaction class to the synthesizable structure to be manipulated by the monitor and driver BFMs.
Any solution/suggestion?
Thanks a lot,
Marco
In reply to traf:
Hi Marco,
If emulation is not a concern then it is entirely legal to pass a queue across to the BFM (or just pass the transaction handle itself across and let the BFM handle it). You can generate this by setting the “veloce_ready” flags in the UVMF generators to “False” (they default to “True”) for both your interface and bench.
If the goal is to produce a UVMF bench that can be synthesized to run in emulation then yes, queues are not an option on the BFM side. In those situations you would need to implement the translation of your transaction class queue structure into a fixed size array to be used within the BFM. The most inefficient but probably easiest to grasp approach would be to pass the queue contents into the BFM one byte/word/dword at a time but that would cause a lot of unnecessary HVL/HDL layer overhead. On the other end of the spectrum you could pass the full queue over at once by placing it into a fixed array of maximum possible size, but this also may not be feasible due to the protocol you’re targeting or due to how much data can be passed over at once to the BFM. Ultimately you’d need to work with your emulation vendor’s experts to determine the best way to pass that data across.
In reply to traf:
Dear All,
I have a big problem: I want to develop a verification environment for a codec of a packet-base communication protocol and I would like to use UVMF.
Aforementioned packets are of unknown size, so queues should be the best way to model them, but I suppose that queues are not an allowed variable data type to be passed from transaction class to the synthesizable structure to be manipulated by the monitor and driver BFMs.
Your requirement is quite common. I’d assume you have a packet item consisting of different data, i.e. header with a certain structure and payload. In most communication systems the payload does not really matter and the size of the payload is somewhere in the header. In this case it is a common approach to use a dynamic array for the payload. You can construct it with the size information from the header.
In reply to chr_sue:
In reply to traf:
Your requirement is quite common. I’d assume you have a packet item consisting of different data, i.e. header with a certain structure and payload. In most communication systems the payload does not really matter and the size of the payload is somewhere in the header. In this case it is a common approach to use a dynamic array for the payload. You can construct it with the size information from the header.
Thanks for your suggestion, but unfortunately this protocol only specifies the destination address in the header, not the size of the payload. Furthermore, dynamic arrays, like queues, should be not synthesizable.
In reply to jcraft:
In reply to traf:
Hi Marco,
If emulation is not a concern then it is entirely legal to pass a queue across to the BFM (or just pass the transaction handle itself across and let the BFM handle it). You can generate this by setting the “veloce_ready” flags in the UVMF generators to “False” (they default to “True”) for both your interface and bench.
If the goal is to produce a UVMF bench that can be synthesized to run in emulation then yes, queues are not an option on the BFM side. In those situations you would need to implement the translation of your transaction class queue structure into a fixed size array to be used within the BFM. The most inefficient but probably easiest to grasp approach would be to pass the queue contents into the BFM one byte/word/dword at a time but that would cause a lot of unnecessary HVL/HDL layer overhead. On the other end of the spectrum you could pass the full queue over at once by placing it into a fixed array of maximum possible size, but this also may not be feasible due to the protocol you’re targeting or due to how much data can be passed over at once to the BFM. Ultimately you’d need to work with your emulation vendor’s experts to determine the best way to pass that data across.
Thanks a lot, I would have liked to create an environment ready for emulation as well, but it’s not a real need at the moment, so if there are no solutions, I’ll settle for using queues and setting the “veloce_ready” flags in the UVMF generators to “False” for both interface and bench.