28 Aug 2023

Previous journal:	Next journal:
0134-2023-08-27.md	0136-2023-08-29.md

raybox-zero sim keyboard/mouse control and partial POV SPI synth success

Accomplishments

Added keyboard/mouse view control into sim, per Raybox.
Default is typical mouse left/right (as though view is rated), but o (orientation) key toggles mouse X/Y axis swapping, so that mouse up/down controls what appears to be the up/down view orientation. When in this mode, strafing isn't as expected -- how would you represent drifting up/down vs. forwards/backwards anyway? Maybe up/down are elevation, and space/CTRL are advance/retreat?
Motion speed in sim should be based on real time, but is currently just based on frame.
Fixed an issue with multiple drivers on internal pov.ready signal: https://github.com/algofoogle/raybox-zero/commit/a26525aca430deb3163502bb46c3d6f5b9024e07
- NOTE: This showed up as a synth error in OpenLane step 1, and that at least made sense because of this competing with this, HOWEVER...
- ...even after I put the latter one within if (!reset), I was still getting the same error.
- Strangely, though, I wasn't always getting it... I think maybe the SYNTH_STRATEGY was leading to differing results.
- In any case, reworking per the commit above seemed to make the error go away.
- See below for the multiple drivers error.

Synth results

Baseline (before POV SPI): `3cda177`

	4x2:1	8x2:1	4x2:2	8x2:2	4x2:3	8x2:3	4x2:4	8x2:4
cells_pre_abc	18,675	18,675	18,675	18,675	18,478	18,478	18,675	18,675
TotalCells	20,968	35,823	20,933	35,903	0	0	-1	-1
suggested_mhz	25.00	25.00	40.80	40.67	47.62	47.62	47.62	47.62
logic_cells	8,054	7,990	8,046	8,021	0	0	0	0
utilisation_%	51.99	25.80	51.99	25.80	0.00	0.00	0.00	0.00
wire_length_um	265,305	246,408	265,320	246,738	0	0	0	0

Summary:

25MHz is achievable, but fails in standard TT04 SYNTH_STRATEGY (due to yosys-abc bug).
~18.7k cells reduces to ~8k

Initial POV SPI attempt: raybox-zero `cc01526`

Combos 1, 2, 4 (tt04) both sizes: Multiple drivers error:

[STEP 1]
[INFO]: Running Synthesis (log: ../work/runs/wokwi/logs/synthesis/1-synthesis.log)...
[ERROR]: Yosys checks have failed: Encountered check error:
Warning: multiple conflicting drivers for tt_um_algofoogle_raybox_zero.\rbzero.pov.ready:
    port Q[0] of cell $flatten\rbzero.\pov.$procdff$508 ($dff)
    port Q[0] of cell $flatten\rbzero.\pov.$procdff$522 ($dff)

child process exited abnormally
[ERROR]: See the full report here: ../work/runs/wokwi/reports/synthesis/1-synthesis_pre_synth.chk.rpt

Combo 3 (MPW8) at 4x2: Target density too low (i.e. Area too small). This is kinda expected for 4x2 tiles at this point before I've done optimisations:

[STEP 7]
[INFO]: Running Global Placement (log: ../work/runs/wokwi/logs/placement/7-global.log)...
[ERROR]: during executing openroad script /openlane/scripts/openroad/gpl.tcl
[ERROR]: Log: ../work/runs/wokwi/logs/placement/7-global.log
[ERROR]: Last 10 lines:
[InitialPlace]  Iter: 16 CG residual: 0.00062282 HPWL: 107165583
[InitialPlace]  Iter: 17 CG residual: 0.00077172 HPWL: 106861248
[InitialPlace]  Iter: 18 CG residual: 0.01332201 HPWL: 107038044
[InitialPlace]  Iter: 19 CG residual: 0.00053054 HPWL: 106697781
[InitialPlace]  Iter: 20 CG residual: 0.00062116 HPWL: 106565949
[ERROR GPL-0302] Use a higher -density or re-floorplan with a larger core area.
Given target density: 0.55
Suggested target density: 0.85

Combo 3 at 8x2: SIGABRT in OpenROAD:

[STEP 7]
[INFO]: Running Global Placement (log: ../work/runs/wokwi/logs/placement/7-global.log)...
[ERROR]: during executing openroad script /openlane/scripts/openroad/gpl.tcl
[ERROR]: Log: ../work/runs/wokwi/logs/placement/7-global.log
[ERROR]: Last 10 lines:
33# 0x00007F80964F5F1E in /lib64/libtcl8.5.so
34# Tcl_EvalEx in /lib64/libtcl8.5.so
35# Tcl_Eval in /lib64/libtcl8.5.so
36# sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) in openroad
37# ord::tclAppInit(Tcl_Interp*) in openroad
38# Tcl_Main in /lib64/libtcl8.5.so
39# main in openroad
40# __libc_start_main in /lib64/libc.so.6
41# 0x0000000000CAB507 in openroad
child killed: SIGABRT

Fixed POV SPI: `7aae611`

	4x2:1	8x2:1	4x2:2	8x2:2	4x2:3	8x2:3	4x2:4	8x2:4
cells_pre_abc	29,795	29,795	29,795	29,795	29,682	29,682	29,795	29,795
TotalCells	18,462	42,260	18,462	42,106	0	0	14,618	39,259
suggested_mhz	24.39	25.00	47.62	37.04	47.62	47.62	47.62	33.84
logic_cells	16,142	17,026	16,142	16,901	12,346	12,346	12,298	12,959
utilisation_%	0.00	53.26	0.00	53.26	0.00	0.00	0.00	41.03
wire_length_um	0	535,742	0	536,900	0	0	0	368,835

