Forum Discussion

ChristofAbt's avatar
ChristofAbt
Icon for New Contributor rankNew Contributor
5 days ago

Shift Register triggers occassionally on both clock edges

Good morning community, in my project a MAX10 M08 FPGA serves as an interface between a microcontroller and an ADC board with 32 channels. In order to parallelize the serial data from the board I developed a shift register. This register shall only read the first 512 bits of a data stream. Therefore a counter is included.

-- serial-parallel converter synchronous to falling edge of DCLK
p_ser_par_dclk : process (DCLK,nRES) is
begin
   if (nRES = '0') then
     dout0_shr_dclk <= (others => '0');
     dout1_shr_dclk <= (others => '0');
     mod1023_count_i <= 0;
  elsif (falling_edge(DCLK)) then
    -- resets counter when nDRDY active
    if (nDRDY = '1') then 
      mod1023_count_i <= 0; 
    elsif (mod1023_count_i < 512) then
      mod1023_count_i <= mod1023_count_i + 1;
    end if;
    -- counter masks the 512 DCLK clock edges without data
    if (mod1023_count_i < 512) then
      -- shift-registers, alert bit, address bits, CRC bits shifted, maybe later omitted
      dout0_shr_dclk(0) <= DOUT0;
      dout1_shr_dclk(0) <= DOUT1;
      dout0_shr_dclk((snr_length - 1) downto 1) <= dout0_shr_dclk((snr_length - 2) downto 0);
      dout1_shr_dclk((snr_length - 1) downto 1) <= dout1_shr_dclk((snr_length - 2) downto 0);
    -- no shifting
    else
      dout1_shr_dclk <= dout1_shr_dclk;
      dout0_shr_dclk <= dout0_shr_dclk;
    end if;
 end if;
end process p_ser_par_dclk;
 
The data from the AD converters contains the channel number. Therefore there must be regular data patterns in the 512 bit wide vector when a complete set of 16*32bit have been written into the FIFO. I could never see this pattern when I visualized the internal data with the signal tap analyzer. What I can occassionally see is that the shift registers and the counter triggers at the wrong edge. This is a severe error. What could be the reason?
Best regards
Christof Abt
 
 

6 Replies

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor

    Hi Christof,

    a possible reason is ringing external clock. Signaltap recording isn't very informative, it's not clear how dclk is related to acquisition clock.

    Regars Frank

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    Signal names on the Signal Tap capture would be helpful.  Is your design meeting timing?

    The code could also use some clean up, combining the if blocks for the counter operation and performing the shift.

    And as mentioned, what are you using as the acquisition clock in Signal Tap?

    • ChristofAbt's avatar
      ChristofAbt
      Icon for New Contributor rankNew Contributor

      Good morning, thank you for your reply. Sorry, I should have included the signal names. The counter and the shift operation could be combined but the original code should not cause any problems. Everything is synchronous to the falling edge of DCLK. The acquisition clock is very low, around 2MHz.

      • sstrell's avatar
        sstrell
        Icon for Super Contributor rankSuper Contributor

        2 MHz?  Why are you using that?  What is the frequency of dclk?  That should be your acquisition clock in Signal Tap.  A faster clock provides much better sampling.

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor

    There are a few things you can try:
    1) Set DCLK as global clock 

    2) Constrain the source‑synchronous input properly in your sdc e.g. set_input_delay

    3) Synchronize async signals into the DCLK domain:
     - Two-stage synchronizer for nDRDY and any other async control; sample DOUT* only with respect to the synchronized signals.