Re: So, they started synthesizing shared variables?

On Jun 4, 2:38*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 3 Jun 2009 21:26:06 +0000 (UTC), Matthew Hicks wrote:
> >By the way, if you look at the synthesis standards for VHDL (IEEE 1076.6-2004)
> >it clearly says shared variables aren't supported. *So a designer shouldn't
> >be using them even if tool support is there.
>
> I agree.

It is my understanding (perhaps flawed) that the VHDL Synthesis
Standard sets the minimum set of the language to be supported by
synthesis. Shared variables are not required to be supported by a
compliant synthesis tool. If it sets limits on which VHDL constructs/
features CAN be supported, then it becomes a tremendous detriment to
the advancement of synthesis capabilities in general, since no vendor
will support it until it becomes part of the standard, and no vendor
will spend their money to develop a new capability if they cannot use
it any sooner than their competition.

We should seriously consider the adverse effects on the development of
synthesis technology before we advise ourselves and others to avoid
anything not already documented in "the" synthesis standard. Various
individuals and their employers have differing needs WRT portability
across multiple synthesis tools.

As it is, we have an agreement that synthesis results' behavior must
be consistent with simulation (or else at least warnings are issued),
and market competitiveness drives innovation (e.g. multiple clock-edge
processes, handling of signal assignments after the clocked clause,
etc.)

In this case of shared variables, there are serious potential issues
with simulation mismatch, but none that could not be handled by
limiting the synthesizeable subset of shared variables such that
simulation and synthesis will agree. In the bargain, we get the
ability to store more abstract and/or efficient data types(enumerated
types, integers, records, etc.) in an inferred dual port memory than
is possible with instantiated primitives.

Andy

Andy

On Jun 4, 11:38*am, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> IEEE 1076.6 states, "The intent of this version was to include a maximum
> subset of VHDL that could be used to describe synthesizable RTL logic." *
> The standard does include MAY rules which leave open to interpretation how
> certain constructs can be handled by synthesis tools. *Shared is not one
> of those.

Like I said, my understanding of the intent of the standard could be
flawed...

> > If it sets limits on which VHDL constructs
> > features CAN be supported, then it becomes a tremendous detriment to
> > the advancement of synthesis capabilities in general, since no vendor
> > will support it until it becomes part of the standard, and no vendor
> > will spend their money to develop a new capability if they cannot use
> > it any sooner than their competition.
>
> Since no synthesis tool currently meets the requirements, I don't think your
> logic holds. *It seems most vendors use the standards as a guide and make
> language support decisions based upon what the majority of customers want..
> *Remember that vendors can do what they want, the IEEE isn't going to stop
> them, they just can claim IEEE 1076.6 conformance.


So we have a standard that no tool can or does correctly claim
compliance to?

How good a standard is that?

My logic is that because the standard is what it is, no one follows it
verbatim. In turn, because no one follows it verbatim, the standard
must be flawed.

> > We should seriously consider the adverse effects on the development of
> > synthesis technology before we advise ourselves and others to avoid
> > anything not already documented in "the" synthesis standard. Various
> > individuals and their employers have differing needs WRT portability
> > across multiple synthesis tools.
>
> We should also think of the adverse affect of adding features and bloat to
> the tools/language just to meet the needs of a few. *But, this is a religious
> argument akin to RISC vs CISC (<--- computer architectures).

Features sell, but bloat does not (usually); let the market decide.
Standards are there to coax interoperability to the maximum extent
practical. Vendors support and adhere to standards to the extent that
those standards create/support a market, but in the end, the vendors
support the market, as it should be.

What discerns features from bloat in the standard?

> > As it is, we have an agreement that synthesis results' behavior must
> > be consistent with simulation (or else at least warnings are issued),
> > and market competitiveness drives innovation (e.g. multiple clock-edge
> > processes, handling of signal assignments after the clocked clause,
> > etc.)
>
> I wish this were the case. *I have had plenty of experiences with both Verilog
> and VHDL where synthesis differed from simulation, but the tool didn't care
> to inform me of the potential difference, when it could have. *Maybe tool
> vendors should work on perfecting features before adding new, possibly buggy,
> ones.

Bugs exist, and most synthesis vendors will fix bugs related to
simulation mismatch (except in traditional "accepted" ways like
sensitivity lists, etc.) when they are brought to their attention.

I think we can agree on perfecting existing features for sure!

>
> In this thread, I've seen no mention/proof of some unique utility provided
> by shared variables, but lots of problems. *Dual-port ram isn't a good example
> as it is just a case of using search-and-replace on a highly constrained
> version of shared variables.

