Clocked Process, but Outside of the Clocked IF...

R

Rick C

Guest
This is a good example of how rusty I am. I like to use variables where I can because it localizes the scope. So I have an accumulator that is incremented in a clocked process. Then I want to use a portion of the result depending on a control, much like a mux, but no register is required, just combinatorial logic.

process (rst, clk) is
variable...
begin
if (rst)
... initialization stuff
elsif (rising_edge(Clk)) then
accum := (accum + input) mod modulus;
end if;

if (condition) then
output <= accum / 2;
else
output <= accum;
end if;

end process;

I want to say that while the non-clocked IF will be synthesize as combinatorial logic and not a register. In the simulation it will look like a register because the value will change on the rising edge of the clock because accum is a variable and so updated right away. Accum will be registered, but output will not be.

Or will accum not be registered and output registered??? I guess I could try some synthesis to see what happens.

I\'m pretty sure I\'ve done this sort of thing before and it works fine.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
 
On 2020-09-15 14:54, Rick C wrote:
This is a good example of how rusty I am. I like to use variables where I can because it localizes the scope. So I have an accumulator that is incremented in a clocked process. Then I want to use a portion of the result depending on a control, much like a mux, but no register is required, just combinatorial logic.

process (rst, clk) is
variable...
begin
if (rst)
... initialization stuff
elsif (rising_edge(Clk)) then
accum := (accum + input) mod modulus;
end if;

if (condition) then
output <= accum / 2;
else
output <= accum;
end if;

end process;

I want to say that while the non-clocked IF will be synthesize as combinatorial logic and not a register. In the simulation it will look like a register because the value will change on the rising edge of the clock because accum is a variable and so updated right away. Accum will be registered, but output will not be.

Or will accum not be registered and output registered??? I guess I could try some synthesis to see what happens.

I\'m pretty sure I\'ve done this sort of thing before and it works fine.
Based on my experience, I would be inclined to make accum a signal and
assign output in a separate concurrent statement like this:
output <= (accum / 2) when condition else accum;

That way accum will be registered for sure and output will not.

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.
signal accum : ... ;

process (clk) is
begin
if (rising_edge(Clk)) then
if (rst)
... initialization stuff
else
accum <= (accum + input) mod modulus;
end if;
end if;
end process;


Charles Bailey
 
On Tuesday, September 15, 2020 at 10:12:14 PM UTC-4, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
This is a good example of how rusty I am. I like to use variables where I can because it localizes the scope. So I have an accumulator that is incremented in a clocked process. Then I want to use a portion of the result depending on a control, much like a mux, but no register is required, just combinatorial logic.

process (rst, clk) is
variable...
begin
if (rst)
... initialization stuff
elsif (rising_edge(Clk)) then
accum := (accum + input) mod modulus;
end if;

if (condition) then
output <= accum / 2;
else
output <= accum;
end if;

end process;

I want to say that while the non-clocked IF will be synthesize as combinatorial logic and not a register. In the simulation it will look like a register because the value will change on the rising edge of the clock because accum is a variable and so updated right away. Accum will be registered, but output will not be.

Or will accum not be registered and output registered??? I guess I could try some synthesis to see what happens.

I\'m pretty sure I\'ve done this sort of thing before and it works fine.

Based on my experience, I would be inclined to make accum a signal and
assign output in a separate concurrent statement like this:
output <= (accum / 2) when condition else accum;

That way accum will be registered for sure and output will not.

The expression is a bit more complex than that and I was trying to limit the scope of signals/variables. But you are probably right. This likely would be confusing to anyone seeing this code in the clocked process.

I am pretty sure the assignment to output will not be clocked. The reset code is not clocked. But clarity is also important.


Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.
signal accum : ... ;

process (clk) is
begin
if (rising_edge(Clk)) then
if (rst)
... initialization stuff
else
accum <= (accum + input) mod modulus;
end if;
end if;
end process;

This is an FPGA where you get an async reset whether you like it or not. I will need to go through the design and either remove the resets or connect them to local reset generators that aren\'t sensitive to the timing of the reset release, like a shift register where only one bit changes at a time. Then it won\'t matter if the different FFs come out of reset at different times.

Again, I\'m forgetting much of what I used to know well. Now that I think about it, I seem to recall the initialization in the declarations are what translate to the config reset states. At least that is true in the technologies I\'ve used. Need to check their synthesis user guide. Yes, they show the signal declaration setting the config value of the FF. I don\'t have any other signal to drive the RST signal anyway. To make sure it comes out of config properly, I need to provide a global reset with local re-sync to the clock I suppose.

