Hi!
I am trying to solve the problem of concurrent transactions that uvm scoreboard receives.
I have an IP to verify and it has two interfaces on it. One for configuration and another for data to process.
I’ve created two ports in my scoreboard and respectively I have two write function. And now there is 2 possible combination:
Configuration comes before data transaction - No problem. Save configuration and process data accordingly
Configuration comes concurrently with data transaction (in the same clock). The execution order of write functions is unpredictable and result of scoreboard depends on order of this executions. If write method for data executes first The scoreboard calculates data with previous configurations but in RTL design new configurations is applied.
Can you suggest me how to process this transaction in scoreboard?
I cannot use fifo, because I don’t know if configuration transaction are going to be or not. I can use #1 before getting data from transaction but is this a good way?
Or should it be only one transaction with configuration and data?
Do you compare data and config in scoreboard? If yes, then you may have 4 write methods, 2 for expected (config + data) and 2 for actual, right?
Can you please elaborate about “you can’t use fifo”. Do you mean data can come with or without the config? If yes, then what’s the condition specifying whether this data has config or not?
Could you please explain how your transactions are looking like? Is the configuration transaction of the same type as the data transaction.
What do you want to compare with respect to the configuration transaction?
I have met this problem a lot of times in the different verifications. The simplest example is with 2 interfaces as I described. Lets take some decoder RTL IP with two interfaces of different types. One is to configure registers of this IP with some settings how to decode stream and another one interface is the stream by itself (data transaction). For simplicity lets take only predictor (model) of our scoreboard without any comparators. This predictor should produce output(decoded) stream (result transaction). The problem is that the configuration transaction may occurs on the same clock cycle with the stream transaction (stream data should be processed with new configuration) or may not occurs at all (in this case we decode stream with old configuration).
There is no problems if each stream transaction would have it own configuration transaction. In this case I add fifos in the predictor and wait until configuration and stream data is in fifos and process the data. But in my case stream data may occurs without any configuration transaction and the predictor does not know whether to wait for it in fifo or not.