When binding with <:auto:> it seems clocks do not autobind properly, see

In contrast to subroutines, which are actual jump/return routines, a macro would provide a way to inline a piece of code.

Currently, upon calling an algorithm/subroutine/circuit the parameters are passed in order of input and received in order of outputs.
This can quickly be dangerous. We could (optionally or enforce) naming upon calls.

Instead of
(a,b) <- foo <- (c,d)
We'd have
(a=computed_value) <- foo <- (param_x=c,param_y=d)
With
suboutine foo(input uint8 param_x,input uint8 param_y,output uint8 computed_value) {}

Algorithm outputs take a value of 0 at startup. However, it might be desirable to set this default to something else. This also may be confusing when a variable with initial value is bound to the output. Clarify this behavior and implement an initial value.

doomface_nfo[frame][16,8]

becomes

_c_doomface_nfo[(_c_frame)*32+:32][16+:8]

which is not supported by verilog ; this should be either disallowed, concatenated into a single access, or addressed with a wire/temp reg.

When using "output!" algorithms can result in combinational loops. These are currently not detected. Detect and issue a warning (or error).

Bitfields can be used as initializers, but not in expressions. Should be easy enough as they translate to concatenations. Also, it seems assigning through a bitfield leads to an internal error.

In some cases adding a temporary register can remove a combinational cycle:

a = 2;
if (b == 0) {
  a = a + 1; // cycle
}

removed with a tmp_a

a = 2;
tmp_a = 2;
if (b == 0) {
  a = tmp_a + 1; // ok!
}

It seems this should have no impact, but beware of cases where a could be tracked by an expression, could there be side effects?

Fails for bram, at least

In rare cases, the simulation segfaults at startup.
Prior investigation revealed a memory corruption, unclear where. Investigate again with memory tracking tool.

Some comfort improvements:

• [done] allow variable declaration within code (with block scope)
  => need to add per-block init

• [done] preprocessor line markers ($$) have to be exactly on line start, relax (allow spaces)

• [todo] allow if () {} else if () {} (without brackets on else of first if)

• [done] allow whole group to be declared as input or output in algorithm parameters (equivalent to declaring all members as either input or output)

• [done] relax declaration order, interleave vars, algos and subroutines

This tool looks really great!

A slight inconvenience during installation:
When running compile_silice_linux.sh, the installation of e.g. Verilator, yosys etc. is hardcoded and therefore always run.
The repo version of e.g. Verilator in my repo (Linux Mint) is quite old (3.916) but I have a more current version installed. It would be better if the script only installs these tools if the tool exists.
I have no idea how to achieve that and am aware that checking and comparing the version of each tool is a challenge in itself and not the scope of an Algorithm-to-Verilog converter.

We often pack multiple entires in wide bitfields.

For instance
uint32 v = 32hffff0101;

We could define a 'pack' as

pack lo_hi = {
  int16   a;
  uint16 b;
}

and then

uint32 v = lo_hi(a=16hffff,b=16h0101);
lo_hi(v).a
lo_hi(v).b

The initializer uses names so we can later rearrange the pack without having to modify it.

Careful though that casting would require a temporary ... unless $signed() does the job?

NOTE: this relates to structs, but is a weaker form.

Implement a switch case

I have noticed that the function call “free(texinfo)” was performed for an object which was created by the operator “new”.
Please avoid undefined behavior.

Would you like to wrap any pointers with the class template “std::unique_ptr”?

Finalize local (per-block) variables declaration to properly handle:

• scope
• init in block
  This should also work within a circuitry.

Update documentation.

Add support for C-style structs, to build composed types.
This should not be too hard, a struct simply becomes an array of bits, each member has an index and bit-width.
Some important points:

• we want nested structures
• what to do with structures containing arrays?
• if structures cannot contain arrays then we could specify layout (array of structs; vs struct of arrays)
• initializers? (especially when nesting structures ...)
• needs proper type checking!!

Triggers a cycle detection on sec_c_o , but this seems ok

                  tmp1_h    = (sec_c_o   * invd_h);
                  tmp2_m    = tmp1_m <<< $FPm$;
                  sec_c_o   = tmp2_m;
                  $macro_to_h('tmp1_h','c_o')$ // shift and round
                  if (btm > c_o) {
                    sec_c_o = tmp2_m + ((btm - c_o) * d_m); // offset texturing
                    c_o     = btm;
                  } else { if (top < c_o) {
                    sec_c_o = tmp2_m + ((top - c_o) * d_m); // offset texturing
                    c_o     = top;
                  } }

