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, muchlike a mux, but no register is required, just combinatorial logic.
process (rst, clk) isupdated right away. Accum will be registered, but output will not be.
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
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.
On 2020-09-15 14:54, Rick C wrote:much like a mux, but no register is required, just combinatorial logic.
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,
updated right away. Accum will be registered, but output will not be.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
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;
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.
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:mountain of reading for a new device. But then I don't design multi-million dollar satellites.
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
I don't agree with the third conclusion that an async reset is required.
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 16/09/2020 18:30, Rick C wrote:mountain of reading for a new device. But then I don't design multi-million dollar satellites.
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
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?
On 17/09/2020 18:28, Rick C wrote:a mountain of reading for a new device. But then I don't design multi-million dollar satellites.
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
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.
On Thursday, September 17, 2020 at 4:33:37 AM UTC-4, HT-Lab wrote:mountain of reading for a new device. But then I don't design multi-million dollar satellites.
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
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".
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?
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 itmust be managed locally, but only on certain critical circuits.
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 resetIf 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
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 18:20:27 |
Calls: | 6,646 |
Calls today: | 1 |
Files: | 12,190 |
Messages: | 5,327,231 |