Scoreboard: Allow user to override the Received: XXX Expected: XXXX log message(s) with a custom report

[SkydiverTricky]

The current log message can be fairly difficult to decode if there are complex/long types used as the expected/actual types. Here is an example using AXIS record types:

KERNEL: %% Alert ERROR   in data_checker_inst,    Received: tid: 0xXX tdata: 0x2F2E2D2C2B2A29282726252423222120 tuser: 0x1 tdest: 0xX tkeep: 0xFFFF tstrb: 0xXXXX tlast: 0    Expected: tid: 0xXX tdata: 0x0F0E0D0C0B0A09080706050403020100 tuser: 0x1 tdest: 0xX tkeep: 0xFFFF tstrb: 0xXXXX tlast: 0    Item Number: 1 at 200 ns

I have a custom report function that outputs much more detailed comparison inside the match function. This currently gives me the following output:

KERNEL: %% Log   ALWAYS  in testbench_tools_pkg, act: tid: 0xXX tdata: 0x2F2E2D2C2B2A29282726252423222120 tuser: 0x1 tdest: 0xX tkeep: 0xFFFF tstrb: 0xXXXX tlast: 0  at 200 ns
KERNEL: %% Log   ALWAYS  in testbench_tools_pkg, exp: tid: 0xXX tdata: 0x0F0E0D0C0B0A09080706050403020100 tuser: 0x1 tdest: 0xX tkeep: 0xFFFF tstrb: 0xXXXX tlast: 0  at 200 ns
KERNEL: %% Log   ALWAYS  in testbench_tools_pkg,                         X X X X X X X X X X X X X X X X                                                              at 200 ns
KERNEL: %% Alert ERROR   in data_checker_inst,    Received: tid: 0xXX tdata: 0x2F2E2D2C2B2A29282726252423222120 tuser: 0x1 tdest: 0xX tkeep: 0xFFFF tstrb: 0xXXXX tlast: 0    Expected: tid: 0xXX tdata: 0x0F0E0D0C0B0A09080706050403020100 tuser: 0x1 tdest: 0xX tkeep: 0xFFFF tstrb: 0xXXXX tlast: 0    Item Number: 1 at 200 ns

Ideally, I could just replace the default report with my own.

[JimLewis]

For now, you can do:
SetReportMode(REPORT_NONE);

It is going to yack at you and say that that option is deprecated. You can comment that alert out in the package. It is going to do exactly what you wanted in the first place.

[JimLewis]

There have been numerous issues related to "I want to print it my way". I have plans for an update that will allow that.

[SkydiverTricky]

Actually - I did consider it could be passed in as a generic, but that requires the existing generics, which would require a default generic package, and ActiveHDL has only offered packages as generics since v11.1 (most recent)

[SkydiverTricky]

Will be much easier with Generics on protected types :)

[JimLewis]

Yes will be much easier with Generics on PT. Make sure to submit a bug report against it if your simulation vendor has not implemented this yet.

[JimLewis]

Just confirming, this is still planned. I am thinking by summer 2022.

[Paebbels]

@JimLewis should we define 2-3 labels like:

• Next release
• Next 2-3 months
• Next 4-6 months

[JimLewis]

@SkydiverTricky
ScoreboardGenericPkg was created before we had the AlertLogPkg. Since we have a good way of reporting errors with the AlertLogPkg, instead of a custom Match function that does the printing, you could do push on the sending side, and then pop on the checking side. That will give you the expected value, from there you can compare it how you see fit.

Not to worry though, there is still a planned update to address this.