Add Writting Tests for CORE-V-VERIF

[MikeOpenHWGroup]

This is the second in a set of tutorial slides generated to help on-board new teams to core-v-verif. More to come.

[DBees]

page 2.

• What is the ENV architecture (expand acronym)
• if possible insert links to the other presentations instead of just a list
  page 5
• diagram implies the implementation only applies to E40*
• is the 2nd line into the imperas block supposed to be dashed orange? (is it configuration)
  page 6
• sometimes test-case and sometimes testcase
• "The UVM" or "UVM"? both are used, "The UVM" might imply something more specific
• I found the explanation about Test-Cases etc. confusing. Are you saying that there is only one test-case per core under the definition of test-case by UVM? But under the CORE-V-VERIF definition there are many test cases per core?
  What is the CORE-V definition of a test case? Maybe a diagram would make these related terms more easy to understand.

page 7

• why say RTL model of the core? RTL implementation of the core?
• cross-compiler not cross-compile
• (maybe motivate use the term BSP? No boards in evidence...)
• bare-metal in what sense?

page 8

• why do you mean by consistency? Do you mean ensuring the appropriate version of all components is used, and coordinating the configuration of each component?

page 9-27 - lots of good detail here, again suggest a diagram up front of the hierarchy of test-case, test programs, tests etc. would help to understand

page 28 - tests using manually-written test-programs ARE not necessarily directed tests (I think the word ARE is missing and important)

page 30

• what do you mean by unique

[MikeOpenHWGroup]

Thanks for the detailed feedback @DBees. I've made several updates (see my responses below). Please keep in mind that these slides are not at the introductory level and are not intended to stand on their own - the presenter (me) is expected to add background information as required.

page 2.

• What is the ENV architecture (expand acronym)

Done

• if possible insert links to the other presentations instead of just a list

The link will break when the files are checked-out into a local repo.

page 5

• diagram implies the implementation only applies to E40*

By design - these are the only cores fully integrated into core-v-verif. The CVA6 is not yet fully integrated into core-v-verif.

• is the 2nd line into the imperas block supposed to be dashed orange? (is it configuration)

Yes. The Imperas reference model reads a file to get it's configuration, this is different than how the UVM components get their configuration.

page 6
sometimes test-case and sometimes testcase

Fixed!

"The UVM" or "UVM"? both are used, "The UVM" might imply something more specific

If one were to expand it out, you would say "the Universal Verification Methodology". So inquisitively, both "the UVM" and just "UVM" can be correct.

I found the explanation about Test-Cases etc. confusing. Are you saying that there is only one test-case per core under
the definition of test-case by UVM?

Yes, that is exactly correct. It is typical that there will be only a few UVM test-cases. It is unusual to have only one, so I wanted to point it out.

But under the CORE-V-VERIF definition there are many test cases per core?
What is the CORE-V definition of a test case? Maybe a diagram would make these related terms more easy to understand.

Slides #6 is explicit on this point: "a test-case is a SystemVerilog class that is an extension of uvm_test". This presentation assumes that the reader is sufficiently familiar with the UVM to know what that means.

page 7

• why say RTL model of the core? RTL implementation of the core?

RTL model is an appropriate way to express that. Typically the term "implementation" implies a lower level of abstraction such as placed gates.

• cross-compiler not cross-compile

Good catch - thanks. Fixed.

• (maybe motivate use the term BSP? No boards in evidence...)

Software people tend to use this term whether there is a board or not.

• bare-metal in what sense?

Bare-metal is a software term that means "little or no programming environment support".

page 8

• why do you mean by consistency?

Intermediate to senior level verification engineers will understand this without need of explanation. In a walk through of these slides I would probably check to ensure the audience had the right context and explain it verbally if needed.

• Do you mean ensuring the appropriate version of all components is used, and coordinating the configuration of each component?

Yes, that is part of it.

page 9-27
- lots of good detail here, again suggest a diagram up front of the hierarchy of test-case, test programs, tests etc. would help to understand.

That would get into a lot of tutorial information which could easily double the size of the slide deck. These slides are not an "introduction to verification with the UVM".

page 28

• tests using manually-written test-programs ARE not necessarily directed tests (I think the word ARE is missing and important)

Another good catch - thanks.

page 30

• what do you mean by unique

I updated the wording to (hopefully) make it a bit more clear.

[MikeOpenHWGroup]

Hi @DBees can you give this another look over? I've got a requested from a Member Company (Metrics) to see these slides and I'd prefer to send them to the source rather than email them a copy.

Thanks!