Sorgelig wrote:I don't see ANY offer of help. Only complains, complains, complains.

Calm down Sorgelig. Nobody was complaining here. Certainly I wasn't. Not at all. Well, my only complain was about your aggressive attitude.

I just though (and I still think) that it is interesting to comment and exchange ideas about the heating issue. I made some actual temperature measurements comparing with other boards with the same FPGA. And I thought it would be interesting to share my measurements. I thought it is interesting to mention that the board uses an industrial grade part. And I though it was interesting to comment about the different board revisions. I never said, that the heating issue is your fault, and honestly I don't think so.

Bernouilli was saying he was looking at modifying the preloader to use a lower MPU frequency. There was no complain there and I do think it is interesting. It remains to be seen if it is worth. But I think it is an interesting experiment nevertheless.

ijor wrote:Cores should not fail if they meet timing with the slow model. It makes you think that perhaps some cores are not properly constrained.

isn't it a request?

Of course it wasn't. When we followed up I said:

Most, if not all, the other cores probably fit comfortably and they could be constrained properly (assuming they are not already). And I am not complaining to you, that should be implemented by the original developers that are very familiar with the design.

I think I couldn't make it more clear that I wasn't complaining to you nor doing any requests to you. It even wasn't my intention to complain to the original developers either. It was more of a comment that most of the cores in the "clone scene" are not properly constrained.

Newsdee wrote:I have zero clue in what goes in a constraints file, but I understand it as "cores can be optimized further".

Not exactly. Constraining the design means providing all the data Quartus needs to perform a full and proper timing analysis. If the design is properly constrained Quartus should be able to compile the design in such a way to avoid timing issues even in the worst conditions. And if it can't, it will at least tell you that timing couldn't be met, and will give you lot of detailed information to help you solve the issue.

Sorgelig wrote:I believe only few people are really masters at this task. Usually HDL projects either have no such files (SDC), or just basic one without tweaking.

Sometimes it is just an issue of providing proper constrains. Sometimes there is a design problem that must be redesigned. I was meaning to look at the timing issues of ao486. But being so big and taking so much time to compile, it might help if you could provide the full compilation report files. Otherwise I need to spend hours just to see the report.

I am quite familiar with Quartus timing constrains. But it is very difficult to constrain a (non trivial) design without being familiar both with the original architecture and the design itself. That's why it should better be done by the original developer.

ijor wrote:But being so big and taking so much time to compile, it might help if you could provide the full compilation report files. Otherwise I need to spend hours just to see the report.

If it could be so easy to fix the timing problems by just looking at report files.. I've spent several weeks to port this core. Why? May be because i really wanted to make it work on MiSTer. If i want something, then i can spend a lot of time just to make it happen.. of course if it only depend on my willing.So, if you really want to fix the core, then don't afraid to spend your time. It won't happen without effort.

I know. Again, I wasn't complaining to you. Actually I wasn't exactly complaining at all, not even to the original developer.

If it could be so easy to fix the timing problems by just looking at report files ...

I didn't say that, not nearly, did I ??? But it would certainly help.

I've spent several weeks to port this core. Why? May be because i really wanted to make it work on MiSTer. If i want something, then i can spend a lot of time just to make it happen.. of course if it only depend on my willing.So, if you really want to fix the core, then don't afraid to spend your time. It won't happen without effort.

Of course that it requires an effort. But I don't see the reason to spend unnecessary hours when I could start looking at the reports right away. Yes, that would only be a start.

But if you don't want to provide the compilation report files, then don't.

Sorgelig wrote:Some cores like ao486 impossible to tweak to make it work reliably with any temperature of FPGA. Core is too big and even without much constrains took more than hour to compile.

I tried compiling this core, and at the end it seems it is actually the other way around. The reason that the ao486 cores takes so much time to compile, the reason that it takes so much routing resources and sometimes even fails to compile, seems to be precisely because it is not fully constrained and has some severe timing issues.

It already seemed to me very strange when you said that compilation fails at the router. FPGA's are actually designed with spare routing resources (because it is cheap), so that this would normally not happen. If a design fails to fit in the device, it should fail at placement time because it needs more logic resources (LEs, memory, etc). That's one of the reason that I wanted to see the compilation report. To understand better the problem.

