sgherbst / svreal Goto Github PK

Hey! Awesome library. Can you explain what you mean by the range of a in this section:

In svreal, fixed-point formats are generally determined automatically from the range of the signals they represent. In this case, the range of a is set to +/- 5.0, and the range of b is set to +/- 10.0.

I'm far from a fixed point expert, and am only aware of the Q format to establish bits for integer and fractional widths.

The buildkite CI test for this repo, which used to be here:
https://buildkite.com/stanford-aha/svreal
appears to be long dead and maybe never used at all. So, in the interest of efficiency, I am deleting the pipeline from the buildkite repo. The pipeline steps still exist in this repo:
https://github.com/sgherbst/svreal/tree/master/.buildkite/pipeline.yml
and can be used if/when you might want to reinstate the pipeline at some future time. But the old webhook
f78f1e38
no longer points to anything, and it can safely be deleted
(see https://github.com/sgherbst/svreal/settings/hooks).

At the moment, defining RANGE_ASSERTIONS will cause svreal to fail with a fatal error whenever a real value is outside of the range of the signal to which it is being assigned. As currently implemented, though, this is pickier than necessary -- logic delays may cause values to temporarily exceed the allowed range, without causing any issues. Something like this might work:

`ifdef RANGE_ASSERTIONS
    `undef RANGE_ASSERTIONS
    `COPY_FORMAT_REAL(in, in_inertial);
    `define RANGE_ASSERTIONS
`else
    `COPY_FORMAT_REAL(in, in_inertial);
`endif
assign #(1ns) in_inertial = in;

always @(in_inertial) begin
    if (!((min <= `TO_REAL(in_inertial)) && (`TO_REAL(in_inertial) <= max))) begin
        $display("Real number %s with value %f out of range (%e to %e).", name, `TO_REAL(in_inertial), min, max);
        $fatal;
    end  
end  

We might want to make that inertial delay of 1ns user-adjustable, and maybe also have a flag for if range assertions should be fatal errors or just warnings.

Currently, updating ROM contents requires rebuilding the FPGA bitstream, which can be very time consuming. There are two ways to get around this problem:

1. Update the bitstream file directly with the new BRAM contents, then re-program the FPGA. This is possible using the data2mem tool (page 32 here). Since Vivado may sometimes use LUTs and FFs instead of a BRAM, the user would need to force BRAM inference for blocks that should be updatable in this manner. One advantage of this approach, however, is that there would be no additional resource utilization.
2. Wire control signals to the BRAM and update the BRAM contents while the FPGA is running. This could be done using either a single-port BRAM or a dual-port BRAM. This approach is less tool-dependent and doesn't require the user to force BRAM inference. However, it would increase resource utilization.

This task encompasses identifying which approach is more promising, and then implementing the required features in svreal (i.e., flag to force BRAM inference or port for writing BRAM contents).

Looks like the Vivado simulator outputs "x" when "x" is multiplied by "0". For that reason, we might want to have mul_real check for that condition and output "0" if either input is zero, e.g.

assign prod = ((a == 0) || (b == 0)) ? 0 : (a * b);

This can otherwise cause x's to propagate during some startup scenarios.