Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20688 Discussions

delayed register rising at the same time with original register

Altera_Forum
Honored Contributor II
1,316 Views

Dear sir, 

Since i use cyclone V (5CEFA9F31C8 with quartus 12.1 and 14.0), several strange things happened, which made me suspect if altera FPGA could be used anymore, or maybe i should divert to Xlinx FPGAs. 

 

1. The compiled sof file is very large of around 12MB, even if i used little LEs(less than 1%, memory block <2%, pins-39%, PLLs: 3 out of 8). Strange thing is when the LE usage is 15% and memory block usage is 66%, the compiled sof file is still 12MB! 

2. The signalTap captures impossible phenomenons, however, timequest did not give timing violation. 

3. FIFO's rdusedw changed strangely, similar to this thread: http://www.alteraforum.com/forum/showthread.php?t=1615, but in my case, both rdclk and wrclk are from PLL outputs, so it should not be the glitches problem. I changed sync stage of FIFO from 2 to 4, this problem seemed disappeared temporarily. 

 

look at the following code: 

reg top_c_lval_reg; 

always@(posedge clk) top_c_lval_reg<=top_c_lval; 

 

the 'top_c_lval' is from outside of FPGA, here i defined a register 'top_c_lval_reg' to latch the value of top_c_lval. 

i use this to detect the rising edge of top_c_lval, in other places in my code, i have 'if(~top_c_val_reg&top_c_lval)'. 

i inserted these two signals in signalTap, the capture clock designated in signalTap is the same as latch clock in the code. 

after compiling the code and running signaltap, i found top_c_lval and top_c_val_reg were rising at the same time! that is, edge-aligned! 

HOW could this be happen? should top_c_lval_reg be delayed a clock cycle to top_c_lval?  

http://www.alteraforum.com/forum/attachment.php?attachmentid=10109&stc=1  

could anymore explain this to me? 

i am crazy about the result. 

 

Best wishes and Regards, 

ingdxdy
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
381 Views

1. That is understandable. The .sof file contains the setup for the entire FPGA. so all .sof files will be the same size, regardless of resource usage. 

2. Then I more likely suspect port timing constraints or poor clock/signal combinations in signal tap. 

3. Ive never had a problem with DC fifos, so cannot comment. 

 

You say that you are registering signals from external to the FPGA - are you doing it safely? with IO timing constraints? are you using the fast IO registers in the Pins? how are you getting it across the clock domains? at least 2 registers?  

Your comments seem to suggest poor domain crossing. 

 

Secondly, what clock are you using in signal tap? is it just possible that the clock you are using is unrelated to at least one of the signals?
0 Kudos
Altera_Forum
Honored Contributor II
381 Views

Thanks much for the quick reply. 

 

1. ok,thanks for clarifying. 

2. use fast io register, without io timing contraints, the trigger clock used in signaltap is the same clock used in the logic, for at the beginning, i doubted if the phase problem of trigger clock caused the erratic phenomenon, so i intentionally chose the same clock to trigger signaltap. 

 

my opinion, whether i used io timing contraints or not, top_c_lval_reg signal should be a clock cycle delayed to top_c_lval, am i wrong? 

 

one more word, the top_c_lval is given by a outside ADC, whose reference clock(feed by PLL output from FPGA, frequency is 40MHz) is the same clock used in the code(also in the signaltap), according to the ADC spec, top_c_lval should be edge-aligned with the rising edge of its reference clock. 

 

Regards, 

ingdxdy
0 Kudos
Altera_Forum
Honored Contributor II
381 Views

Its difficult to see what you are doing without the code. 

Can you post it?
0 Kudos
Altera_Forum
Honored Contributor II
381 Views

The code segment is as following. 

the basic idea is, detecting the rising edge of lval signal, and latch data from ADC. 

-------------------- 

 

reg top_c_lval_reg; 

always@(posedge clk) top_c_lval_reg<=top_c_lval; 

 

reg [12:0] cnt_rd_tc2; 

reg top_c_wr_start; 

always@(posedge clk or negedge rst_n) begin  

if(~rst_n) cnt_rd_tc2<=0; 

else if(top_c_lval_reg&&cnt_rd_tc2==0) cnt_rd_tc2<=1; //else if((~top_c_lval_reg&top_c_lval)&&cnt_rd_tc2==0) cnt_rd_tc2<=1;  

else if(cnt_rd_tc2==1295) cnt_rd_tc2<=0; 

else if(|cnt_rd_tc2) cnt_rd_tc2<=cnt_rd_tc2+1'b1; 

else cnt_rd_tc2<=0; 

 

if(~rst_n) top_c_wr_start<=1'b0; 

else if(cnt_rd_tc2==6) top_c_wr_start<=1'b1; 

else if(cnt_rd_tc2==1295) top_c_wr_start<=1'b0; 

else top_c_wr_start<=top_c_wr_start; 

 

 

if(~rst_n) cnt_rd_tc1<=2'b00; 

else if(top_c_wr_start) cnt_rd_tc1<=cnt_rd_tc1+1'b1; 

else cnt_rd_tc1<=2'b00; 

end 

 

reg [1:0] cnt_rd_tc1; 

always@(posedge clk or negedge rst_n) begin  

if(~rst_n) top_c_L1_wr<=1'b0; 

else if(&cnt_rd_tc1) top_c_L1_wr<=1'b1; 

else top_c_L1_wr<=1'b0;  

end 

---------------------- 

 

If top_c_lval_reg rises at the same time with the rising edge of top_c_lval, it means that cnt_rd_tc2 starts counting ahead of time, which directly causes a misaligned data frame. 

 

Regards 

ingxy
0 Kudos
Altera_Forum
Honored Contributor II
381 Views

as top_c_lval is coming from an external source, it will be rising between the two clock edges, hence why you see them rise at the same time. You need at least 2 registers to get it into the clock domain to detect a rising edge. 

 

Remember, the PCB tracks will add delay to the value coming from ADC
0 Kudos
Altera_Forum
Honored Contributor II
381 Views

I added io timing contraints for lval signal, TimeQuest reported hold timing violation, i adjusted the phase relationship of clocks, it seemed that the problem had disappeared. 

 

i will reconfirm it these days. 

 

Thanks much for your help and my apology for complaining at the beginning. 

 

 

Regards, 

ingxy
0 Kudos
Reply