Lattice Diamond: Secondary Clock resources - Page 1
Forum section: electronics / general

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 02, 2018, 09:41:30 am
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 02, 2018, 03:36:24 pm
content: 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?

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 02, 2018, 04:53:01 pm
content: Code: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;endmodulemodule 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;initialbeginoutput_byte = 8'b00000000;counter = 32'b0;endalways @(posedge clock)beginif (reset) beginoutput_byte = 8'b00000000;counter = 32'b0;endelse if(enable == 1'b1)begincounter <= counter + 1'b1;output_byte <= counter[31:24];endendendmoduleCode: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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 02, 2018, 05:22:12 pm
content: You may try replacing the output_byte assignment 'output_byte <= counter[31:24];' with 'output_byte = counter[31:24];'Does the warning disappear?

author: KrudyZ
author_rank: Frequent Contributor
timestamp: June 03, 2018, 03:14:13 am
content: 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 ( <= ).

author: KrudyZ
author_rank: Frequent Contributor
timestamp: June 03, 2018, 03:21:59 am
content: 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)beginif (reset) beginoutput_byte <= 8'h0;counter <= 32'd0;endelse if(enable == 1'b1)begincounter <= counter + 32'd1;output_byte <= counter[31:24];endendendmodule

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 09:07:54 am
content: Quote from: KrudyZ on June 03, 2018, 03:14:13 amOops... that must have crept in whilst tinkering.. but that's not the primary question here...Reverted to all <=

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 09:13:35 am
content: The warning...Code:61061008WARNING - 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:################### Begin Clock Report ######################Clock NetsNumber of Clocks: 1Net : fpga_clock, loads : 40Clock Enable NetsNumber of Clock Enables: 1Top 1 highest fanout Clock Enables:Net : fpga_clock_enable_40, loads : 1Highest fanout non-clock netsTop 10 highest fanout non-clock nets:Net : reset_c, loads : 41Net : fpga_clock_enable_40, loads : 40Net : counter/counter_24, loads : 2Net : counter/counter_31, loads : 2Net : counter/counter_29, loads : 2Net : counter/counter_30, loads : 2Net : counter/counter_27, loads : 2Net : counter/counter_28, loads : 2Net : counter/counter_25, loads : 2Net : counter/counter_26, loads : 2################### End Clock Report ##################andCode:Number of clocks: 1Net fpga_clock: 21 loads, 21 rising, 0 falling (Driver: rc_oscillator )Number of Clock Enables: 1Net fpga_clock_enable_40: 21 loads, 21 LSLICEsNumber of LSRs: 1Net reset_c: 21 loads, 21 LSLICEsNumber of nets driven by tri-state buffers: 0Top 10 highest fanout non-clock nets:Net reset_c: 22 loadsNet fpga_clock_enable_40: 21 loadsNet counter/counter_24: 2 loadsNet counter/counter_25: 2 loadsNet counter/counter_26: 2 loadsNet counter/counter_27: 2 loadsNet counter/counter_28: 2 loadsNet counter/counter_29: 2 loadsNet counter/counter_30: 2 loadsNet counter/counter_31: 2 loadsCode: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?PSI am using Lattice ISE

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 09:19:17 am
content: 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?

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: June 03, 2018, 09:35:57 am
content: 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 warningBut 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.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 11:05:45 am
content: I tried moving the reset input to M1 expecting the warning to disappear but it didn't; it's tricky stuff this.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: June 03, 2018, 11:13:37 am
content: 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

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 11:29:31 am
content: MachXO3LF Starter Kit => LCMXO3LF-6900C-5BG256CI might have miscalculated M1... need to check

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: June 03, 2018, 11:37:55 am
content: Ok this is the exact pinout file for your part.http://www.latticesemi.com/view_document?document_id=50412CABGA256 part column107 PL22B 3 PCLKC3_0 Comp_OF_PL22A - + M1Try L2

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 11:52:47 am
content: Quote from: David Chamberlain on June 03, 2018, 11:37:55 amAha! Great! That works.L2 is PCLKT3_0 whereas M1 was PCLKC3_0I 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??

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: June 03, 2018, 12:02:45 pm
content: CoolYeah 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.

author: daveshah
author_rank: Unknown
timestamp: June 03, 2018, 12:28:38 pm
content: 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.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 03, 2018, 12:31:00 pm
content: Quote from: daveshah on June 03, 2018, 12:28:38 pmI was interested in the 'why' rather than being stressed but point taken. Thanks.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 03, 2018, 02:51:33 pm
content: Quote from: NivagSwerdna on June 03, 2018, 09:19:17 amWhen 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: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

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 03, 2018, 03:07:24 pm
content: 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.

author: KrudyZ
author_rank: Frequent Contributor
timestamp: June 03, 2018, 04:02:04 pm
content: 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.