- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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, ingdxdyLink Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Its difficult to see what you are doing without the code.
Can you post it?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page