Lattice Diamond with Synpify Pro - cannot specify a clock - Page 1
Forum section: electronics / general

author: Axk
author_rank: Regular Contributor
timestamp: September 16, 2019, 12:05:05 pm
content: Lattice Diamond 64bit 3.8.0.115.3 (Windows 7)Trying synthesize a simple project with 3 System Verilog files.With Verilog files it allows to use the built-in Lattice LSE synthesizer but with SV files it requires to use Synpify Pro.I have a clk input in my top-level module but cannot figure out how to make it appear as a clock input under Spreadsheet View.Synpify Pro does say that clk is an inferred clock and I need to add a constraint for it.I open Synpify Pro (from the Diamond toolbar) add an SDC file (under Logic Constraints) and add a clock there as follows (done in trough the SCOPE ui on the clocks tab):define_clock {clk} -name {clk} -freq 50 -clockgroup default_clkgroup_0But back in Diamond I re-synthesize the design and the clk input is still appearing under "unconnected" in Spreadsheet View.And it is giving me this warning "WARNING - logical net 'clk' has no load."I've tried adding the same SDC file in Diamond under Synthesis Constraint Files but the synthesizing give me the following error:ERROR - 'clk' matches no clock ports in the designIt looks like the design is synthesizable (at least I don't see any warnings that it isn't)Edit:must me something with this particular design, not synthesizable somehow after all...I've just created a very basic test design and it did infer clk as a clock input in Spreadsheet automatically.The code of the top level module is as follows:Code:module ufmtest(clk, led);input clk;output reg led;parameter ST_IDL = 0;parameter ST_READING = 1;parameter ST_WRITING = 2;parameter ST_FINISHED = 3;reg st = ST_IDL;reg wr_rq = 0;reg rd_rq = 0;reg [7:0] wr_data = 0;ufm1 ufm1(.clk(clk), .ufm_wr_rq(wr_rq), .ufm_rd_rq(rd_rq), .ufm_wr_data(wr_data));efbif efbif(.wb_clk_i(ufm1.wb_clk), .wb_rst_i(ufm1.wb_rst), .wb_cyc_i(ufm1.wb_cyc), .wb_stb_i(ufm1.wb_stb), .wb_we_i(ufm1.wb_we),.wb_adr_i(ufm1.wb_addr), .wb_dat_i(ufm1.wb_dat_i), .wb_dat_o(ufm1.wb_dat_o), .wb_ack_o(ufm1.wb_ack));always @(posedge clk)begincase(st)ST_IDL:beginrd_rq <= 1;st <= ST_READING;endST_READING:beginrd_rq <= 0;if(ufm1.ufm_rd_ack && ufm1.ufm_rd_data == 8'hCD)beginled <= 1;endif(ufm1.ufm_done)beginwr_rq <= 1;wr_data <= 8'hCD;st <= ST_WRITING;endendST_WRITING:beginwr_rq <= 0;if(ufm1.ufm_done)beginst <= ST_FINISHED;endendendcaseendendmodule

author: Axk
author_rank: Regular Contributor
timestamp: September 16, 2019, 01:15:53 pm
content: Must me something with this particular design, not synthesizable somehow after all...I've just created a very basic test design and it did infer clk as a clock input in Spreadsheet automatically.

author: TimCambridge
author_rank: Regular Contributor
timestamp: September 16, 2019, 01:23:24 pm
content: Try opening your routed design in Diamond using "Tools/Physical View" and check the name that is eventually assigned to the net/pad.It starts as "clk" under verilog but synthesis can change the name to something like "clk_1"

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 16, 2019, 01:54:25 pm
content: I think the simplest way of declaring this clock constraint would be the following:Code:create_clock -name clk -period 20 [get_ports clk]Clock names from the tools POV can be decorated (as Tim suggested), so the correct way of referring to a clock *port* is using 'get_ports' as above.I think the 'define_clock' statement assumes that the referred clock has already been created, so I don't think you can use a single 'define_clock' statement like this in this context, unless you already know the clock name. But you don't, as inferred clocks get weird decorated names you can't count on. And I think the 'create_clock' one as above is enough in your case to define your constraint.

author: Axk
author_rank: Regular Contributor
timestamp: September 16, 2019, 03:05:21 pm
content: I wonder if there's an easy way to figure out why the "clk" net ends up with "no load".The ufm1 module ran fine in simulation in Modelsim.I've looked through the Sypify Pro warnings but it is just unused this and unused that (because of no clock I suppose), but no obvious reason to me.So I would just try simplifying the design, commenting out portions of it using the divide by 2 approach for now.Below is the list of warnings:Quote

author: ale500
author_rank: Frequent Contributor
timestamp: September 16, 2019, 06:07:11 pm
content: You have 4 values for the states but the state register is only one bit wide !Code:reg st = ST_IDL;

author: Axk
author_rank: Regular Contributor
timestamp: September 16, 2019, 07:15:57 pm
content: Quote from: ale500 on September 16, 2019, 06:07:11 pmD'oh!Thanks for spotting this.But this alone didn't fix the issue unfortunately.

author: Axk
author_rank: Regular Contributor
timestamp: September 16, 2019, 11:29:10 pm
content: This must be my misunderstanding of how output port registers are synthesized in Synplify Pro/Diamond, but adding an else block for setting the "output reg led" fixed the issue.I understand that with combinational logic one should have all cases covered to avoid latches, but in this case this is an output register (sequential logic), so I don't understand what the deal is.The code that I've added is highlighted inboldbelow.Quote

author: ale500
author_rank: Frequent Contributor
timestamp: September 20, 2019, 04:23:18 pm
content: I'd suggest you simulate your designs, simulation helps to catch most of these "oh, I forgot to initialize some register" or width mismatch and things like that. A life saver isCode:`default_nettype noneundefined nets are then not "generated automatically when needed"

author: Axk
author_rank: Regular Contributor
timestamp: September 21, 2019, 02:32:47 pm
content: I did simulate the design, I'm not at that level where a design of this complexity (writing/reading MachXO2 UFM flash via Wishbone - relatively complex, at least for me) would work without simulation with no bugs right away.I didn't simulate the top level (test) module though...It mostly worked but there was this gotcha with the register value.I ended up using just plain Verilog because Lattice LSE is presumably better, gives more clear warnings pointing to concrete lines of code, doesn't give false warnings.But even with Lattice LSE the below design didn't work without zeroing the led register first in the procedural block:Code:module ufmtest(clk, led, debug, debug2);input clk;output reg led = 0;output debug, debug2;parameter ST_IDL = 3'd0;parameter ST_READING = 3'd1;parameter ST_WRITING = 3'd2;parameter ST_FINISHED = 3'd3;reg [2:0] st = ST_IDL;reg wr_rq = 0;reg rd_rq = 0;reg [7:0] wr_data = 0;reg [7:0] rd_data;reg [4:0] matches = 0;wire wb_clk, wb_rst, wb_cyc, wb_stb, wb_we, wb_ack, ufm_rd_ack, ufm_wr_ack, ufm_done;wire [7:0] wb_addr;wire [7:0] wb_dat_i;wire [7:0] wb_dat_o;wire [7:0] ufm_rd_data;ufm1 ufm1(.clk(clk),.ufm_wr_rq(wr_rq),.ufm_rd_rq(rd_rq),.ufm_wr_data(wr_data),.ufm_wr_ack(ufm_wr_ack),.ufm_rd_data(ufm_rd_data),.ufm_rd_ack(ufm_rd_ack),.ufm_done(ufm_done),.wb_clk(wb_clk),.wb_rst(wb_rst),.wb_cyc(wb_cyc),.wb_stb(wb_stb),.wb_we(wb_we),.wb_addr(wb_addr),.wb_dat_i(wb_dat_i),.wb_dat_o(wb_dat_o),.wb_ack(wb_ack));efbif efbif(.wb_clk_i(wb_clk), .wb_rst_i(wb_rst), .wb_cyc_i(wb_cyc), .wb_stb_i(wb_stb), .wb_we_i(wb_we),.wb_adr_i(wb_addr), .wb_dat_i(wb_dat_i), .wb_dat_o(wb_dat_o), .wb_ack_o(wb_ack));assign debug = !wb_rst && wb_cyc && wb_stb && wb_we;assign debug2 = !wb_rst && wb_cyc && wb_stb && !wb_we;always @(posedge clk)begincase(st)ST_IDL:beginrd_rq <= 1;led <= 0; // !!this was necessary to get the clk input detected as clock, it apparently inferred that led was always 1 for some reason otherwisest <= ST_READING;rd_data <= 8'hA5;wr_data <= 8'hAA;endST_READING:beginrd_rq <= 0;if(ufm_rd_ack && ufm_rd_data == rd_data)beginrd_data <= rd_data + 8'd1;matches <= matches + 5'd1;endif(matches == 5'd16)beginled <= 1;endif(ufm_done)beginwr_rq <= 1;wr_data <= 8'hA5;st <= ST_WRITING;endendST_WRITING:beginwr_rq <= 0;if(ufm_wr_ack)beginwr_data <= wr_data + 8'd1;endif(ufm_done)beginst <= ST_FINISHED;endendendcaseendendmodule

author: asmi
author_rank: Super Contributor
timestamp: September 22, 2019, 01:21:33 am
content: Quote from: Axk on September 21, 2019, 02:32:47 pmBecause it is right. I also see absolutely no condition in which "led" register would be assigned zero... You probably presumed that it would clear to zero on startup - but if my memory serves me Lattice does not support "initial" style initialization in hardware (Xilinx FPGAs do support that). So it's your job as designer to ensure all registers are what they should be at all times - you can make no assumptions about which way will they end up after configuration. If my memory serves me (it's been a while since I used Lattice parts, so don't quote me on that), Synplify Pro even displays a warning about that (it's probably one of those "false warnings" that you've chosen to ignore), or it might've been simulator - can't remember now. Oh, and by the way - LSE is total garbage, you Synplify Pro if you can at all times.

author: ale500
author_rank: Frequent Contributor
timestamp: September 22, 2019, 05:46:00 am
content: Synplify Pro in the Lattice package supports initial values for registers, you have to specify them. Anyways somewhere it is written that registers are initialized to zero, somewhere, kind of footnote.I normally assign a default (I try to use always 0) at register declaration, but then the synthesizer complains and likes that the registers gets a reset-provided value.Anyways for simulation registers are initialized to 'X'... a value which could be very useful at finding missing uninitialized registers.