Redline Telemetry

1 / 1

View past submissions Leaderboard

Back to submissions

Submission #1

PASSED

RankingPercentile

Latency

235.42 (82 cycles)ns

2nd

top 100%

Throughput (ranked)

348.31 (100.0%)MHz

2nd

top 100%

Throughput (visible)

348.31 (100.0%)MHz

—

top —%

Fmax

348.31MHz

—

top —%

Area

1096μm²

1st

top 1%

Score

99.55

1st

top 1%

Throughput is Fmax × the measured percentage. Rankings use hidden tests; visible tests are unranked feedback.

Submitted Solution

// Stream-based solution component
//
// Input stream interface:
//   i_ready (output): Assert when ready to accept input
//   i_valid (input): Asserted when input data is valid
//   i_payload_* (input): Input payload fields
//
// Output interface:
//   o_valid (output): Assert when output data is valid
//   o_payload* (output): Output payload fields
//
// Handshaking: Data transfers when both ready and valid are high

module Solution (
  input wire clk,
  input wire reset,
  output wire i_ready,
  input wire i_valid,
  input wire [1-1:0] i_payload_injector_fragment,
  input wire i_payload_injector_last,
  output wire [1-1:0] o_payload_fragment_1,
  output wire [8-1:0] o_payload_fragment_2,
  output wire [1-1:0] o_payload_fragment_3,
  output wire o_payload_last,
  output wire o_valid
);

// this problem has a specific latency requirement.  the output
// is valid on the first 0 after a 1.
//
// acc will start at 0.  then an input of 110 will have acc as
// 0, 1, 2 at the start of these three cycles.  this places the
// correct value in place.
//
// the next part is the saturation and overflow detection.
//
// let's work with a smaller version that caps out at 3.
// input of 10 gives x 1
// input of 110 would give x x 2
// input of 1110 gives x x x 3
// input of 11110 gives x x x x 3!, where the ! means overflow.
//
// this means the count looks like:
//
// acc | acc+1 | will_ovf | has_ovf | acc_load
//  00 | 001   | 0        | 0       | 1
//  01 | 010   | 0        | 0       | 1
//  10 | 011   | 0        | 0       | 1
//  11 | 100   | 1        | 0       | 0
//  11 | 100   | 1        | 1       | 0
//  
// will_ovf is the msb of acc+1.  has_ovf is registered version of
// will_ovf.  acc_load when !will_ovf.
//
// and then these actions only happen when input is valid and 1.
// if input is valid and 0, reset state.
// if input is not valid do nothing.
//
// the outputs must be gated so they are 0 on cycles without a
// completed pulse.
// 
// i'm taking this to mean that this includes cycles without i_valid.
// it's possible the outputs can be arbitrary when o_valid = 0,
// although that isn't how I read "cycles".
//
// having a bus valid and data valid both using "valid" makes
// the problem example confusing.  the example shows output
// samples of (0,0,0), which makes me think o_valid can be 1 based
// on i_valid.  otherwise why would there be two "valid" signals?

logic [7:0] acc;
logic overflow;
logic previous;

