In the user guide documents for the Stratix 10 Mailbox Client IP (both versions, both with and without Avalon Streaming interface) there is a comment indicating that the input clock frequency is limited to 250 MHz. See:
However, these IP cores seem to be able to meet timing with input clock frequencies far beyond that, easily 400+ MHz. Which begs the question:
What's behind the comment in the user guide documents about a 250 MHz limitation?
Can these cores be safely used at higher clock frequencies if Quartus indicates that timing is met?
Or is there truly a 250 MHz limitation lurking in there that is somehow not accounted for in the Quartus timing analyzer???
The recommended max input clock for Mailbox Client IP is 250Mhz. If you are putting higher clock frequency, you will need to make sure that you can close timing properly else they might end up running at slower speed.
Thank you, but I'm confused by your response. Of course you need to make sure that a design is fully constrained and must close timing properly. You need to do this always, not just if you're targeting a clock frequency above some recommended value. That's a fundamental part of the design implementation process in general, so I'm not sure what distinction you're making above 250 MHz. And also, generally speaking, if you don't close timing properly, a design won't necessarily just "run at slower speed". Rather, with timing violations present, a design cannot be assumed to function correctly in hardware at all. So your comment raises more questions than it answers.
I'll ask my question again, in the form of a specific example:
A customer's design includes the Mailbox Client IP core. The design is fully constrained, and the clock frequency is specified to be 400 MHz. The customer ignored the unexplained 250 MHz max recommendation in question. The design fully meets timing at 400 MHz, as indicated in Quartus timing analysis. Is there any problem at all? Yes or no?
So to be clear, you're saying that lurking in these IP cores there is in fact a timing issue of some sort that Quartus timing analyzer is unable to detect?
If so, this is a problem that should be addressed.
Thanks, @YuanLi_S_Intel. I'll look forward to hearing the outcome of your discussion with your internal team.
Also, in the mean time I've poked around a bit in what Quartus produces with this IP core, which is a wrapper/bridge to the SDM, and I have a hunch as to what's behind all this. I see the following:
It looks as though Quartus creates a bunch of soft interface logic (using general fabric resources) between the user-visible ports of the core and the actual SDM hard block, and this soft interface logic includes an asynchronous clock domain crossing between the user's clock and an internal oscillator clock. And interestingly, that internal oscillator clock is being auto-constrained to 250 MHz. Does that ring true?
So it may be that the SDM hard block proper has a 250 MHz limitation, as you said. But then...
Taking an educated guess here, I suspect that the 250 MHz internal oscillator clock is being used internally in this IP core to satisfy the SDM hard block's clock frequency limitation independently of the user's clock frequency. And that clock domain crossing, if it was implemented properly in the soft interface logic inside this IP core, should relieve the user from having to deal with any such frequency limitation in the user's own clock domain. A reasonable design approach, if that's how this IP core was designed.
So could it be that the 250 MHz limitation is just an internal limitation of the SDM hard block as you've said, but is handled by the soft interface logic and internal oscillator clock inside this IP core, hidden from the user? And as such, is the mention of this limitation in the user guide of this IP core nothing more than a relic that ended up in the wrong place, whereas it doesn't actually pertain to the user clock? Is that the case?