VHDL expert puzzle

[glen herrmannsfeldt]

In comp.arch.fpga Bart Fox <bartfox@gmx.net> wrote:

rickman wrote:
I think for FPGAs it is very common to specify an async reset to assign
the configuration value of each FF, so I have come to expect async
resets.
Dream on. It ist *not* common to use asnchronous resets on every flipflop.

This is your opinion or the opinion of the academic VHDL book you read.

In synchronous designs an asynchronous reset has no right.
Make an synchronous reset from your asynchronous reset input on one
place, and all will work.

Yes, FPGAs usually have an asynchronous reset.

They at least usually have a reset when they come out of
configuration, which tends to be asynchronous to your clock.

Usually it is easy to also put your own signal into the same
reset line, but you don't have to do that.

So, it is common to have one, it may or may not be common
to use it, other than at the end of configuration.

-- glen

 

[Jan Decaluwe]

On 11/29/2012 09:05 PM, rickman wrote:

What blogs have you done? I'd like to read them.

My MyHDL blog on APP (APP uses no tags, sorry):

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=250236&

My HDL design blog on Sigasi:

http://www.sigasi.com/tag/janhdl

--
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

 

[Jan Decaluwe]

On 11/30/2012 10:10 AM, Thomas Stanka wrote:

On 28 Nov., 09:55, Jan Decaluwe <j...@jandecaluwe.com> wrote:
On 11/28/2012 09:34 AM, Thomas Stanka wrote:
I can only guess, that the simulator the author is using messes up
with this two lines

process(clk,clk_i,lfsr,rst) begin
if rising_edge(clk) then

and execute the code inside the if rising_edge clause also in delta
cycles that have no rising clock edge.

A VHDL simulator broken in this way? Hard to imagine.

I agree it is hard to imagine.
If I would have got a penny for every bug I detected within EDA-Tools,
I would be rich. And there are sometimes issues real hard to believe
that I'm the first to detect. So I'm no longer surprised, if another
major bug happens in EDA-World.

I fully agree with that, and I have been through that experience
myself.

Unfortunately, it looks like were not going to find out
in this case ;-)

--
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

 

[Thomas Stanka]

On 30 Nov., 06:55, Bart Fox <bart...@gmx.net> wrote:

rickman wrote:
I think for FPGAs it is very common to specify an async reset to assign
the configuration value of each FF,  so I have come to expect async
resets.

Dream on. It ist *not* common to use asnchronous resets on every flipflop..

This is your opinion or the opinion of the academic VHDL book you read.

In synchronous designs an asynchronous reset has no right.
Make an synchronous reset from your asynchronous reset input on one
place, and all will work.

At least a asynchronous asserting but synchronous deasserting reset is
very reasonable in synchronous design.

Those who ignore reset when designing for vandor x or a often forget
that good code should be as much as possible vendor independant, as
you never know, when part of your code is reused on different
technology in which you have no guraanteed start-up value at power up.

regards Thomas

 

[Thomas Stanka]

On 28 Nov., 09:55, Jan Decaluwe <j...@jandecaluwe.com> wrote:

On 11/28/2012 09:34 AM, Thomas Stanka wrote:
I can only guess, that the simulator the author is using messes up
with this two lines

   process(clk,clk_i,lfsr,rst) begin
          if rising_edge(clk) then

and execute the code inside the if rising_edge clause also in delta
cycles that have no rising clock edge.

A VHDL simulator broken in this way? Hard to imagine.

I agree it is hard to imagine.
If I would have got a penny for every bug I detected within EDA-Tools,
I would be rich. And there are sometimes issues real hard to believe
that I'm the first to detect. So I'm no longer surprised, if another
major bug happens in EDA-World.

 

[rickman]

On 11/30/2012 12:55 AM, Bart Fox wrote:

rickman wrote:
I think for FPGAs it is very common to specify an async reset to assign
the configuration value of each FF, so I have come to expect async
resets.
Dream on. It ist *not* common to use asnchronous resets on every flipflop.

I didn't say it was common to specify an async reset on *every* FF. I
said it is common to specify an async reset so that the configuration
value is assigned. You can do that on all of the FFs in the design or
you can do that one the twelve FFs that control your design or you can
do it on none. But if you want set a configuration value it is very
common to use an async reset to do that.

I think some or perhaps most vendors now provide a non-portable method
of setting the configuration value and some even will use an
initialization value in the declaration to do that. But I don't believe
this is very portable as of yet.

This is your opinion or the opinion of the academic VHDL book you read.

This is based on my experience with the tools and looking at other's code.

In synchronous designs an asynchronous reset has no right.
Make an synchronous reset from your asynchronous reset input on one
place, and all will work.

I have no idea why you say an async reset won't work in a sync design.
Do I misunderstand your statement? I am talking about FPGAs where every
chip has an async reset during configuration. You can choose to use
this in your design or not, but it is there and it works no matter what
you do. I supposed I should have qualified my statement to FPGAs that
use RAM configuration and have to be configured. There aren't a lot of
true flash based device that come up instantly without a configuration
process.

Rick

 

[Andy]

On Thursday, November 29, 2012 11:55:39 PM UTC-6, Bart Fox wrote:
In synchronous designs an asynchronous reset has no right.

Get around much?

Note: when I refer to "asynchronous reset", I'm referring to an asynchronous reset controlled by a signal whose deasserting edge is properly synchronized to the corresponding clock domain. That way, the registers are released from reset on the same clock cycle, but reset asynchronously.

RAM based FPGA registers are initialized at power up, during configuration. Flash based FPGA registers are not initialized at power up, since there is no configuration step after power up, before the device is off and running..

A synchronous reset will not control register states if the clock does not run. If "no-clock" control is important in your domain, then you'll likely have to use asynchrounous resets.

Most safety-critical design standards require initialization of ALL registers at startup, which may occur more often than power up and/or configuration. The simplest, most reliable and verifiable method of doing so is with an asynchronous reset on every register.

There are plenty of designs where a lot of the registers may not really need a reset. But for all the work "saved" by surgically resetting only those things that "need a reset", you'll waste that much and more determining (and verifying!) which registers are which. Don't borrow trouble if you don't need to.

Granted, there are some FPGA families that have resources that only implement synchronous resets. If you use them, you have no choice, at least on those resources. And if you need "no-clock" control in the same device, you'll need asynchronous resets at least on the outputs.

For those resources that require synchronous reset, I usually synchronize the asynchronous reset for that resource alone, rather than change everything else (that can be changed) to synchronous reset. In other words, I have to have a really good reason NOT to use an asynchronous reset on everything..

Andy

 

[Bart Fox]

Thank you *all* for your replys.
I think the reset topic is now enough clarified.
At least to me

Best regards,
Bart