wire [8:0] acc_add = {1'b0, acc} + 1;
wire will_overflow = acc_add[8];

always@(posedge clk) begin
  if (i_valid) begin
    previous <= i_payload_injector_fragment;
    if (i_payload_injector_fragment) begin
      if (!will_overflow) begin
        acc <= acc_add[7:0];
      end
      overflow <= will_overflow;
    end else begin
      acc <= 8'b0;
      overflow <= 1'b0;
    end
  end

  // reset at end
  if (reset) begin
      acc <= 8'b0;
      overflow <= 1'b0;
      previous <= 1'b0;
  end 
end

wire fall = i_valid && !i_payload_injector_fragment && previous;

assign i_ready = 1'b1;
assign o_payload_fragment_1 = fall;
assign o_payload_fragment_2 = {(8){fall}} & acc;
assign o_payload_fragment_3 = fall && overflow;
assign o_payload_last = i_payload_injector_last;
assign o_valid = i_valid;

  
endmodule

Generated Verilog

// Stream-based solution component
//
// Input stream interface:
//   i_ready (output): Assert when ready to accept input
//   i_valid (input): Asserted when input data is valid
//   i_payload_* (input): Input payload fields
//
// Output interface:
//   o_valid (output): Assert when output data is valid
//   o_payload* (output): Output payload fields
//
// Handshaking: Data transfers when both ready and valid are high

module Solution (
  input wire clk,
  input wire reset,
  output wire i_ready,
  input wire i_valid,
  input wire [1-1:0] i_payload_injector_fragment,
  input wire i_payload_injector_last,
  output wire [1-1:0] o_payload_fragment_1,
  output wire [8-1:0] o_payload_fragment_2,
  output wire [1-1:0] o_payload_fragment_3,
  output wire o_payload_last,
  output wire o_valid
);

// this problem has a specific latency requirement.  the output
// is valid on the first 0 after a 1.
//
// acc will start at 0.  then an input of 110 will have acc as
// 0, 1, 2 at the start of these three cycles.  this places the
// correct value in place.
//
// the next part is the saturation and overflow detection.
//
// let's work with a smaller version that caps out at 3.
// input of 10 gives x 1
// input of 110 would give x x 2
// input of 1110 gives x x x 3
// input of 11110 gives x x x x 3!, where the ! means overflow.
//
// this means the count looks like:
//
// acc | acc+1 | will_ovf | has_ovf | acc_load
//  00 | 001   | 0        | 0       | 1
//  01 | 010   | 0        | 0       | 1
//  10 | 011   | 0        | 0       | 1
//  11 | 100   | 1        | 0       | 0
//  11 | 100   | 1        | 1       | 0
//  
// will_ovf is the msb of acc+1.  has_ovf is registered version of
// will_ovf.  acc_load when !will_ovf.
//
// and then these actions only happen when input is valid and 1.
// if input is valid and 0, reset state.
// if input is not valid do nothing.
//
// the outputs must be gated so they are 0 on cycles without a
// completed pulse.
// 
// i'm taking this to mean that this includes cycles without i_valid.
// it's possible the outputs can be arbitrary when o_valid = 0,
// although that isn't how I read "cycles".
//
// having a bus valid and data valid both using "valid" makes
// the problem example confusing.  the example shows output
// samples of (0,0,0), which makes me think o_valid can be 1 based
// on i_valid.  otherwise why would there be two "valid" signals?

logic [7:0] acc;
logic overflow;
logic previous;

wire [8:0] acc_add = {1'b0, acc} + 1;
wire will_overflow = acc_add[8];

always@(posedge clk) begin
  if (i_valid) begin
    previous <= i_payload_injector_fragment;
    if (i_payload_injector_fragment) begin
      if (!will_overflow) begin
        acc <= acc_add[7:0];
      end
      overflow <= will_overflow;
    end else begin
      acc <= 8'b0;
      overflow <= 1'b0;
    end
  end

  // reset at end
  if (reset) begin
      acc <= 8'b0;
      overflow <= 1'b0;
      previous <= 1'b0;
  end 
end

wire fall = i_valid && !i_payload_injector_fragment && previous;

assign i_ready = 1'b1;
assign o_payload_fragment_1 = fall;
assign o_payload_fragment_2 = {(8){fall}} & acc;
assign o_payload_fragment_3 = fall && overflow;
assign o_payload_last = i_payload_injector_last;
assign o_valid = i_valid;

  
endmodule

Timing Analysis

Path 1-2.866 ns

From: acc[2]$_SDFFE_PP0P_/Q

To: acc[4]$_SDFFE_PP0P_/D

Data Arrival: 2.697 ns

Arrival (ns)	Cell	Pin
0.000	Solution	`clk`
0.000	sky130_fd_sc_hvl__dfxtp_1	`acc[2]$_SDFFE_PP0P_/CLK`
0.566	sky130_fd_sc_hvl__dfxtp_1	`acc[2]$_SDFFE_PP0P_/Q`
0.566	sky130_fd_sc_hvl__and3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$378/C`
0.915	sky130_fd_sc_hvl__and3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$378/X`
0.915	sky130_fd_sc_hvl__nand3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$380/C`
1.231	sky130_fd_sc_hvl__nand3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$380/Y`
1.231	sky130_fd_sc_hvl__o21ai_1	`$abc$371$auto$blifparse.cc:396:parse_blif$382/A1`
1.787	sky130_fd_sc_hvl__o21ai_1	`$abc$371$auto$blifparse.cc:396:parse_blif$382/Y`
1.787	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$402/C`
2.021	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$402/Y`
2.021	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$405/B`
2.430	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$405/X`
2.430	sky130_fd_sc_hvl__o21a_1	`$abc$371$auto$blifparse.cc:396:parse_blif$410/A2`
2.697	sky130_fd_sc_hvl__o21a_1	`$abc$371$auto$blifparse.cc:396:parse_blif$410/X`
2.697	sky130_fd_sc_hvl__dfxtp_1	`acc[4]$_SDFFE_PP0P_/D`

Path 2-2.796 ns

From: acc[0]$_SDFFE_PP0P_/Q

To: acc[3]$_SDFFE_PP0P_/D

Data Arrival: 2.605 ns

Arrival (ns)	Cell	Pin
0.000	Solution	`clk`
0.000	sky130_fd_sc_hvl__dfxtp_1	`acc[0]$_SDFFE_PP0P_/CLK`
0.718	sky130_fd_sc_hvl__dfxtp_1	`acc[0]$_SDFFE_PP0P_/Q`
0.718	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$376/B`
1.107	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$376/X`
1.107	sky130_fd_sc_hvl__nand3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$380/B`
1.307	sky130_fd_sc_hvl__nand3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$380/Y`
1.307	sky130_fd_sc_hvl__o21ai_1	`$abc$371$auto$blifparse.cc:396:parse_blif$382/A1`
1.741	sky130_fd_sc_hvl__o21ai_1	`$abc$371$auto$blifparse.cc:396:parse_blif$382/Y`
1.741	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$402/C`
2.197	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$402/Y`
2.197	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$405/B`
2.505	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$405/X`
2.505	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$407/B`
2.605	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$407/Y`
2.605	sky130_fd_sc_hvl__dfxtp_1	`acc[3]$_SDFFE_PP0P_/D`

Path 3-2.520 ns

From: acc[0]$_SDFFE_PP0P_/Q

To: acc[1]$_SDFFE_PP0P_/D

Data Arrival: 2.359 ns

Arrival (ns)	Cell	Pin
0.000	Solution	`clk`
0.000	sky130_fd_sc_hvl__dfxtp_1	`acc[0]$_SDFFE_PP0P_/CLK`
0.718	sky130_fd_sc_hvl__dfxtp_1	`acc[0]$_SDFFE_PP0P_/Q`
0.718	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$376/B`
1.107	sky130_fd_sc_hvl__and2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$376/X`
1.107	sky130_fd_sc_hvl__nand3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$380/B`
1.307	sky130_fd_sc_hvl__nand3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$380/Y`
1.307	sky130_fd_sc_hvl__o21ai_1	`$abc$371$auto$blifparse.cc:396:parse_blif$382/A1`
1.741	sky130_fd_sc_hvl__o21ai_1	`$abc$371$auto$blifparse.cc:396:parse_blif$382/Y`
1.741	sky130_fd_sc_hvl__nor2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$385/B`
2.048	sky130_fd_sc_hvl__nor2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$385/Y`
2.048	sky130_fd_sc_hvl__nor2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$398/B`
2.154	sky130_fd_sc_hvl__nor2_1	`$abc$371$auto$blifparse.cc:396:parse_blif$398/Y`
2.154	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$401/A`
2.359	sky130_fd_sc_hvl__nor3_1	`$abc$371$auto$blifparse.cc:396:parse_blif$401/Y`
2.359	sky130_fd_sc_hvl__dfxtp_1	`acc[1]$_SDFFE_PP0P_/D`

Post-Synthesis Verilog

Download synth.v