-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libero: add run support #408
base: main
Are you sure you want to change the base?
Conversation
These files actually implement the build stage and not the run stage. Rename them in preparation for the addition of run stage support. Signed-off-by: Liam Beguin <liambeguin@gmail.com>
In preparation for the addition of the run stage, factorize the call to the libero binary so it can be reused. Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Add support for loading a bitstream on target. Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Hi @olofk, Here's my first pass at implementing the run stage. I'll try to look into the new API too.
I was also thinking of implementing something to read the device info. Is there a way to support that in FuseSoC? I couldn't find anything in the documentation. Cheers, |
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
in TCL, join takes a list as first parameter and a separator as second. Update function call to match that, and fix relative path making the expansion null! Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
This was causing string parameters to be ignored during synthesis, preventing things like: fusesoc run servant --target=polarfire_splashkit --memfile=anything.hex Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Thanks for this. Highly appreciate the well-structured commits! It looks great overall, but I have some questions/comments on the programmer addition. Do we need to specify all these parameters for the different Flashpro devices? The general rule in Edalize is to avoid hard coding things like this, so that the user is free to set them as needed. I would also like to mention that long-term I would really really like device programming be handled by some external library so that all projects that need to program an FPGA can share that code. The current implementation in Edalize turned out to be a bit naive. When I started this in 2011 I assumed there would be one programmer per EDA tool, but in reality there can be many different tools, so this needs an overhaul. A bit of historical context here olofk/fusesoc#319 . This doesn't affect any of your work, but I'm mentioning it in the hope that someone someday will create a library I can use :) When it comes to a Flow API implementation of the Libero backend, I would suggest looking at the Vivado or Efinity tool classes, which probably are the closest ones. You need a |
Allow users to program FPGA targets with edalize.
snippet of the output of the run stage: