Document scala file path

[numero-744]

See answer from https://github.com/SpinalHDL/SpinalTemplateSbt/issues/9

But, as SpinalHDL is a DSL, maybe the general guidelines are suboptimal and we could suggest another structure which would fit more the hardware description needs? Would it be supported by scala toolchains? Do you have suggestions?

Also, if we support scalatest in the template (as suggested in https://github.com/SpinalHDL/SpinalTemplateSbt/pull/21) maybe we should specify that the testbench should be in the tests?

[Dolu1990]

But, as SpinalHDL is a DSL, maybe the general guidelines are suboptimal and we could suggest another structure which would fit more the hardware description needs?

Yes right.

Would it be supported by scala toolchains?

I kind of tweeked things a bit for instance in SaxonSoc.

the testbench should be in the tests?

This also can be customized.

[numero-744]

For reference: https://github.com/SpinalHDL/SaxonSoc#repository-structure

[numero-744]

What do you think about this kind of path?

src
└── mylib
    └── MyTopLevel
        ├── formal.scala // formal tests
        ├── gen.scala    // Generators (useful only for top level I guess?)
        ├── rtl.scala    // Spinal hardware description
        ├── sim.scala    // Spinal simulation debug testbench
        └── test.scala   // Spinal simulation unit tests (redundant with sim above?)

[Dolu1990]

Hmm, i'm not sure to understand :

    └── MyTopLevel
        ├──  xxx.scala

why a MyTopLevel level ?

As a default structure, hmmm. hw/scala test/scala that way things can be expended easily ? ex : sw/c sw/rust

[numero-744]

why a MyTopLevel level ?

My idea is to have things related to a component close to the component, so there is a folder for the component, with inside it the hardware description, regression tests, formal tests, and possibly a testbench for debug.

As a default structure, hmmm. hw/scala test/scala that way things can be expended easily ? ex : sw/c sw/rust

I like the idea, two points:

• I would like (don't know if it is possible) to have a spinal folder instead of scala (self-advertisement XD)
• I would like unit tests of a Component to be closer to the component if possible
• No packages anymore?

Also, I would find it neat to have generation in a specific folder, for instance:

• hw/scala or hw/spinalhdl: user's source code
• hw/spinalgen generated files
• hw/rtl user's source code eg for blackboxing in SpinalHDL

[Dolu1990]

My idea is to have things related to a component close to the component, so there is a folder for the component, with inside it the hardware description, regression tests, formal tests, and possibly a testbench for debug.

Ahhhh, i understand.

I would like (don't know if it is possible) to have a spinal folder instead of scala

Yes, that's possible i think

I would like unit tests of a Component to be closer to the component if possible

in general, that's not realy friendly with the SBT flow, where you realy need to specify a folder for what will be released, and another one for what will not be released (tests)

No packages anymore?

Yes yes packages, so, hw/spinal/mylib/Miaou.scala

Also, I would find it neat to have generation in a specific folder, for instance:

Yes hw/gen ?

hw/rtl

hmmm hw/verilog hw/vhdl ?

[numero-744]

in general, that's not realy friendly with the SBT flow, where you realy need to specify a folder for what will be released, and another one for what will not be released (tests)

I would say it is to release Scala libraries, and here we just want code to run, so this split would not be applicable?
For a "component library" we would want to *release" it would be an issue, but in this case I think it would be better using the standard sbt structure.
What do you think about it?

hw/gen ?

:+1:

hmmm hw/verilog hw/vhdl ?

And systemverilog too, or mix it with verilog? Or unify the 3 with only a v folder XD

[numero-744]

Structure suggestion from the current discussion can be browsed here: https://github.com/numero-744/SpinalTemplateSbt/tree/rework-structure

Tested with sbt and Metals for VSCodium.

mill configuration not updated yet.

[Readon]

What do you think about this kind of path?

src
└── mylib
    └── MyTopLevel
        ├── formal.scala // formal tests
        ├── gen.scala    // Generators (useful only for top level I guess?)
        ├── rtl.scala    // Spinal hardware description
        ├── sim.scala    // Spinal simulation debug testbench
        └── test.scala   // Spinal simulation unit tests (redundant with sim above?)

It seems that sbt have some path policy should be followed. such as src/main/scala .... I saw some on mill's sbt support PR. and this

[numero-744]

Yes, the sbt path policy is followed for now. But maybe this path policy is over-complicated to describe hardware, and can be simplified to better match hardware designers needs?

[numero-744]

Whether we keep sbt-like structure or move to something "designed for hardware description", I suggest to add a file putting together Spinal configuration: https://github.com/SpinalHDL/SpinalTemplateSbt/pull/24

[Dolu1990]

And systemverilog too, or mix it with verilog? Or unify the 3 with only a v folder XD

That's freedoom for the user. Personnaly i would unify SystemVerilog and Verilog

[numero-744]

Okay, let's do that by default.

About user's freedom, @Readon in all case the user has freedom to re-organize things, so if the they want to use sbt conventions, it is still possible, there would be only one line to remove in the build tool configuration.

I think here the question is more: what is the best default structure we can provide to new users using the template?