Summary:

Only 8x2 fits so far.
Combo 4 (TT04 OpenLane with default SYNTH_STRATEGY and 50MHz clock) is notably smaller than combos 1 and 2!
~30k cells reduces to ~13k with combo 4.
Combo 1, 8x2, success at 25MHz.
Combo 2, 8x2, completes with setup violations at 50MHz.
Combo 3, 8x2, crash as above with SIGABRT.
Combo 4, 8x2, completes with setup violations at 50MHz.

Note also:

WARNING: 8x2 combo 4 had antenna violations??

From --full-summary (metrics.csv):

pin_antenna_violations : 7
net_antenna_violations : 7

Worst was 675 versus 400 target. Many were still in the 400s, though.

This is the list from runs/wokwi/reports/signoff/40-antenna_violators.rpt:

_05709_ 
_06774_ 
rbzero.height_scaler.i_data\[3\] 
rbzero.row_render.side 
rbzero.wall_tracer.rayAddendY\[-2\] 
rbzero.wall_tracer.rayAddendY\[0\] 
rbzero.wall_tracer.rayAddendY\[1\]

Total power is 2.84 watts!

===========================================================================
report_power
============================================================================
======================= Typical Corner ===================================

Group                  Internal  Switching    Leakage      Total
                        Power      Power      Power      Power (Watts)
----------------------------------------------------------------
Sequential             2.79e-03   4.56e-04   4.71e-09   3.24e-03   0.1%
Combinational          1.17e+00   1.66e+00   6.85e-08   2.83e+00  99.9%
Macro                  0.00e+00   0.00e+00   0.00e+00   0.00e+00   0.0%
Pad                    0.00e+00   0.00e+00   0.00e+00   0.00e+00   0.0%
----------------------------------------------------------------
Total                  1.18e+00   1.66e+00   7.32e-08   2.84e+00 100.0%
                        41.5%      58.5%       0.0%

From runs/wokwi/logs/synthesis/1-synthesis.log:

reciprocal params for Q12.12:  n1466=001774, n10012=001004, nSat=7FFFFF

Other oddities:
- 1-synthesis.errors: ABC: Error: The network is combinational. -- supposedly can be ignored.
- 1-synthesis.warnings: ABC: Warning: Detected 2 multi-output gates (for example, "sky130_fd_sc_hd__fa_1"). -- ??
- 2-sta.warnings: Warning: There are 16 unconstrained endpoints.

Next steps

Fix synth warnings inc. $rtoi stuff.

Reciprocal sharing. Thoughts:

If we were to get away with exactly 1 reciprocal, we need to work out the range of its possible inputs and outputs.
e.g. truncating 'facing' vector is definitely likely and would be effective, and so far the only other reciprocal is the height_scaler which also only uses bits 2:-8.

FSM update might look like this:

//SMELL: Ideally we want this shared_reciprocal to be outside of wall_tracer, so it doesn't 'belong'
// to any one module. If we do that, how do we control registered access to it? Or do we use a mux instead?
// I'd rather not have to tristate it, but maybe that would be needed...?
reg `F rcp_in, rcp_out;
wire rcp_sat;
wire rcp_abs = 1'b1; //SMELL: ??
reciprocal #(.M(`Qm),.N(`Qn)) shared_reciprocal (.i_data(rcp_in), .i_abs(rcp_abs), .o_data(rcp_out), .o_sat(rcp_sat));
...
reg `F stepDistX, stepDistY;
...
// Add new states between PREP and STEP, or blend them at the edges...
RCPX1: begin
    rcp_in <= rayDirX;
    state <= RCPX2;
end
RCPX2: begin
    // This state is just here to give the reciprocal's large combo logic time to settle.
    state <= RCPX3;
end
RCPX3: begin
    //SMELL: This state is probably not necessary to keep separate from RCPY1,
    // but I'm just considering it now because we have plenty of time and this might
    // help avoid both setup and hold violations.
    stepDistX <= rcp_out;
    state <= RCPY1;
end
RCPY1: begin
    rcp_in <= rayDirY;
    ...

NOTE: Power consumption should reduce because the reciprocal won't be frequently changeable now via SPI/POV.

Sim could do with a view rotate option. Is there a cheating way we could just rotate the whole canvas without having to change the X/Y code?

Notes

Is it better to have rcp_in as a register, or driven by a mux?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

0135-2023-08-28.md

0135-2023-08-28.md

28 Aug 2023

raybox-zero sim keyboard/mouse control and partial POV SPI synth success

Accomplishments

Synth results

Baseline (before POV SPI): `3cda177`

Initial POV SPI attempt: raybox-zero `cc01526`

Fixed POV SPI: `7aae611`

Next steps

Notes

Files

0135-2023-08-28.md

Latest commit

History

0135-2023-08-28.md

File metadata and controls

28 Aug 2023

raybox-zero sim keyboard/mouse control and partial POV SPI synth success

Accomplishments

Synth results

Baseline (before POV SPI): 3cda177

Initial POV SPI attempt: raybox-zero cc01526

Fixed POV SPI: 7aae611

Next steps

Notes

Baseline (before POV SPI): `3cda177`

Initial POV SPI attempt: raybox-zero `cc01526`

Fixed POV SPI: `7aae611`