Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17252 Discussions

Dual-Clock FIFO (DCFIFO) not behaving

Altera_Forum
Honored Contributor II
1,464 Views

I'm getting warnings from the megafunction DCFIFO that I can't get rid off: 

Info: Evaluating HDL-embedded SDC commands Info: Entity dcfifo_edl1 Info: set_false_path -from *rdptr_g* -to *ws_dgrp|dffpipe_0v8:dffpipe8|dffe9a* Info: set_false_path -from *delayed_wrptr_g* -to *rs_dgwp|dffpipe_vu8:dffpipe5|dffe6a* Warning: At least one of the filters had some problems and could not be matched Warning: *ws_dgrp|dffpipe_0v8:dffpipe8|dffe9a* could not be matched with a clock or keeper or register or port or pin or cell or partition Warning: Ignored assignment: set_false_path -from -to Warning: Argument <to> is not an object IDAs stated in the quote, these are HDL-embedded SDC commands that is generated by the megafunction. Also, this DCFIFO is the only place where my timing isn't met. It's an asynchronous FIFO, the purpose of it is to handle just that!:cool: 

 

Has anyone else ran into this?
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
727 Views

No, it looks like a bug... 

Did you give a strange name to your fifo? Something with not-so-legal characters in HDL (-, as an example, or a name that begins by a digit), or the same name than a signal elsewhere in the design?
0 Kudos
Altera_Forum
Honored Contributor II
727 Views

Don't think so, named it asynch_fifo in subfolder fifo. 

Main design instantiates asynch_buf.v: 

// ========================================================================== // Asynchronous buffer // -------------------------------------------------------------------------- // The high-speed LVDS clocks rx_clk and tx_clk are synchronous but // off-phase, thus the buffer should maintain constant size. // ========================================================================== assign asynch_buf_reset_n = reset_n && opt_done; asynch_buf async_buf_i ( .data ( rx_data ), .rdclk ( rx_clk ), .wrclk ( tx_clk ), .reset_n ( asynch_buf_reset_n ), .q ( tx_data ) );And asynch_buf instantiates asynch_fifo.v: 

module asynch_buf ( input data, input rdclk, input wrclk, input reset_n, output q ); // +----------------------------------------------------------------- // | Internal signals // | // +----------------------------------------------------------------- wire rdempty; wire rdusedw; wire wrfull; wire wrusedw; // +----------------------------------------------------------------- // | Write Request // | * Active when not in reset // +----------------------------------------------------------------- reg wrreq; always @(posedge wrclk, negedge reset_n) begin if ( !reset_n ) wrreq <= 0; else wrreq <= 1; end // +----------------------------------------------------------------- // | Read request // | * Active when data is available // +----------------------------------------------------------------- wire rdreq; assign rdreq = !rdempty; // +----------------------------------------------------------------- // | Asynchronous FIFO // | // +----------------------------------------------------------------- asynch_fifo asynch_fifo_i( .data ( data ), .wrreq ( wrreq ), .rdreq ( rdreq ), .rdclk ( rdclk ), .wrclk ( wrclk ), .q ( q ), .rdempty ( rdempty ), .rdusedw ( rdusedw ), .wrfull ( wrfull ), .wrusedw ( wrusedw ) ); endmodule It's a mystery. I also tried to generate the FIFO again, no luck... Any ideas? 

 

[EDIT] 

Added megafunction generated verilog file
0 Kudos
Altera_Forum
Honored Contributor II
727 Views

Could it be that the compiler did some optimization and removed/renamed the path: *ws_dgrp|dffpipe_0v8:dffpipe8|dffe9a* ? So the TimeQuest could not find the path in the post-synthesis netlist and gave out the warning.

0 Kudos
Reply