Lattice Diamond: Secondary Clock resources

[NivagSwerdna]

Newbie question...

So I am playing with my MachXO3LF development board... (it's such a sweet thing)...

I keep getting what appear to be harmless warnings...

   61061008   WARNING - Signal "thing_c" is selected to use Secondary clock resources. However, its driver comp "thing" is located at "N1", which is not a dedicated pin for connecting to Secondary clock resources. General routing has to be used to route this signal, and it might suffer from excessive delay or skew.

thing is just an input associated with a DIP switch on the board at N1.

What is thing_c? Why would a simple input be associated with any clock resources?  it's a switch!  I think somehow it is trying to create an association between the I/O pin and the subsequent logic... maybe for edge sensing???

What am I missing here?

Thanks

[SiliconWizard]

It's hard to tell without seeing your code.

Is this signal used as a clock for any process (for instance by reacting on its edges), or as an asynchronous reset signal?

[NivagSwerdna]

Code: [Select]

module top (LED, rstn, reset);

output wire [7:0] LED;
input wire rstn;
input wire reset;

wire fpga_clock;

wire    [7:0] LED_array;

OSCH #(.NOM_FREQ("133.00")) rc_oscillator(.STDBY(1'b0), .OSC(fpga_clock),.SEDSTDBY());
slow_counter counter(.clock(fpga_clock), .enable(rstn), .output_byte(LED_array), .reset(reset));

assign LED = ~LED_array;

endmodule 

module slow_counter (clock, enable, output_byte, reset);


input wire clock;
input wire enable;
input wire reset;
output reg [7:0] output_byte;

reg [31:0] counter;

initial
begin
output_byte = 8'b00000000;
counter = 32'b0;
end

always @(posedge clock)
begin
if (reset) begin
output_byte = 8'b00000000;
counter = 32'b0;
end
else if(enable == 1'b1)
begin
counter <= counter + 1'b1;
output_byte <= counter[31:24];
end
end

endmodule

Code: [Select]

WARNING - Signal "reset_c" is selected to use Secondary clock resources. However, its driver comp "reset" is located at "N1", which is not a dedicated pin for connecting to Secondary clock resources. General routing has to be used to route this signal, and it might suffer from excessive delay or skew.

[SiliconWizard]

You may try replacing the output_byte assignment 'output_byte <= counter[31:24];' with 'output_byte = counter[31:24];'

Does the warning disappear?

[KrudyZ]

You are using a mix of blocking and non-blocking assignments in the same module.
That's a no-no. Synchronous processes should be using non-blocking assignments throughout ( <= ).

[KrudyZ]

Try this:

module slow_counter (clock, enable, output_byte, reset);
   
   input wire clock;
   input wire enable;
   input wire reset;
   output reg [7:0] output_byte = 8'h0;
   
   reg [31:0] counter = 32'd0;
   
   always @(posedge clock)
   begin
      if (reset) begin
         output_byte <= 8'h0;
         counter <= 32'd0;
      end      
      else if(enable == 1'b1)
      begin
         counter <= counter + 32'd1;
         output_byte <= counter[31:24];
      end
   end
   
endmodule

[NivagSwerdna]

You are using a mix of blocking and non-blocking assignments in the same module.
That's a no-no. Synchronous processes should be using non-blocking assignments throughout ( <= ).

Oops... that must have crept in whilst tinkering.. but that's not the primary question here...

Reverted to all <=

[NivagSwerdna]

The warning...

Code: [Select]

61061008 WARNING - Signal "reset_c" is selected to use Secondary clock resources. However, its driver comp "reset" is located at "N1", which is not a dedicated pin for connecting to Secondary clock resources. General routing has to be used to route this signal, and it might suffer from excessive delay or skew.

Looking through the output I see a reset_c being synthesised...

Code: [Select]

################### Begin Clock Report ######################
Clock Nets
Number of Clocks: 1
  Net : fpga_clock, loads : 40
Clock Enable Nets
Number of Clock Enables: 1
Top 1 highest fanout Clock Enables:
  Net : fpga_clock_enable_40, loads : 1
Highest fanout non-clock nets
Top 10 highest fanout non-clock nets:
  Net : reset_c, loads : 41
  Net : fpga_clock_enable_40, loads : 40
  Net : counter/counter_24, loads : 2
  Net : counter/counter_31, loads : 2
  Net : counter/counter_29, loads : 2
  Net : counter/counter_30, loads : 2
  Net : counter/counter_27, loads : 2
  Net : counter/counter_28, loads : 2
  Net : counter/counter_25, loads : 2
  Net : counter/counter_26, loads : 2
################### End Clock Report ##################
and

Code: [Select]

   Number of clocks:  1
     Net fpga_clock: 21 loads, 21 rising, 0 falling (Driver: rc_oscillator )
   Number of Clock Enables:  1
     Net fpga_clock_enable_40: 21 loads, 21 LSLICEs
   Number of LSRs:  1
     Net reset_c: 21 loads, 21 LSLICEs
   Number of nets driven by tri-state buffers:  0
   Top 10 highest fanout non-clock nets:
     Net reset_c: 22 loads
     Net fpga_clock_enable_40: 21 loads
     Net counter/counter_24: 2 loads
     Net counter/counter_25: 2 loads
     Net counter/counter_26: 2 loads
     Net counter/counter_27: 2 loads
     Net counter/counter_28: 2 loads
     Net counter/counter_29: 2 loads
     Net counter/counter_30: 2 loads
     Net counter/counter_31: 2 loads


Code: [Select]

The following 1 signal is selected to use the primary clock routing resources:
    fpga_clock (driver: rc_oscillator, clk load #: 21)


The following 2 signals are selected to use the secondary clock routing resources:
    fpga_clock_enable_40 (driver: SLICE_18, clk load #: 0, sr load #: 0, ce load #: 21)
    reset_c (driver: reset, clk load #: 0, sr load #: 21, ce load #: 0)

WARNING - Signal "reset_c" is selected to use Secondary clock resources. However, its driver comp "reset" is located at "N1", which is not a dedicated pin for connecting to Secondary clock resources. General routing has to be used to route this signal, and it might suffer from excessive delay or skew.
No signal is selected as Global Set/Reset.

So my real question... Why is reset_c synthesised?  (I do not have a reset_c in my code only a reset) and why does it complain about routing of this signal?

Note: My code and project does work I am just trying to understand the reset_c.  I'm thinking it relates to the I/O cells on the MachXO3?

PS
I am using Lattice ISE

[NivagSwerdna]

LSR seems to be local set/reset on a Slice which appears to be a reasonable place for a reset signal to end up. Not sure why it becomes reset_c rather than reset.

Maybe the secondary clock routing is chosen, despite this not being a clock, because it is fast and the warning is due to an unnecessarily harsh constraint imposed by default?

[David Chamberlain]

Hi, also learning HDL with the MachXO3 however I'm using Diamond rather than ISE but I'm sure that are much the same thing.  I have also seen these warnings and figured the tool is just telling me that in it's assessment the best performance would be gained by using a pin dedicated to clocking - OK so I realise I just reworded the warning

But how the synthesis and routing tools work that out I figured was either a) This input is being used to clock registers so must be a clock or b) This input has a large fan out to various blocks and so must be a clock.

If any of that is an issue or not comes down to timing constraints you place in the 'spreadsheet view' or determine from reading through the timing reports. The reports will mention worst case rise times and thus max frequencies for different i/o paths.

The 'reset_c' I'm just going to say this means "reset"+"clock" but either way they are just internal net names that the tools have assigned. Again if you look a the timing reports you will see all sorts of crazy and incomprehensible suffix's to you signal names.

[NivagSwerdna]

I tried moving the reset input to M1 expecting the warning to disappear but it didn't; it's tricky stuff this.

[David Chamberlain]

Not sure what pin M1 is.. BGA package?

You can get csv pin out files at the link below they show the dedicated clocking pins, differential pairs and so on.
http://www.latticesemi.com/Products/FPGAandCPLD/MachXO3#_FAB1DF60223D4AFA8425413790E0F113

[NivagSwerdna]

MachXO3LF Starter Kit => LCMXO3LF-6900C-5BG256C

I might have miscalculated M1... need to check

[David Chamberlain]

Ok this is the exact pinout file for your part.
http://www.latticesemi.com/view_document?document_id=50412

CABGA256 part column

107   PL22B   3   PCLKC3_0   Comp_OF_PL22A   - +  M1

Try L2

[NivagSwerdna]

Try L2

Aha! Great!  That works.

L2 is PCLKT3_0 whereas M1 was PCLKC3_0

I can see PCLKT3_0 is a potential secondary clock input so that is golden.

Not sure about PCLKC3_0... maybe that is a differential input?  For LVDS or similar??

[David Chamberlain]

Cool 

Yeah i figure because M1 was marked as Comp_OF_PL22A. A complenent of another 'True_OF...' pin meaning its not going to work as a clock source unless you specified the design to use a differential pair.

[daveshah]

I wouldn't stress too much about the warning. Reset signals are nowhere near as critical as clock signals, the main advantage of using dedicated global (aka "clock") routing for them is to avoid congestion. But it is possible in the architecture, I think, to route any signal onto the high fanout global networks through the fabric regardless of which pin is used using only a small amount of general routing, which I would not expect to affect a reset signal, particularly a synchronous one, significantly. For a clock using dedicated inputs is more important in order to minimise jitter.

[NivagSwerdna]

I wouldn't stress too much about the warning.

I was interested in the 'why' rather than being stressed but point taken. Thanks.

[SiliconWizard]

LSR seems to be local set/reset on a Slice which appears to be a reasonable place for a reset signal to end up. Not sure why it becomes reset_c rather than reset.

Maybe the secondary clock routing is chosen, despite this not being a clock, because it is fast and the warning is due to an unnecessarily harsh constraint imposed by default?

When generating the netlist, the synthesis tool usually appends '_c' to the signal names that are treated as clocks. This can be confusing but this is just some name decoration.

An asynchronous reset signal would typically be handled this way. Clock distribution resources are prefered for asynchronous resets. The interesting point here is why the 'reset' signal is handled this way, whereas you're using it as a synchronous reset in your counter process.

The modification I suggested had a two-fold objective: first:
 

Code: [Select]

counter <= counter + 32'd1;
         output_byte <= counter[31:24];
Doing this, an additional register (flip-flops) will be inferred for the output_byte signal. I think this wastes resources for no good reason. Additionally, this will make the output_byte signal lag the counter value by one clock cycle. You may or may not care.

The 'output_byte' could just be an alias of 'counter[31:24]' without any extra registering IMO. (The registering could have some benefits for speed, not too sure in this case though.)

The second reason was that I was making the hypothesis that this is this extra register that makes the 'reset' signal asynchronous for the corresponding flip-flops.
But the fact that you used a blocking assignment in the reset case of your process may well be the real reason.

You may find this paper interesting: http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf

[SiliconWizard]

Just thinking about it a little more. There is still something that we overlooked here, and a common trap, not just for beginners either.

Your 'reset' signal, which is itself asynchronous by nature (meaning not synchronized to your process clock) may be the cause, and this should be addressed anyway.

You should synchronize it before using it as a synchronous reset IMO, otherwise you can get metastability issues. Looks like the synthesis tool did the job for you by making it an asynchronous reset. But I'd suggest learning about clock domains and metastability.

[KrudyZ]

Do you have timing constraints in your project?
Without constraints, it's quite possible that the tool wants to minimize any skew and conservatively asks for the reset to be on the clock tree.
Since the reset is synchronous, adding a timing constraint would allow the tool to actually calculate the required setup and hold times and it should have no problem with placing it on any pin as long as the timing is met.