Shared variables allow inferring dual port rams with different clocks
from arrays of any data type you want. Inferred memories allow storage
of data not easily (if at all) described by SLV, and in a target-
independent manner. Just because you say it is not a good example does
not make it so. There may be flaws in the allowed use of shared
variables (e.g. unprotected access), but the proof of unique utility
is there nevertheless.

I applaud vendors that try to advance the state of the art in
synthesis. It is certainly more than the synthesis standard has
accomplished lately (merely listing the existing capabilities that
vendors had already come up with on their own).

Andy

Andy

Matthew Hicks wrote:

> I wish this were the case. I have had plenty of experiences with both
> Verilog and VHDL where synthesis differed from simulation, but the tool
> didn't care to inform me of the potential difference, when it could
> have.

As a counterpoint, I have coded vhdl and verilog on the edge
for years using modelsim, quartus and ise.
I found only one such bug, and none since.
http://groups.google.com/groups/sear...pdate_regs_bug

What did you find?

-- Mike Treseler

Mike Treseler

Mike Treseler wrote:

> As a counterpoint, I have coded vhdl and verilog on the edge
> for years using modelsim, quartus and ise.
> I found only one such bug, and none since.
> http://groups.google.com/groups/sear...pdate_regs_bug

After rereading that thread, there was a synthesis
warning, so my total of cases breaking
Andy's rule is still zero.

-- Mike Treseler

Mike Treseler

On Jun 4, 1:47*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> Mike Treseler wrote:
> > As a counterpoint, I have coded vhdl and verilog on the edge
> > for years using modelsim, quartus and ise.
> > I found only one such bug, and none since.
> >http://groups.google.com/groups/sear...pdate_regs_bug
>
> After rereading that thread, there was a synthesis
> warning, so my total of cases breaking
> Andy's rule is still zero.
>
> * * * * * * -- Mike Treseler

I've recently been having a back-and-forth with Xilinx about what XST
does when there's a top-level inout port with a VHDL init value of
'Z'. XST makes such a signal init to '0' - in other words, it doesn't
set the INIT value of the tristate-enable register correctly. When
they said they weren't going to fix it, I said that they should at
least throw a warning or error about a sim/synth mismatch. This was
the reply:

<snip>

I have reviewed the notes for case XXXXXX and understand the
situation. In regards to adding a "mismatch" warning in XST, here are
some thoughts:

1) Following synthesis, we expect customers to review the
functionality of the generated netlist by looking at the post-
synthesis netlist simulation, not the behavioral (RTL) simulation.
2) In several circumstances, XST already issues "potential simulation
mismatch" where the post-synthesis netlist simulation can potentially
show a mismatch on actual hardware behavior. As such, a "mismatch
warning" is only applicable against the post-synthesis simulation, not
the behavioral (RTL) simulation.

Please let me know if the information in this e-mail explains the
conclusion to this case.

<snip>

I guess their definition of a mismatch is different from mine.

Dave

Dave

Andy,
> I applaud vendors that try to advance the state of the art in
> synthesis. It is certainly more than the synthesis standard has
> accomplished lately (merely listing the existing capabilities that
> vendors had already come up with on their own).

Your ignorance is both insulting and part of the problem with
getting the standards implemented.

Among other things, 1076.6-2004 has coding styles for implementing
dual port rams with different clocks. For a quick start on this
standard, see the paper or slides on "IEEE 1076.6-2004: VHDL
Synthesis
Coding Styles for the Future" that is at:
http://www.synthworks.com/papers/

If a vendor implements an inferior alternative to what is in
1076.6-2004 (and do not implement what is in 1076.6-2004), I would
not call that advancing the state of the art. I would call it a bad
investment.

Please educate yourself on what is current and make sure your vendors
are implementing the parts you need. Vendors are market driven and
if you fail to do this, they will not implement it.

If you need something that is not in 1076.6-2004, quit whining
and get involved. There are quite a few of you here
who are senior enough that you ought to be participating in standards
development - if not driving the standards development.
Participation is volunteer work. A typical committee
will let anyone with a vested interested participate - ie: a VHDL
user - after all free labor is free. Typically issues are resolved
by consensus. Only when the group is polarized does an official
membership vote come up. If you want to participate in those
you will need to be a member of the appropriate groups (typically
IEEE and DASC).

1076.6-1999 did as you said, listed a baseline set of existing
capabilities that intellectual property developers could depend
on all synthesis tools implementing. Its purpose was not to push
the state of the art - its intent is allow model developers to
claim compliance, and hence, if you purchased a compliant model
you could count an a synthesis tool creating a good implementation.

If not you then who?

Cheers,
Jim

JimLewis

Matthew Hicks wrote:

> Speaking of which, does anyone know of an automated tool that will
> equivalence check the behavior pre and post synthesis designs?

I rarely check post-synthesis, but when I do,
I just compile the gate architecture over the rtl
and rerun the testbench.

