Skip to content
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

Question: How to get the bitstream file of LFE5U-25F instead of LFE5U-12F based on r1.4.0 version? #185

Open
knowic opened this issue Sep 11, 2024 · 7 comments
Assignees
Labels
question question from the community that is not technical support

Comments

@knowic
Copy link

knowic commented Sep 11, 2024

Hello,
I have changed the device "LFE5U-12F" to "LFE5U-25F" in cynthion_r1_4.py, set the system variable LUNA_PLATFORM ="cynthion.gateware.platform:CynthionPlatformRev1D4", and have a dry run like this "python3 -m cynthion.gateware.analyzer.top -D --output myanalyezer.bit"
After that I compared the new bitstream file with old one(without device name change), they are all same, the head of the new bit stream binary file still have this string "Part: LFE5U-12F-8CABGA256"
Also I have get some study that the 0D7 version use device 25F, so I setting the LUNA_PLATFORM to 0D7, regenerate bitstream file, it does look like ok, the binary file have the string "Part:LFE5U-25F-8CABGA256"
so, my question is that did I miss some thing else with r1.4 or other common setting?

Thank,
Jason

@martinling martinling self-assigned this Sep 19, 2024
@martinling
Copy link
Member

Changing the device type in the platform file should change the IDCODE tag in the bitstream, and I've just tested that this works.

Had you perhaps forgotten to reinstall the cynthion python package after modifying it? If you installed with pip install . then you will need to re-run that after making changes.

You can also use pip install -e . to do an editable install which refers to the original source files, and then any changes will take effect immediately.

@knowic
Copy link
Author

knowic commented Sep 23, 2024

Hi, Martin,
Thanks for your mention,
I changed the device name in cynthion_r1_4.py , and get the command pip install -e . run at cynthion package directory, but it reports such error:

tt@ubuntu:~/.local/lib/python3.8/site-packages/cynthion$ pip install -e .
/usr/bin/pip:6: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
from pkg_resources import load_entry_point
ERROR: File "setup.py" not found. Directory cannot be installed in editable mode: /home/tt/.local/lib/python3.8/site-packages/cynthion

Discard this error, I get a new dry run and the new bitstream file have the head include the "25F" character, but file size is same with "12F",

-rw-rw-r-- 1 443766 Sep 23 06:36 facedancer_1d4_12F.bit
-rw-rw-r-- 1 443766 Sep 23 07:02 facedancer_1d4_25F.bit

So, I wonder to know, for the two FPGA device, only the ID code is different, the program routing or setting bits is same, is this correct or not ?

Thanks.

@martinling
Copy link
Member

Oh, sorry - I didn't make that clear. The pip install command needs to refer to to the directory that contains the pyproject.toml file. So if you're in the python directory it's pip install -e ., but if you're in the top level of the repository you'd need to use pip install -e cynthion/python.

The bitstreams being the same size is expected, due to a fact about these FPGAs that I guess you didn't hear yet:

The 12F and 25F parts are actually the same die. They both have all 25K LUTs. The only thing that differs between them is the IDCODE, which I'm guessing is blown in via fuses at the factory to differentiate the two products.

If you use the proprietary toolchain, it will enforce a limit of 12K LUTs when you select the 12F part. But when the chips were reverse engineered for Project Icestorm it was discovered that these two parts actually have the same resources, and take exactly the same bitstream - only the IDCODE differs.

In theory the manufacturer could be binning the parts, with those marked 12F being ones that failed tests in one half of the LUTs. But in practice nobody has ever detected any difference that I know of. So all the open source tools just treat them as equivalent parts, and generate bitstreams that are the same for both except for the IDCODE.

@knowic
Copy link
Author

knowic commented Sep 24, 2024

Hi, Martin,
Thanks for your patience, I have a run as you mentioned, it does reports such error:
ERROR: File "setup.py" not found. Directory cannot be installed in editable mode: /home/tt/01-cynthion/cynthion-0910-main/cynthion/python
(A "pyproject.toml" file was found, but editable mode currently requires a setup.py based build.)

I get some information with google and upgrade the pip3 to version pip 24-2, get a new re-run, reports some other new issue with urllib3 , maybe I should spend some time to fix it, may I know the detail version about python 3 and pip3 in your working environment?

By the way, I have other two question about it,

  1. For the FPGA firmware design, the work of Cynthion is behaviored with Amaranth HDL code and translated into verilog for sythesis, is the file vexriscv_cynthion+jtag.v in build directory is the top cell file and includes all sub-modules ? If I try to get bit stream generation to do comparation with Lattice Diamond , it this the source I can use?
  2. For the Cynthion FPGA software design, we add one more step with Amaranth-HDL coding, why not use verilog language directly ? I have study that the Amaranth haven't get all the feature of verilog implemented now.

Thanks again,
Jason

@antoinevg
Copy link
Member

antoinevg commented Sep 24, 2024

Hi @knowic -- let's go through your questions:

may I know the detail version about python 3 and pip3 in your working environment?

I use https://github.com/pyenv/pyenv to manage my day-to-day working environment.

Generally, at the start of any new task I'll create myself a fresh virtual environment based on Python 3.8 (this is the minimum version we support) and whichever version of pip is the latest. That said, I'll often use newer Python versions instead when testing compatibility. Cynthion has been verified to work on all versions of Python from 3.8 to 3.12.

For me, the biggest advantage of virtual environments is that you can avoid conflicting dependencies between different tasks by simply creating a dedicated environment for each.

For the FPGA firmware design, the work of Cynthion is behaviored with Amaranth HDL code and translated into verilog for sythesis, is the file vexriscv_cynthion+jtag.v in build directory is the top cell file and includes all sub-modules ?

So, the verilog in the repository is only for the VexRiscv RISC-V processor we use in our SoC design. Given that it is originally coded in the SpinalHDL language and we use Amaranth for all our FPGA work, we compile it down to Verilog first to make interoperability easier as Amaranth has great support for instantiating Verilog modules directly. (see for e.g. https://github.com/greatscottgadgets/luna-soc/blob/main/luna_soc/gateware/cpu/vexriscv.py#L111-L154)

For the Cynthion FPGA software design, we add one more step with Amaranth-HDL coding, why not use verilog language directly ? I have study that the Amaranth haven't get all the feature of verilog implemented now.

Amaranth operates at a level of abstraction higher than Verilog which makes managing complex projects a lot easier for us.

Given that Amaranth itself compiles down to Verilog it's made projects that require integration an absolute breeze! :-)

@antoinevg
Copy link
Member

Sorry, I missed one aspect of your question:

If I try to get bit stream generation to do comparation with Lattice Diamond , it this the source I can use?

If you would like the full Verilog generated by Amaranth you'll need to edit:

# invoke cli
_overrides = {
"debug_verilog": False,
"verbose": False,
}

Change the debug_verilog value to True and then the top-level will be build/top.debug.v

@knowic
Copy link
Author

knowic commented Sep 25, 2024

Hi, @antoinevg
Thanks, I am newbie with the environment and development, your information is much helpful to me, let me get some further study.

@martinling martinling added the question question from the community that is not technical support label Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question question from the community that is not technical support
Projects
None yet
Development

No branches or pull requests

3 participants