Hard Reset Required After Each Boundary Scan Operation
Hello there, I am working on a project involving JTAG operations (specifically boundary scan on the data register) using Quartus Prime Standard (v24) and a USB-Blaster cable. Issue: After every scan operation, I need to perform a hard reset on the device connected to the cable. If I skip the hard reset, the next scan returns incorrect TDO values. I have tried performing a soft reset after each operation, but this does not resolve the issue. Only a hard reset consistently allows me to get the correct TDO results. Sequence being used (via my Python library executing TCL commands): open_device -hardware_name {USB-Blaster [USB-0]} -device_name {@1: JTAG_DEVICE (0x12345678)} device_lock -timeout 10000 device_ir_shift -ir_value 0x00000000 puts "TDO is: 0x[device_dr_shift -length 48 -value_in_hex]" device_unlock close_device Notes: - The Python library manages TCL sessions in a dedicated terminal. - I observe the same issue when performing these operations using Quartus directly. My question: Is there a Quartus or TCL command or procedure that can help avoid the need for a hard reset after each boundary scan operation? Or is there a way to reliably ensure the correct TDO value is returned every time without hard resetting the device? Thank you for your assistance.
MSGDMA ST-to-MM: Linux Driver Necessity & F2SDRAM Path Feasibility
Hello everyone, I am currently working on an MSGDMA implementation. I have verified that I can read the MSGDMA CSR and Descriptor registers via the LWH2F bridge using devmem2. My setup is configured in Streaming-to-Memory-Mapped (ST-to-MM) mode. I have two specific questions regarding this setup: 1、Is configuring the MSGDMA Linux kernel driver a mandatory condition for the hardware to function correctly? Is it possible to bypass the driver and configure the MSGDMA to start data transfer directly using devmem2 (user-space access)? 2、I noticed that some implementations write to the PS-side memory via the FPGA-to-HPS bridge. However, my design utilizes the F2SDRAM link, as indicated by the numbered sequence in the attached diagram. Could you please confirm if this architectural approach is feasible?Hard reset with USB-Blaster and Quartus
Hello there, I am working on few JTAG operations using Quartus prime standard (v24) with USB-Blaster (cable). After every operation I need to hard reset to perform the next operation. Unless Hard-reset is performed, the data received in TDO is not correct. Is there any command to make sure we do not have to perform hard-reset (Just to note, soft-reset is always performed). A quick response to this would be appreciated. Thanks in advance :) BR, Alkesh
Trying to print warning messages from tcl build script
I am using quartus prime v22.1 std lite and have a build script for a max10 FPGA. It seems to build correctly, but i want to create a log file containing any errors/warnings etc. Every time the tcl fails at the 'get_messages' command (and also 'get_message_count' command), how can I generate the log file from within the tcl script? Thanks Section of script file shown below: # set compilation output folder to "factory" and compile project_open -revision wrapper factory-524-069 set_global_assignment -name PROJECT_OUTPUT_DIRECTORY "./factory" # open log file for writing set log_file "quartus_warnings.log" set fp [open $log_file w] fconfigure $fp -encoding utf-8 execute_flow -compile # filter warnings # Quartus stores messages in the internal database; we can query them load_package report load_report set msgs [get_messages -type warning] # Write warnings to log file foreach msg $msgs { puts $fp $msg } project_close # close log file close $fp the load_package report and load report seem to have no effect but were included in one example script I found.
Confusion for TX Clock direction for Triple Speed 1G Ethernet IP?
Hello ALTRA IP experts, Can anybody please explain to me why, when i set the Triple Speed Ethernet IP up for RGMII mode, the tx clock for the MAC is set as an input? eth_tse_0_pcs_mac_tx_clock_clk : in std_logic := 'X'; -- clk I was expecting this signal to be an output for the Transmit MAC section to to the PHY TX block ? Here are all of the signal connections i get when i setup in RMII mode for the Triple Speed 10/100/1000 Ethernet IP core (its easier to see directions and sizes using the VHDL instance template) : eth_tse_0_mac_status_set_10 : in std_logic := 'X'; -- set_10 eth_tse_0_mac_status_set_1000 : in std_logic := 'X'; -- set_1000 eth_tse_0_mac_status_eth_mode : out std_logic; -- eth_mode eth_tse_0_mac_status_ena_10 : out std_logic; -- ena_10 eth_tse_0_mac_rgmii_rgmii_in : in std_logic_vector(3 downto 0) := (others => 'X'); -- rgmii_in eth_tse_0_mac_rgmii_rgmii_out : out std_logic_vector(3 downto 0); -- rgmii_out eth_tse_0_mac_rgmii_rx_control : in std_logic := 'X'; -- rx_control eth_tse_0_mac_rgmii_tx_control : out std_logic; -- tx_control eth_tse_0_receive_data : out std_logic_vector(31 downto 0); -- data eth_tse_0_receive_endofpacket : out std_logic; -- endofpacket eth_tse_0_receive_error : out std_logic_vector(5 downto 0); -- error eth_tse_0_receive_empty : out std_logic_vector(1 downto 0); -- empty eth_tse_0_receive_ready : in std_logic := 'X'; -- ready eth_tse_0_receive_startofpacket : out std_logic; -- startofpacket eth_tse_0_receive_valid : out std_logic; -- valid eth_tse_0_transmit_data : in std_logic_vector(31 downto 0) := (others => 'X'); -- data eth_tse_0_transmit_endofpacket : in std_logic := 'X'; -- endofpacket eth_tse_0_transmit_error : in std_logic := 'X'; -- error eth_tse_0_transmit_empty : in std_logic_vector(1 downto 0) := (others => 'X'); -- empty eth_tse_0_transmit_ready : out std_logic; -- ready eth_tse_0_transmit_startofpacket : in std_logic := 'X'; -- startofpacket eth_tse_0_transmit_valid : in std_logic := 'X'; -- valid eth_tse_0_mac_mdio_mdc : out std_logic; -- mdc eth_tse_0_mac_mdio_mdio_in : in std_logic := 'X'; -- mdio_in eth_tse_0_mac_mdio_mdio_out : out std_logic; -- mdio_out eth_tse_0_mac_mdio_mdio_oen : out std_logic; -- mdio_oen eth_tse_0_mac_misc_magic_wakeup : out std_logic; -- magic_wakeup eth_tse_0_mac_misc_magic_sleep_n : in std_logic := 'X'; -- magic_sleep_n eth_tse_0_mac_misc_ff_tx_crc_fwd : in std_logic := 'X'; -- ff_tx_crc_fwd eth_tse_0_mac_misc_ff_tx_septy : out std_logic; -- ff_tx_septy eth_tse_0_mac_misc_tx_ff_uflow : out std_logic; -- tx_ff_uflow eth_tse_0_mac_misc_ff_tx_a_full : out std_logic; -- ff_tx_a_full eth_tse_0_mac_misc_ff_tx_a_empty : out std_logic; -- ff_tx_a_empty eth_tse_0_mac_misc_rx_err_stat : out std_logic_vector(17 downto 0); -- rx_err_stat eth_tse_0_mac_misc_rx_frm_type : out std_logic_vector(3 downto 0); -- rx_frm_type eth_tse_0_mac_misc_ff_rx_dsav : out std_logic; -- ff_rx_dsav eth_tse_0_mac_misc_ff_rx_a_full : out std_logic; -- ff_rx_a_full eth_tse_0_mac_misc_ff_rx_a_empty : out std_logic; -- ff_rx_a_empty clk_out_5_clk : out std_logic; -- clk eth_tse_0_pcs_mac_tx_clock_clk : in std_logic := 'X'; -- clk eth_tse_0_pcs_mac_rx_clock_clk : in std_logic := 'X'; -- clk eth_tse_0_mac_clkena_rx_clkena : in std_logic := 'X'; -- rx_clkena eth_tse_0_mac_clkena_tx_clkena : in std_logic := 'X' -- tx_clkena These all make sense to me EXCEPT for the eth_tse_0_pcs_mac_tx_clock_clk signal which i thought would be an OUPUT and NOT and INPUT ! Thanks for your help, BarryCorrect way to configure the RGMII input and output pins on a MAX10 FPGA
Greetings ALTERA Expetrs, I am using an ALTERA Triple Speed Ethernet IP core configured n MAC only mode, which talks to a MARVELL 88E1111 PHY. Actually for this example i am using an ALTERA MAX10 10M50-C Development kit. I am having trouble understanding exactly HOW to configure the DDR RGMII input and output pins. After instantiating the Triple Speed Ethernet IP in a top level System Verilog file and connecting up Avalon MM, Avalon Tx/Rx ST interfaces etc, and connecting up clocks and resets, do i need to to connect up my RGMII DDR outputs using altddio_out IP and my RGMII DDR inputs to FPGSA pins using altddio_in IP blocks ? This is how i am thinking i need to connect my DDR RGMII FPGA pins up to my Triple Speed Ethernet RGMII tx in and rx in busses on the IP: Connect the TX Clock output : altddio_out #(.width(1), .INTENDED_DEVICE_FAMILY("max10")) altddio_out_a_txc (.outclock (clk_125MHz), .datain_h (1'b1), .datain_l (1'b0),.dataout (RGMII_ETH_TXC), // TSE clock TX PORT A .oe (1'b1), .outclocken (1'b1), .aclr (1'b0), .aset (1'b0) ); Connect the RGMI TX data outputs : altddio_out #( .width(4), .INTENDED_DEVICE_FAMILY("max10") ) altddio_out_a_txd ( .outclock (clk_125MHz), // 125 MHz Transmit clock for RGMII .datain_h (rgmii_out_ddr), // rising edge .datain_l (rgmii_out_ddr), // falling edge .dataout (rgmii_out), .aclr (1'b0), .aset (1'b0), .oe (1'b1), .outclocken (1'b1) ); Where in the above code rgmii_out wires are going to FPGA DDR RGMI TX output pins, and rgmii_out_ddr is from the Triple speed IP core. For the RX side for the INPUT DDR RGIM Rx data bus: altddio_in #(.width(4), .INTENDED_DEVICE_FAMILY("max10")) altddio_in_a_rxd ( .inclock (RGMII_ETH_RXC), .datain (rgmii_in), .dataout_h (rgmii_rxd), .dataout_l (/* unused */) ); Do these sort of DDR interface IP instantiations looks correct ? All help gratefully received ! Thanks, Dr Barry HMAX10 10M50 Development KIT Triple Speed Ethernet problem
Greetings to all of the ALTERA Experts, I have been trying to get a Gigabit Ethernet interface working on an ALTERA MAX10 10M50-C Development kit and keep hitting a bit of a brick wall when tying to communicate with the MARVEL ALASKA 88E1111 PHY. It does not appear to respond correctly when i try to read for example the PHY ID register (address x02) which should respond with the value 0x041 but instead sends back 0x7fff. I am using a System Verilog HDL approach to both instantiate the ALTERA Triple speed IP core in MAC only mode, with 2K word FIFOs, and full duplex 10/100/1000. The IP is set to work in Gigabit mode. When i connect the board to a windows 10 PC using an Ethernet cable i can see the Yellow LED lit up on the Dev KITS PHY connector and when i test the connection on the windows 10 PC it says it is up and connected. But when i try to send any Ethernet packets (i am using IPV4 + UDP as packet payload) nothing gets through to the PC. I have verified this as well using WIRESHARK which shows me no ethernet frames are coming in from the MAX10 Dev kits end. I have set the Triple speed Ethernet IP cores mac0/mac1 register to this random value: 48'h321C23174ACB I think this is OK and what the Triple Speed Ethernet User Guide says. Please correct me if my thinking is wrong though ? Questions: a) Does any body know of any errata / bugs with this Development KIT OR with the MARVELL PHY ? b) Can anybody point me to a Git Hub which has a known working example using this ALTERA Dev Kit along with this MARVELL PHY ? This can use either a HDL approach (like i am trying to use here) or a NIOSV softcore processor approach. c) The MAX10 Dev Kit has 2 Ethernet PHYS. A and B. I think that the MAX10 10M50-C Dev Kit sets its A MARVELL PHY Address to 0x0 and its B side MARVELL PHY Address to 0x1 BUT its not easy i found to figure out the PHY addresses. If somebody can please show me how to properly derive the PHY ADDRESSES for both the MARVELL 88E1111 devices for PHY A (ETHERNET A) and PHY B (ETHERNET B) on the MAX10 10M50-C Dev Kit Board Schematic) i will be very grateful ! Thanks for any help, Dr Barry H
Quartus Prime 25.1 Lite - Display Issues
Dear Altera / Intel, I have noted a large obstruction while trying to work with the latest version of Quartus Prime Lite. I have made two screenshots that show the display issues I am having with this version. They are two-fold: The mega-wizard plugin manager dialog for the ALT_PLL megafunction: All "windows-controls" panels that house the controls for the various wizard pages are set to transparent on my system. All controls of all wizard pages are visible and make it near impossible to work with for me. The first screenshot says it all. The second issue is syntax-highlighting for the Verilog HDL. I've followed developments in this area for years and as a software developer, for visual recognition performance I do rely on syntax-highlighting a great deal. Since version 23 this seems to have gone fubar. It's the 2nd screenshot. When it comes to the syntax highlighting I noted that now port identifiers are now regarded HDL key words which I think they are not as they are still identifiers. The word "port" for as far as I can remember is not a Verilog keyword either (unlike "modport"). Further, it's also parameter/constant identifiers that are regarded keywords which they are not. Funny though is that the parameter identifier must be full caps to be regarded a keyword. (the word "low" in the screenshort, contary to "HIGH"). I would love to see the syntax highlighting be addressed and have this work fluently if possible; too detailed a high-light may be too hard to add or require too much work, I don't know. If I am to supply a wish-list it would be short: Syntax highlighting as of Quartus 20.1.1 as a basis Port highlighting with its own element "Verilog Port Identifier" is indeed useful and nice. That's it. Parameters / constants are no specific desire, but if you wish to colorize these, please try to be consistent and not let this be case sensitive as it is now. And an obligatory disclaimer: It may be possible all of this works like fine on everyone else's systems and it's just me (lol). For what its worth, I use an old though established components custom PC. (i7 920, Foxconn bloodrage board and an Asus RTX2060 TUF as its main components, all with drivers up to date and the CPU and board still supported by windows 10. Thanks in advance! Arno
Agilex 5 IOPLL Max Numbers and Tool Display Mismatch
Hello everyone Let me discuss the title. [Question] What is the maximum number of IOPLLs (Bank IOPLLs, Fabric Feeding IOPLLs, and perspective of whether System PLL can be used for other purpose ) on an A5EC008BB32AE5S, both device wide and bank/block wise? In particular, I would like to know the official opinion on how Quartus Pro Edition (Fitter/Report) and Power and Thermal Calculator count the upper limit on IO96B (HSIO) banks and the upper limit on HVIO blocks. Please check the attached file for details. Best Regards
