Move CoreCounter behind the frontend

[xThaid]

• moved CoreCounter behind the frontend, so in particular behind all of its FIFOs. As the result, the flushing process should take a few cycles less.
• decode_fifo is now a Pipe
• the size of the instruction buffer can be parametrized (I increased the default)

edit: I also had to rename debug_signals in CoreConfiguration as auto_debug_signals incorrectly assumed that this field is of protocol HasDebugSignals

Metric backend.retirement.trap_latency/sum:

	aha-mont64	crc32	minver	nettle-sha256	nsichneu	slre	statemate	ud
Before	70032	2138	51797	1924	27950	89013	10643	42058
After	52303	2136	33884	1473	20082	75631	8539	24714

Depends on #698

[github-actions[bot]]

Benchmarks summary

Performance benchmarks

aha-mont64	crc32	minver	nettle-sha256	nsichneu	slre	statemate	ud
▲ 0.426 (+0.019)	▼ 0.513 (-0.014)	▲ 0.351 (+0.030)	▲ 0.655 (+0.004)	▲ 0.364 (+0.019)	▲ 0.293 (+0.010)	▲ 0.329 (+0.012)	▲ 0.435 (+0.030)

You can view all the metrics here.

Synthesis benchmarks (basic)

Device utilisation: (ECP5)	LUTs used as DFF: (ECP5)	LUTs used as carry: (ECP5)	LUTs used as ram: (ECP5)	Max clock frequency (Fmax)
▼ 22370 (-408)	▲ 5730 (+169)	▲ 802 (+32)	▼ 896 (-108)	▼ 51 (-1)

Synthesis benchmarks (full)

Device utilisation: (ECP5)	LUTs used as DFF: (ECP5)	LUTs used as carry: (ECP5)	LUTs used as ram: (ECP5)	Max clock frequency (Fmax)
▲ 33515 (+3572)	▲ 8983 (+180)	▼ 1944 (-20)	▼ 1076 (-108)	▲ 40 (+0)

[tilk]

The performance loss on crc32 is worrying. Did you investigate why that happened? Is this because of clear conflicts?

[xThaid]

The performance loss is caused by the increased size of the fetch queue (the instruction buffer). I need to investigate further why that is.

[xThaid]

It seems that the performance loss is not directly related to this change. I opened an issue #702 for that.