I am writing a statemachine, which has a generic parameter, and some states existence depends on this. Since I have my states defined in something like an enum (don't know the vhdl term for it), I wonder if I can define this enum depending on the generic somewhat like so:
generic(x: bool); -- in the entity
....
architecture ...
if x then generate
type states_t is (State1, State2, State3ifX)
else
type states_t is (State1, State2)
end generate;
variable state : states_t;
begin
case state is
....
if x then generate
when State3ifX =>
...
end if;
end case
end architecture;
Do I have to carry the dead weight (logic for state3, danger to drop into it (does not matter in my case since I do not expect radiation), additional bit since ceil(ld(3))=2 > ld(2)=1), or is there a possibility to strip unnecessary state(s)?
(In my case there are several states that could be stripped, however seperate architectures are not worth while the effort)
you can define the "states"-type in a process that is optionally generated using a generic. see a reference example below:
entity blabla is
generic(sel: std_logic := '0');
port(
...
architecture Behavioral of blabla is
begin
q1: if sel='0' generate
p: process(clk)
type t_state is (s1, s2, s3);
variable state: t_state;
begin
if rising_edge(clk) then
...
end if;
end process;
end generate;
q2: if sel='1' generate
p: process(clk)
type t_state is (s1, s2);
variable state: t_state;
begin
if rising_edge(clk) then
...
end if;
end process;
end generate;
I can't think of a way to achieve what you need.
On the upside, your concern about having to "carry the dead weight (logic for state3, danger to drop into it)" is not something you need to worry about - the synthesizer will optimise the logic away, so the state register will only be as big as it needs to be for the states you can actually reach.
I know its an old tread but still a hit on google so Im adding how Im doing it
label: if x generate
declarations <- put types, signals & attribures here !!!!
begin
ur code
end generate label;
You might want to consider second architecture or even simpler just a different entity - just another vhd file with slightly different name (like _x1, then _x2)
I find "genercis system" not really practical in more advanced cases (to much bloat-code to write), and then u might use different synthezisers so two archoitecture with one entity might not work, generate with decalrations inside might not work.... I would create different vhd for that - it will work in all the cases)
Cheers
Related
I'm watching a beginner tutorial on VHDL. The lecturer says that it's bad practice to not include an else-condition inside a "process" block because it will create a latch and is bad for timing in advance circuits. He said that including an else-condition will create a mux instead and is better to use in most case.
Why is that?
snippet from lecture video
Why is a latch design bad for timing and what makes the mux design better?
The point is to make VHDL code that results in the design you want, and the risk is that you will inadvertently create a latch.
There are several basic constructions in VHDL, that can illustrate this.
Mux by process with if-then-else, can be made with this code:
process (all) is -- Mux
begin
if sel = '0' then
z <= a;
else
z <= b;
end if;
end process;
Mux by process with if-then and default assign, can be made with this derived code:
process (all) is -- Mux
begin
z <= b; -- Default b, thus for sel = '1', since no overwrite
if sel = '0' then
z <= a;
end if;
end process;
However, if you want to make a mux, then a better coding style is by continuous assign with this code:
z <= a when (sel = '0') else b;
Finally, what can lead to a latch with a process, is if the resulting output is not assigned in all branches of the code. That can occur, if the if-then does neither have an else, nor a default assign to the output, like this code:
process (all) is -- Latch
begin
if en = '1' then
q <= d;
end if;
end process;
So a good rule when designing combinatorial logic using a process, is to have an initial line that makes a default assignment to the resulting output, for example just assing undefined 'X'. A latch is thereby avoided, and functional verification should catch the undefined 'X', if this is a bug.
Also, remember to check the syntheis report for warnings about created latches, since that is most likely a bug in the design.
Why is it when we try to synthesize incomplete if statements in VHDL the synthesizer uses latches instead of flip-flops?
An explanation from a digital/circuit standpoint would be greatly appreciated.
The premise of the question is wrong. The latch is not inferred instead of a flip-flop.
Flip-flops are inferred every time a signal goes through a clocked process even with an incomplete IF statement. For example, the following code infers a flip-flop:
process(clock) is
begin
if rising_edge(clock) then
if (A) then
B <= C;
end if;
end if;
end process;
Latches are inferred only in combinatorial logic processes when there is an incomplete IF statement. This is due to the fact that an incomplete if statement requires the storage of information which is not possible with the simpler elements of combinatorial logic (wires and gates).
Short answer: because the behaviour of a latch matches that of an incomplete IF. A register does not.
if (A)
B = C;
If the condition A is true and C changes, the output B follows the input immediately. If A is false B keeps it value. This behavior of the IF statement corresponds with the behavior of a latch. Thus a latch is what is generated.
You can not generate this behaviour with a register.
Unfortunately, I can't answer to oldfart (not enough reputation), so technically the short answer is kinda correct.
But, the long answer has different variables: what kind of design do you implement, what tool do you use and what platform is your target.
E.g. Quartus II 16.1, Cyclone V CSXFC6D6F31C6 such code:
library ieee;
use ieee.std_logic_1164.all;
entity d_latch_test is
port
(
signal clk : in std_logic;
enable : in std_logic;
sr_in : in std_logic;
sr_out : out std_logic
);
end entity;
architecture rtl of d_latch_test is
begin
process (clk)
begin
if (rising_edge(clk)) then
if (enable = '1') then
sr_out <= sr_in;
end if;
end if;
end process;
end rtl;
Quartus Synthesis would not tell you that your code is a latch, but it is a D-flip-flop
But! It has asynchronous input.
So basically you can do a flip-flop from if-statement.
A lot of VHDL structures has the option for an optional_label before the declaration, but what is this label used for?
Here is a process declaration example from vdlande showing the option for a label:
optional_label: process (optional sensitivity list)
-- declarations
begin
-- sequential statements
end process optional_label;
Labels are used for identification.
IEEE1076-2008 for instance says
7.3.1 General
A configuration specification associates binding information with component labels representing instances of a given component declaration.
consider the next piece of code:
entity e is end entity;
architecture a of e is begin
process is begin wait; end process;
foo: process is begin wait; end process;
end architecture;
In simulation (with modelsim) this will show as
I.e. label foo is fixed, while the other process is just assigned some reference, in this case the line number. Is you are using attributes, configurations, aliases, etc, you often need to refer to specific objects and their location. You need fixed names for that.
If you look at the IEEE1076-2008 standard, you can see that about every statement can have a label: if, case, loop, etc.
You can use labels to identify things in a simulator as JHBonarius says, but there are other uses for labels, too:
i) Identifying the end of a long block of code, eg
my_if : if A = B then
-- lots of lines of code
end if my_if;
ii) keeping track of complicated code, eg
my_if_1 : if A = B then
my_if_2 : if A = B then
my_if_3 : if A = B then
my_if_4 : if A = B then
my_if_5 : if A = B then
my_if_6 : if A = B then
-- blah blah blah
end if my_if_6;
end if my_if_5;
end if my_if_4;
end if my_if_3;
end if my_if_2;
end if my_if_1;
iii) It is usually a good idea to label assertions so that they can be easily identified in an EDA tool, eg :
enable_check : assert enable = '1';
iv) If you label something, then you can decorate it with an attribute (ie attach some metadata for some other EDA tool), eg something like this might stop a synthesiser optimising something away:
attribute KEEP : boolean;
attribute KEEP of g0:label is TRUE;
...
g0 : CLK_EN port map ( ...
(The exact names will depend on the synthesiser.)
I have a piece of code that needs to be executed after another. For example, I have an addition slv_reg2 <= slv_reg0 + slv_reg1; and then I need the result subtracted from a number.
architecture IMP of user_logic is
signal slv_reg0 : std_logic_vector(0 to C_SLV_DWIDTH-1); --32 bits wide
signal slv_reg1 : std_logic_vector(0 to C_SLV_DWIDTH-1);
signal slv_reg2 : std_logic_vector(0 to C_SLV_DWIDTH-1);
signal slv_reg3 : std_logic_vector(0 to C_SLV_DWIDTH-1);
signal flag : bit := '0';
begin
slv_reg2 <= slv_reg0 + slv_reg1;
flag <= '1';
process (flag)
begin
IF (flag = '1') THEN
slv_reg3 <= slv_reg0 - slv_reg2;
END IF;
end process;
end IMP;
I haven't tested the code above but I would like some feedback if my thought is correct. What is contained in the process doens't need to run in sequence, how can I make this part also run in parallel?
In summary, I have two chunks of code that need to be executed in sequence but the code itselft should run in parallel.
--UPDATE--
begin
slv_regX <= (slv_reg0 - slv_reg1) + (slv_reg2 - slv_reg3) +(slv_reg4 - slv_reg5); --...etc
process(clk) -- Process for horizontal counter
begin
if(rising_edge(clk)) then
if(flag = 1) then
flag <= 0;
end if;
end if;
end process;
It's concurrent, not parallel. Just use intermediate signals
I am afraid your thought process about VHDL is not entirely correct. You acknowledge the first assignment happening 'in parallel', but you must realise that the process is also running concurrently with the rest of the statements. Only what happens inside a process is evaluated sequentially - every time any of the signals in the sensitivity list change.
I need to make a lot of assumptions about what you need, but perhaps you're just after this style:
c <= a + b;
e <= d - c;
The signal e will contain d-(a+b) at all times. If you don't immediately understand why - this is where the difference between concurrent and parallel comes in. It is being continuously evaluated - just like if you'd hook the circuit up with copper wires.
If what you actually need is for something to happen based on a clock - you're really not there yet with your example and I recommend looking up examples and tutorials first. People will be happy to help once you provide VHDL code that is more complete.
Issues in your example
Assuming you are intending to write synthesisable VHDL, there several problems with your code:
Your process sensitivity list is not correct - you would either make it sensitive to only a clock, or to all the input signals to the process.
You are both initialising your 'flag' to '1' and assigning it a '0' in concurrent code, that doesn't make sense.
Signals ..reg0 and ..reg1 are not assigned. If they are inputs, don't declare them as signals.
You have named your signals as if they are anonymous numbered 'registers', but they are not registers, just signals: wires! (if ended up with this style because you are comparing to Verilog - let me argue that the Verilog 'reg' regularly don't make sense as they often end up not being registers.)
Try it
I haven't tested the code above but
You really should. Find code examples, tutorials, go and play!
How do I write a code segment which would evaluate a generic and create (or not create) an attribute accordingly?
Example :
if G_MY_GENERIC then
attribute my_attribute_typ : string;
attribute my_attribute_typ of signal_having_an_attr : signal is "value";
else
--nothing is created
end if;
It is perfectly possible to write something similar to that, but the attribute will only be visible in the scope of the generate statement.
g_something: if test_condition generate
attribute my_attribute_typ : string;
attribute an_attribute of my_attribute_typ: signal is "value";
begin
-- attribute is visible in this scope
p_my_process: process(clk)
begin
-- attribute is also visible here
end process;
end generate;
-- but not here
Instead you have to use something like the following to conditionally set an attribute (cumbersome, but achieves the result):
signal asvRam : svRam_at(0 to gc_nFifoDepth-1) := (others => (others => '0'));
type svStr_at is array(boolean) of string(0 to 10);
constant c_svRamStyle : svStr_at := (false => " ", true => "distributed");
attribute ram_style : string;
attribute ram_style of asvRam : signal is c_svRamStyle(gc_bDistributedRam);
We talked more generalized conditional compilation in the IEEE VHDL Working Group. The debate was heated. Some wanted a compile time approach (similar to 'C') and some an elaboration time approach. Compile time approach works well in C because constants are also compile time objects, however, in VHDL, a compile time approach will not understand things in the VHDL environment, and hence, using a generic is not an option. OTOH, the compile time option would probably give you vendor name, tool type (simulator, synthesis, ...), ...
I have added your code as a requirement to the proposal page. It is at: http://www.eda.org/twiki/bin/view.cgi/P1076/ConditionalCompilation
If you are willing to share additional insight on your application, I would like to add that to the proposal also.
Basically: this is exactly how VHDL does not work. In VHDL you declare your intent to use specific bits of hardware, and then the synthesizer attempts to connect those bits of hardware. Any semblance of dynamically creating hardware like for ... generate loops are essentially just a semblance: syntactic sugar to take the pain away.
What you can do is conditionally assign to signals/variables:
process (sig1, sig2, enable) is
begin
if enable = '1'
then
out <= sig1;
else
out <= sig2;
end if;
end process;