-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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 You can also use |
Hi, Martin, tt@ubuntu:~/.local/lib/python3.8/site-packages/cynthion$ pip install -e . 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 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. |
Oh, sorry - I didn't make that clear. The 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. |
Hi, Martin, 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,
Thanks again, |
Hi @knowic -- let's go through your questions:
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.
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)
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! :-) |
Sorry, I missed one aspect of your question:
If you would like the full Verilog generated by Amaranth you'll need to edit: cynthion/cynthion/python/src/gateware/facedancer/top.py Lines 323 to 327 in de15bd8
Change the |
Hi, @antoinevg |
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
The text was updated successfully, but these errors were encountered: