Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > clocked process and sensitivity list

Reply
Thread Tools

clocked process and sensitivity list

 
 
Andy
Guest
Posts: n/a
 
      05-09-2013
Rick,

In the typical pattern for clocked logic with asynchronous reset:

if reset then
-- asynchronous reset/preset assignments to registers
eslif rising_edge(clk) then
-- synchronous assignments to registers
end if;

The elsif keeps the synchronous section from executing while reset is active.

Thus, even if a register is not reset, the register does not keep updating on clock edges while reset is active. In order to correctly implement that behavior in the circuit, a feedback mux (clock enable) is used to retain the previously stored value in the register on every clock edge while reset is active. That feedback mux is extra logic, whether it is in the form of a built-in clock enable or not.

Andy
 
Reply With Quote
 
 
 
 
rickman
Guest
Posts: n/a
 
      05-10-2013
On 5/9/2013 2:55 PM, Andy wrote:
> Rick,
>
> In the typical pattern for clocked logic with asynchronous reset:
>
> if reset then
> -- asynchronous reset/preset assignments to registers
> eslif rising_edge(clk) then
> -- synchronous assignments to registers
> end if;
>
> The elsif keeps the synchronous section from executing while reset is active.
>
> Thus, even if a register is not reset, the register does not keep updating on clock edges while reset is active. In order to correctly implement that behavior in the circuit, a feedback mux (clock enable) is used to retain the previously stored value in the register on every clock edge while reset is active. That feedback mux is extra logic, whether it is in the form of a built-in clock enable or not.


That's what I'm not clear on. I don't see why *anything* is needed to
keep the register in reset as long as the reset is asserted. That's
what the reset does, it holds the FF in reset. I've never seen a
feedback mux added to a FF to implement a reset. Or are you referring
to the internal logic of the FF?

I looked and I couldn't find a transistor based model of a D FF with set
and reset inputs.

--

Rick
 
Reply With Quote
 
 
 
 
Jan Decaluwe
Guest
Posts: n/a
 
      05-10-2013
On 05/10/2013 06:48 AM, rickman wrote:

> That's what I'm not clear on. I don't see why *anything* is needed
> to keep the register in reset as long as the reset is asserted.
> That's what the reset does, it holds the FF in reset. I've never
> seen a feedback mux added to a FF to implement a reset. Or are you
> referring to the internal logic of the FF?


The feedback mux is needed if you *forget* to reset the register
in the 'if reset' clause. In that case, HDL semantics dictate
that the register should keep its previous value during reset,
hence the feedback mux.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com
 
Reply With Quote
 
GaborSzakacs
Guest
Posts: n/a
 
      05-10-2013
Jan Decaluwe wrote:
> On 05/10/2013 06:48 AM, rickman wrote:
>
>> That's what I'm not clear on. I don't see why *anything* is needed
>> to keep the register in reset as long as the reset is asserted.
>> That's what the reset does, it holds the FF in reset. I've never
>> seen a feedback mux added to a FF to implement a reset. Or are you
>> referring to the internal logic of the FF?

>
> The feedback mux is needed if you *forget* to reset the register
> in the 'if reset' clause. In that case, HDL semantics dictate
> that the register should keep its previous value during reset,
> hence the feedback mux.
>
> Jan
>


I've found that Symplify is very good at warning you about
forgetting the reset terms in this case. You get a warning
about feedback mux, followed by "Did you forget..."

I wish XST did that instead of all the useless warnings it
gives...

--
Gabor
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      05-10-2013
On 5/10/2013 5:45 AM, Jan Decaluwe wrote:
> On 05/10/2013 06:48 AM, rickman wrote:
>
>> That's what I'm not clear on. I don't see why *anything* is needed
>> to keep the register in reset as long as the reset is asserted.
>> That's what the reset does, it holds the FF in reset. I've never
>> seen a feedback mux added to a FF to implement a reset. Or are you
>> referring to the internal logic of the FF?

>
> The feedback mux is needed if you *forget* to reset the register
> in the 'if reset' clause. In that case, HDL semantics dictate
> that the register should keep its previous value during reset,
> hence the feedback mux.


I'm not sure that is really needed. If the reset clause is missing an
assignment doesn't it become a clock enable? When the reset is asserted
the clock does not work and the output is held. Still no need for a
feedback mux...

--

Rick
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      05-13-2013
Rick,

We are in complete agreement, but saying the same thing in different ways.

The feedback mux IS A CLOCK ENABLE. If the target architecture supports built-in clock enables on registers, then one will be used to implement the feedback mux.

It may be that at the time during processing when the need for a feedback mux is determined, it may not be known whether the target architecture supports built-in clock enables, thus the message indicates a feedback mux.

Andy
 
Reply With Quote
 