Maybe that\'s overkill. Very little of this device runs on the main clock rate. It\'s all clocked by the main clock, but the enables are very slow. There\'s only a small amount of circuitry that will be sensitive to the timing of the config reset release.

Thanks for making me think about this.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
 
On 16/09/2020 03:12, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
...

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.

Yes on ASIC\'s an asynchronous reset requires extra logic but this does
not generally apply to FPGA\'s. Although I haven\'t checked I believe
Microchip still recommends async reset for their FPGA\'s.

I would advice you read up on the Wire satellite mission which in effect
was lost due to the use of a Synchronous instead of an Asynchronous
reset (Actel FPGA).

Hans
www.ht-lab.com
 
On Wednesday, September 16, 2020 at 2:59:10 AM UTC-4, HT-Lab wrote:
On 16/09/2020 03:12, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
..

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.

Yes on ASIC\'s an asynchronous reset requires extra logic but this does
not generally apply to FPGA\'s. Although I haven\'t checked I believe
Microchip still recommends async reset for their FPGA\'s.

I would advice you read up on the Wire satellite mission which in effect
was lost due to the use of a Synchronous instead of an Asynchronous
reset (Actel FPGA).

Hans
www.ht-lab.com

Interesting. I would point to the designers as failing in two of the three conclusions drawn, failure to account for startup values and not reading all the documentation. I\'m guilty of the second myself since it can be overwhelming to start in on a mountain of reading for a new device. But then I don\'t design multi-million dollar satellites.

I don\'t agree with the third conclusion that an async reset is required. The issue with the sync reset is the absence of a clock. That is the real issue, although I suppose a clock can fail. But if the clock has failed, what good will the reset do?

I\'m good with only using sync resets. My purpose in using an express async reset has always been to show the intent for the configuration state of logic, but that can also be done with initialization of signals.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
 
