eschkufz / cascade Goto Github PK

Overview

Following discussion with josh, we're going to make the following chances.

1. By default, cascade is responsible for managing everything that it determines to be stateful (ie. everything in non-volatile).
2. If the user uses the $yield() task anywhere in their program, then cascade assumes instead that all of the variable in the program are managed by the user (ie. volatile). The user can override this behavior by sticking an annotation on a variable like this: (* non_volatile *) reg x;
3. If the user uses the $yield() task, then they become responsible for the values of any non-volatile variable. Non-volatile variables become undefined at the beginning of the next logical clock tick following a call to $yield().
4. In terms of internal API I'm going to add new methods (1) ModuleInfo::uses_yield() if yield appears anywhere in the user's program (not necessarily just in the current module) and (2) ModuleInfo::is_volatile() which reflects the semantics described above.
5. I'm also going to add a new scheduling method: schedule_blocking_yield_interrupt(), which queues interrupts which will be executed in the order they were scheduled after the normal interrupt queue is drained at the end of a tick where $yield() was asserted. This method is for cascade-internal methods only (meaning, system tasks such as display shouldn't use this code path, and should instead rely on the semantics of the usual scheduling methods). Once this is done, I'm going to change the semantics of schedule_state_safe_interrupt to use this method.

Deliverables

• See changes listed above

Hi Eric,

I also found an interesting malformed program with two consecutive end that makes the last always block never execute, so the simulation runs indefinitely.

reg [31:0] __cycles = 0;

always @(posedge clock.val) begin
    __cycles <= __cycles + 1'b1;
    $display("cycles:%d", __cycles);
end
end // this second end is not a parse error and makes simulation infinite-loop

always @(posedge clock.val) begin
  if (__cycles == 12) begin
    $finish;
  end
end

If I swap the always blocks, then it terminates.

reg [31:0] __cycles = 0;

always @(posedge clock.val) begin
  if (__cycles == 12) begin
    $finish;
  end
end

always @(posedge clock.val) begin
    __cycles <= __cycles + 1'b1;
    $display("cycles:%d", __cycles);
end
end // this second end is not a parse error and makes simulation infinite-loop

Probably the right behavior here is to emit a parse error no matter the order.

Hey Eric,

Very cool project. I was trying to use delay but I am getting a parse error. Is this feature not implemented?. I also tried to run the regression test called timing and got the same error.

$ build/tools/cascade -e share/cascade/test/regression/simple/timing_1.v
>>> Parse Error:
>>>   > In share/cascade/test/regression/simple/timing_1.v on line 2:
>>>     syntax error, unexpected #
>>> Caught Signal
Goodbye!

Thanks!

Overview

This means that from the runtime's perspective, programs running in remote runtimes never execute yield tasks.

Deliverables

• Add handler

Overview

Avmm backends return the number of iterations remaining rather than the number of iterations completed on early exists of Avmm::open_loop(). This code path is only triggered on evaluation of $retarget() and other tasks which abort open loop execution, so it shouldn't affect performance reporting significantly.

Deliverables

• fix return value

Overview

Before we lost access to the vmware repository, we had a branch in progress where we were building out a script to generate an sd card image for the de10 that runs cascade. Let's get that code merged in and bring the documentation in the README up to date.

Deliverables

• Merge de10 scripts from vmware repository

Overview

The adpcm benchmark still points to data files in the old data/ directory.

Deliverables

• Repoint paths to share/cascade/

Overview

Bug report. Module with similar structure to this example hangs after two clock cycles. Removing the assignment to new_requests_left on line 153 (or the conditional dependent upon this var on line 155) causes the display statements to print every cycle, as expected. May be related to this issue.

Overview

A program with an outstanding JIT compilation (which is now placed in the volatile scheduling queue) will hang if the program finishes without calling yield to unblock the compilation.

The fix is straightforward: finish() should recursively invoke yield() against the runtime

Deliverables

• ...

Bug report

When clock.val is passed to a module in a generate statement, Cascade throws the error CASCADE SHUTDOWN UNEXPECTEDLY. Expected behavior is for the clock to be propagated normally to each module. In the below example, excluding the clk input to the EX module works fine (no problem with the foo input); only when clock.val is passed in does the shutdown occur.

Using version with commit ID f14c2de0b50e33a9df97d76a9a522f4bc267f63b.

module EX(
    input clk,
    input foo
);

endmodule
 
wire [1:0] somefoo;

