Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:43
    TParry-SystematIC synchronize #512
  • 15:42
    TParry-SystematIC synchronize #512
  • Jul 30 06:48
    alperyazar commented #515
  • Jul 29 08:23
    imphil commented #515
  • Jul 29 05:23
    alperyazar edited #515
  • Jul 29 05:16
    alperyazar opened #515
  • Jul 27 22:03
    faberc opened #514
  • Jul 21 02:44
    daly closed #513
  • Jul 21 02:44
    daly commented #513
  • Jul 21 02:12
    daly opened #513
  • Jul 15 07:32
    TParry-SystematIC opened #512
  • Jul 13 17:02
    imphil commented #189
  • Jul 13 16:52
    carminestore commented #189
  • Jul 07 20:29

    olofk on master

    Add ::servant:1.0.2-r1 (compare)

  • Jul 05 22:33

    olofk on master

    Documentation: Recommend quotin… Document flags and their use (compare)

  • Jul 05 22:33
    olofk closed #510
  • Jul 05 22:33
    olofk commented #510
  • Jul 05 09:50
    imphil commented #510
  • Jul 05 09:47
    imphil synchronize #510
  • Jul 05 09:42
    imphil synchronize #510
Chuck Faber
@faberc_gitlab
asking it to run this script (which isn't ideal because it contains the flattened VLNV core name), or we have to specify to the python script to generate its files in a different folder from which it is located (not ideal because developers may want to test their python scripts and such with their testbenches), or we have to give absolute paths to the testbench.
We were wondering what exactly is going on with this work root and why it worked with GHDL and not modelsim if maybe there's some handling going on behind the scenes that's been done for GHDL but maybe not for modelsim?
Chuck Faber
@faberc_gitlab
From what I can gather, Vunit relies on tb_path to allow the VHDL source files to point to other files in reference to the location of the top testbench module source that Vunit is simulating from (which is the copy made from the core in the build/flatVLNV/src/flatVLNV/ directory). Whereas the FuseSoC core references items from the WORK_ROOT directory, (which is in build/flatVLNV/sim_tool). If I want the core to run a script, the script must be referenced from the WORK_ROOT, but the outputs of the script which the testbench must reference must be located in reference to the tb_path (the path to the top level source file after being copied into the build folder) because I am trying to use Vunit with FuseSoC. I think this is what is causing a lot of our headaches in trying to combine these two tools.
Ben Reynwar
@benreynwar
Hi all! I know there were plans for generators to be able to specify core dependencies dynamically. Is this already supported? The reason I'm asking is that I'm trying not to include files that are not used and at the moment, because I specify all possible dependencies of a generator, there are typically many cores included that are not actually needed for the given generation parameters.
Ben Reynwar
@benreynwar
Looked through the issues and I see it's still being worked on. Is there anyway I could help with this? It looks like at the moment it's mostly a question of deciding how to approach it.
GlenNicholls
@GlenNicholls
What is the recommended way of dealing with a PCIe end point library for example that supports multiple devices and vendors (Xilinx and Altera)? E.g. we would have a common wrapper for all of the PCIe IP cores that we would instantiate in our RTL along with interface logic for the PCIe core. Are there any CAPI2 examples somewhere for something like this?
Olof Kindgren
@olofk
@GlenNicholls I would first use conditionals to switch in the appropriate filesets depending on the tool. So that your target might look like e.g.
filesets : ["tool_vivado? (vivado_files)", "tool_quartus? (quartus_files)"]
Not knowing the exact situation, it's sometimes easiest to deal with different devices from the same vendor by just using a verilog parameter/vhdl generic, but if you need some more advanced decision logic it might be a case for a generator instead
Jonathan Balkind
@Jbalkind
or for a use flag :)
if for example simulating IP in another simulator
Olof Kindgren
@olofk
Yes! A use flag could very well be a good fit here
GlenNicholls
@GlenNicholls
@olofk I see. So in our case we use vhdl generics and/or wrappers to deal with the IP itself. The specific question is how to add the correct version of the IP (e.g. the XCI or TCL script)? My original thought was to use VLNV, but this seems verbose when the only thing that I need to select would be the IP file
A use flag in this case could be quite ugly (that is if it supports nested use flags)
Jonathan Balkind
@Jbalkind
sounds to me like a job for a dependency and a use flag
here's an example of how I did something simliar for openpiton (though using .. in paths has been deprecated I think so ignore that) https://github.com/Jbalkind/openpiton/blob/fusesoc_redux/piton/design/rtl/system.core
the fpga target was only using vivado there
so you can have a different target to choose the filesets too
but what olofk said above would work if I wanted to keep the fpga target and support altera for example
Chuck
@faberc
Thanks for your prior help. We've decided to dump Vunit. Too much effort and like mkru mentioned, it tries to work too much in the same space as FuseSoC does. We will be looking at implementing fsva instead. We did have a question regarding running FuseSoC in Windows. We noticed issues when trying to simulate with Vivado (xsim) (installed in Windows) because it tries to use 'make'. From what I can tell, WSL can't run Windows installed Vivado. What is the recommended setup for a Windows environment?
Olof Kindgren
@olofk
@faberc Yes, requiring make is a hassle on Windows. We are actually moving towards an updated Edalize in which, among other things, you should be able to use e.g. ninja (or potentially even bat files) instead of make to control the sequencing of the tools. My expectation is that ninja is much easier to install on windows, hopefully being automatically available if specified as a python dependency
Several of the backends have gotten the first part of this makeover, but not xsim
Chuck
@faberc
That's great news! Thanks!
Chuck
@faberc
We've created a python workaround for now that wraps the FuseSoC command and calls the Xilinx batch programs and parses the Core file for options. We're still ironing out some issues with it, but we can host it and share it as a possible work around until the better solution comes along.
Chuck
@faberc

