> To the DASC:
>
> I would like to add my "well done" to Victor's appreciative note. Apparently, John Williams does not have a real understanding about what the standardization process is all about. To wit:
>
> John Williams says,
> >>>>
>
> In reality, I doubt Victor ar anyone else can identify more than 10%
> in the standards approved which were NOT rephrasings or reaffirmations
> of functionality already implemented in currently existing EDA tools.
>
> <<<<
>
> The standardization process demands that a standard be representative of current processes. Standards do not lead one into new territory, but capture the essence of what the industry can do. Standards make order out of potential chaos by looking at the many solutions and coming up with a good cross-section that is acceptable to all. Making a standard is a consensus process.
>
I'm sorry Ron but you must have been out of the picture for a while. This
standard is NOT representative of current processes. Exemplar has far exceeded
this standard in every respect. Standards should lead us into new territory.
That is exactly what the VHDL 87 standard did. Nobody had tools for it back then
but the standard was still created. Or have you forgotten? And yes,
it did take a while for the tools to appear but appear they did. In fact, in a
few years we will probably be balloting some type of type of SDL. Should we blow
that off because it is new?
I also don't recall reading anywhere in the IEEE Standards bylaws where it says
that the standard be representative of current processes.
Also, why does everybody keep mentioning chaos??? Its not chaos that is the
problem, its compatibility across tools, some of which are dramatically cheaper
then others. Standards bring all the vendor's to parity to benefit the consumer.
If we, as consumer's force the vendors to produce inferior products to meet a
low level standard then we both suffer. We don't get what we
need and they don't get the *income they require to innovate in the area's that
we allow them to differentiate themselves in -- which ultimately benefit us.
I wish that somebody would just figure out that the synthesis should be easy to
come to agreement on. The real value has and always will be the algorithms which
optimize circuits. Those don't need standardization because we don't access them
directly. Wouldn't it be great if some EDA voice came out and asked the
synthesis vendor's to just publish their scanner/parser so that
becomes the standard? Wouldn't they still achieve a huge value from their
proprietary optimization methods. Anybody think of that??
The IEEE has always considered their documents to be *the* standard. No document
has been or ever will be the standard. It is the software that is the true
standard because that is what we operate to do our jobs. True standardization
will only occur when each of us uses the exact same piece of software.
>
> John Williams says,
> >>>>
>
> My question is, why should we so glowingly praise the hardening
> of the arteries we so far have accomplished?
>
> My answer is indirect: Let's get over the need to show we
> know everything.
>
> <<<<
>
> The fact that some work was designated as "future" actually indicates that industry is not ready to reach consensus on those items. However, the identification of those areas provides a basis for industry to move forward from a defined base.
Perhaps the problem here is not the standard but the standard's process. The
means by which the IEEE achieves its consensus is out dated, slow,
and doesn't take in a large enough number of participants to adequately
represent the consumer's needs.
> Let's not knock down the good and difficult work that was accomplished by Bhasker and his group. They have put a stake in the ground where no standard existed before. We can move forward from there; as all standards are, and should be, a living object, at least in the EDA arena.
I suspect that John Williams indicates that honesty is never a bad policy. Sure,
Bhasker and crew worked hard and under difficult circumstances. No doubt they
should be commended for their effort -- I commend them for it. Bhasker discussed
the extreme difficulty in putting standards together using volunteers last
January. It was an eye opener for me. I think it is possible to
praise the workers and still publicly acknowledge that we are a long way away.
As I have stated before leadership is what was missing here. Not hard work.
> Congratulations to the RTL team.
>
> Ron Waxman
>
> ========================================
> At 11:04 AM 09/23/1999 -0700, John Michael Williams wrote:
> >Hi All.
> >
> >I don't want to put anyone on the spot, but I think Victor's comments
> >here
> >were premature.
> >
> >Whereas "What we are doing is always just the right thing" is a good
> >theme
> >while digging foxholes or charging fortified enemy positions, it is
> >not really necessary while building bridges in peacetime.
> >
> >
> >Victor Berman wrote:
> >>
> >> ... This specification goes
> >> a long way toward achieving that goal and correcting the current chaotic
> >> situation where the semantics of synthesis is tool defined rather than
> >> language based.
> >
> >In reality, I doubt Victor ar anyone else can identify more than 10%
> >in the standards approved which were NOT rephrasings or reaffirmations
> >of functionality already implemented in currently existing EDA tools.
> >
> >For example, the synthesis Backus-Naur was in the form of crossings-out
> >and corrections of the Backus-Naur of preexisting standards,
> >corrected--NOT REPLACED--and now hailed as new. What's wrong here?
> >
> >> There is certainly an opportunity to be discouraged by how long
> >> and difficult it is to define and standardize a specification like this one,
> >> but this opportunity is better spent on celebrating the significant
> >> progress that has been made and looking forward to more good work
> >> in the future.
> >>
> >
> >This is very true: Yhe good work was in the features rescheduled
> >and put off for the future. After those features have been
> >implemented and made available commercially, presumably there will
> >be enough happy tool developers on the committees that they will
> >be approved for standardization. Why take a chance on software
> >design without code already available to cut-and-paste? It would
> >be a tragic embarassment to have to say, "We don't know how to do
> >that part of the standard yet!"
> >
> >My question is, why should we so glowingly praise the hardening
> >of the arteries we so far have accomplished?
> >
> >My answer is indirect: Let's get over the need to show we
> >know everything.
> >
> >Let's do the standard the way it should be done, and ALLOW
> >EDA developers to admit to those sections they can not yet make
> >available for the customer. In my opinion, this will be
> >good for EDA tool users and for business, too!
> >--
> > John
> > jwill@pacbell.net
> > John Michael Williams
> >
> >
> -------------------------------------------------------------------->>>>
> Ronald Waxman r.waxman@computer.org
> EDA Standards Consulting voice: (+1)(703) 620-2117
> Principal Scientist at UVa, retired fax: (+1) (703) 620-6716
> 2369 Paddock Lane mobile: (+1) (703) 509-0372
> Reston, VA 20191-2607
--Tim Davis Aspen Logic
EM: TimDavis@AspenLogic.com WB: www.aspenlogic.com/~timdavis PH: +1 (303) 426-0800 FX: +1 (303) 426-1023