genvar i;
generate
    for (i = 0; i < 2; i = i + 1) begin
        EX ex(
            .clk(clock.val),
            .foo(somefoo[i]), 
    end
endgenerate

Overview

1. There is a race condition in ProxyCompiler which is triggered when asynchronous compilation requests invoke open() at the same time. The method should be atomic.

2. It looks as though either compile() or stop_compile() sockets are being leaked. False alarm.

3. segfault in remote_compiler on engine teardown. Looks like overrides_done_step is being invoked after an engine is destroyed? This isn't a bug with the remote compiler, it's a bug related to the last major refactoring we did. With state_safe_interrupts going on the volatile queue, they've fallen out of order with the regular queue. This is a bug with the remote compiler and the way it maps pid/eid pairs to local engine ids. File under "how the heck did anything work with this bug in production?".

Deliverables

• ...

Overview

Bug report. Module with similar structure to this example hangs after one clock cycle. Removing the for loop defined on lines 130-132 causes the display statement to print every cycle, as expected. May be related to this issue.

Overview

Most of the time this is fine since these are non-standard annotations and will be ignored. For the avalon backend, this can lead to some ugly unsound behavior.

Deliverables

• Remove all annotations from codegen.

Overview

Bug report.
When instantiating a module with the same structure as this sample, Cascade never starts up verilator. If !macroWrQ_empty is replaced with the variable not_macroWrQ_empty, the code seems to run properly. Removing the for loop defined from lines 83-85 prevents Cascade from hanging.

Overview

The newest version of osx is causing trouble for the verilator backend. This is primarily a verilator problem, but the backend should be smart enough to detect a failed compilation and return an error code rather than trying to compile the code over and over again.

Deliverables

• Sensible error reporting for verilator backend.

Overview

Feature request.
Currently, $fseek requires the "off" parameter to be a decimal number. It would be helpful to be able to use a variable to change the offset into a file, like fseek on line 21 here. I'm currently trying to use file i/o in Cascade as a substitute for the AmorphOS memory interface, and the ability to modify this value is critical.

Deliverables

The Avmm backend doesn't generate fall through logic for case statements without default branches. The result is that the avmm statement can hang and cause cascade to become unresponsive.

Minimal example:

integer COUNT = 0;
always @(posedge clock.val) begin
  COUNT = COUNT + 1;
  case (count) begin
    10000: $finish;
  endcase
end

Here's the corresponding state machine:

if (__continue)
  __task_id[0] = 0;   
if (((__state[0] == 0) && (__task_id[0] == 0))) begin
  __l2_next <= (__l2 + 1);
  __update_mask[1+:1] <= (~__prev_update_mask[1+:1]);
  case (__l2)
    10000: __state[0] = 1;
  endcase
end  

Meanwhile, if you have a default case:

integer COUNT = 0;
reg r = 0;
always @(posedge clock.val) begin
  COUNT = COUNT + 1;
  case (count) begin
    10000: $finish;
    default: r = 0;
  endcase
end

Everything works fine

if (__continue) 
  __task_id[0] = 0;
if (((__state[0] == 0) && (__task_id[0] == 0))) begin
  __l2_next <= (__l2 + 1);
  __update_mask[1+:1] <= (~__prev_update_mask[1+:1]);
  case (__l2)
    10000: __state[0] = 1;
    default: __state[0] = 3;
  endcase
end 

• ...

Overview

Leaving vmware has left us without a continuous integration solution.

Deliverables

• Reenable support for continuous integration

Overview

Bug report.
Certain coding styles cause Cascade to produce an incorrect sensitivity list, which results in the following compiler error:

Avmm backends do not currently support the use of implied latches!
Control will remain in software-simulation!

In the Verilog produced by this example for we_decoder does not include the variable for index in the sensitivity list for the always block. Thus, when wr_sector_index is declared as a reg, the compiler error occurs.

Overview

Features we don't currently support:

Variables with little-endian ranges

wire[0:5] x;

References with little-endian ranges

wire[31:0] y;
initial $display(y[0:15]);

Deliverables

• Support for this language feature

Overview

For example (all legal syntax):

initial $display(!!x);
initial $display(|&x);
initial $display(~!x);

Deliverables

• Parser fix

Overview

Upgrading to catalina causes the osx build to fail.

Deliverables

• Fix the build

Overview

A variable is assigned the incorrect value when there are uppercase letters in the literal. An example to reproduce the problem can be found at https://github.com/ynaffitgnay/CascadeBenches/blob/master/bugreports/uppercase_hex_assignment.v

The current output is:

ffffffffffffffed
deaddeaddeaddead

It should be:

deaddeaddeaddead
deaddeaddeaddead

Deliverables

• Correct output for this use case

Overview

This means that the first time a program with variables which are only used in initial blocks is eval'ed, those variables will make it to n>1 compilation passes leading to inconsistent backend code. This has serious negative effects for backends which rely on code caching to reduce compilation overhead.

Deliverables

• Add dead code elimination pass after deleting initial blocks.

Overview

Bug report. Cascade crashes with the following error when a register is not assigned a value inside of an always @(*) block:

CASCADE SHUTDOWN UNEXPECTEDLY

Code to replicate the crash can be found here. Leaving rd_mux_sel declared does not appear to affect the behavior, but whenever rd_mux_sel is not assigned a value in the always block, the crash occurs.

Overview

Avmm backends initialize stream state to random values on construction. These should be synced to runtime state. Minimal example:

integer fd = $fopen("empty_file");
reg r;
integer COUNT = 0;
always @(posedge clock.val) begin 
  COUNT <= COUNT + 1;
  case (COUNT) 
    0: $fread(fd, r);
    1: $write($feof(fd));
    // ... enough counts that we're in the avmm backend
    100000: $write($feof(fd));
  endcase
end

While we're on the subject... AVMM backends don't seem to handle $feof() in write or display statements correctly either. We don't provide an eof handler in the avmm logic's Evaluate object, which means the default behavior (which always returns true) takes over.

Deliverables

• synchronize stream states with runtime on construction

Overview

The easiest way to expose this bug is to place a yield() statement at the end of the bitcoin benchmarks's always @(posedge clock.val) loop.

Deliverables

• Fix crash.

Overview

`timescale is a very common annotation. Short of doing something sensible with it, say if we extend cascade to support delay annotations, we should at the very least be able to recognize and ignore it. The current behavior is to emit a parse error which isn't particularly helpful.

Deliverables

• Parse `timescale annotations and emit a warning that cascade ignores them.