User Profile
KennyT_altera
Super ContributorJoined 6 years ago
User Widgets
Contributions
Re: Quartus did not start
Hi team, This is the root cause provided by the sophos. Root cause: Sophos Endpoint flagged and blocked Quartus due to its behavior-based exploit mitigation engine detecting certain Quartus runtime activities as similar to exploit techniques. The block was not caused by the Quartus executable being malicious or by its file signature/hash, but by Sophos monitoring low-level runtime behavior that matched exploit-like patterns. The issue was mitigated by adding the appropriate process, file/folder, and exploit-mitigation exclusions. https://support.sophos.com/support/s/article/KBA-000007176?language=en_US I think we shall close the case if there are no further queries.10Views0likes4CommentsRe: setup and hold time with set_input_delay
sstrell is correct that the first thing is to distinguish source synchronous vs system synchronous. For set_input_delay, the key point is that it describes the external data arrival window at the FPGA input pin, relative to the reference clock edge. It is not “remaining internal time after subtracting board clock delay.” For a true source-synchronous interface, common clock/data PCB delay usually cancels, so what matters is mostly: upstream device Tco(min/max) clock/data board skew jitter/uncertainty A common model is: set_input_delay -max = Tco_max + data_trace - clock_trace set_input_delay -min = Tco_min + data_trace - clock_trace refer to https://docs.altera.com/v/u/docs/653688/an-433-constraining-and-analyzing-source-synchronous-interfaces So if data and clock traces are matched, the trace delay does not magically give the FPGA extra internal time. Also, set_output_delay on the transmitting chip and set_input_delay on the receiving chip are related, but they are not redundant. One constrains the transmitter against receiver requirements; the other constrains the receiver against transmitter behavior.15Views0likes0Comments