profile
viewpoint
Thomas Hornschuh ThomasHornschuh The Bonfire Project Heidelberg, Germany https://bonfirecpu.eu

bonfireprocessor/bonfire-cpu 21

FPGA optimized RISC-V (RV32IM) implemenation

ThomasHornschuh/bonfire-soc-fireant 5

Bonfire SoC running on FireAnt FPGA Board

ThomasHornschuh/elua 2

eLua Project on GitHub

ThomasHornschuh/autobahn-js 0

WAMP in JavaScript for Browsers and NodeJS

ThomasHornschuh/edalize 0

An abstraction library for interfacing EDA tools

ThomasHornschuh/elua_examples 0

Some eLua Example code

issue openedolofk/fusesoc

Iterative dependency resolution

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.

created time in 2 days

startedToporin/SatochipApplet

started time in 3 days

delete branch olofk/fusesoc

delete branch : ci-gh-actions

delete time in 3 days

startedInfineon/BlockchainSecurity2Go-Android

started time in 3 days

PR opened MannyPeterson/HeliOS

Added a blink and button example!

Using this code, you can test the difference between using delay() and using Helios. If you run the regular example, the button will not start as soon as you push it.

+177 -0

0 comment

5 changed files

pr created time in 4 days

fork bogdanm/snapcast

Synchronous multiroom audio player

fork in 4 days

startedexclave/exclave

started time in 4 days

issue commentolofk/fusesoc

Move FuseSoC configuration on Windows to APPDATA/LOCALAPPDATA

XDG isn't applicable to Windows at all, it's a Linux-only thing.

imphil

comment created time in 7 days

issue commentolofk/fusesoc

Move FuseSoC configuration on Windows to APPDATA/LOCALAPPDATA

I'm not a big fan of moving sruff without a good reason since we need to add code for the migration parh and probably lose the backwards compatibility.

With that said, what does the xdg spec say about this on windows? ~/.config is the fallback if it can't find the xdg definitions. I' ve been considering to use the xdg_utils python package to save a few lines of code and add consistency but it has been low priority

imphil

comment created time in 8 days

push eventolofk/fusesoc

Alfred E Neuman

commit sha 00d84045170bb57c2ff3d15625b3f51758baebad

Update index.rst

view details

push time in 9 days

PR merged olofk/fusesoc

Reviewers
Update index.rst

Hello, At least on my windows installation the initial fusesoc.conf file is located in the following Path: %HOMEPATH%\.config\fusesoc
Regards, Markus

+3 -2

3 comments

1 changed file

hackathlete

pr closed time in 9 days

pull request commentolofk/fusesoc

Update index.rst

Seems like many other applications originating from the Unix world have the same problem :-) I filed https://github.com/olofk/fusesoc/issues/448 to get this sorted properly, but for now, let's at least document what we have. Thank you!

hackathlete

comment created time in 9 days

issue openedolofk/fusesoc

Move FuseSoC configuration on Windows to APPDATA/LOCALAPPDATA

Currently, FuseSoC stores its configuration file under Windows at ~/.config, which resolves normally to something like C:\Users\john\.config.

Until #447 we documented we'd put the config into LOCALAPPDATA, but actually put it into the home directory.

https://github.com/olofk/fusesoc/blob/24350b2d10a8b27819d84210554654baff6cd877/fusesoc/main.py#L203-L204

Using the home directory is very Unix-y, the more typical variant for Windows would be %APPDATA% (roaming, i.e. per user) or %LOCALAPPDATA% (per user and machine).

We should

  • Decide on the use of LOCALAPPDATA vs APPDATA. (Where does pip place its packages? Do they roam?)
  • Change the config file location.
  • Include code to move the config file over if it is found in the old path.

created time in 9 days

pull request commentolofk/fusesoc

Update index.rst

You're welcome @imphil and thanks for your explanation!

From a user perspective I agree, that %LOCALAPPDATA% is a better location as this would keep my %HOMEPATH% tidy. My %HOMEPATH% directory is cluttered with a lot folders from many different tools (for example .eclipse, .atom, .mozilla, ...). It seems, that using %HOMEPATH% is a common practice.

