RE: [Embedlets-dev] Re: HDL

[Christopher S. <cs...@oo...>]

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> >> Differences between Hardware and Software are simply not existent.
> >> Show
> >> me the if they exist.
> >>
> >> Mostly the hardware today _is_ in fact Software. Not only the
> >> micrcodes, but in the process of development and construction. I am
> >> not
> >> able to construct any thing more complicated than a binkenlight
> >> without
> >> Software in it.
> >>
> > Agreed that there is a great deal of overlap. The general concept of a
> > declarative language that generates an operational system is also a
> > common
> > theme. As I stated in an earlier post there are a number of synergies.
> > The
> > key differences that I have picked up on are:
> >
> > 1. The Embedlets specification is about how to package Java objects so
> > that
> > they behave like hardware, with defined inputs and outputs, triggers
> > (events) etc, while retaining an object oriented environment within the
> > component.
>
> This met the behavioral concept in VHDL.

Here is a brief clip of VHDL:

entity latch is
  port (s,r: in bit;
        q,nq: out bit);
end latch;

I do not know many programmers who would recognize this as an object
oriented contruct, especially one that they would like to learn.

>
> > HDL is about generating fast and compact systems from predefined
> > components
> > (logical building blocks etc).
>
> This maps to the architectural concept of VHDL, the entities.
>
> > 2. The Embedlets specification defines extended services that allow
> > embedded
> > systems to integrate with enterprise systems, each other and hardware
> > in
> > standardized re-usable ways.
> >
> > You could do this in HDL but you would have to come up with the same
> > type of
> > services and standards.
>
> Here met VHDL JHDL. We may take the wave and define services (which i
> expect mostly FSM are in the so called 'embedded world' - not the fair
> ;) and standards in a emerging standard way - in pure Java.

Services are not related to Finite State Machines but rather underlying
infrastructure support: communication, persistence, lookup etc. As  I said
there is no doubt that they could be implemented in HDL or its variants -
but then you would be re-inventing the wheel in a domain that is outside
that of the original scope of HDL.

>
> > 3. The embedlet configurations are based on XML which provides a
> > parsable,
> > self documenting, open standards format.
>
> uppps, where is the task for providing the schema (xsd) for this?
A formal schema will 'fall out' of the XML configuration design quite
naturally and I would expect it to be a part of the specification.

> Whithout this, XML degrades to a textfile with '<', '<' and '/'.
That happens to have 100s of readily available tools, overwhelming industry
acceptance, a natural object representation format, WEB enabling technology
(xslt), volumes of documentation and training material...

>
> > HDL is dependent on the 'C' preprocessor and compiler and requires
> > learning
> > (yet) another language.
>
> Wrong, have a look at the opensourced JHDL project.
I have - it is an improvement but will still get a lot of resistence from
OO/Java developers. For example the statement:

  or_o( and(a,b), and(a,cin), and(b,cin), cout ); /* cout is output */

indicates that there is a syntax defined by the or_o() and and() super class
Logic methods which is overlaying the native Java syntax. This seems to have
flattened Java OOP to many static function calls in the Logic class. An XML
based represenation would retain the OO recognizable structure and
declarations without requiring a new syntax, just a new XML schema eg:

<SupplyAnd Name="SupplyGate" Identity="AND_GATE_01"
Class="com.oopscope.opc.node.BinaryAnd" Inverting="true">
  <Inputs Size="2" Identity="GATE_01_INPUTS"
Class="com.oopscope.opc.persistence.PersistentCollection">
	<Input href="INVERTER_01"/>
	<Input href="INVERTER_02"/>
  </Inputs>
</SupplyAnd>

This also supports dynamic configuration - something that would be very
difficult using a language based tool such as HDL and its variants.

>
> > The Embedlets space is different and compelling enough to justify a
> > distinct
> > specification utilizing enterprise standards and techniques.
>
> This is the exact sentence my marketing manager say to me if he want to
> have it proprietary, not standard compliant, or simply does not know
> what argument should provide enough power otherwise.
>
> Sorry, for being frankly :)

The statement was made to indicate that there is enough interest among the
participants and (we believe) the general development community to warrant
the effort. It will benefit from constructive input from a variety of
related fields, which is always welcome and will lead to my suggestion
below.

>
> > My suggestion is that we look for commonality and areas where
> > interoperablility is possible. JHDL looks like a move in that
> > direction.
>
> yeap, last sentence. But enough todo even, it is Version 0.3.
>
> bax
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>