Ensure vlog_tb_utils is not included in the file-set for verilator runs. Verilator versions < 4.030 do not implement dumpfile and dumpvar, which are used in vlog_tb_utils.

This project is now deleted.

https://www.librecores.org/ShashankVM/stack-systemverilog

Thank you, @imphil

Unfortunately, deleting projects is currently only possible through us. Please let us know which project we should delete and we'll do that for you.

hi, l saw some infomation in README.md .:"If adding/removing instructions, espresso must be installed (used by tools/coredecode)". Can this increase the custom instructions ，and how to use this script .

thank you for your help

FuseSoC currently does one (and after #391 two) dependency resolution runs, and expects to be able to fully resolve all dependencies in that run.

With generators adding dynamicity to the picture, we should be looking into an iterative dependency resolution as long as new information becomes available.

What I'm looking for is an algorithm like this:

core_db = collect_core_files()
dep_tree = solve_dependency_tree(core_db, entrypoint)

while (True):
	# Perform all operations which might produce new cores
	changed = False
	generators = get_generator_list(dep_tree)
	for g in generators: 
		new_cores = run_generator_and_get_new_cores(g)
		if new_cores:
			core_db += new_cores
			changed = True	

	# In the future: Expand to look at certain remote locations for new cores
	
	# Resolve dependency tree again to take new information into account.
	dep_tree_before = dep_tree
	dep_tree = solve_dependency_tree(core_db, entrypoint)
	if dep_tree_before == dep_tree:
		break

if not is_completely_resolved(dep_tree):
	exit("Unable to resolve all dependencies.")

This algorithm isn't guaranteed to stabilize, so we need to add additional exit conditions, e.g. abort after n tries. Equally, there is room for some optimization (e.g. avoid the second resolution if generators didn't produce new cores).

Use cases for this new approach:

• Cores can depend on cores which are produced by a generator, but don't exist anywhere else. This is actually something we're likely to need in OpenTitan, and effectively solves #235 through generators (more on that once I've finished thinking about it).
• We can expand the search scope step-by-step. For example: First, only search local cores, then also search cores in a certain remote location (librecores!). This will keep dependency resolution fast for local use cases.

@danielmlynek, it is perfectly OK to request changes. If they are reasonable and compatible with our toolsets, they will be considered for merging. We do run LEC on all requested RTL changes that do not modify the functionality or fix bugs.

Thank you for your contributions.

Please, do not ask to change not essential or style related things.

Some simulators hangs on orginal code - that is why I've requested this change.

Hi Daniel,

Did the original RTL code cause any simulation/synthesis problem?

All our simulation/synthesis tools did not flag this. Furthermore, this coding style is recommended by Synopsis as less prone to infer unwanted latches in combo logic.

The code represents combinatorial logic which is by definition glitchy and there are other pieces of glitchy logic in the core. I've never heard that combo logic in RTL cause any deadlocks ..

Please, do not ask to change not essential or style related things.

Why do you change RTL? Initializing signal to default value at the begining of process may lead to glitches an in this case it cause deadlock between proceses

RIVIERA variable in Makefile is not used - why to change? That is true. There was a typo so Ijust have fix it. This variable can be removed or may be used to define name of riviera compilation/simulation program. Let me know if I should open PR to fix it.

Why to change what is deleted by make clean ? Don't create work directory where you run simulations ... "work" was dublicated so I've removed the 2nd its occurense from make clean list.