Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior of table_print_detected? #7

Open
scottj97 opened this issue Apr 25, 2019 · 3 comments
Open

Behavior of table_print_detected? #7

scottj97 opened this issue Apr 25, 2019 · 3 comments

Comments

@scottj97
Copy link
Contributor

In the included demo code, it seems the table_print_detected logic is never activated. The table that gets printed in producer.sv does not go through this custom_report_server at all, it seems.

I'm trying to understand what the intended behavior is. I tried modifying the producer.sv so it uses `uvm_info to print the table, like so:

`uvm_info("producer", $sformatf("Sending %s",p.get_name()), UVM_MEDIUM)                                              
`uvm_info("scottj", p.sprint(), UVM_HIGH) // instead of p.print()

And now the table_print_detected logic is activated, but the output is a little messed up:

   UVM_INFO @      0ns  Sending producer2-0 :producer
   UVM_INFO @      0ns  ---------------------------------------                                                               
Name         Type           Size  Value
---------------------------------------
producer2-0  packet         -     -
  addr       integral       32    'h1a
  initiator  producer #(T)  -1    @1942
---------------------------------------  :scottj
                          top.producer2, producer.sv(69)
   UVM_INFO @      0ns  Starting. :producer

As you can see, the first line is not lined up with the rest of the table. (Even with +UVM_REPORT_DEFAULT, it is similarly misaligned.)

I can see that without the table_print_detected logic, the word wrapping messes up the table far more, so it is useful, but I'm curious if this is really the intended behavior?

@kaushalmodi
Copy link
Owner

Tables are tricky and I did not want to put much time into robust parsing of tables. So I just precede the table sprints with \n, and let them show up without the hanging indentation. At least that they are are more readable.

Do you have ideas to improve this? The challenge is to figure out when the incoming string is actually a table.

@scottj97
Copy link
Contributor Author

I think that's reasonable. Would you accept a PR that changes the demo to do it that way? It would then exercise the table_print_detected logic in the example code.

@scottj97
Copy link
Contributor Author

Er...are you talking about the el_container.sprint() in the custom_report_server? That's also not getting exercised in the example code, and I'm not sure how to exercise it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants