Hot answers tagged

4

As FPGAs* do NOT support on-chip tri-state drivers you can not implement option-1 on them. You should go for the MUX version. *At least I don't know any FPGA of reasonable size which still has them.


3

NO. Latches are generated for the "assigned to" signals. You could define these, as Dave Tweed said, as output signals. Latches appear if you have combinatorial logic where a variable does not get assigned a value in every possible path. You find latches by checking every if, else, case, when etc. to see if at that point in the code a value has been ...


3

For some reason, if i sets the control range to 0 to 10, it works, but I can't explain why, it's like before a length overflow occurred in buff signal. It can be demonstrated with a a simple testbench: library ieee; use ieee.std_logic_1164.all; entity paralelsequencial_tb is end entity; architecture foo of paralelsequencial_tb is signal clk: ...


2

Style I'd never let this pass through code review, but not because you want to write a lookup table. Combinatorial logic definition using signals was relevant in the 1980s, but we're 4 decades later now. The whole concatenation/lookup really belongs in a process, like so: p_main: process(a, b, c) variable together : std_logic_vector(2 downto 0); begin ...


2

Your ports are of "std_logic_vector" type but the internal signal Out5bit is unsigned. Numeric_std doesn't provide an "+" operator that adds the first type and returns the other, so no matching "+" operator is visible. Three approaches to fix this: 1) Type conversions from std_logic_vector to unsigned and back again. Ugly, but clearly describes what you ...


1

The best you can do is to use the high period from the clock to 'gate' a compare signal. But you might still end up with some 'runt' pulses. This is what might get: This is where the 'runt' pulses can come from: At the beginning your individual dat1 bits will have tiny delays to get to the final value. Thus your compare might not straight go to 1 or 0 ...


1

Why aren't these 3 ways of doing this the same in this case? The behaviour of the three codes is NOT identical. Number one: R <= R + 1 when (rising_edge(clk)) else "00000000" when (rising_edge(btn_center)) else R; R has to change on a rising clock edge, but if there is no rising clock edge it has to reset on a rising btn_center edge. ...


Only top voted, non community-wiki answers of a minimum length are eligible