The following code runs well in simulation mode but synthesis fails. Please let me know how I can get this synthesized, thanks!
Fei `timescale 1ns / 1ps module blink_led(clk, d, led); input clk; input d; output wire led;
parameter blink_freq = 2; reg [blink_freq:0] count = 0; reg [1:0] state = 0; reg [1:0] next_state = 0; assign led = !count[blink_freq];
always @(posedge clk) begin state
I've managed to code this to get synthesis done but I don't understand why next_state can be assigned in both always blocks but count cannot? The only difference is count update depends on count itself...
`timescale 1ns / 1ps
module blink_led(clk, d, led); input clk; input d; output wire led;
parameter blink_freq = 2; reg [blink_freq:0] count = 0; reg [1:0] state = 0; reg [1:0] next_state = 0; assign led = !count[blink_freq];
always @(posedge clk) begin state
(snip)
It is usual not to be able to synthesize the above logic. Pretty much anything with a numeric delay won't synthesize.
This means there are two outputs connected together.
You can't do that in real logic as the output drivers will fight each other, often with large currents flowing.
Without going all the way through the logic, I believe it is count that has more than one source.
-- glen
I'm assuming you're not trying to synthesize your test-bench ie module stimuli. You can only synthesize blink_led and if you want to exercise it after synthesis, you can use the gate level version under your test-bench or implement in an fpga and drive the pins on the board.
As to synthesizing the blink_led module, you need to make sure that any signal is driven from only one always block. Put all next_state and count assignments to the second (combinational) block. You can add another set of wires for something like count_d and assign it in the second block (ie count_d = count + 1; etc) and add count
Thanks, I think my second iteration does exactly what you described here. I do have one last doubt about timing. In my synthesizable version, when I run the test bench, the value of state always lags behind next_state for 1 or half clock period. My understanding is that since they are in separate always blocks, the simulation is free to do this assignment with a delay. Is there a deeper reason why state value always lag behind next_state for 1 clk?
clk period = 40
0 clk = 0, d = 0, led = 0, state = 00, next_state = 00 20 clk = 1, d = 0, led = 0, state = 00, next_state = 00 40 clk = 0, d = 0, led = 0, state = 00, next_state = 00 60 clk = 1, d = 0, led = 0, state = 00, next_state = 00 80 clk = 0, d = 1, led = 0, state = 00, next_state = 01
Actually there is. This is exactly how sequential logic is supposed to work. At every positive edge of the clock the registers store the value at their input and their output changes. This is accomplished by the first always block. Then the combinational always block takes the register outputs and calculates the next cycle's values which are not noticed by the registers till the next clock. With actual logic delays, the calculation of the next state can take almost all the period of a single cycle so correct data may not arrive at the input of the registers till almost the next clock cycle has arrived. If clock arrives after the next state is calculated it is said that the circuit "meets timing".
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.