Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16587 Discussions

Changed PERST# to 1.8V and Quartus crashed.

New Contributor I

If you tell me I can't make PERST# 1.8V compatible, I'm going to have to rework my board.


Here is the dump from the code:


Problem Details
Internal Error: Sub-system: FIOMGR, File: /quartus/fitter/fiomgr/fiomgr_io_manager_impl.cpp, Line: 7696
Stack Trace:
    0xecc54: FIOMGR_IO_MANAGER_IMPL::set_voltage_of_the_bank_if_needed(FIOMGR_IO_BANK*, CDB_ATOM_NODE*) + 0x354 (fitter_fiomgr)
    0xed525: FIOMGR_IO_MANAGER_IMPL::body_legality_check(FITCC_MSGR*) + 0x575 (fitter_fiomgr)
    0x99db2: FIOMGR_IO_MANAGER::legality_check(FITCC_MSGR*) + 0xf2 (fitter_fiomgr)
    0x57110: FSV_EXPERT::create_and_initialize_utilities() const + 0x2c0 (fitter_fsv)
    0x58ca9: FSV_EXPERT::fitter_preparation_pre_fpp() + 0x649 (fitter_fsv)
    0x598a6: FSV_EXPERT::fitter_preparation() + 0x26 (fitter_fsv)
    0x4b5f2: FSV_EXPERT_BASE::fitter_preparation() const + 0x312 (fitter_fsv)
    0x4d7f0: FSV_EXPERT_BASE::invoke_fitter() const + 0xc80 (fitter_fsv)
    0x4812d: fsv_execute + 0x48d (fitter_fsv)
    0x22762: fmain_start(CMP_FACADE*) + 0x4a2 (fitter_fmain)
    0x23174: qfit_execute_fit(QCU_FRAMEWORK*, QFIT_FRAMEWORK*) + 0x1c4 (comp_qfit_legacy_flow)
    0x16fa6: QFIT_FRAMEWORK::execute() + 0x1b6 (comp_qfit_legacy_flow)
    0x3bb45: qfit_legacy_flow_run_legacy_fitter_flow + 0x515 (comp_qfit_legacy_flow)
    0x48109: TclInvokeStringCommand + 0x79 (tcl8.6)
    0x4c977: TclNRRunCallbacks + 0x47 (tcl8.6)
    0x4e1ca: TclEvalEx + 0x96a (tcl8.6)
    0xf68c6: Tcl_FSEvalFileEx + 0x266 (tcl8.6)
    0xf69ce: Tcl_EvalFile + 0x2e (tcl8.6)
    0x11a90: qexe_evaluate_tcl_script(std::string const&) + 0x3c9 (comp_qexe)
    0x1702d: qexe_do_tcl(QEXE_FRAMEWORK*, std::string const&, std::string const&, std::list<std::string, std::allocator<std::string> > const&, bool, bool) + 0x824 (comp_qexe)
    0x181d1: qexe_run_tcl_option(QEXE_FRAMEWORK*, char const*, std::list<std::string, std::allocator<std::string> >*, bool) + 0x640 (comp_qexe)
    0x38da5: qcu_run_tcl_option(QCU_FRAMEWORK*, char const*, std::list<std::string, std::allocator<std::string> >*, bool) + 0xe68 (comp_qcu)
    0x1adf5: qexe_standard_main(QEXE_FRAMEWORK*, QEXE_OPTION_DEFINITION const**, int, char const**) + 0x486 (comp_qexe)
     0x36f0: qfit2_main(int, char const**) + 0xd0 (quartus_fit)
    0x3ee20: msg_main_thread(void*) + 0x10 (ccl_msg)
     0x5abc: thr_final_wrapper + 0xc (ccl_thr)
    0x3eedf: msg_thread_wrapper(void* (*)(void*), void*) + 0x62 (ccl_msg)
     0x9f8c: mem_thread_wrapper(void* (*)(void*), void*) + 0x5c (ccl_mem)
     0x8b29: err_thread_wrapper(void* (*)(void*), void*) + 0x27 (ccl_err)
     0x5aff: thr_thread_wrapper + 0x15 (ccl_thr)
    0x40e91: msg_exe_main(int, char const**, int (*)(int, char const**)) + 0xb2 (ccl_msg)
    0x237fd: __libc_start_main + 0xcd (

Executable: quartus
I changed the PCI PERST# pin to 1.8V to be compatable with the BGA NVMe I'm using and Quartus crashed. That is the only thing I changed.

System Information
Platform: linux64
OS name: This is
OS version:

Quartus Prime Information
Address bits: 64
Version: 20.1.1
Build: 720
Edition: Standard Edition


0 Kudos
1 Solution

Hi BrianM,


Below is a similar case. 


Probably the error is due to incorrect voltage set for the pin in .qsf (quartus settings file).


Best regards,



View solution in original post

0 Kudos
3 Replies

Hi BrianM,


Below is a similar case. 


Probably the error is due to incorrect voltage set for the pin in .qsf (quartus settings file).


Best regards,



0 Kudos
New Contributor I

FYI: for anyone else who finds this thread in the future. On the Cyclone V, the PERST# pin is 3.3V only and Quartus will crash (bug!) as shown above if it isn't set to 3.3V. The software should not allow you to change it.

To use a 1.8V only BGA NVMe (ie Swissbit) you need to add a reverse biased schottky diode in series with the signal to the NVMe so the an FPGA low will pull the signal low, but a high will simply let the signal go to whatever pullup is on the BGA package.


I think Swissbit dropped the ball on this, since 3.3V is the PCIe specification for the signal.


Hi BrianM,


Appreciate your helpful information on this thread. It really matter to community. I’m also glad that your question has been resolved.


I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.


Best regards,

p/s: If any answer from the community or Intel support are helpful, please feel free to give Kudos.

0 Kudos