Hi,
Is there any information on how big (LLEs, etc) current MiSTer cores are? I found one spreadsheet about that, but it looks outdated. I'm mostly interested in Console and Computer cores.
Hi,
Is there any information on how big (LLEs, etc) current MiSTer cores are? I found one spreadsheet about that, but it looks outdated. I'm mostly interested in Console and Computer cores.
Yes, but I need to learn how to do that first though, because rn I have no clue on how to compile a core So if may be this info is available somewhere, please share.
Btw, if this info can be extracted from rbf, could please you point me to a tool which can do that?
That data can't be extracted from the rbf directly and I am not aware of any tool that can analyze it and give an estimate/report.
The only way I am aware of is, as MostroW pointed out, to compile it yourself.
To do that, you'll need to install Quartus 17, download the core's source from github, open up it's .qpf in Quartus, then Processing -> Start Compilation....
Then, depending on your system and which core you are compiling, go grab a coffee, some lunch/dinner or what not and wait for it to compile.
At the end it will generate a report which will include that information.
In the event you miss it, check the output_files folder for a corename.fit.rpt file...open that in a text editor/viewer and grab what you need.
If you are interested in core development, check out the Development section of the Wiki for some helpful info.
Thanks for the info. No, i'm afraid i'm not qualified yet to develop for FPGA , but i need this info for my (semi)technical article/blog.
don't you have to press record and play at the same time..
nymous wrote: ↑Sun Mar 24, 2024 1:37 pmIs there any information on how big (LLEs, etc) current MiSTer cores are? I found one spreadsheet about that, but it looks outdated. I'm mostly interested in Console and Computer cores.
I doubt that’s outdated (outside of missing some cores), they are unlikely to change massively in scale. But if you are looking for N64/PSX/Saturn, maybe MisterAddons will be willing to add those.
So, if someone interested, I got the following results for some of the newer cores:
N64:
Logic utilization (in ALMs) 36,710 / 41,910 ( 88 % )
Total block memory bits 1,284,912 / 5,662,720 ( 23 % )
PSX:
Logic utilization (in ALMs) 39,207 / 41,910 ( 94 % )
Total block memory bits 2,539,730 / 5,662,720 ( 45 % )
Saturn:
Logic utilization (in ALMs) 41,285 / 41,910 ( 99 % )
Total block memory bits 4,167,006 / 5,662,720 ( 74 % )
Sega 32X:
Logic utilization (in ALMs) 26,549 / 41,910 ( 63 % )
Total block memory bits 3,834,952 / 5,662,720 ( 68 % )
Nuked Megadrive:
Logic utilization (in ALMs) 33,091 / 41,910 ( 79 % )
Total block memory bits 2,891,312 / 5,662,720 ( 51 % )
For comparison:
Old Genesis core:
Logic utilization (in ALMs) 21,790 / 41,910 ( 52 % )
Total block memory bits 2,714,040 / 5,662,720 ( 48 % )
MegaCD:
Logic utilization (in ALMs) 24,763 / 41,910 ( 59 % )
Total block memory bits 4,019,302 / 5,662,720 ( 71 % )
That's crazy how the nuked core is almost twice the size of the older fpgagen core. I wounder why? Because of full implementation of VDP, including SMS modes?
Unless I'm misreading the utilization report (possible; I'm not an expert on these), the main difference is that the NukedMD VDP uses logic resources for its internal RAMs where the old core uses block RAMs. Possibly they were asynchronous on the original chip and NukedMD is simply reproducing that (block RAMs are synchronous; output doesn't change until a clock edge).