MAX10 FPGA IOs not entering Tri-state (Hi-Z)
Hello Team, I am using 10M16 FPGA and observed that the IOs are not getting tri-stated/ Hi-Z state after: The Reset is released through a switch / press button on "DEV_CLRN" pin, considering there is no .sof/ .pof code flashed. Hardware Configuration: "DEV_OE" pin is Grounded with 10K resistor. Reference: Intel® MAX® 10 Device Handbook - Combined Pin Name Pin Functions Pin Description Connection Guidelines DEV_OE Input, I/O This is a dual-purpose pin. Optional pin that allows you to override all tristates on the device. When this pin is driven low, all I/O pins are tristated. When this pin is driven high, all I/O pins behave as programmed. You can enable this pin by turning on the Enable device wide output enable (DEV_OE) option in the Quartus Prime software. Altera recommends you to tie the DEV_OE pin to GND when the Enable device-wide output enable (DEV_OE) option is disabled and not used as a user I/O pin. You can also tie the DEV_OE pin to VCCIO or leave the DEV_OE pin unconnected provided that the Enable device-wide output enable (DEV_OE) option is disabled and not used as a user I/O pin. When you leave the DEV_OE pin unconnected, Altera recommends you to set the DEV_OE pin to input tristate with a weak pull-up.169Views0likes1CommentLTC Connector DE10-Standard FPGA
I am trying to access the I2C bus on the LTC connector on the DE10 Standard FPGA board. I have enabled the i2c controllers on the HPS. How do I now gain access to the i2c2 pins that are connected to the ltc connector from the HPS? I was able to communicate to the g-sensor that shares the same bus with the ltc connector, but I need to access the LTC connector to communicate with a separate board. I see that there is a TS3A5018 switch. Am I required to set the HPS_LTC_GPIO to low to switch communication from spi to i2c? Kindly help.429Views0likes22CommentsSecuring device: How to disable JTAG port?
Hello everyone, I am currently working on a design where we have strict security requirements. To prevent unauthorized readback, tampering, or reverse-engineering, our goal is to completely disable or lock the JTAG interface for production units. I initially attempted to achieve this by simply turning the JTAG pins (specifically TDO on PIN_Y9 and TDI on PIN_W10) into standard, unused I/O. However, I ran into the following roadblocks: Pin Planner: These pins are greyed out/locked and cannot be edited or reassigned to user logic. Device and Pin Options: I went to Assignments -> Device -> Device and Pin Options -> Dual-Purpose Pins hoping to change them to "Use as regular I/O", but the JTAG pins are not listed in this menu at all (only pins like Data[15..8] are present). Device Information: FPGA Family: Cyclone V Exact Part Number: 5CSEBA5U23I7 Quartus Version: Quartus Prime Standard Edition (15.1.0.185) My questions: What is the correct way to secure/disable JTAG? Since I cannot disable the pins in the GUI, what is the recommended Intel/Altera workflow to permanently lock or disable the JTAG port on this specific device family? Does this require blowing security fuses, enabling a specific "JTAG Secure Mode" via the .qsf, or relying strictly on Bitstream Encryption? Why the restriction? From an architectural standpoint, why are JTAG pins treated differently than other configuration pins (like AS or PS config pins)? Why aren't they available in the Dual-Purpose pins menu so they can be easily disconnected from the TAP controller? Any guidance or links to the relevant security documentation for this device family would be greatly appreciated. Thank you!Solved52Views0likes2CommentsCyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
Dear Intel Altera, I would like to confirm that the 6 channels GXB device: Q1) Do it possible to use all 6 TX / RX GXB Transceivers when Hard PCIe is used. Based on: CV-53004 There are no specific diagram to explains the single PCIe hard core device with only 6 channel case. Q2) Based on the document: CMU PLL will use CH5 and do this simply means there will be one extra for PCIe Hard-Core? Q3) If not understood falsely, Either PCIe X2 GEN1 + 4 custom GXB usage nor PCIe X4 GEN1 + 2 custom GXB usage is possible? And most protocol uses 1,2,4 and the only possible case is PCIe X4 GEN1 + 1 custom GXB? A little more info from CV-53002 So in order for PCIe Hard Core to run x2 or x4 CH4 must be used. As a result for custom TRX there is no way to use CH1 when PCIe is > x1? Thanks, Brian192Views0likes12CommentsAgilex 5 A5ED043AB23AI2V with pcie and usb 3.1 design issue
Hi, I took the design for the dev kit example design with the device (A5ED065BB32AE4SR0) for PCIe Gen4 x4 and HPS USB 3.1, and I changed the part number to A5ED043AB23AI2V and upgraded the required IPs and started the compilation. I am getting the error... I attached it. I thought this was due to the difference in package B32 vs. B23. For the B23 package, it only has 4c for PCIe and 1c for HPS USB 3.1. For B32, it has 4c and 4b banks also for PCIe and 1c for HPS USB 3.1. Does my part number support the req design with both PCIe Gen4 x4 and HPS USB 3.1? Because individually it is compiling; if not, why...? What is the reason...? If it supports where I am getting wrong. Please help me. Thank you128Views0likes6CommentsHas the 5AGXFB7K4F40I3G updated the process to replace the steel lid with the glass lid after 2021
Dear Sir or Madam We received a batch of product of part number 5AGXFB7K4F40I3G, the parts with steel lid, and the date code is 2133. But we found package drawing in the official website is different with the part. Link: https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/packaging/04R00410-09.pdf However, we received a batch of product with same part number before, these parts are glass lid, and the date code is 2225. This part is consistent with the package drawing in official website. So I would like to know whether the 5AGXFB7K4F40I3G updated the process to replace the steel lid with the glass lid after 2021. Can provide the steel lid package drawing? Thanks982Views0likes10CommentsHow to tell Quartus my Arria10 target system CLKUSR frequency is 100MHz?
Timing analyser reports CLKUSR at 125MHz but target system has 100MHz on this pin to accommodate AS in combination with transceiver calibration as per the manuals -- there doesn't seem to be any consequences as the project seems to run fine but is a bit unsettling79Views0likes6Comments