AxiLite4: Add read only and write only driver classes

[kleinai]

Context, Motivation & Description

Add drivers for AxiLite4 read only and write only channels. These are designed to replicate some of the features the Axi4 sim drivers have. This supports future Axi to AxiLite4 tests.

Impact on code generation

Checklist

• Unit tests were added
• API changes are or will be documented:
  • using Scaladoc comments: /** */?
  • on RTD?
  • thanks to a new tracking issue on RTD?

[Readon]

Sorry, I am not that familiar with GitHub's operation, and wrongly edited the file directly.

@numero-744 would you please give some tips on how to create the modification suggestion by reviewer, so that authors can determine if they can accept the changes easily by clicking the button.

[numero-744]

@Readon

• Click "files changed" tab
• Click the line number you want to comment, it becomes yellow
• If needed, Shift+click another one to select a range, which becomes yellow
• Click the white-on-blue + button of the last line of the selected range
• Then there is a line with "Write", "Preview", then a blank, then the formatting buttons. The first one is a file with a + and a - on it. Click it
• It adds a snippet ```suggestion in your comment with the selected code inside. You can then just edit this snippet in your comment, and the diff will be processed on Preview (line diff) and after submission of the comment (line + word diff).

[Readon]

@Readon

• Click "files changed" tab
• Click the line number you want to comment, it becomes yellow
• If needed, Shift+click another one to select a range, which becomes yellow
• Click the white-on-blue + button of the last line of the selected range
• Then there is a line with "Write", "Preview", then a blank, then the formatting buttons. The first one is a file with a + and a - on it. Click it
• It adds a snippet ```suggestion in your comment with the selected code inside. You can then just edit this snippet in your comment, and the diff will be processed on Preview (line diff) and after submission of the comment (line + word diff).

Thanks, that would be useful.

[Readon]

At the same time, I understand that the simulation code could not call the setOKAY directly.

[numero-744]

Cause not an HLS ^^' @Readon can I try to clean the branch by removing your 2 commits?

[Readon]

Cause not an HLS ^^' @Readon can I try to clean the branch by removing your 2 commits?

Sure, thanks.

[numero-744]

@Readon Nothing happened XD

[kleinai]

At the same time, I understand that the simulation code could not call the setOKAY directly.

Yes I don't believe that function can be used to drive the simulation signals as it's a hardware assignment.

[Readon]

At the same time, I understand that the simulation code could not call the setOKAY directly.

Yes I don't believe that function can be used to drive the simulation signals as it's a hardware assignment.

I just always concerns on the constant values.

[kleinai]

At the same time, I understand that the simulation code could not call the setOKAY directly.

Yes I don't believe that function can be used to drive the simulation signals as it's a hardware assignment.

I just always concerns on the constant values.

I could define them in the file if that looks better.

[numero-744]

@Readon I think you meant discussing using literal values when constants can be used instead, in this case I aggree.

Maybe the simulation equivalent for hardware functions should be implemented? This was one of the goals of withEnv in #968 and of #879

[Readon]

I could define them in the file if that looks better.

It's not necessary to do that now, there are still lots of code with constant value.