Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,236 Views

Failed programming at 85%

Hello All, 

 

I have a very simple FPGA project to test the Intel Arria 10 SoC Dev kit (DK-SOC-10AS066S-A) with Quartus Prime Pro 18.0 as follows. The main code instantiates an IOPLL Intel FPGA IP core to reduce the input board clock from 100 MHz down to 2 MHz which drives a Unique Chip ID core. It also blinks an LED on the board. 

LIBRARY iopll; 

LIBRARY chip_id; 

 

 

 

ENTITY blink_id IS 

PORT ( board_clock: in std_logic; 

button_0_reset: in std_logic; 

led_0_blink: out std_logic; 

led_1_id_ready: out std_logic; 

led_2_id_0: out std_logic := '1'); 

END;  

 

 

 

ARCHITECTURE rtl OF blink_id IS 

signal main_clock: std_logic; 

signal unique_id: std_logic_vector(63 downto 0); 

BEGIN 

 

 

 

entity_iopll: entity iopll.iopll port map ( 

refclk => board_clock, 

outclk_0 => main_clock, 

rst => not button_0_reset); 

 

 

 

entity_chip_id: entity chip_id.chip_id port map ( 

clkin => main_clock, 

data_valid => led_1_id_ready, 

chip_id => unique_id, 

reset => not button_0_reset); 

 

 

 

 

 

-- Get ID 

-- led_2_id_0 <= unique_id(0); 

 

 

 

-- Blink LED 

process (main_clock)  

variable counter: integer := 0; 

begin 

if rising_edge(main_clock) then 

counter := counter + 1; 

 

 

if counter = 2000000/2 then 

counter := 0; 

led_0_blink <= not led_0_blink; 

end if; 

end if; 

end process; 

 

 

END; 

 

 

The device & pin assignments are as follows:Device: 10AS066N3F40E2SG 

board_clock: PIN_AN18, I/O Standard, 1.8 V 

button_0_reset: PIN_R5, I/O Standard, 1.8 V 

led_0_blink: PIN_AR23, I/O Standard, 1.8 V, minimum current, 1, 

led_1_id_ready: PIN_AR22, I/O Standard, 1.8 V, minimum current, 1, 

led_2_id_0: PIN_AM21, I/O Standard, 1.8 V, minimum current, 1, 

 

 

 

The compilation got the following warnings:Critical Warning(17951): There are 48 unused RX channels in the design.  

Critical Warning(18655): There are 48 unused TX channels in the design.  

Critical Warning(332012): Synopsys Design Constraints File file not found: 'blink_id.sdc'. A Synopsys Design Constraints File is required by the Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.  

Critical Warning(332012): Synopsys Design Constraints File file not found: 'blink_id.sdc'. A Synopsys Design Constraints File is required by the Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.  

Critical Warning(19317): No user constrained generated clocks found in the design. Calling "derive_pll_clocks -create_base_clocks"  

Critical Warning(19317): No user constrained base clocks found in the design. Calling "derive_clocks -period 1.0"  

 

 

The code above works fine and I can see the blinking LED. However, if I un-comment the red line, the chip programming would fail at 85% (attached image). 

https://alteraforum.com/forum/attachment.php?attachmentid=15716&stc=1  

 

Similarly, if I made any bit of the "unique_id" vector visible in Signal Tap Logic Analyzer, the chip programming would fail as well. 

 

What do you think the issue was? 

You can download the project here: https://www.dropbox.com/s/3kimkjcwgo1kozj/blink_id_id0.zip?dl=0 

 

Thanks 

Arintel
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
119 Views

You have not included a .sdc file in your design, so it has set the base clock constraint for the incoming clock to be 1 GHz with all other clocks in the design based off of that. So your design is most likely failing timing.  

 

Check the messages window in Quartus to get an idea of why programming might be failing.
Altera_Forum
Honored Contributor I
119 Views

Thanks.  

 

However, I'm still not clear. Even though I don't have a .sdc file, the clocks are still correct as they were specified when I generated the IOPLL core. Please see the attached screen shot. 

https://alteraforum.com/forum/attachment.php?attachmentid=15721&stc=1  

 

And if the lack of a clock constraint is the issue, why didn't I have an error when I commented out the red line? And the LED was still blinking as expected. 

 

Thanks, 

Binh
Altera_Forum
Honored Contributor I
119 Views

Even with the PLL settings, you still have to have a .sdc for timing closure. The report you show may be showing the clock settings from the PLL settings (it's not clear which part of the Compilation Report you're showing; is it from the timing analyzer folder?), but as the messages you posted say, timing analysis is using a 1 GHz base clock, not these clocks. 

 

But as you say, it still doesn't explain why programming is failing. As I asked, did you check the Messages window to see if there was an error reported during programming?
Altera_Forum
Honored Contributor I
119 Views

Yes, the report I showed was from the Compilation Report -> Timing Analyzer -> Clocks section. 

 

I added a .sdc file as follows:set_time_format -unit ns -decimal_places 3 

create_clock -name {board_clock} -period 20.000 -waveform { 0.000 10.000 } [get_ports { board_clock }] 

derive_pll_clocks -create_base_clocks 

derive_clock_uncertainty 

 

And I did a compilation again. Got the same report as before and the following warnings:Critical Warning(18655): There are 48 unused TX channels in the design.  

Critical Warning(17951): There are 48 unused RX channels in the design.  

Critical Warning(332148): Timing requirements not met 

 

I still have the same programming error at 85%. And the Message Window does not show anything about the programming error.
Altera_Forum
Honored Contributor I
119 Views

I think I figured out the problem. It seems that the Unique Chip ID core uses JTAG signals internally to read the ID. And in my code, the core's reset signal is initialized as de-asserted. Consequently, when the chip loading process reached 85% and the circuit (including the Unique Chip ID core) was activated, the Unique ID core immediately tried to use JTAG to read the ID. This interfered with the finalization of the loading process (which was also via JTAG) and caused the error. 

 

The solution was simply to initialize the core's reset signal to be asserted and wait a little bit for the loading process to finish before de-asserting it. 

 

Arintel
Reply