FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5949 Discussions

max10, fiftyfivenm_crcblock, crc error do re config internally?

Honored Contributor II


Im using max10 and need to detect seu error for crc.  

Is it necessary to use the block fiftyfivenm_crcblock  

if I want to access the crc_error from the error detection logic 

by internal logic? If so how to get the crc_error routed to the 

crc_error pin and also access it for other logic as fiftyfivenm_crcblock? 

A AN note says it could be routed to a bidir pin and then routed to the 

fiftyfivenm_crcblock, but how? The max10 have a crc_error pin which  

is a pure output, not a bidir pin ~ALTERA_CRC_ERROR~ : D6 : output. 


Also how could I by only using internal logic detect an crc-error and then 

force a re-configuration (force eg nconfig) without using any external logic at all? 

Is it necessary to use the fiftyfivenm_rublock and if so how to use it as a simple 

internal re-config controller? 


fiftyfivenm_crcblock port map ( 

clk => pld_clk, 

shiftnld => shiftnld, 

ldsrc => ldsrc, 

crcerror => mapp to what and how, 

regout => regout
0 Kudos
2 Replies
Honored Contributor II

I am also interessed on this issue.


Although the original question is about 2 years old, I think this solution can be of interrest to others as well.


Most of this is based on the Max10 Handbook page 3-9 "Accessing Error Detection Block Through User Interface" and some guessing and trying of the actual vhdl component interface.

Through try and error, I determined it also needed an lcell (or non-trivial logic) in order to route the crc output signal to arbitrary pins. Without it, it was limited to the special-use crc_error pin.

The uses of the internal output signal of the crcblock does not require one to activate the external crc_error pin in the device settings.

I only tried this in Quartus 18.1, not in hardware yet:

library ieee; use ieee.numeric_std.all; use ieee.std_logic_1164.all; library lpm; use lpm.all;   entity XYZ is port( ErrorOut : out std_logic ); end entity;   architecture arch of XYZ is   component fiftyfivenm_crcblock is generic ( oscillator_divider : integer range 2 to 256 := 1 -- default is nonsense ); port ( clk : in std_logic := '0'; shiftnld : in std_logic := '0'; ldsrc : in std_logic :='0'; crcerror : out std_logic; regout : out std_logic ); end component;   component lcell is port ( a_in : in std_logic; a_out : out std_logic); end component;   signal CRC : std_logic; signal CRC_lcell : std_logic;   begin X1: fiftyfivenm_crcblock generic map( oscillator_divider => 256 ) port map( crcerror => CRC ); L1: lcell port map( a_in => CRC, a_out => CRC_lcell ); ErrorOut <= '0' when CRC_lcell='1' else 'Z'; -- Open drain output with proper polarity for nConfig end architecture;

(The code is taken from a larger code block for one of my projects.)

Some other remarks about the crc error block:

- It looks like the crcblock was part of the old megawizard plugin, but it has no equivalent in the new IP catalog.

- Based on the documentation I conclude that a crc error does not automatically induce a reload of the configuration. I also noted that the polarity of the crc_error pin and the nConfig pin is opposite - direct connection will not work.