profile
viewpoint

zephyrproject-rtos/zephyr 3872

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.

jeremiah-c-leary/vhdl-style-guide 56

Style guide enforcement for VHDL

UVVM/UVVM_Community_VIPs 7

Repository for the UVVM community to share VIPs. Community forum: https://forum.uvvm.org/ UVVM.org: https://uvvm.org/

m-kru/fsva 6

FuseSoc Verification Automation

wzab/addr_gen_wb 3

Support for automatic address map generation and address decoding logic for Wishbone connected hierachical systems

m-kru/fp2p 1

fp2p - FPGA Port To Pin. Utility for safe and reusable port to pin assignment in multi-board FPGA designs.

m-kru/hdls 1

Hardware Description Language Server

m-kru/VHDL-examples 1

Examples of the VHDL syntax, libraries, packages, practices etc.

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 4 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 4 days

push eventolofk/fusesoc

Alfred E Neuman

commit sha 00d84045170bb57c2ff3d15625b3f51758baebad

Update index.rst

view details

push time in 5 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 5 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 5 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 5 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 7 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 7 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 7 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 7 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 7 days

PR merged olofk/fusesoc

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!)

+4 -1

0 comment

1 changed file

imphil

pr closed time in 7 days

PR opened olofk/fusesoc

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!)

+4 -1

0 comment

1 changed file

pr created time in 7 days

push eventolofk/fusesoc

Philipp Wagner

commit sha 63353c418898c56522c3d9800b64a27edf339c3a

Add tox configuration Tox makes it much easier to run the FuseSoC tests in an isolated environment without installing fusesoc first, or overwriting a production version. Simply run `tox` in the FuseSoC root source directory to run all tests. Fixes #213

view details

Philipp Wagner

commit sha b94e8c1bf28e208044a31f1c100bbfb3fc393b22

Enable GitHub actions for CI It's much easier to maintain GitHub actions than Travis and AppVeyor together.

view details

Philipp Wagner

commit sha 0ffaa6ffd4a225a89a1a5ffb9160011606a7e323

Remove Appveyor and Travis from CI Not needed any more now that we have GitHub Actions enabled.

view details

Philipp Wagner

commit sha 3652dde98691b9c5774dedd726f550d7ab817323

Report test outcomes in PR runs

view details

push time in 7 days

issue closedolofk/fusesoc

Use tox for tests in travis

Currently fusesoc runs tests in travis with "pip install .". This prevents catching bugs which happen due to wrong packaging, i.e. when installing from sdist. Using tox first creates packages and then installs and tests them, making the test results more reliable in this regard. This would have prevented e.g. 165fa40bde15aea8f53eeddc20b87fcdc37f258a

closed time in 7 days

imphil

PR merged olofk/fusesoc

Reviewers
Use GitHub Actions for CI

It's much easier to maintain than the current CI setup, and faster as well. To make things even easier, I've added tox support, so that tests can be executed simply by running tox in the source root directory.

+140 -71

4 comments

7 changed files

imphil

pr closed time in 7 days

push eventolofk/fusesoc

Philipp Wagner

commit sha d7961717e0435f5d084c62372e90c17f5c3e57f9

Add more cache directories to gitignore

view details

Philipp Wagner

commit sha 838933c79a42f689d2b3d4e7036d442ddaa3e515

Doc: Make wide tables wrap Wide tables don't wrap by default in the RTD theme; add a CSS override to achieve wrapping.

view details

Philipp Wagner

commit sha e5ff5e934386722a9cbfce080483066c334a8dfb

Add tests for user guide

view details

Philipp Wagner

commit sha c92c8508e26c7829de76266dafe6d8854bef8758

[doc] Rewrite documentation Rewrite the FuseSoC documentation with a focus on the user guide. The rewrite adds a lot of new content, but isn't complete yet: the advanced topics of the build system are yet to be covered, as are the package manager functionalities. Goals of this documentation effort: - Think hard about target audiences, and provide the right content (split) for them. - Split build system and package manager functionality clearly. - Try to give only one recommended approach if there are multiple options in FuseSoC. The other approaches should be mentioned in the reference guide, but not in the user guide. For example: In the user guide - core names are always specified in full VLNV, - dependency constraints are only given in a single form, and - CAPI1 is not mentioned. Since the information that was previously available within the tutorial is now in the user guide, the tutorial was removed.

view details

push time in 7 days

PR merged olofk/fusesoc

[doc] Rewrite documentation

Rewrite the FuseSoC documentation with a focus on the user guide. The rewrite adds a lot of new content, but isn't complete yet: the advanced topics of the build system are yet to be covered, as are the package manager functionalities.

Goals of this documentation effort:

  • Think hard about target audiences, and provide the right content (split) for them.
  • Split build system and package manager functionality clearly.
  • Try to give only one recommended approach if there are multiple options in FuseSoC. The other approaches should be mentioned in the reference guide, but not in the user guide.

For example: In the user guide

  • core names are always specified in full VLNV,
  • dependency constraints are only given in a single form, and
  • CAPI1 is not mentioned.

Since the information that was previously available within the tutorial is now in the user guide, the tutorial was removed.

This PR is available in rendered form at https://fusesoc--442.org.readthedocs.build/en/442/.

+1161 -601

4 comments

34 changed files

imphil

pr closed time in 7 days

more