Hi,
There was a statement in the unapproved minutes of 6/13 that suggested
that between SV or VHDL and SC, one cannot have the "same type" because
the definition has to exist in 2 places, i.e., in HDL as well as a C++
header file. Of course this is an implementation truth, but the
requirement is not weakened and nor is the semantic concept of same
type. I can still define the semantic equivalence rules necessary to
have a single source for a shared type definition. Again, your
implementation mileage may vary, but I can translate that definition to
its equivalent definition between HDL and SC automatically and rebuild
code and recompile HDL automatically, too. At the other end of the
implementation spectrum, I may require the HDL and SC header to be both
manually written and declared to be the same and require the user to
keep his entire design properly up to date manually. Better tools will
make less work for the users, but a good definition of what
is correct is what we are aiming at, and not how
to build the tools.
Under cover of the implementation, I will eventually have an HDL
package and C++ header file and perhaps some mapping information that
asserts the correspondence between types within them. A user can
probably always defeat the desired semantics by compiling object code
with a header that is inconsistent with the associated VHDL types and
still link them together. The user has to do some work to make those
kind of problems happen and ignore some aspects of what (s)he is
required to do. The key point is that those actions lead to erroneous
conditions and we should call them that. The desire to achieve
transparency and strong typing across SC and the HDLs must remain an
important goal.
Regards, John
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Wed Jun 27 11:37:04 2007