2110 - LatticeECP3: How to fix <i>netsanitycheck </i>error when dynamic clock selector drives DDR (Double Data Rate) primitive components?<br>
LatticeECP3 device requires dedicated or primary clock resources to drive DDR (Double Data Rate) primitive components. The clock nets from the clock input pads to the destination DDR component must use pure primary or dedicated clock nets. If you implement a dynamic clock selector element in your RTL design, it may use general routing resources. This causes a design rule check violation and generates the netsanitycheck error.
LatticeECP3 incorporates dedicated DCS (Dynamic Clock Select) function blocks that allows you to use only the primary clock resources. Although your RTL coding is an equivalent function of the DCS block, the synthesis tool may not use the DCS resource unless you explicitly instantiate the DCS block. The following Verilog example shows how to instantiate a DCS function in a LatticeECP3 design:
Assume that "ck_a" and "ck_b" are two clock inputs, and "sel" is a clock selector input. It can be expressed as shown below, and note that it may not use the DCS block function.
[Verilog]
assign clk_out = (sel)? ck_a : ck_b;
[VHDL]
if (sel = '1') then
clk_out = ck_a;
else
clk_out = ck_b;
endif
To use the dedicated DCS block function instead, instantiate the DCS primitive as shown below:
[Verilog]
DCS u1_dcs (.CLK0 (ck_a), .CLK1 (ck_b), .SEL (sel), .DCSOUT (clk_out));
[VHDL]
u1_dcs : DCS port map
(CLK0 => ck_a, CLK1 => ck_b, SEL => sel, DCSOUT => clk_out);
The use of DCS block will let you use fully dedicated primary clock resources, and you will not see the netsanitycheck error.