Synthetic frontend

[sweet12prof]

Synthetic frontend

Defines

• Logic and Plugins for frontend
• APIs that generate microkernels that can be issued at the frontend

Files

Find files in src/frontend/synthetic

• distributions : templated sequences that can be orchestrated to be according to a particular pattern (eg: strided mem addresses, random branch dir pattern etc)
• synthetic_kernels : contains low-level apis that generate very basic one line ctype_insts and higher-level apis that make use of those lower-levels and distributions to create complex micorkernels.
• bottleneck_table: some complex microkernels already created can be seen here
• synth_fe : frontend plugins
• Usage
• .... --frontend synthetic --bottleneck [ table_entry_from_bottleneck_table ]

Bottleneck Requirements

Some bottlenecks have some rquirements

• icache Limited : fdip must be off
• CBR/BR workloads: To truly make the kernels bound to control flow . we must ensure full ft issue every cycle. So every ft group for CF workloads has (ISSUE_WIDTH-1) leading NOPs followed by a branch. Also the issue packet sums up to icache_line_size for simplicity.
• For CBR/BR workloads ensure the uop cache is large enough to minimise frontend latency and limit workload to bad spec

[hlitz]

some first comments. I think you can actually squash the commits otherwise you have to rebase continuously. I will review the whole thing at once.

[hlitz]

If you do separate commits (which is good) then they need to be self-contained. Every commit needs to be able to compile which I don't think is the case. I saw older commits including header files introduced in newer commits. So individual self-contained commits is best but a single squashed is good to. If you decide to do multiple commits have them in separate Pull Requests.

…

On Fri, Jan 23, 2026 at 8:24 AM Chris Nutsukpui ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/frontend/synthetic/synth_fe.cc <#17 (comment)>: > +#include "ctype_pin_inst.h" +// #define PRINT_INSTRUCTION_INFO +#define DEBUG(proc_id, args...) _DEBUG(proc_id, DEBUG_SYNTHETIC_INST, ##args) + +/* intrinsic frontend variables */ +static ctype_pin_inst next_onpath_pi[MAX_NUM_PROCS]; +static ctype_pin_inst next_offpath_pi[MAX_NUM_PROCS]; +static bool off_path_mode[MAX_NUM_PROCS] = {false}; +static uint64_t off_path_addr[MAX_NUM_PROCS] = {0}; +static ctype_pin_inst dummyinst = {}; + +void synth_init() { + bottleneck = static_cast<BottleNeck_enum>(BOTTLENECK); + uop_generator_init(NUM_CORES); + synthetic_kernel_init(); + dummyinst = generate_synthetic_microkernel(0, bottleneck, START_PC, UID_START, false); Oh okay i will refactor accordingly. Actually its already handled in the kernel itself. This is a remnant of the old strategy, most of the arguments passed here are not even used, my bad. I will refactor accordingly. With regards to the commits, I made it 5 commits so that the plugin logic of the frontend, basic APIs and complex microkernels can be separate and decoupled. I will reduce the whole thing to just 2 or 3 commits. according to your direction. Sorry for the mess. — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3EU7QY7JGLGSPXMJWYFY34IJDMPAVCNFSM6AAAAACPRBZZDOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTMOJYGQYDCOJRGU> . You are receiving this because you commented.Message ID: ***@***.***>

[hlitz]

ROUND_ROBIN and RANDOM should pick from the same datastructure/object. I agree that "distribution" is not longer the right term when we pick from it in round robin order. So can we rename "distribution" to "sampler" or "generator" and then make it generic so that it can support all different pick strategies?

get_next_element() should just do: return sampler->next_element()

The API should like this:
struct type {
UNIFORM_SEQUENTIAL, //value_range numbers, starting at start_value, incrementing by 1
UNIFORM_RANDOM, //like UNFORM_SEQUENTIAL but shuffled
NORMAL_RANDOM, //computes as in Formula 1
USER_DEFINED //receives an optional argument, a vector of distinct values
}

Formula 1.
C(x) = Round( H * e^(-0.5 * ((x - mu) / sigma)^2)

Where C(x) is the x'th value of the value_range,
H = e^4.5 = 90
sigma = R/6
mu = R/2
and R = value_range

for a value_range of 1000 distinct values (e.g. 1-1000) this should yield a normal distributed sampler containing about 30000 values

sampler(type, start_value, value_range ) to define the values that will be generated by the sampler at construction time. So you want to prefill the sampler at construction time and then just draw from it.