-- Mike Treseler

Mike Treseler

JimLewis wrote:

> If a vendor implements an inferior alternative to what is in
> 1076.6-2004 (and do not implement what is in 1076.6-2004), I would
> not call that advancing the state of the art. I would call it a bad
> investment.

Nevertheless, the fact is interesting to a least
one reader of this newsgroup.

> Please educate yourself on what is current and make sure your vendors
> are implementing the parts you need. Vendors are market driven and
> if you fail to do this, they will not implement it.

I hear what you are saying, but consider the designer's point of view.
I live in the moment with tightly budgeted time and money.
I would like like nothing better than to work on logic
description and synthesis all day, but that does not pay the bills.
A few lines of text in the newsgroup is all I can afford.

-- Mike Treseler

Mike Treseler

On Jun 4, 3:42*pm, JimLewis <j...@synthworks.com> wrote:
> Andy,
>
> > I applaud vendors that try to advance the state of the art in
> > synthesis. It is certainly more than the synthesis standard has
> > accomplished lately (merely listing the existing capabilities that
> > vendors had already come up with on their own).
>
> Your ignorance is both insulting and part of the problem with
> getting the standards implemented.
>
> Among other things, 1076.6-2004 has coding styles for implementing
> dual port rams with different clocks. *For a quick start on this
> standard, see the paper or slides on "IEEE 1076.6-2004: VHDL
> Synthesis
> Coding Styles for the Future" that is at:http://www.synthworks.com/papers/
>
> If a vendor implements an inferior alternative to what is in
> 1076.6-2004 (and do not implement what is in 1076.6-2004), I would
> not call that advancing the state of the art. *I would call it a bad
> investment.
>
> Please educate yourself on what is current and make sure your vendors
> are implementing the parts you need. *Vendors are market driven and
> if you fail to do this, they will not implement it.
>
> If you need something that is not in 1076.6-2004, quit whining
> and get involved. *There are quite a few of you here
> who are senior enough that you ought to be participating in standards
> development - if not driving the standards development.
> Participation is volunteer work. *A typical committee
> will let anyone with a vested interested participate - ie: a VHDL
> user - after all free labor is free. *Typically issues are resolved
> by consensus. *Only when the group is polarized does an official
> membership vote come up. *If you want to participate in those
> you will need to be a member of the appropriate groups (typically
> IEEE and DASC).
>
> 1076.6-1999 did as you said, listed a baseline set of existing
> capabilities that intellectual property developers could depend
> on all synthesis tools implementing. *Its purpose was not to push
> the state of the art - its intent is allow model developers to
> claim compliance, and hence, if you purchased a compliant model
> you could count an a synthesis tool creating a good implementation.
>
> If not you then who?
>
> Cheers,
> Jim

I do not have access to the latest non-draft revision either, but
would add that there is a huge difference between a dual port ram that
operates with two independent, asynchronous clocks, and a dual-edge/
clock device such as a DDR flip-flop which requires constrained timing
between clocks for proper operation.

I also read your related paper. Your model in section 6.1 of the
behavior of a dual edged flop is flawed. An asynchronous reset should
be the highest priority (not an elsif to the clock conditions), as is
correctly mentioned in section 2.1. Also, with two simultaneous
clocks, it is a bit pessimistic. The output should not assume 'X'
unless the two data inputs are different and reset is not asserted.
Just like set and hold violations, RTL models need not faithfully
describe clock skew related behavior either.

But relax, I'm not insulted by your ignorance... :^) Seriously, I
truly enjoy and respect your fervent advocation of VHDL, whether I
agree with all of it or not.

I believe the 1999 approach (not the content) of the standard is more
useful than apparently that of the 2004 standard. By implementing a
minimum set of common capabilities, the 1999 standard allows both
model writers, consumers, and tool vendors to ascertain compatibility,
while not restricting progress in the state of the art until the next
version of the standard is published. You seem to believe it is the
standard that sets the state of the art, yet I know there were
synthesis vendors that implemented some if not all of the features in
your paper prior to 2004. Had the 1999 standard prohibited
capabilities in excess of the standards, those vendors would have had
to choose between providing the advanced capabilities desired by their
customers, or claiming compliance with the standard in order to ensure
compatibility with their users. Thankfully, the 1999 standard let them
do both.

Andy

Andy

Brian Drummond wrote:

> I have seen XST using variable assignment rules (immediate not postponed) on
> signals, when the assignments were in a procedure, with the signal passed as an
> inout parameter. Eventually acknowledged as a bug; I don't know if it's fixed in
> ISE11.

Thanks for the tip!
I would not have seen this since I only
use signals in structural entities.

-- Mike Treseler

Mike Treseler