commit 477301ae regressed my code with obscure error message

[tommythorn]

I originally abandoned Silice when this happened, but I finally regressed the commit. My sample
yarvi3.ice
compiled prior to this change, but post that commit

$ silice-make.py -s yarvi3.ice -b verilator -p basic -t shell -o /tmp/BUILD_yarvi3

fails with

...
        dualport_bram_template =     dualport_bram_generic.v.in
                templates_path = /home/tommy/projects/silice-examples/Silice/frameworks/templates
                frameworks_dir = /home/tommy/projects/silice-examples/Silice/frameworks
  dualport_bram_wenable0_width =                              1
   dualport_bram_wenable0_type =                           uint
simple_dualport_bram_supported =                            yes
   dualport_bram_wenable1_type =                           uint
assembling source /home/tommy/projects/silice-examples/Silice/frameworks/libraries/memory_ports.si.
assembling source /home/tommy/projects/YARVI3/yarvi3/yarvi3.ice.
main
preprocessing 
[preprocessor] 179]  ')' expected (to close '(' at line 178) near ';'
error: the preprocessor was interrupted

which doesn't seem to match any source lines.

[sylefeb]

Thanks for the report! The code should have worked, but replacing $display by __display fixes the problem on master (all intrinsic Verilog calls in Silice now are using the '__' prefix, like __display, __write, __signed, etc.).

However the grammar still supports $display precisely for backward compatibility, I am investigating the problem but wanted to share the fix asap.

Also, regarding pipelines, there is a documentation start in the wip branch: https:/sylefeb/Silice/blob/wip/learn-silice/Documentation.md#pipelines ; pipelines are still evolving actively.

[sylefeb]

Found the problem (due to new pre-processor parser) and added a proper error message indicating to replace $display with __display. This is pushed to master.

[tommythorn]

Thanks. How does the three additional assignment operators work? The description is pretty terse.

[sylefeb]

Yes, the documentation is far from finished ; this is where I stopped last, but I'll resume on it shortly and expand with examples. I also have to fix a couple pending issues regarding these operators, so things may still change a bit).

But the idea is that a ^= assignment is immediately visible (within same cycle) to earlier stages, the v= assignment is immediately visible to later stages, and the vv= assignment will be visible to all stages at the next cycle. When assigned with these operators the variable is not captured by the pipeline. This is primarily useful for dealing with pipeline hazards.

[tommythorn]

Hmm, I’ll need to experiment. FWIW, it’s a concern I have with Silice that the semantics aren’t always clear and especially with how features interact.

I’ll test and close, thanks.

[sylefeb]

Noted - keeping everything consistent is a top priority. Pipelines are taking time to develop due to this, and this is the reason these features are mostly still in wip branch (with their final form being developed in draft) ; and also why they are not fully documented yet.

Please let me know how your tests go (latest wip branch contains fixes). There's one minimal example of the ^= and v= operators here: https:/sylefeb/Silice/blob/wip/tests/pipeline_ops.si

Thanks for the feedback!