We were wondering about running a test multiple times but changing the parameters/generics of the test each time (which might be generated by a script). My best guess for this implementation would be to define a target in the core that just runs a python script that calls the appropriate FuseSoC commands pointing to another target in the core, and changing flags or parameters each time. Is this the best solution? Also I'm a bit confused about how to use core parameters, or flags with the fusesoc run --flags command. I haven't found any examples of either of these. Can someone point me to some of these?

Also the CAPI2 reference states: "All paramtypes are not valid for every backend. Consult the backend documentation for details." I was unsure which documentation it was referring to. There isn't much in the CAPI2 reference guide, though I know xelab/xsim supports overriding of generics with the -generic_top "PARAM=<VAL>" option. Will 'generic' parameters be parsed appropriately to add those flags?

Chuck
@faberc
Actually nevermind for the parameters. Looking at the SweRVolf core cleared up a lot for me in that matter. I'm still haven't found a good reference for flags yet though
Chuck
@faberc
When passing a parameter or generic with a fusesoc run --parameter command, is it possible to pass this parameter through as an argument to scripts in the core file?
Adithya Sunil
@adithyasunil26
Hello everyone. I am trying to create a fusesoc generator for bsg_fakeram and I need a way to pass in a JSON config file to the generator from the user side. What is the best way to do this?
Jonathan Balkind
@Jbalkind
can the file just always have the same name? if so you can add it to the fileset and declare it as user
Adithya Sunil
@adithyasunil26
Yes, it can always have the same name. Could you elaborate on what you mean by declaring it as user?
Chuck
@faberc
I think he means using a user file type when defining it's filetype
As opposed to verilogsource etc
Adithya Sunil
@adithyasunil26
oh okay thank you @Jbalkind and @faberc
Jonathan Balkind
@Jbalkind
@adithyasunil26 you can see one for .coe files for vivado here: https://github.com/Jbalkind/openpiton/blob/fusesoc_redux/piton/design/rtl/system.core#L29-L30
Adithya Sunil
@adithyasunil26
Okay yep, I get it now. Thanks.
Chuck
@faberc
I wanted to check in again: when passing a parameter through the command line, is there a way to reference it in the core file itself. For example to use as arguments to a script? so I might be able to do something like fusesoc run <target> --<parameter> in the CLI, and in the core file, in a script it might be something like: cmd: ["python3", "script.py", {parameter}]. I'm wondering if something like this is possible particularly if we have a script that requires this parameter to generate proper inputs or reference vectors.
Jonathan Balkind
@Jbalkind
I'm not sure about that but it'd definitely be really useful
Timothy Daly
@daly
I am trying to run fusesoc run --target=icebreaker servant --memfile=$SERV/sw/blinky.hex
it fails with no such file icepll
where can I get icepll?
Timothy Daly
@daly
ah. it's in sft which I've installed.
../src/servant_1.0.2-r1/servant/servant_timer.v:0: ERROR: Can't find object for defparam RESET_STRATEGY!
Tim Ansell
@mithro
olofk: I just discovered https://aignacio.com/posts/hdls/mpsoc_riscv/ -- mentions FuseSoC
Timothy Daly
@daly
Well, the icebreaker demo won't work so I switched to an icestick. Now it fails with ERROR: No tool was supplied on command line or found in 'servant' core description
Timothy Daly
@daly
Sigh. fusesoc run --tool=icestorm --target=icestick servant
ERROR: Failed to determine work root. Could not resolve target
Timothy Daly
@daly
I tried to run it on my orangecrab board. No luck there either
I've tried on 5 boards (icestick, icebreaker, arty-a7-35, orangecrab, DE10-Nano). All have failed.
Timothy Daly
@daly
The common blocking problem seems to be "failed to determine work root"... I can't find out where this message is printed. It isn't in any of the sources.
Timothy Daly
@daly
I cloned the fusesoc sources and found "work root" but it doesn't say how to set it. Something is badly broken. I'm going to nuke it all and start again.
Chuck
@faberc
I'm wondering if there is a paramtype (maybe cmdlinearg) which can be used only internally to the core file, for example for use with scripts, but not passed to the actual modules/tools. This may be a somewhat unique use case though. We've created a FuseSoC wrapper that allows us to use parameters/generics in script cmd definitions in the core-files which will change depending on the target calling the script based on how the parameter is defined within the target (hopefully this functionality will eventually be included in FuseSoC in the future though =] ). However so far we've only used generic paramtypes with xsim. I'm not sure how it would behave if we were to give a cmdlinearg to an xsim target. My guess is that it would pass it with the xsim call which isn't what we want.