[Feature request] Simplify the VCD_OUT mechanism.

[zapta]

This applies to testbenches and the generation of .vcd. Currently it's done in three steps that are error prone and not obvious to the users. With this feature, the operation will be fully automatic without the user being in the loop.

Currently apio sets the macro VCD_OUTPUT and the users expect to have this sequence in their benchmarks

`define DUMPSTR(x) `"x.vcd`"

...

  $dumpfile(`DUMPSTR(`VCD_OUTPUT));
  $dumpvars(0, main_tb);

With the -dumpfile= option of vvp, the sequence may look like this

  $dumpvars(0, main_tb);

https://steveicarus.github.io/iverilog/usage/vvp_flags.html

[cavearr]

Great!

[cavearr]

Hi @zapta !, I'm trying everything and so far it's going great. The only thing in the simulation, perhaps it would be nice to be able to set a flag to regenerate the simulation, if you repeat it and do not manually delete the vcd of the _build, just open gtkwave with whatever is there. I think it might be convenient to pass some type of flag to be able to force the simulation to be generated every time celery sim is run.

[zapta]

Hi @cavearr, no problem, I can mark also the iverilog and vvp steps of 'apio sim' as 'always build'. It's very fast anyway.

BTW, currently if you modify a source file or the benchmark the sim starts from scratch, right?

[cavearr]

Thanks! i think this is more useful if implemented a command to clean or a command to open gtkwave.

In long simulations could be useful that open gtkwave not implied run the simulation again.

[zapta]

Let me see if I got it correctly, you want support for 'apio sim main_tb.v --force' which will always run the simulation before opening gtkwave. Is it correct?

…

On Sun, Dec 1, 2024 at 10:00 PM Carlos Venegas Arrabé < ***@***.***> wrote: Thanks! i think this is more useful if implemented a command to clean or a command to open gtkwave. In long simulations could be useful that open gtkwave not implied run the simulation again. — Reply to this email directly, view it on GitHub <#481 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQVMQMUUT7ZXW5D5RVILBL2DPZRHAVCNFSM6AAAAABSZ4OOA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJQGY2DOOBWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cavearr]

yes! i don't know this --force flag,, thanks! and sorry for my delay i don't view this message before.

In other way i'm dumping in a md document the result of the test to standardize the method and in the future use the same test for all of the boards or when adding new boards, What do you think if we add this test results to the project to track the tests realized?

For the moment all the tests are run correctly and the integration in Icestudio is going well in next days i'll have done.

[zapta]

Hi @cavearr, having a written pre release test procedure would be very useful.

Also, some of the tests may be automated so this will cut that manual work.

[zapta]

$dumpfile and VCD_OUTPUT where eliminated. Closing.

[cavearr]

@zapta, yes, some of the tests should be automated, in fact I am writing a test suite for the main commands.

On the other hand, it is necessary that other tests be manual at the moment to check if the result is physically applied.

For example, last year in a toolchain update, everything seemed to work fine (lint, build, upload), but in some cases, although the bitstream loaded fine, the layout didn't work because Yosys had included some changes that modified the configuration of the inputs.

In the near future I have a plan to make a rig with all the boards, and an mcu that physically verifies the correct operation of some example, but let's go simple, step by step.

At the moment I want to define the "test plan documents", although we will complete them manually for the moment, this is a lot of work because I am testing board by board on four operating systems but I want to ensure a solid release.

Since I haven't gone into the development of celery so far, I prefer that you, who have gone into the mud :) propose the folder structure for the tests and I will fill them with the tests that I am doing and with the automatic tests that I create If that's okay with you.

Thank you very much for the work!

[zapta]

Hi Carlos, we already have directory for tests that require boards, so you can put it there https://github.com/FPGAwars/apio/tree/develop/test-boards I suggest a subdirectory for each board type, with the board id as the directory name (e.g. alhambra-ii). You can find here an example of an integration test that goes through the steps of project project build, test, lint, etc. https://github.com/FPGAwars/apio/blob/develop/test/integration/test_projects.py but this one doesn't require any board. Currently each of the integration tests installs its own apio packages which takes time, I suggest that you will do the same, until we will figure out a way to load the packages once and then each test can install it from a local cache.

…

On Wed, Dec 4, 2024 at 10:50 PM Carlos Venegas Arrabé < ***@***.***> wrote: @zapta <https://github.com/zapta>, yes, some of the tests should be automated, in fact I am writing a test suite for the main commands. On the other hand, it is necessary that other tests be manual at the moment to check if the result is physically applied. For example, last year in a toolchain update, everything seemed to work fine (lint, build, upload), but in some cases, although the bitstream loaded fine, the layout didn't work because Yosys had included some changes that modified the configuration of the inputs. In the near future I have a plan to make a rig with all the boards, and an mcu that physically verifies the correct operation of some example, but let's go simple, step by step. At the moment I want to define the "test plan documents", although we will complete them manually for the moment, this is a lot of work because I am testing board by board on four operating systems but I want to ensure a solid release. Since I haven't gone into the development of celery so far, I prefer that you, who have gone into the mud :) propose the folder structure for the tests and I will fill them with the tests that I am doing and with the automatic tests that I create If that's okay with you. Thank you very much for the work! — Reply to this email directly, view it on GitHub <#481 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQVMQKNT4LG7URNADCW65L2D7ZSRAVCNFSM6AAAAABSZ4OOA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJZGM2TEMRUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>