I eventually manager to compile a working kernel, my point was to see how the heat issue would be with two core running.Since there is only one main running process (MiSTer), when there are two running cores, the second core is almost all the time at 0%.So there is no real difference between one or two active core.

However, to manage to get the second core running, I had to disable an option in the kernel (CONFIG_KERNEL_THUMB2). I'm not really sure what this option is but I suppose that it enables the use of the thumb2 instruction set which produces executable that uses less space but is still almost as performant than the ARM instruction set.

I did some testing with this new kernel and it seems that the temperature of the CPU grows more slowly than with the official kernel.

I tested it with a digital thermometer, I taped the sensor directly on the cyclone5 chip without using a heatsink and without a fan.

I start the board with a displayed temperature of about 22°C, and then I see how fast it increases.Meanwhile, I don't use any core, I just leave the de10 on the menu.With the official kernel the almost maximum temperature (50,5°C) is reached after about 5 minutes.

With the new kernel, after 5 minutes, the temperature is only 45,7°C, and it reaches 50,8°C after 9 minutes.

Next step is to manage to lower the frequency of the core to 400Mhz and 200Mhz and see how this affects the heat.

Using the heatsink and fan I sell, the max temperature is ~35C (dead center of the bottom of the board) and the CPU/heatsink is ~26C, and that is after 8 hours of being on. I don't think heat is every going to be an issue when you using the proper heat sink and fan.

Less heating probably caused by switching from Thumb2 to ARM instructions, but it needs to be verified carefully. You need to compare Thumb2 and ARM in same environment. Either enable second core in both configs or disable it in both. If ARM version really produces less heat then it will be worth to switch to ARM instructions. But need to be sure.

I doubt i will agree with lower ARM frequency since it will affect the whole performance. It may introduce "visible" input latency, increase the loading time and future emulations on ARM side. ARM cores in Cyclone V has no dynamic frequency switch. You have to setup the frequencies in preloader(U-boot) and it will be use the whole time. Probably it will affect the the DDR3 frequency as well (not sure, i didn't explore it precisely).For heating test it's worth to try different frequencies of ARM, but less likely it will go to official version.For reducing heat to that level when it won't affect the FPGA fabric, you will need to reduce the ARM speed (and probably DDR3 clock) very much. And in closed space (box/case) even slight heating will eventually grow slowly to high temperature. Will you get a high temperature in 2 minutes or 30 minutes - it doesn't matter. You don't want to turn off the MiSTer and cool it down every 30 minutes - isn't?

I also want to mention important thing: Fan is necessary anyway. Even if you will put a large heat sink but in closed case, it will just delay the heating but won't stop it. Airflow is the main cooling factor.So, if you will use the cooler+fan, then the whole hassle of reducing heat is pointless, IMHO.

bernouilli wrote:Meanwhile, I don't use any core, I just leave the de10 on the menu.

You're right about saying that using thumb2 generates more heat. I'll do the same testing with the same u-boot passing maxcpus=1 to the kernel and two kernels built with the same compilator and the only difference being the THUMB2 option and see if the results are the same.

I also agree on the fact that even though the temperature grows slowly, it does grow.

My point was to see if we can use the board without a fan, with just a heatsink that isn't that huge. The Mist doesn't even have heatsink.I think it's worth trying to see how it behaves with lower clock frequency. The de10 has a complicated set of clocks and you can lower the frequency of the mpu without lowering the other clocks.

And about the latency, I doubt there would be noticeable latency if the mpu is running at 200Mhz instead of 800Mhz. The arm on the Mist is running at 48Mhz and there is no latency.

Do not compare to MiST. MCU and FPGA are not in one package there and completely irrelevant for comparison.MiSTer uses Linux while MCU on MiST is bare-metal project. Linux provides great support for many devices, as a consequence it requires much more power to handle everything smoothly.Even if with lower frequency, the performance of ARM+Linux will be similar to MCU of MiST, then i don't want such performance. MiST is slow as hell, especially when it comes with big file loading. Compare the size of MiST FPGA bitsream and MiSTer's - more than 10 times of difference.