hackathlete

comment created time in 9 days

pull request commentolofk/fusesoc

Update index.rst

Thanks for this documentation update @hackathlete!

Your fix is correct, we use os.path.expanduser() on all platforms, which is documented for Windows at https://docs.python.org/3/library/os.path.html#os.path.expanduser.

I'm wondering, however, if the current behavior is actually what we want, or if we should put the config file into LOCALAPPDATA, where it probably belongs?

(In that case, we should still take this PR for now, but do a follow-up to migrate the config file to LOCALAPPDATA.)

hackathlete

comment created time in 9 days

PR opened olofk/fusesoc

Update index.rst

Hello, At least on my windows installation the initial fusesoc.conf file is located in the following Path: %HOMEPATH%.config\fusesoc
Regards, Markus

+3 -2

0 comment

1 changed file

pr created time in 9 days

pull request commentolofk/fusesoc

Test the position attribute for generate blocks

This test is only to document the current behavior, which will change in #391. I want to ensure, however, that we have a very clear picture on what changes and ensure that we don't miss anything, so I'd like to get this test change in first.

imphil

comment created time in 10 days

PR opened olofk/fusesoc

Test the position attribute for generate blocks

The position attriute is meant to insert files generated by the core at a specific location: after the chosen core, at the beginning of the file list, or at the end. This behavior was not tested so far. Add a test for it.

+31 -3

0 comment

3 changed files

pr created time in 10 days

pull request commentolofk/fusesoc

Fix regression in the file order of designs with generators.

Seems like I dropped @benreynwar's actual fix and only picked the test changes in my rebasing action. It is a mystery to me why CI didn't pick that up, but the most likely explanation is that the test ran actually not against the PR, but against master.

I added the changes back in https://github.com/olofk/fusesoc/pull/444. Sorry for the confusion (well, I mostly confused myself).

benreynwar

comment created time in 10 days

push eventolofk/fusesoc

Ben Reynwar

commit sha 9649a004db47363e71be80789a6797a8fae40c2c

Fix regression in the file order with generators Fileset files should come before generated files within a core to be consistent with previous fusesoc behavior.

view details

Philipp Wagner

commit sha 638791191e2f8cab2e78ef2a39a700dd149f4f12

CI: Run test in forked repo context Right now, we run pull request CI jobs in the context of the olofk/fusesoc repository. We did this to be able to create Check runs, which show the pytest results in the GitHub UI. There are multiple problems with that: First, the runs actually didn't contain any data. That's probably fixable if we found the right configuration regarding test result files and artifacts. Second, and more importantly, it seems that the "old" test code was run, i.e. pytest didn't pick up test changes done in the PR. That's hard to believe, but also not very useful, as PRs often modify code and tests at the same time. There might be some misconfiguration going on somewhere, but I didn't debug it fully. Finally, the test result reporting action we used is actually rather slow (significantly slower than the test runs themselves), as it creates and then runs a Docker container. In this commit, we try a different approach and annotate the source code with test results.

view details

Philipp Wagner

commit sha 24350b2d10a8b27819d84210554654baff6cd877

CI: Switch explicitly to Ubuntu 20.04 ... to avoid GitHub Actions warnings about an upcoming migration.

view details

push time in 10 days

PR merged olofk/fusesoc

CI: Run test in forked repo context

Right now, we run pull request CI jobs in the context of the olofk/fusesoc repository. We did this to be able to create Check runs, which show the pytest results in the GitHub UI. There are multiple problems with that:

First, the runs actually didn't contain any data. That's probably fixable if we found the right configuration regarding test result files and artifacts.

Second, and more importantly, it seems that the "old" test code was run, i.e. pytest didn't pick up test changes done in the PR. That's hard to believe, but also not very useful, as PRs often modify code and tests at the same time. There might be some misconfiguration going on somewhere, but I didn't debug it fully.

Finally, the test result reporting action we used is actually rather slow (significantly slower than the test runs themselves), as it creates and then runs a Docker container.