celine
Guest
Posts: n/a
 
      05-22-2013
Le vendredi 10 mai 2013 11:45:56 UTC+2, Jan Decaluwe a écrit*:
> On 05/10/2013 06:48 AM, rickman wrote:
>
>
>
> > That's what I'm not clear on. I don't see why *anything* is needed

>
> > to keep the register in reset as long as the reset is asserted.

>
> > That's what the reset does, it holds the FF in reset. I've never

>
> > seen a feedback mux added to a FF to implement a reset. Or are you

>
> > referring to the internal logic of the FF?

>
>
>
> The feedback mux is needed if you *forget* to reset the register
>
> in the 'if reset' clause. In that case, HDL semantics dictate
>
> that the register should keep its previous value during reset,
>
> hence the feedback mux.
>
>
>
> Jan
>
>
>
> --
>
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>
> Python as a HDL: http://www.myhdl.org
>
> VHDL development, the modern way: http://www.sigasi.com
>
> World-class digital design: http://www.easics.com


Hi all,
Your discussion rises a lot of questions in my head on whether I usually doright or not.
For simple FSMs I usually use a one process description, and when I have some signals that I am sure that are assigned in a state before use I don't reset them. I do this because I work with Xilinx technology and I understoodthat not resetting these signals gives more freedom to the tool:
from Spartan 6 CLB User Guide : "To maximize design flexibility and utilization, use the GSR and avoid local initialization signals."

