Comments (8)
I would probably lean more towards option 2.
The main PeakRDL command-line interface is definitely the more "productized" and user-oriented workflow. As I develop the PeakRDL tools, I will be pushing users more towards that interface as the primary and preferred way to interact with the various PeakRDL sub-tools. This will inevitably be more familiar to users as well. This also has the benefit of implementing the user/org configuration mechanism described here: https://peakrdl.readthedocs.io/en/latest/configuring.html
Sub-tools will still always have their own documented and stable API for power-users.
from fusesoc.
Generators can't use information from other cores. For tasks that affect several cores I would recommend doing this as an Edalize frontend instead. Perhaps look at the sv2v tool class which receives SV files and produces Verilog files, but in your case it would consume rdl files and create SV files instead.
from fusesoc.
Great! I will look into it. Once I have it, are you interested in a pull request with that feature in the edalize repo? Otherwise I think I can use it as an external plugin.
from fusesoc.
That would be great. I'm likely to need something like that myself when I start some new project. But as you have noted, there is nothing preventing you from keeping it in an external plugin if you so wish. Btw, is this using @amykyta3's excellent PeakRDL tooling?
I also remembered that I did something similar to this but with IP-XACT not too long ago. Let me see if I can dig up an example of that for reference.
from fusesoc.
I started writing a edalize plugin for PeakRDL today.
Any suggestion on whether there should be 1) a separate edalize tool for every peakrdl backend, or 2) a single edalize tool where the user defines the backend via a tool option?
from fusesoc.
Now lets say I have 3 cores: A, B and C. The C core rdl file includes A and B rdl files, in order to be able to compile the C core rdl file I need to provide the compiler the paths where it should search for the included files.
I would recommend treating RDL as distinct target filesets in the fusesoc file manifests. I usually discourage users from using `include directives in the source RDL, and instead use multi-file compilation. But even so, it probably makes sense to provide a mechanism for users to specify include search paths for the RDL preprocessor too.
from fusesoc.
Include directives shouldn't be a problem as we can mark the RDL files that need to be included with is_include_file : true
in FuseSoC. Agree that multi-file compilation is to prefer though.
@jamesrbailey Are you intending to release this plugin as open source? I'm working with peakRDL on a project right now and have been considering making such a plugin myself, but would be better if there is something to build upon instead.
from fusesoc.
It's unlikely I will have anything available to open source in the near or medium term, although that would be my intent.
from fusesoc.
Related Issues (20)
- Builtin fusesoc parsing cores tree command HOT 1
- Feature request: ability to control arguments to Generators HOT 2
- Modelsim with Cocotb [new flow] HOT 2
- Question: Different cores from the same provider HOT 1
- Question: `env` section problem. HOT 3
- Invalid choice: 'migrate-capi1-to-capi2' HOT 1
- Setting vivado parameters using core file HOT 1
- Bugs of flags only with numeric
- Librarys from git
- fusesoc is not working for tool=QuestaSim in Linux RedHat. HOT 2
- Reseting cache HOT 2
- script order with conditional statements
- Using multiple revisions of the same library in a project
- Is there any way to pass a *value* to an `Edatool`'s`tool_options` attribute via the command line HOT 2
- Fusesoc yosys target creates fusesoc error and a partially complete Makefile
- Variables in script arguments HOT 1
- Dependencies and target-specific files HOT 2
- provide schema as json
- What is the file_type for SDF file HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fusesoc.