In this commit, we try a different approach and annotate the source code with test results.

+33 -52

1 comment

4 changed files

imphil

pr closed time in 10 days

pull request commentolofk/fusesoc

Fix regression in the file order of designs with generators.

Oh man. CI in this PR (and local testing) passed, but after rebasing this PR into master CI fails (https://github.com/olofk/fusesoc/runs/1417908199). Let me figure out what is going on ...

benreynwar

comment created time in 10 days

issue openedolofk/fusesoc

Disable AppVeyor GH integration

We currently get a failing CI test for each PR:

grafik

This is due to AppVeyor not finding a config file any more (which is expected).

@olofk can you deactive the AppVeyor integration in the GH settings of this repository?

created time in 10 days

pull request commentolofk/fusesoc

CI: Run test in forked repo context

Nice! we now actually get test results inline in the code, e.g.

grafik

Currently, since we do matrix testing, each individual platform shows up and identical failures are not merged. That's not super beautiful, but probably better to show too much than too little. And not worth going in and developing a merging solution on our own, I'm sure someone will come up with something like that in the not too distant future.

imphil

comment created time in 10 days

PR opened olofk/fusesoc

CI: Run test in forked repo context

Right now, we run pull request CI jobs in the context of the olofk/fusesoc repository. We did this to be able to create Check runs, which show the pytest results in the GitHub UI. There are multiple problems with that:

First, the runs actually didn't contain any data. That's probably fixable if we found the right configuration regarding test result files and artifacts.

Second, and more importantly, it seems that the "old" test code was run, i.e. pytest didn't pick up test changes done in the PR. That's hard to believe, but also not very useful, as PRs often modify code and tests at the same time. There might be some misconfiguration going on somewhere, but I didn't debug it fully.

Finally, the test result reporting action we used is actually rather slow (significantly slower than the test runs themselves), as it creates and then runs a Docker container.

In this commit, we try a different approach and annotate the source code with test results.

+26 -49

0 comment

4 changed files

pr created time in 10 days

pull request commentolofk/fusesoc

Resolve dependencies for generator-created cores

Here we go. I updated this PR on top of @benreynwar's test improvements, and did a bit more digging around the position attribute of generators. There are three things which need addressing:

  • position is untested so far.
  • position will most likely be unsupported/not needed any more with this change. I need to properly test and document that.
  • Somehow CI is failing, but not for me locally. Could be a Python version issue, I'll do some digging.
imphil

comment created time in 10 days

push eventolofk/fusesoc

Ben Reynwar

commit sha 0fc7783619ffb91d267759f5ae2d3fb944bd90bd

Fix typo in deptree test cores Change typo fileType to file_type in deptree test core files.

view details

Ben Reynwar

commit sha d89aac24ab3edc16d474f46dc8ca3814e8d1b8a2

Better test file order in test_coremanager Improve test_coremanager so that it also tests generator file order and is not so sensitive to implementation details of core order.

view details

push time in 10 days

PR merged olofk/fusesoc

Fix regression in the file order of designs with generators.

Recent refactoring of the Edalizer class introduced a bug where the files in the generated .eda are not in a dependency-consistent order.

This fixes this bug, by keeping track of how the generated cores are positioned in the ordered list of cores.

+167 -34

10 comments

8 changed files

benreynwar

pr closed time in 10 days

pull request commentolofk/fusesoc

WIP: Fix regression in the file order of designs with generators.

OK, here we go. I updated this PR with a version that contains addresses my review comments and a couple tiny fixes, but is otherwise Ben's code. Let's get this in to document the current state of affairs regarding generators.

I do have code ready for #391 to update this test with the slightly different behavior we get in this PR. This should make it much easier to see what is actually changing.

benreynwar

comment created time in 10 days

push eventolofk/fusesoc

Philipp Wagner

commit sha 2e9c10b8585ea76812de60afecdeb6936a186532

Fix lint Turns out we had a small window where this lint job didn't run when merging PRs, and things broke immediately. (And it's even my fault!)

view details

push time in 10 days

more