I have a source qualifier with 4 ports in this exact order: A, B, C, D.
I have to process the data so that using only one expression and NO spaghetti links I get to a target with the same ports but in the following order: A, D, B, C.
How could I do that?
This requirement is... dumb. Yet, if you still need to achieve it, just create an expression with the following port definitions:
in_A
in_B
in_C
in_D
out_A = in_A
out_D = in_D
out_B = in_B
out_C = in_C
Now, all your links will be parallel, no crossings.
PS.
Please tell the recruiter to come up with something that actually makes sense...
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.
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 problem with this piece of code, "s" doesn't appear in "Floorplan I/O pins" because it is never used why? How could I solve this problem?
entity tempModule is
port (s : in std_logic;
ss : out std_logic);
end tempModule;
architecture tempModule_Behavioral of tempModule is
begin
process(s)
begin
if (s = '1') then
ss <= '1';
end if;
end process;
end tempModule_Behavioral;
Are you sure that pin s and ss are in your UCF?
One thing you could try would be to just do:
ss <= s;
That would ensure that it would not be optimized away.
The VHDL design describes a module that drives 'U' (Uninitialized) on output
ss from power up and until input s is '1', and then output ss is '1'
from then on.
Since the 'U' (Uninitialized) value output in the beginning on ss can be
implemented as any value by the simulation tool, it may be implemented as
'1', whereby the output ss is just trivial '1', and the input s is
thereby unused.
So it sounds like the synthesis tool behaviour is as can be expected, but maybe
the module behavior is to be modified, since the modules does not appear to do
anything useful.
You are implementing a COMBINATIONAL circuit, so the COMPLETE truth table must be described.
However, you have only specified ss for s='1', thus the compiler understands that it is OK to simply keep the output high all the time, in which case s is not actually needed.
To specify ss for all possible values of s, try to end your if statement with "else", like this:
if ...;
elsif ...;
else ...;
I am designing a project on Modelsim VHDL where I use two components. Depending on a control input I'll choose which component to use:
If control=0 then the inputs will be ported to the first component.
If control=1 the inputs will be ported to the second component.
However, a compilation error appeared when I wrote "U1: port map..." in an if statement
(can't put an structural statement inside a sequential architecture).
Any ideas how to solve my problem?
There are two possible interpretations to your question:
Situation #1: Your design uses only one of two possible components at a time. The decision of which component to use is done at compile time, i.e., it is written in your code and is impossible to change after the circuit is synthesized.
Situation #2: Your design uses the two components concurrently, and you use a signal to select dynamically one of the possible outputs.
Each situation has a different solution.
Solution for situation #1: Use a generic in your entity, and an if-generate statement in your architecture body. Here is an example:
entity component_selection_at_compile_time is
generic (
-- change this value to choose which component gets instantiated:
COMPONENT_SELECT: in integer range 1 to 2 := 1
);
port (
input: in integer;
output: out integer
);
end;
architecture rtl of component_selection_at_compile_time is
component comp1 is port(input: in integer; output: out integer); end component;
component comp2 is port(input: in integer; output: out integer); end component;
signal comp1_output, comp2_output: integer;
begin
c1: if COMPONENT_SELECT = 1 generate
u1: comp1 port map (input, output);
end generate;
c2: if COMPONENT_SELECT = 2 generate
u2: comp2 port map (input, output);
end generate;
end;
Solution for situation #2: Create a third component. This component will be a wrapper, and will instantiate both of your original components. In certain cases, you can even assign the same inputs to both components. Then use a select signal to chose which output will be forwarded to outside the wrapper.
entity wrapper is
port (
wrapper_input: in integer;
wrapper_output: out integer;
component_select: in integer range 1 to 2
);
end;
architecture rtl of wrapper is
component comp1 is port(input: in integer; output: out integer); end component;
component comp2 is port(input: in integer; output: out integer); end component;
signal comp1_output, comp2_output: integer;
begin
u1: comp1 port map (wrapper_input, comp1_output);
u2: comp2 port map (wrapper_input, comp2_output);
wrapper_output <= comp1_output when component_select = 1 else comp2_output;
end;
The answer to this question depends on the nature of the control input. If the control input is a way of configuring your design at compile time, the desired functionality can be achieved using generics and generate statements. Otherwise....
Based on the way you have worded your question, I am going to assume that this is not the case. I will assume that your design must support both at different times, with the same compiled design. In that case, you must instantiate both components, and route data to both components and somehow indicate to those components when the data is valid and must be processed. For example:
en1 <= not control;
en2 <= control;
U1 : entity work.design1
port map (
data => data,
en => en1
);
U2 : entity work.design2
port map (
data => data,
en => en2
);
In this example, we have created 2 new signals, en1 and en2 which are '1' to enable each of the components at the appropriate time. In each of the instantiated entities, you need to look at the en input to determine when the input data is valid.
Note: Your design may already have a signal similar to en1 or en2. For example, you may have a generic "bus" which has a valid signal, indicating when data on the bus is valid. In that case, you can add something like this, gating the enable signal with bus_valid:
en1 <= not control and bus_valid;
en2 <= control and bus_valid;
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