Only include a global subroutine if it is indeed used, investigate why a subroutine read/write ends up in global rw counts?

Add checks for bit-width and signed/unsigned mismatches (with either warning or error depending on command line flag). In particular detect the use of unsigned operators on signed quantities (e.g << versus <<<).

Investigate how to integrate formal verification of designs, and how this could interact with e.g. yosys.
Exposing assert/assume would be a start.

A starting point:
http://www.clifford.at/papers/2016/yosys-synth-formal/slides.pdf

While it mostly works, there seems to be an instability in the verilator vga framework making it randomly crash in some cases. Could be uninitialized vars or out of bound access. To investigate and fix.

The bitfield provides a definition of an uintN where N is the total width. For completeness and to avoid any hardcoded widths, it is important to be able to use the bitfield name in declarations. For example usage see:

as well as:

Right now the checks are at best disabled, at worst erroneous: verify and correct.

Allow at least 'access' (table, io, etc.) for inputs.

Cannot commit original game textures (copyright), find an acceptable free replacement.

We now have brams:
bram uint8 tbl[1024];

We also need dual clock block RAMs. Potential syntax:
dualbram uint8 tbl<@rclock1,@wclock2>[1024];

Expression tracking may use the 'value at previous clock' assignment (::=). However, in some cases (tracking another tracker, or value bound to instance output) this does nothing as there is no flip-flop associated. In such a case ::= is the same as :=.

This should issue an error. The docummentation should explain and provide a solution on how to achieve the desired effect (i.e. adding an intermediate flip-flop).

Report them using the numbering before, and indicate if error occurs in pre-processor generated code.

E.g. with group sdio:

sdio sdqueries[64];

and then

sdqueries[3].rdata = 0;

Since bram/dualbram become modules they could be global and shared between algorithms.

Probably need to compile the tables as actual verilog memory-like code?

Related to but different from #5

It would be useful for the compiler to report a notion of computational depth, that is the longest combinational chain through dependencies (including through instances).

While this is far from actual hardware, it would give insights regarding the data paths and help visualize the flow of data and data overly long chains.

This relates to #5, since detecting combinational loops likely requires explicitly building the dependency chains.

• signed/unsigned
• later structs/(u)int

• fails silently if file not found?
• input/output cannot use 'wire'?

When chaining calls to subroutines it is possible to save one cycle:

(...a,b,c,...) <- sub1 <- (...);
(...) <- sub2 <- (...a,b,c,...);

Normally, there would be one cycle wasted in between due to return/setup params/call, but we could chain the calls by having sub1 directly jump to sub2. The trick is to modify the entry point of subroutines to have not only the 'standard' call but also context dependent calls that are determined at compile time. The call to sub2 would land in the state that directly pipes the output of sub1 used as input by sub2 (a,b,c).

This can be useful when writing code where subroutines are, in a sense, instructions (pieces of circuits to be reused multiple times), and the chain of subroutines describes a 'program' (sequence of instructions). This would make this type of coding more attractive.

• write_image_in_table
• write_palette_in_table
• get_image_as_table
• get_palette_as_table

An extra null pointer check is not needed in functions like the following.

• lua_write_image_in_table
• ReadTGAFile

Would you like to add more error handling for return values from functions like the following?

• fclose ⇒ lua_save_table_as_image_with_palette
• fread ⇒ ReadTGAFile

Allow at least 'access' (table, io, etc.) for inputs.

Bound variables are not checked for existence ; the following will compile just fine:

vga vga_driver( vga_hs :> video_hs_WHATEVER_NAME, // ... );

Silice uses ANTLR, which was great to get started and focus on the essential.
Now, to produce a nice, useful syntax error reporting, a custom parser is important. As the language stabilizes this will become a must have.

A must have

Like brams, inouts can become structs with three members (see sdramctrl.ice) generating a special module.

The Algorithm class has grown way too large. It consists of three main parts: gather / optimize / writer. These should be split in three classes interacting through a common datastructure with, possibly, a level of abstraction on the writer to target other HDLs than Verilog.