For instance it gives this kind of process:
--! @brief Receiver Finite State Machine
--! @details The module detects the frame header according to the frame forming protocol, receives the data and check the CRC
p_rx_fsm : process (clk, rst)
constant DFL_NULL : unsigned(rx_ctr_dfl'length-1 downto 0) := (others=> '0');
variable frx_sr : std_logic_vector((maximum(maximum(ADR_L, CRC_L), maximum(CMD_L, DFL_L))*FW_L)-1 downto 0); --!
begin
if (rst = RST_ALVL) then
frx_fsm <= FRX_IDLE;
-- no reset required for frx_dat_cnt
elsif (rising_edge(clk)) then
case frx_fsm is
when FRX_IDLE =>
if (f_rx_wr = '1' and f_rx_d = rx_ctr_sof) then
frx_fsm <= FRX_DFL;
end if;
when FRX_DFL =>
if (f_rx_wr = '1') then
frx_fsm <= FRX_DAT;
frx_dat_cnt <= unsigned(frx_sr(DFL_L*FW_L-1 downto 0))-1;
end if;
when FRX_DAT =>
if (f_rx_wr = '1') then
if (frx_dat_cnt = DFL_NULL) then
frx_fsm <= FRX_EOF;
else
frx_fsm <= FRX_DAT;
frx_dat_cnt <= frx_dat_cnt - 1;
end if;
end if;
when FRX_EOF =>
if (f_rx_wr = '1') then
frx_fsm <= FRX_IDLE;
end if;
when others =>
frx_fsm <= FRX_IDLE;
end case;
end if;
end process p_rx_fsm;


I synthesized it on a Spartan 6 and looked in FPGA Editor what the frx_dat_cnt FF looked like and I saw that no SR pin was used.
I then wrote the above process in two different processes, one for the FSM state in a (clk, rst) process and another for the frx_dat_cnt signal with clk only process.
Both methods gave me exactly the same diagram in FPGA Editor.

So here is my question: is it just an XST interpretation of the VHDL or is it valid in all cases ?
In other words can the code above lead to the same "feedback mux" warning in another synthesizer ?
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      05-22-2013
OK, you implied that both code versions generated the same circuit with respect to set/reset, but you did not say whether they had exactly the same clock enable (feedback mux) logic for the counter. Did they?

The reason I ask is that many years ago, Synopsys FPGA Compiler II (may it rest in peace) did not give warnings about feedback muxes, because it did not insert them!

Synplify, as far as I know (I've been using it for at least 15 years) has always implemented the feedback mux (and issued warnings) in order to createhardware that behaved like the RTL, even while reset was asserted and the clock was still running.

I have no idea whether XST inserts feedback muxes or not, or if it does, whether it issues warnings for them. Any tool that does not insert feedback muxes (usually implemented using the clock enable input on the flip-flop) inthis situation is broken.

As to whether all registers should be reset, there are many design techniques that will work. There are fewer of them that are easily verifiable and are not mistake-prone.

If you reset all registers, it is fairly easy to find out if you missed one(look for register primitives that do not have reset inputs). Verifying that all non-reset registers are initialized otherwise is more difficult to verify, and more prone to mistakes.

When I worked with PALs, we designed state machines that handled asynchronous inputs without separately synchronizing them by controlling the state mapping and ensuring that only one register bit changed in response to that asynchronous input. It worked really well, and saved registers in PALs with very few registers available. I would not recommend using the same technique in FPGAs because it is much harder to verify, much more mistake-prone, and using an extra register or two to explicily synchronize an input before the state machine reads it is no big deal in an FPGA, they have lots of registers.

Also, IIRC, Xilinx FPGAs cannot merge multiple registers into the same CLB (or slice?) that have different reset or clock signals. This means that youare better off resetting all registers to allow maximum freedom in mappingthem to CLBs and slices during P&R.

Andy
 
Reply With Quote
 
celine
Guest
Posts: n/a
 
      05-23-2013
Le mercredi 22 mai 2013 20:53:25 UTC+2, Andy a écrit*:
> OK, you implied that both code versions generated the same circuit with respect to set/reset, but you did not say whether they had exactly the same clock enable (feedback mux) logic for the counter. Did they?


In the case of only one process, the CE pin is directly driven by f_rx_wr alone, but in the equation of the D pin I see my asynchronous reset.
In the case of two separated processes, one with clk an rst, the other withclk only, the D pin has a complicated equation where I don't see my asynchronous reset, and the CE pin has also a complicated equation where the asynchronous reset doesn't appear.

And if I add the initialization on reset of frx_dat_cnt in the one process above, the SR pin is now driven by my asynchronous reset, the CE pin simplyby f_rx_wr, and the D pin has an equation not so much complicated.
I'll go with this one.

In fact I used to systematically initialize all my registers on an externalreset for ten years until I had to design an FPGA with multiple digital filters in a virtex 6 at a quite high speed (240MHz) and I found that the reset line exploded the timing constraints.
So I changed my reset strategy to initialize only the signals that needed it.
Seems that I have gone a little too far this way...

You're right about the fact that Xilinx FPGAs cannot merge multiple registers into the same CLB if they have different control signals (clock, reset but I think also clock enable), but I can not find what is the best for the placer:
avoiding local initialization or having all signals with the same controls.
I understood that the need to avoid local initialization was statistical: if you have a big design the Xilinx placer will fit it more easily if a goodpart of your registers are not initialized because some of the FF resources don't have SR pin at all. I hope I'm not mistaken.
In the case of my little FSM though I think I should initialize all the registers in my process.
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      05-23-2013
It sounds like you are seeing the logic of the feedback mux in the single process version where you don't reset all registers.

There is an easy way to infer different registers with different types of reset (or no reset) from a single process, without feedback muxes.

The key is to code it such that the reset (whatever kind) has priority overclocked logic, but is not exlusive of the clocked logic. Here is an example pattern for defining registers with asynchronous, synchronous, or no reset, all in one process, with no feedback muxes"

process (arst, clk) is
begin
if rising_edge(clk) then
-- synchronous assignments and control statements here
if srst = '1' then
-- synchronous reset assignments here
end if; -- srst
end if; -- clk
if arst = '1' then
-- asynchronous reset assignments here
end if; -- arst
-- don't assign non-reset registers in either reset region
end process;

The reset assignments override the effects of the synchronous asssignments,but they do not keep the latter from executing. Thus registers that are not reset are not overridden by reset either, and behave as if there were no reset at all (and therefore need no feedback mux).

I should note that having asynchronously reset registers feeding other registers that are not held in reset can cause problems with unsynchronized inputs to the non-reset registers. This can be very hard to detect and diagnose without gate level simulation and lots of variation in the onset of the asynchronous reset relative to the clock.

All asynchronous reset control signals should be synchronized to each clockdomain for their deasserting edge only. This makes sure that all asynchronously reset registers come out of reset on the same clock edge. You also need to ensure that the STA tool is checking timing on that path.

Finally, WRT timing on a heavily used asynchronous (or synchronous) reset signal, you can pipeline the reset (you are synchronizing the deasserting edge aren't you?!), and P&R on some tools can replicate the last pipeline stage(s), creating a "reset tree" to ease timing. If the replication is performed in synthesis, I don't know whether the P&R tool will be able to swap loads between the replicated registers to match a given placement, and you cartainly don't want the synthesis register allocations to drive placement. Of course, physical synthesis tools will handle this latter issue automatically.

Andy
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
latch inferrence in clocked process vu VHDL 3 08-14-2006 12:38 PM
The following signals are missing in the process sensitivity list antonio bergnoli VHDL 5 12-18-2005 08:16 PM
Generating combination signal from within clocked clocked block Valentin Tihomirov VHDL 3 10-28-2003 08:56 AM
custom types in process sensitivity list Roger Dahl VHDL 10 10-03-2003 09:03 PM
Are all the signals read in the process should appear in the sensitivity list of the process? walala VHDL 3 09-09-2003 07:47 AM



Advertisments