Damn! I find resetting an FPGA design to be one of the harder tasks in working with them. I recall my first design I included both a sync reset and an async reset. The software guy asked me why so many resets (there\'s also the configure input on the chip).

So I now have a design that has battery backup, so it will need to boot up configuration once and run indefinitely. The processor is treated as suspect at all times, so no reset is provided for him to mess up the FPGA with.

I really need to remove all the reset code and find another way to specify the initial state of all the FFs. Using an initialization in the declaration seems to be recommended by at least some users and in app notes. But when a signal is an output it is less clear how well that will work. The signal can be initialized in the output declaration, but I\'ve seen some indication this might actually be treated as a conflict like a second driver to the assignments that actually drive the output.

Anyone know? Will this work in both simulation and synthesis?

ENTITY MotorControl IS
GENERIC (
CLK_MHZ : REAL := 32.0E6
);
port (
Clk : in std_logic;
Rst : in std_logic;
Mot_Restart : in std_logic;
Mot_Overcur : in std_logic;
Mot_Off : out std_logic := \'0\' -- <<<<
);
end MotorControl;

I\'m worried if it will work with Gowin devices even if it works with other tool brands. Seems their synthesis tool is in house. All their examples are Verilog where the register has to be declared separately from the output.. I guess that\'s what I\'ll need to do for VHDL as well.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
 
On 16/09/2020 18:30, Rick C wrote:
On Wednesday, September 16, 2020 at 2:59:10 AM UTC-4, HT-Lab wrote:
On 16/09/2020 03:12, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
..

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.

Yes on ASIC\'s an asynchronous reset requires extra logic but this does
not generally apply to FPGA\'s. Although I haven\'t checked I believe
Microchip still recommends async reset for their FPGA\'s.

I would advice you read up on the Wire satellite mission which in effect
was lost due to the use of a Synchronous instead of an Asynchronous
reset (Actel FPGA).

Hans
www.ht-lab.com

Interesting. I would point to the designers as failing in two of the three conclusions drawn, failure to account for startup values and not reading all the documentation. I\'m guilty of the second myself since it can be overwhelming to start in on a mountain of reading for a new device. But then I don\'t design multi-million dollar satellites.

I don\'t agree with the third conclusion that an async reset is required.

Third conclusion? My advice is not to assume sync reset is the best
solution for all FPGAs or designs.

The issue with the sync reset is the absence of a clock. That is the
real issue, although I suppose a clock can fail. But if the clock has
failed, what good will the reset do?

It is not a clock failure which is the issue as that is an easy one to
detect. The real problem are power supplies, clock domain and clock
stability issues as they can all make your synchronous reset misbehave.
In addition most reset input signals (push button, POR etc) are
asynchronous so meta stability measures (async asserted, sync negated)
are recommended.

If you are working on some user appliance then pressing the reset button
twice is not a big deal but you are working on a ventilator right?

Hans
www.ht-lab.com


I\'m good with only using sync resets. My purpose in using an express async reset has always been to show the intent for the configuration state of logic, but that can also be done with initialization of signals.
 
On Thursday, September 17, 2020 at 4:33:37 AM UTC-4, HT-Lab wrote:
On 16/09/2020 18:30, Rick C wrote:
On Wednesday, September 16, 2020 at 2:59:10 AM UTC-4, HT-Lab wrote:
On 16/09/2020 03:12, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
..

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.

Yes on ASIC\'s an asynchronous reset requires extra logic but this does
not generally apply to FPGA\'s. Although I haven\'t checked I believe
Microchip still recommends async reset for their FPGA\'s.

I would advice you read up on the Wire satellite mission which in effect
was lost due to the use of a Synchronous instead of an Asynchronous
reset (Actel FPGA).

Hans
www.ht-lab.com

Interesting. I would point to the designers as failing in two of the three conclusions drawn, failure to account for startup values and not reading all the documentation. I\'m guilty of the second myself since it can be overwhelming to start in on a mountain of reading for a new device. But then I don\'t design multi-million dollar satellites.

I don\'t agree with the third conclusion that an async reset is required..

Third conclusion? My advice is not to assume sync reset is the best
solution for all FPGAs or designs.

I mean in the report. They had three conclusions. The third is \"there should be a direct asynchronous path from the reset input for initialising the device state, being independent of any clock activity\".


The issue with the sync reset is the absence of a clock. That is the
real issue, although I suppose a clock can fail. But if the clock has
failed, what good will the reset do?

That would be covered by the same issues that must be managed by the start up consideration. Many FPGAs do not specify behavior at the very start of the power up process. So no assumptions can be made about any control outputs and must be independently managed. This will also deal with any reset related issues in the absence of a clock.


It is not a clock failure which is the issue as that is an easy one to
detect. The real problem are power supplies, clock domain and clock
stability issues as they can all make your synchronous reset misbehave.
In addition most reset input signals (push button, POR etc) are
asynchronous so meta stability measures (async asserted, sync negated)
are recommended.

Power supply issues result in no controls being specified to work, including async resets.

The async nature of power on reset release is always an issue in FPGAs and must be managed. The real problem is that even if the global power on reset is synchronous, the propagation can be slow enough to not meet the synchronous setup time. So it must be managed locally, but only on certain critical circuits.


If you are working on some user appliance then pressing the reset button
twice is not a big deal but you are working on a ventilator right?

Yes, but it doesn\'t power up/down. It has battery backup and the FPGA may never be powered down. But of course it has to be designed to power up correctly. That will be local sync resets that start state machines and such. Essentially, each critical circuit needs to be immune to problems from the release of the global async reset. Not hard to do at all. Much of my design relies on timing enables. If these enables are not released for a couple of clock cycles after the global async reset is released that\'s 99% of the design already. Then the remaining circuity needs to be handled on its own.

Other than power up, there are no resets because there is no trusted source of a reset. Maybe building something into the touch pad would be a good idea??? Maybe not.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
 
On 17/09/2020 18:28, Rick C wrote:
On Thursday, September 17, 2020 at 4:33:37 AM UTC-4, HT-Lab wrote:
On 16/09/2020 18:30, Rick C wrote:
On Wednesday, September 16, 2020 at 2:59:10 AM UTC-4, HT-Lab wrote:
On 16/09/2020 03:12, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
..

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.

Yes on ASIC\'s an asynchronous reset requires extra logic but this does
not generally apply to FPGA\'s. Although I haven\'t checked I believe
Microchip still recommends async reset for their FPGA\'s.

I would advice you read up on the Wire satellite mission which in effect
was lost due to the use of a Synchronous instead of an Asynchronous
reset (Actel FPGA).

Hans
www.ht-lab.com

Interesting. I would point to the designers as failing in two of the three conclusions drawn, failure to account for startup values and not reading all the documentation. I\'m guilty of the second myself since it can be overwhelming to start in on a mountain of reading for a new device. But then I don\'t design multi-million dollar satellites.

I don\'t agree with the third conclusion that an async reset is required.

...

> I mean in the report. They had three conclusions. The third is \"there should be a direct asynchronous path from the reset input for initialising the device state, being independent of any clock activity\".

Did you understand how this satellite failed and how an async reset
could have saved it?

The issue with the sync reset is the absence of a clock. That is the
real issue, although I suppose a clock can fail. But if the clock has
failed, what good will the reset do?

Ough, you might want to think about that last statement again.

> Power supply issues result in no controls being specified to work, including async resets.

Really?

Either you still don\'t understand asynchronous resets or you simply
looking for an argument which I don\'t have time for, sorry.

Hans.
www.ht-lab.com


The async nature of power on reset release is always an issue in FPGAs and must be managed. The real problem is that even if the global power on reset is synchronous, the propagation can be slow enough to not meet the synchronous setup time. So it must be managed locally, but only on certain critical circuits.


If you are working on some user appliance then pressing the reset button
twice is not a big deal but you are working on a ventilator right?

Yes, but it doesn\'t power up/down. It has battery backup and the FPGA may never be powered down. But of course it has to be designed to power up correctly. That will be local sync resets that start state machines and such. Essentially, each critical circuit needs to be immune to problems from the release of the global async reset. Not hard to do at all. Much of my design relies on timing enables. If these enables are not released for a couple of clock cycles after the global async reset is released that\'s 99% of the design already. Then the remaining circuity needs to be handled on its own.

Other than power up, there are no resets because there is no trusted source of a reset. Maybe building something into the touch pad would be a good idea??? Maybe not.
 
On Monday, September 21, 2020 at 3:28:16 AM UTC-4, HT-Lab wrote:
On 17/09/2020 18:28, Rick C wrote:
On Thursday, September 17, 2020 at 4:33:37 AM UTC-4, HT-Lab wrote:
On 16/09/2020 18:30, Rick C wrote:
On Wednesday, September 16, 2020 at 2:59:10 AM UTC-4, HT-Lab wrote:
On 16/09/2020 03:12, Charles Bailey wrote:
On 2020-09-15 14:54, Rick C wrote:
..

Also, based on many years of experience doing timing analysis on
million+ latch ASICs, I would highly recommend using synchronous rather
than asynchronous resets wherever possible.

Yes on ASIC\'s an asynchronous reset requires extra logic but this does
not generally apply to FPGA\'s. Although I haven\'t checked I believe
Microchip still recommends async reset for their FPGA\'s.

I would advice you read up on the Wire satellite mission which in effect
was lost due to the use of a Synchronous instead of an Asynchronous
reset (Actel FPGA).

Hans
www.ht-lab.com

Interesting. I would point to the designers as failing in two of the three conclusions drawn, failure to account for startup values and not reading all the documentation. I\'m guilty of the second myself since it can be overwhelming to start in on a mountain of reading for a new device. But then I don\'t design multi-million dollar satellites.

I don\'t agree with the third conclusion that an async reset is required.

..

I mean in the report. They had three conclusions. The third is \"there should be a direct asynchronous path from the reset input for initialising the device state, being independent of any clock activity\".

Did you understand how this satellite failed and how an async reset
could have saved it?

I understand, but the failure was in the design process, not the lack of an async reset. The idea of adding an async reset to every design ignores the fact that not all designs have the same requirements. In my case the FPGA already provides a power on reset that is independent of an outside clock working on an internal clock. Other than that no reset is required. Adding any sort of additional reset uses logic for no benefit.


The issue with the sync reset is the absence of a clock. That is the
real issue, although I suppose a clock can fail. But if the clock has
failed, what good will the reset do?

Ough, you might want to think about that last statement again.

Please tell me what else was working or not working when the clock failed. These are system issues, not simply a requirement for an async reset. This one solution doesn\'t fix every problem.


Power supply issues result in no controls being specified to work, including async resets.

Really?

Yes, if the power supply is out of spec there is no guarantee any of the logic will work correctly, reset or not. If the power supply signal goes below the voltage of the inputs the device will go into latchup. What good is a reset signal then?


Either you still don\'t understand asynchronous resets or you simply
looking for an argument which I don\'t have time for, sorry.

If you would actually try to discuss the issue rather than being silly about insisting on an async reset without basing the opinion on reason and facts, maybe we could have a discussion.

Sorry you weren\'t interested in discussing the topic.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209
 

Welcome to EDABoard.com

Sponsor

Back
Top