Clarification

[taylor-bsg]

Is the source code generated from some other source language? We notice the gen_RTL directory name.

This would be useful to know; for example, will pull requests to this repo be accepted, or would the fixes need to be made upstream and then the RTL regenerated by T Head?

[DawnCarol]

it is not generated from some other source language，you can read it.

[secworks]

The code does look like it is generated, with sections marked with (for example) "@266". If it is not generates, but hand written it is really written in a very old Verilog style that are prone to lead to issues.
@MeDove Do you know why the code is written in pre Verilog 2001 style?

[DawnCarol]

The code does look like it is generated, with sections marked with (for example) "@266". If it is not generates, but hand written it is really written in a very old Verilog style that are prone to lead to issues. @MeDove Do you know why the code is written in pre Verilog 2001 style?

not sure.

[avianes]

@secworks is right, the source code is generated from another language called Vperl (or an evolution of this language). There is a paper (1) that explains what Vperl is.

Essentially it's an automation tool on top of Verilog 2001 that saves the developer from writing boring and repetitive code. Vperl offers macros to: automatically generate module declarations, their ports, wires and regs; automatically instantiate modules and connect module ports; automatically generate sensitivity lists; etc.
Comments from the released verilog code correspond to Vperl source code in the original file and the "@266" mark corresponds to the line number in the original file.

Vperl also allows to automate the design verification, but the verification code seems to have been removed from the released code. If you take a look at the line numbers in the comments it appears that there are big chunks of missing Vperl code, this must correspond to the verification code.

(1): A front-end automation tool supporting design, verification and reuse of SOC

[DawnCarol]

@secworks is right, the source code is generated from another language called Vperl (or an evolution of this language). There is a paper (1) that explains what Vperl is.

Essentially it's an automation tool on top of Verilog 2001 that saves the developer from writing boring and repetitive code. Vperl offers macros to: automatically generate module declarations, their ports, wires and regs; automatically instantiate modules and connect module ports; automatically generate sensitivity lists; etc. Comments from the released verilog code correspond to Vperl source code in the original file and the "@266" mark corresponds to the line number in the original file.

Vperl also allows to automate the design verification, but the verification code seems to have been removed from the released code. If you take a look at the line numbers in the comments it appears that there are big chunks of missing Vperl code, this must correspond to the verification code.

(1): A front-end automation tool supporting design, verification and reuse of SOC

@secworks is right, the source code is generated from another language called Vperl (or an evolution of this language). There is a paper (1) that explains what Vperl is.

Essentially it's an automation tool on top of Verilog 2001 that saves the developer from writing boring and repetitive code. Vperl offers macros to: automatically generate module declarations, their ports, wires and regs; automatically instantiate modules and connect module ports; automatically generate sensitivity lists; etc. Comments from the released verilog code correspond to Vperl source code in the original file and the "@266" mark corresponds to the line number in the original file.

Vperl also allows to automate the design verification, but the verification code seems to have been removed from the released code. If you take a look at the line numbers in the comments it appears that there are big chunks of missing Vperl code, this must correspond to the verification code.

(1): A front-end automation tool supporting design, verification and reuse of SOC

not exactly, Vperl is a tool write by perl which is used to deal with the Verilog2001,it is not generated,i think

[avianes]

not exactly, Vperl is a tool write by perl which is used to deal with the Verilog2001,it is not generated,i think

You are confusing Vperl from C-Sky (which has been acquired by T-HEAD) with verilog-perl from Veripool

PS:
Comments in the code contain macros similar to what is described in the Vperl paper.
This paper is explicitly associated with the company C-Sky (acquired by T-HEAD).
The code contains directives that spell out the name of C-Sky and Vperl.
https://github.com/T-head-Semi/openc910/blob/d4a3b947ec9bb8fa72327f1ef87f659c252246a4/C910_RTL_FACTORY/gen_rtl/had/rtl/ct_had_dbg_info.v#L261
There is no reasonable doubt about whether Vperl from C-Sky is used here or not.

[taylor-bsg]

Thanks, this is very helpful.

[secworks]

Hold on! @taylor-bsg don't close this just yet.

This begs the question on how contributions are to be handled?
Will the project accept PRs with changes to the RTL?

[avianes]

To complete my answer about the code maintenance:

By reading the comments it becomes clear that the disclosed code is probably not directly the generated code.
As I said, there are big chunks of Vperl code missing in the comments and there are also places where the generated code seems to have been manually modified to fix problems.
https://github.com/T-head-Semi/openc910/blob/d4a3b947ec9bb8fa72327f1ef87f659c252246a4/C910_RTL_FACTORY/gen_rtl/rtu/rtl/ct_rtu_rob.v#L4575-L4580
The presence of the @ at the end of the line indicates that it has been processed/generated by Vperl, but the absence of generated verilog code and the fact that Vperl code is commented twice seems to indicate that there was some post generation modification.

My point is that it's highly unlikely that T-HEAD would ask its engineers to do this work twice on the generated code, so I don't expect any update with RTL regenerated by T-HEAD and upstreamed.

This would be useful to know; for example, will pull requests to this repo be accepted, or would the fixes need to be made upstream and then the RTL regenerated by T Head?

This only partially answers the original question from @taylor-bsg, but I hope it helps.

[secworks]

One can always provide PRs, but it seems less likely to be accepted, merged unless they are critical.

[taylor-bsg]

Sorry to close it a little early in the dialogue. After Avianes' earlier posts, I had come to the same conclusion as what he posted. Still massive kudos to T-head for opening this up! =)

[CaffreyCC]

Yes, the code is generated through an internal tool. And of course the project will accept PRs with changes to the RTL under appropriate conditions. We are planning to introduce a more complete verification environment to ensure that all the modifications to the project are correct in function and timing.