Recently I was reading a Verilog study book. I finally realized that a Verilog file may not be synthesizable, because some Verilog statements are for simulation use only. But I'm too lazy to make one file to create a module and another to simulate it. Can I mix both up in the same file, and if so, how?
Electronic – create a verilog file to both simulate and synthesize
fpgasimulationsynthesisverilog
Related Solutions
always @(posedge clk or negedge reset) begin
case (!reset)
0: begin
// Assign 0 to things
end
1: begin
// Do stuff
end
endcase
Notice that you have the reset logic inverted.
You have sensitivity to negedge reset
, implying you should reset when the reset
signal goes low.
But then you actually set things to zero if !reset
is low, meaning reset
is high.
This basically means you are trying to create flip-flops with sensitivity to two different clock signals, which isn't synthesizable. The synthesis tool probably tried to create an equivalent function from combinatorial logic, which is why it suggested you to expand the sensitivity list.
I think this was the source of your problem.
The conventional way to create flip-flops with low-active syncronous reset is
always @(posedge clk or negedge reset) begin
if(!reset) begin
// set things to zero
end
else begin
// do things
end
end
First, when designing FPGA's we mostly just think about "resources" rather than "space". Resources are things like routing resources, logic cells, RAM blocks, multiply-add blocks, etc. It looks like you're concerned about minimizing the use of routing resources, and willing to use more logic cells to do that.
Really, the best way to answer your questions (and first off, to find out if trading logic for routing is the right thing to do) is to synthesize your first-draft design and look at the resource usage. If routing resources are close to fully utilized, then start looking for ways to reduce them. If logic is close to fully utilized, then start looking for ways to make the opposite kind of optimization.
Let's assume we have a module X that controls if modules A, B, ... N are logically on/off, that is, it sends signals to them to signal if they should be enabled or disabled.
The typical way to do this in an FPGA is to just let all N modules run continuously. If only one out of the N are used at any given time, then you can often just use a mux to select which of the outputs gets used by downstream logic. If the combinations of modules being "disabled" is more complex, then you often just tell downstream logic to ignore those inputs, rather than disabling the module generating them.
You normally don't have separate wires for enable
and disable
like you proposed in your 1st option. Just one wire that is (for exampel) high when the module should be enabled and low when it should be disabled.
Although of course having separate enable
and disable
lines that only pulse intermittently is also possible if you have a good reason to do it. They would typically drive the SET and RESET inputs of a flip-flop to generate the actual enable
signal.
In the previous problem, we assumed that we were going to enable/disable modules logically. In case we wanted to turn them on/off physically to save power, is there a way to do that, or do we just have an if statement inside the module?
FPGAs don't typically have provisions to selectively power down parts of the fabric.
It is possible to use enable pins to reduce power consumption (due to reduced switching), but if the amount of logic being disabled is not a very large fraction of your design, it's not likely to significantly improve your power budget.
Also, you need to show that at any given time at least some known fraction of the logic is disabled, since you'll have to design your power supplies and heat sinking to account for the worst-case operating conditions anyway.
Let's assume we have a decoder module X that sends commands to modules A, B, ..., N. I see 3 ways to do this:
Your option 1 (a seperate signal for each command) is a very common FPGA coding style. Similarly, one-hot encoding is typically recommended by synthesis tool vendors for encoding state machine states.
Best Answer
Most synthesis tools support pragmas. For example, in the following code, the and gate will not be considered for synthesis.
Also, predefined macros can also be used:
Both of the above are tool specific, so you'll have to see which predefined macros your tool supports, or you could define a macro yourself and use that.
If you'd like something more robust and not as tool specific, you can use a conditional generate statement that nicely splits simulation and synthesis: