Re: [clash-language] Best Way to do Version Control with Clash
21 views
Skip to first unread message
Peter Lebbing
Dec 27, 2021, 10:47:08 AM12/27/21
to Clash - Hardware Description Language
Hello Paddy,
> To solve this, I could commit every new Clash install to the GIT stage
> and make it the current compiler. Maybe there are also other
> solutions. I'd appreciate if you could share your experiences.
We maintain so-called "Clash starter projects" which are suitable for
putting under Git control and that build a Clash installation as part of
building such a project. Using Cabal version constraints, you can choose
which version of Clash that is as part of your commit, so that seems to
match your requirements. I believe Stack works a little differently than
Cabal in that respect, and one of my colleagues should know that. Feel
free to ask if you want to do that and don't know how.
For the Arrow DECA development kit, we have a starter project that uses
Tcl inside Quartus to parse part of the Clash manifest files and then
adds all Clash-generated files (*.vhdl, *.qsys and *.sdc) to the Quartus
project. The Quartus files live in their own directory distinct from the
Clash-generated files (so no -fclash-clean woes). It should be
straightforward to adapt this to the dev kit you're using, I hope.
You can use either Stack or Cabal. Stack users can simply type:
$ stack new my-clash-project clash-lang/deca
and they get a new project named "my-clash-project" initialized with the
starter project.
The starter projects are maintained at
https://github.com/clash-lang/clash-starters
and the DECA one is in the subdir
https://github.com/clash-lang/clash-starters/tree/main/deca
*However*, this Git repository is not such a starter project itself.
Don't check out this Git repository to create a new project. To get a
starter project, you either use Stack as shown above which automatically
picks it up on its own, or you extract a .tar.gz (or .zip) file found at
the root of that Git clash-starters repository if you want to use Cabal.
The compiled Clash installation will be stored inside the project, which
takes some extra space, and if we release a new stable version every one
of your projects will need to recompile, nothing's shared. But that is
offset by a nice user experience otherwise.
HTH,
Peter.
> To solve this, I could commit every new Clash install to the GIT stage
> and make it the current compiler. Maybe there are also other
> solutions. I'd appreciate if you could share your experiences.
We maintain so-called "Clash starter projects" which are suitable for
putting under Git control and that build a Clash installation as part of
building such a project. Using Cabal version constraints, you can choose
which version of Clash that is as part of your commit, so that seems to
match your requirements. I believe Stack works a little differently than
Cabal in that respect, and one of my colleagues should know that. Feel
free to ask if you want to do that and don't know how.
For the Arrow DECA development kit, we have a starter project that uses
Tcl inside Quartus to parse part of the Clash manifest files and then
adds all Clash-generated files (*.vhdl, *.qsys and *.sdc) to the Quartus
project. The Quartus files live in their own directory distinct from the
Clash-generated files (so no -fclash-clean woes). It should be
straightforward to adapt this to the dev kit you're using, I hope.
You can use either Stack or Cabal. Stack users can simply type:
$ stack new my-clash-project clash-lang/deca
and they get a new project named "my-clash-project" initialized with the
starter project.
The starter projects are maintained at
https://github.com/clash-lang/clash-starters
and the DECA one is in the subdir
https://github.com/clash-lang/clash-starters/tree/main/deca
*However*, this Git repository is not such a starter project itself.
Don't check out this Git repository to create a new project. To get a
starter project, you either use Stack as shown above which automatically
picks it up on its own, or you extract a .tar.gz (or .zip) file found at
the root of that Git clash-starters repository if you want to use Cabal.
The compiled Clash installation will be stored inside the project, which
takes some extra space, and if we release a new stable version every one
of your projects will need to recompile, nothing's shared. But that is
offset by a nice user experience otherwise.
HTH,
Peter.
Pat the Builder
Dec 27, 2021, 11:19:14 AM12/27/21
to Clash - Hardware Description Language
Thanks Peter. Sorry about all these questions but I just burnt my fingers with this issue as I have to do a git bisect or equivalent to locate an error. With source not compiling in previous versions this is not so easy:-)
BTW I use Quartus command-line scripts. They're almost completely automated in the sense that you can pass a top module to them and they will compile to vhdl, synthesis the vhdl to netlist, and execute the netlist on the FPGA. With the new Clash version they've become much simpler. I can share if this is useful.
Thanks again/Paddy
Martijn Bastiaan
Dec 27, 2021, 2:55:36 PM12/27/21
to clash-l...@googlegroups.com
With the new Clash version they've become much simpler.
That's great to hear, can I ask why?
Op ma 27 dec. 2021 om 17:19 schreef Pat the Builder <paddythep...@gmail.com>:
--
You received this message because you are subscribed to the Google Groups "Clash - Hardware Description Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clash-languag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clash-language/9aee16e9-f1f2-4f86-bd74-b18440561cadn%40googlegroups.com.
Pat the Builder
Dec 27, 2021, 3:51:18 PM12/27/21
to Clash - Hardware Description Language
Sure. No problem. Some FPGA tool configuration has become a bit simpler. From the top of my head the following are some of the changes.
* With the `-fclash-clear` flag the VHDL target directory simply gets wiped and Clash installs all necessary files.
* With the `StringAttr` annotations in the `topEntity` there's no more need to keep the `top¬entity` in sync with the Quartus `.qsf` file.
* I don't need the `altpll*` files any more.
Regards/Paddy
Peter Lebbing
Jan 6, 2022, 9:02:53 AM1/6/22
to Clash - Hardware Description Language
Hello Paddy!
On Mon, 27 Dec 2021, Pat the Builder wrote:
> Sorry about all these questions
No apologies necessary! This is what the mailing list is for.
> BTW I use Quartus command-line scripts. They're almost completely
> automated in the sense that you can pass a top module to them and they
> will compile to vhdl, synthesis the vhdl to netlist, and execute the
> netlist on the FPGA. With the new Clash version they've become much
> simpler. I can share if this is useful.
As long as you're okay with it potentially ending up being used in
2BSD-licensed code[1], I think it'd be very nice if you shared them
here! Integration with tooling is definitely on our road map as well.
Thanks,
Peter.
[1] And all the derivatives that that licence allows, naturally.
On Mon, 27 Dec 2021, Pat the Builder wrote:
> Sorry about all these questions
> BTW I use Quartus command-line scripts. They're almost completely
> automated in the sense that you can pass a top module to them and they
> will compile to vhdl, synthesis the vhdl to netlist, and execute the
> netlist on the FPGA. With the new Clash version they've become much
> simpler. I can share if this is useful.
2BSD-licensed code[1], I think it'd be very nice if you shared them
here! Integration with tooling is definitely on our road map as well.
Thanks,
Peter.
[1] And all the derivatives that that licence allows, naturally.
Reply all
Reply to author
Forward
0 new messages