[Flip-fl0p 4]

44 минуты назад, MrGalaxy сказал:

 

А при чём тут реализация на триггерах ?

Мы разговаривали про язык VHDL. 

Ещё раз объясню. Вы обьявили ведро объемом 16 литров. Если вы туда наливаете 17 литров - вам средство симуляции сообщает об этом. И это правильно.

Хотите чтобы само обнулялось - тогда применяйте типы bit_vector/std_logic_vector/std_ulogic_vector/unsigned. 

[dvladim 0]

3 часа назад, MrGalaxy сказал:

Выкладываю для тех, для кого VHDL - только язык программирования. Как ещё наглядно объяснить - не знаю...

У вас вообще счетчик не синхронный. В ПЛИС так делать не принято (мягко говоря).

[MrGalaxy 9]

6 часов назад, Flip-fl0p сказал:

А при чём тут реализация на триггерах ?

Мы разговаривали про язык VHDL. 

Не важно как описать, важен конечный результат.

6 часов назад, Flip-fl0p сказал:

Хотите чтобы само обнулялось - тогда применяйте типы bit_vector/std_logic_vector/std_ulogic_vector/unsigned. 

Зачем, если всё корректно работает? Для внутренней организации ПЛИС без разницы, биты - они и в Африке биты. Это я и пытаюсь донести. Вроде, очевидные вещи, а никто не верит.

В параллельной ветке я лишь спросил про возможность подобной реализации на Верилоге, а про то, что так можно делать на vhdl, я знаю. А меня пытаются убедить не верить своим глазам.

4 часа назад, dvladim сказал:

У вас вообще счетчик не синхронный. В ПЛИС так делать не принято (мягко говоря).

 

signal a, b : std_logic;


process(clk)
begin
  if rising_edge(clk)
    then a<= not a;
  end if;
end process;

process(a)
begin
  if rising_edge(a)
    then b <= not b;
  end if;
end process;

 

[andrew_b 14]

56 минут назад, MrGalaxy сказал:

Вроде, очевидные вещи

Для тех, кто далеко не первый год в плисоводстве, очевидно противоположное.

Что же касается вашего счётчика… Это лишнее подтверждение тому, что вы не понимаете фундаментальных вещей.

 

 

[blackfin 16]

17 hours ago, dvladim said:

У вас вообще счетчик не синхронный. В ПЛИС так делать не принято (мягко говоря).

+1

 

Asynchronous_(ripple)_counter:

Quote

11.1.2 Asynchronous Design Hazards

Some designers use asynchronous techniques such as ripple counters or pulse generators in programmable logic device (PLD) designs, enabling them to take “shortcuts” to save device resources. Asynchronous design techniques have inherent problems such as relying on propagation delays in a device, which can vary with temperature and voltage fluctuations, resulting in incomplete timing constraints and possible glitches and spikes. Some asynchronous design structures depend on the relative propagation delays of signals to function correctly. In these cases, race conditions arise where the order of signal changes affect the output of the logic. Depending on how the design is placed and routed in the device, PLD designs can have varying timing delays with each compilation. Therefore, it is almost impossible to determine the timing delay associated with a particular block of logic ahead of time. As devices become faster due to process improvements, the delays in an asynchronous design may decrease, resulting in a design that does not function as expected. Relying on a particular delay also makes asynchronous designs difficult to migrate to different architectures, devices, or speed grades.

 

The timing of asynchronous design structures is often difficult or impossible to model with timing assignments and constraints. If you do not have complete or accurate timing constraints, the timing-driven algorithms used by your synthesis and place-and-route tools may not be able to perform the best optimizations, and the reported results may not be complete. Some asynchronous design structures can generate harmful glitches, which are pulses that are very short compared to clock periods. Most glitches are generated by combinational logic. When the inputs to the combinational logic change, the outputs exhibit several glitches before they settle to their new values. These glitches can propagate through the combinational logic, leading to incorrect values on the outputs in asynchronous designs. In a synchronous design, glitches on the data inputs of registers are normal events that have no negative consequences because the data is not processed until the next clock edge.

 

11.2.1.1 Avoid Combinational Loops

Combinational loops are among the most common causes of instability and unreliability in digital designs. Combinational loops generally violate synchronous design principles by establishing a direct feedback loop that contains no registers. Avoid combinational loops whenever possible. In a synchronous design, feedback loops should include registers. For example, a combinational loop occurs when the left-hand side of an arithmetic expression also appears on the right-hand side in HDL code. A combinational loop also occurs when you feed back the output of a register to an asynchronous pin of the same register through combinational logic.

 

Figure 210. Combinational Loop Through Asynchronous Control Pin

 

11.2.2.3 Avoid Ripple Counters

To simplify verification, avoid ripple counters in your design. In the past, FPGA designers implemented ripple counters to divide clocks by a power of two because the counters are easy to design and may use fewer gates than their synchronous counterparts. Ripple counters use cascaded registers, in which the output pin of one register feeds the clock pin of the register in the next stage. This cascading can cause problems because the counter creates a ripple clock at each stage. These ripple clocks must be handled properly during timing analysis, which can be difficult and may require you to make complicated timing assignments in your synthesis and placement and routing tools.You can often use ripple clock structures to make ripple counters out of the smallest amount of logic possible. However, in all Intel devices supported by the Intel Quartus Prime software, using a ripple clock structure to reduce the amount of logic used for a counter is unnecessary because the device allows you to construct a counter using one logic element per counter bit. You should avoid using ripple counters completely.

См: Quartus® Prime Standard Edition Handbook, page 777.

[des00 25]

@MrGalaxy вы действительно не понимаете парадигму языка, на котором работаете. Вместо этого, с усердием, достойным лучшего применения, спорите

[Maverick_ 15]

4 hours ago, des00 said:

@MrGalaxy вы действительно не понимаете парадигму языка, на котором работаете. Вместо этого, с усердием, достойным лучшего применения, спорите

+1 Согласен

[MrGalaxy 9]

8 часов назад, des00 сказал:

, спорите

действительно,  чего я влез, тем более что нет никакого желания спорить...

[vt313 0]

В 08.04.2020 в 06:36, MrGalaxy сказал:

Не важно как описать, важен конечный результат.

Зачем, если всё корректно работает? Для внутренней организации ПЛИС без разницы, биты - они и в Африке биты. Это я и пытаюсь донести. Вроде, очевидные вещи, а никто не верит.

В параллельной ветке я лишь спросил про возможность подобной реализации на Верилоге, а про то, что так можно делать на vhdl, я знаю. А меня пытаются убедить не верить своим глазам.

 

signal a, b : std_logic;


process(clk)
begin
  if rising_edge(clk)
    then a<= not a;
  end if;
end process;

process(a)
begin
  if rising_edge(a)
    then b <= not b;
  end if;
end process;

 

Всякая проблема имеет несколько простых и всем понятных неправильных объяснений. 

В ПЛИС есть специально выделенные линии clk, rst. Их не много. Совсем не факт, что синтезатор заведет Ваш сигнал "a" на эти линии. Желательно  специально указать это действие. 

[Flip-fl0p 4]

8 часов назад, vt313 сказал:

Всякая проблема имеет несколько простых и всем понятных неправильных объяснений. 

В ПЛИС есть специально выделенные линии clk, rst. Их не много. Совсем не факт, что синтезатор заведет Ваш сигнал "a" на эти линии. Желательно  специально указать это действие. 

Правильно. Для этого применяются всякие примитивы типа тактовых буферов. Или атрибуты если есть нужные.